| 05:22.30 | *** join/#gnu-kbsd tarzeau_ (n=gurkan@bee.ethz.ch) |
| 05:23.42 | NCommander | hey tarzeau_ |
| 07:46.21 | *** join/#gnu-kbsd kaeso (n=luca@debian/developer/kaeso) |
| 09:05.33 | tarzeau_ | aurel32: ok |
| 09:40.37 | tarzeau_ | NCommander: now what? |
| 09:41.13 | NCommander | tarzeau_, well, I imported the snapshot into dak, now I need to hack up wanna-build to properly handle setting binNMU status when reading in from quinn-diff |
| 09:41.50 | NCommander | I already figured out how w-b does binNMU internally, I just need to write the code and properly test it :-) |
| 09:42.56 | tarzeau | great |
| 09:59.45 | NCommander | It's sad that you seem the only one really enthusastic about a kfreebsd release :-P |
| 13:35.58 | *** join/#gnu-kbsd NCommander (n=mcasadev@cpe-69-207-147-100.rochester.res.rr.com) |
| 14:35.46 | *** join/#gnu-kbsd otavio (n=otavio@debian/developer/otavio) |
| 14:41.30 | aurel32 | NCommander: I have just got a discussion about dak with Ganneff |
| 14:41.46 | aurel32 | I send me the scripts used by amd64 when it was not included in the main archive |
| 14:41.55 | NCommander | ?? |
| 14:42.03 | NCommander | (I fixed import-archive which is how I got everything working) |
| 14:42.18 | NCommander | so if you want to migrate from mini-dak to dak, its possible |
| 14:42.31 | aurel32 | there should be enough to sync the testing/unstable/experimental from the official archive |
| 14:42.36 | aurel32 | http://amd64.debian.net/~joerg/scripts/ |
| 14:42.53 | aurel32 | there is no need to develop new scripts |
| 14:43.16 | NCommander | Oooh, I love him now |
| 14:43.17 | aurel32 | yes, that's my plan to switch to dak, but probably not before a few eeks |
| 14:43.18 | aurel32 | weeks |
| 14:43.35 | aurel32 | the problem is to make sure we do not lose any features |
| 14:43.43 | NCommander | I can give you my patch code to get import archive working |
| 14:44.06 | aurel32 | why not, yes, but dak is not yet install on debian-ports.org |
| 14:44.36 | NCommander | well, I want to get it in the offical dak archive |
| 14:44.43 | NCommander | But I have someone of an allegeric reaction to git |
| 14:44.46 | aurel32 | do you know if we can do something such as "unreleased" with dak ? |
| 14:44.49 | NCommander | Yeah |
| 14:44.59 | NCommander | Well |
| 14:45.00 | aurel32 | because that's really something we need |
| 14:45.07 | NCommander | Wait, you'll have to explain unreleased more to me |
| 14:45.24 | NCommander | dak requires some internal consistantly, it would reject binaries that don't match the source version |
| 14:45.38 | aurel32 | unreleased is a special suite to put packages that we are patching |
| 14:45.43 | NCommander | Right, this I know |
| 14:45.49 | NCommander | But how does it vary from a normal suite |
| 14:45.55 | aurel32 | so it need to handle the source + binary |
| 14:46.07 | NCommander | WHy not simply have unreleased for each architecture |
| 14:46.09 | aurel32 | so it means we can have different source for each architecture |
| 14:46.16 | NCommander | unreleased-hurd-i386/unreleased-kfreebsd-* |
| 14:46.25 | tarzeau | where can i donwload the d-i gnu/kfreebsd cd? |
| 14:46.35 | NCommander | tarzeau, d-i doesn't exist for kfreebsd yet |
| 14:46.38 | tarzeau | but... |
| 14:46.42 | NCommander | (I've just gotten into playing with its configuration scripts) |
| 14:46.51 | NCommander | The current installer is based off the freebsd installer |
| 14:47.25 | NCommander | (from what I can gather, its sorta a rather nasty hack to hook the configure part of install packages working) |
| 14:47.25 | aurel32 | NCommander: well seems to looks ok, but that would mean one more change to /etc/apt/sources.list |
| 14:47.33 | aurel32 | and I would try to avoid that |
| 14:48.01 | NCommander | aurel32, ah, use a unionfs mount to join all the unreleased pools into one |
| 14:48.02 | NCommander | ;-) |
| 14:48.18 | aurel32 | the problem is not the pool |
| 14:48.23 | aurel32 | is the Packages.gz |
| 14:48.33 | NCommander | oh |
| 14:48.34 | NCommander | right |
| 14:48.35 | NCommander | d'ho |
| 14:48.38 | NCommander | ... *d'oh |
| 14:48.54 | NCommander | Well, internally, dak just uses apt-ftparchive with filelists to generate packages.gz |
| 14:49.23 | NCommander | It probably won't be that hard to mange dak make-suite-file-lists to do what you need it to do |
| 14:49.41 | aurel32 | I'll have a closer look in the next weeks |
| 14:49.56 | aurel32 | I will travel a lot in the next days/weeks |
| 14:49.58 | NCommander | Be warned. Abandon all documentation for all those entire here ;-) |
| 14:50.12 | aurel32 | so I won't have that much time |
| 14:50.24 | NCommander | I can answer dak questions, I've done two installations |
| 14:50.31 | NCommander | (one on my laptop, and one on my ftp-master) |
| 14:51.15 | NCommander | why the desire to replace mini-dak with dak? |
| 14:51.38 | aurel32 | because it seems m68k will need it |
| 14:51.59 | aurel32 | given all what you said about lenny sync |
| 14:52.07 | NCommander | *nods* |
| 14:52.12 | NCommander | Well, dak isn't that picky about the pool |
| 14:52.23 | NCommander | You could get mini-dak and dak to co-exist without too many issues as long as they each managed seperate repos |
| 14:52.35 | NCommander | (have mini-dak handle unreleased, and dak handle u/t/s/os) |
| 14:52.45 | aurel32 | that would be really to complicated |
| 14:52.53 | aurel32 | that means two incoing queues and so on |
| 14:52.57 | NCommander | yeah |
| 14:53.58 | NCommander | well, to mimic the current setup, mirror-split will have to be done for the pool |
| 14:53.59 | NCommander | That's easy |
| 14:54.28 | NCommander | Unreleased, hrm |
| 14:55.02 | NCommander | each architecture uses different source versions in unreleased I take it? |
| 14:56.13 | NCommander | (out of curosity, how is disk space looking on d-ports? I heard it was kinda full) |
| 15:03.51 | aurel32 | yes |
| 15:04.06 | NCommander | Ew. |
| 15:04.30 | aurel32 | at some point it was full, yes, but now we have changed the machine |
| 15:04.42 | aurel32 | so we have still 200GB free |
| 15:04.44 | NCommander | I dunno if you follow d-devel |
| 15:04.49 | NCommander | We just got our two weeks notice :-) |
| 15:04.51 | aurel32 | not really those days |
| 15:05.14 | NCommander | Ah |
| 15:05.24 | NCommander | So you know we're being removed from the mirror |
| 15:05.31 | NCommander | (I posted a nice long rant about it but meh :-P |
| 15:05.36 | aurel32 | well one other features of unreleased, is that a package upload with a higher version in unstable automatically remove the package from unreleased |
| 15:05.45 | aurel32 | yes I know about that |
| 15:06.05 | NCommander | so dak is going to need some extending to meet all the requirements of mini-dak |
| 15:06.08 | guillem | aurel32: snapshot used to take a lot of the space on gnuab most of the time |
| 15:06.57 | guillem | and obsolete as well, don't remember if that's being purged automatically now though |
| 15:07.00 | NCommander | Well, I just want to make sure mini-dak isn't suitable for our needs. While I would perfer dak, simply because that's what the ftp-masters us, it may still be realistic to stay with mini-dak |
| 15:07.40 | NCommander | doesn't want to affect the kfreebsd/hurd ports any more than necessary |
| 15:07.53 | NCommander | Although I'm making good progress on the kfreebsd lenny release work ;-) |
| 15:09.15 | aurel32 | guillem: no, that's not purged, but we have 500GB of disk in total |
| 15:09.49 | guillem | ok, just mentioning as that was what took most of the archive size |
| 15:09.50 | aurel32 | NCommander: have you got a look at the link I just posted about Ganneff scripts? |
| 15:10.11 | aurel32 | it seems there is already everything to sync testing |
| 15:10.25 | NCommander | It's more for syncing unstable |
| 15:10.39 | NCommander | It would require a britney installation |
| 15:10.50 | aurel32 | well it told me that amd64 used those scripts to sync testing + unstable + experimental |
| 15:11.02 | NCommander | It could be used to sync the source for testing |
| 15:11.23 | NCommander | That would work (it probably needs a slight tweak, this looks like the really old dinstall based dak, not the current iteration) |
| 15:11.23 | aurel32 | but then if you have the package with the same version in unstable that's ok |
| 15:11.48 | aurel32 | yes, it's for an old version of dak, so this may need some tweaks, but that's a good basis I think |
| 15:11.50 | NCommander | I've been working to modify w-b to binNMU in distirbution == testing |
| 15:12.06 | NCommander | (for reasons guillem brought up earlier) |
| 15:12.11 | aurel32 | why do you want that? |
| 15:12.37 | aurel32 | why can't you fetch the packages from unstable directly? |
| 15:12.43 | NCommander | if we're missing a binary revision of a package, and it has to be built, either it has to be built as is, and then the changes file must be changed to get it to enter testing |
| 15:12.51 | aurel32 | just using a build daemon for the missing packages |
| 15:13.01 | NCommander | Yeah, I know that :-P |
| 15:13.15 | NCommander | But the missing versions will go into unstable if the changes file isn't tweaked |
| 15:13.31 | aurel32 | I still I don't see why |
| 15:13.38 | NCommander | And as an older version did exist, but is now being built in a new environment, by definition, its a binNMU |
| 15:13.40 | aurel32 | we already have testing buildds in debian |
| 15:13.49 | NCommander | for t-p-u |
| 15:13.51 | aurel32 | and the uploads are going into the right queue |
| 15:13.53 | NCommander | Not the actual testing suite |
| 15:14.07 | aurel32 | t-p-u could be used for that actually |
| 15:14.24 | NCommander | still have the issue of butchering the changes file |
| 15:14.30 | aurel32 | I have to admit I don't follow you |
| 15:14.32 | NCommander | ALthough thats less of an issue |
| 15:14.38 | NCommander | guillem managed to explain it well |
| 15:14.44 | NCommander | I guess I'm not good at repeating his words |
| 15:15.33 | guillem | aurel32: the problem is that most probably at some point we had a version present in the archive in sid |
| 15:15.36 | aurel32 | do you have a pointer to that? There is such a huge backlog |
| 15:15.39 | guillem | and then it got obsoleted |
| 15:15.55 | guillem | aurel32: so rebuilding with the same name-version-arch tuple would be wrong |
| 15:16.16 | guillem | and for the packages that are out of syn between testing and sid, the cleanest is to binNMU |
| 15:16.37 | guillem | but I said, the best would be to try to fish them from snapshot and obsolete first |
| 15:16.40 | aurel32 | Well but that only applies when we add support for testing |
| 15:16.46 | guillem | and only as a last resort binNMU the missing stuff |
| 15:16.51 | aurel32 | when the script runs every day that won't happen |
| 15:17.02 | guillem | sure, I was only talking about the initial import |
| 15:17.06 | aurel32 | so I am not sure it worth developping a complicated stuff for that |
| 15:17.21 | aurel32 | it's a lot simpler to fetch the package from obsolete |
| 15:17.35 | aurel32 | that will cover 98% of the cases |
| 15:17.44 | guillem | aurel32: sure, that's what I proposed |
| 15:17.49 | aurel32 | and the other 2 % can be handled by hand |
| 15:18.07 | guillem | sid + (snapshot + obsolete) + possible binNMU for the missing stuff |
| 15:18.08 | NCommander | aurel32, the script doesn't handle syncing binaries |
| 15:18.19 | NCommander | and yeah, that's what I did |
| 15:18.27 | NCommander | (I imported a snapshot as the basis) |
| 15:19.08 | aurel32 | NCommander: you mean it can't automatically move (or rather copy) binaries from unstable to testing when the source package make the same? |
| 15:19.34 | NCommander | dak has no concept of testing or releasing |
| 15:19.38 | NCommander | That's all handled by britney |
| 15:19.49 | NCommander | And that's done by freezing the archive and all the binaries in it |
| 15:19.55 | NCommander | ^testing |
| 15:20.08 | NCommander | So in effect, nothing ever has to be built since nothing can enter testing if there is a gap so to speak |
| 15:21.06 | aurel32 | well I am sure the amd64 were able to handle that nicely |
| 15:21.30 | aurel32 | you have to ask for example ganneff about that, I am not sure it worth reinventing the wheel |
| 15:21.37 | aurel32 | NCommander: speaking about dak: |
| 15:22.02 | aurel32 | - it is able to automatically remove package from a suite when a newer version appears in another (for unreleased) |
| 15:22.21 | aurel32 | - is it able to keep obsoleted packages like mini-dak ? |
| 15:22.40 | NCommander | It supports rejecting packages if something is newer/older than |
| 15:22.50 | NCommander | If it doesn't |
| 15:22.58 | NCommander | extending dak won't be very hard since the basic support is there |
| 15:23.13 | NCommander | (I can't say for sure if it does or doesn't, mostly cause dak doesn't come with a manual) |
| 15:23.25 | aurel32 | well it's not about rejecting packages |
| 15:23.36 | aurel32 | it's about automatically removing packages |
| 15:23.51 | NCommander | " cruft-report Check for obsolete or duplicated packages" |
| 15:23.55 | aurel32 | and that's really a showstopper for the switch to dak if it doesn't handle that |
| 15:24.11 | NCommander | " clean-suites remove cruft from the archive" |
| 15:24.16 | NCommander | Off hand |
| 15:24.19 | NCommander | I'd say yes it does |
| 15:25.28 | NCommander | You simply mark unreleased must be newer then stable |
| 15:25.37 | NCommander | and then cruft-report/clean-queues/clean-suite should do what you want) |
| 15:26.41 | aurel32 | what about removed packages? Are they deleted or simply moved somewhere? |
| 15:28.39 | NCommander | looks at the source |
| 15:28.43 | NCommander | Oh, dak rm? |
| 15:28.46 | NCommander | Uh |
| 15:35.56 | aurel32 | I mean for automatically removed packages |
| 15:36.08 | aurel32 | so probably for clean-suites |
| 15:36.28 | NCommander | yeah |
| 15:36.32 | NCommander | It looks like it gets moved aside |
| 15:36.34 | NCommander | (not sure) |
| 15:36.40 | NCommander | If not, its easy to change the default ;-) |
| 15:36.50 | azeem | there's the morgue, no? |
| 15:37.47 | NCommander | yeah |
| 15:37.50 | NCommander | THat's where it should go |
| 15:38.13 | NCommander | Bah, I forgot to add arch all packages when I imported the database |
| 15:38.14 | NCommander | Bah |
| 15:38.18 | NCommander | fixes his dak installation |
| 15:39.51 | NCommander | aurel32, how/when could we possibly move unstable to d-ports? (sorta the pressing concern, and it should be easy with mini-dak) |
| 15:40.07 | NCommander | (I can help in any way possible) |
| 15:40.59 | azeem | does it make sense to move first to mini-dak, and then migrate to dak? |
| 15:41.54 | NCommander | for unstable, it doesn't really matter |
| 15:41.58 | NCommander | Everything has to get imported anyway |
| 15:42.03 | NCommander | and if I understand mini-dak right |
| 15:42.16 | NCommander | Adding our unstable is a change in archive.conf, making the dirs, rsync, and then apt-ftparchive |
| 15:42.17 | NCommander | In that order |
| 15:42.41 | NCommander | (not counting moving the buildd's w-b) |
| 15:43.13 | aurel32 | azeem: for hurd, that's ok to switch to mini-dak first, as it only has unstable/experimental |
| 15:43.39 | aurel32 | azeem: and as we anyway have to import kfreebsd and hurd/unreleased, adding one more thing to import won't be difficult |
| 15:43.42 | azeem | aurel32: did you consider starting a discussion about ports.debian.org? |
| 15:44.13 | aurel32 | NCommander: well w-b is already setup for a long time |
| 15:44.23 | aurel32 | NCommander: I mean for m68k, I have been asked to add it |
| 15:44.34 | aurel32 | NCommander: about the date, probably not before two weeks |
| 15:44.36 | NCommander | Yeah, that end is already covered :-) |
| 15:44.40 | aurel32 | basically when I get back home |
| 15:44.44 | NCommander | Perfect |
| 15:44.54 | azeem | I think Ganneff should be able to handle w-b access now? If he is cooperative, it might make more sense for some bargain where we have a second dak on ports.debian.org, but keep/migrate back w-b on buildd.d.o |
| 15:45.23 | aurel32 | azeem: you mean getting the the domain name? |
| 15:45.25 | azeem | hrm, on second thought, w-b access is probably done by a different set of people |
| 15:45.38 | azeem | aurel32: integrating it better into Debian, yes |
| 15:45.40 | aurel32 | azeem: not sure he will be very cooperative when it concerns hurd and m68k |
| 15:46.00 | aurel32 | azeem: yes, you can start such a discussion |
| 15:46.18 | aurel32 | just keep in mind that ports.debian.org already exists |
| 15:46.20 | NCommander | azeem, w-b is a different group |
| 15:46.35 | NCommander | knows this from the head smacking experience we've gone through trying to get keys added |
| 15:46.37 | aurel32 | it's a web page listing all the architecures in debian |
| 15:46.38 | NCommander | THere is some overlap though |
| 15:46.44 | NCommander | Oh, THAT ports.d.o |
| 15:46.51 | NCommander | I thought it was d.o/ports |
| 15:46.52 | azeem | aurel32: it's just a redirect |
| 15:47.06 | aurel32 | well concerning w-b, it's always better to have w-b and the archive on the same machine |
| 15:47.16 | azeem | nods |
| 15:47.19 | NCommander | considering that page still has netbsd-* on it ... |
| 15:47.20 | aurel32 | or machines in the same location |
| 15:47.29 | azeem | I'm mostly concerned about RM binNMUs |
| 15:47.42 | azeem | that's something at least the Hurd port is sorely lacking currently |
| 15:47.52 | NCommander | azeem, binNMU broken on Hurd? |
| 15:47.53 | aurel32 | azeem: you mean the rght to do binNMU ? |
| 15:48.17 | NCommander | azeem, if you have access to the w-b database, you can binNMU any package |
| 15:48.27 | azeem | aurel32: no, just getting all-ports binNMUs executed for hurd etc. as well |
| 15:48.30 | NCommander | We've binNMUed a few of our own packages |
| 15:48.34 | NCommander | oh, those |
| 15:48.35 | aurel32 | azeem: I see |
| 15:48.43 | azeem | NCommander: pfew, I thought that's what I did all the time, thanks for reassuring me |
| 15:48.53 | aurel32 | azeem: one on the solution I am currently working on, is a mostly automated process |
| 15:49.12 | aurel32 | azeem: it is possible to detect the transitions |
| 15:49.45 | aurel32 | and I have even been to detect transitions unknown from the RM team |
| 15:50.15 | aurel32 | but we can also give an account to the RM on debian-ports.org |
| 15:50.16 | azeem | aurel32: ok, but that's orthogonal |
| 15:50.29 | aurel32 | in the hope that they will use it |
| 15:50.42 | aurel32 | azeem: well I believe that something that can even benefit debian |
| 15:50.46 | azeem | I don't think there's a publically available place where all the buildd.d.o binNMUs are added in a RSS fashion? |
| 15:51.12 | aurel32 | I mean the RM are spending a lot of time on transistions, while some parts can be automated |
| 15:51.32 | aurel32 | azeem: some persons who are doing the binNMU sometimes have a file with a list |
| 15:51.38 | aurel32 | vorlon for example |
| 15:51.45 | aurel32 | but I am not sure it is the cas of all persons |
| 15:52.11 | azeem | yeah, but it's several files, and no time stamps |
| 15:52.13 | aurel32 | also sometimes, it's not just a matter of reproducing the same binNMU |
| 15:52.13 | azeem | HE has one |
| 15:52.26 | aurel32 | a lot of binNMUs have to be computed |
| 15:52.31 | aurel32 | thinking for example of the perl transition |
| 15:52.36 | aurel32 | or the python one |
| 15:52.49 | aurel32 | sorry, but I have to go to Lunch now |
| 15:52.49 | azeem | right |
| 15:52.52 | aurel32 | see you later |
| 15:52.53 | azeem | see you |
| 15:53.08 | azeem | still, having the information centrally available would be nice |
| 16:45.11 | *** join/#gnu-kbsd uwe_ (n=uwe@dslb-084-056-006-076.pools.arcor-ip.net) |
| 17:05.54 | *** join/#gnu-kbsd appaji (n=appaji@unaffiliated/appaji) |
| 17:10.33 | *** join/#gnu-kbsd kaeso (n=luca@debian/developer/kaeso) |
| 17:20.30 | *** join/#gnu-kbsd CIA-2 (n=CIA@208.69.182.149) |
| 17:39.40 | *** join/#gnu-kbsd CIA-2 (n=CIA@208.69.182.149) |
| 19:00.53 | *** join/#gnu-kbsd appaji (i=appaji@gateway/tor/x-2887cffef7d51407) |
| 22:22.20 | *** join/#gnu-kbsd aurel32 (n=aurel32@hall.aurel32.net) |
| 22:22.56 | *** join/#gnu-kbsd aurel32 (n=aurel32@hall.aurel32.net) |
| 22:24.30 | *** join/#gnu-kbsd aurel32 (n=aurel32@hall.aurel32.net) |
| 22:30.16 | *** join/#gnu-kbsd aurel32 (n=aurel32@hall.aurel32.net) |
| 22:32.27 | *** join/#gnu-kbsd aurel32 (n=aurel32@hall.aurel32.net) |
| 22:33.33 | *** join/#gnu-kbsd aurel32 (n=aurel32@hall.aurel32.net) |
| 23:19.24 | *** join/#gnu-kbsd m00bie (n=chatzill@cpc1-bsfd3-0-0-cust305.cmbg.cable.ntl.com) |
| 23:33.24 | *** join/#gnu-kbsd asac_ (n=asac@e177164237.adsl.alicedsl.de) |