[00:08] <bryce_> calc: interesting, I didn't know about that change
[00:09] <bryce_> calc: on the plus side, that may result in a reduction of duplicate tasks (I get a lot of tasks that I assign away from xorg, that grow another xorg task after a while - I finally just wrote a script to detect and eliminate these)
[00:11] <calc> ah
[00:38] <relnev> what do I need to do to build a replacement snd-usb-audio.ko (a kernel module found in the linux kernel source) that i can load without having to rebuild the kernel and reboot?
[00:41] <wgrant> calc: It was causing problems because people would click on a bug link in an email after somebody had reassigned a task. They'd then immediately click on the button to recreate the original task. You were always meant to use 'Also affects (project|distribution)...' normally, anyway.
[01:16] <calc> wgrant: ok
[01:20] <lifeless> is anyone else seeing oddly high load in jaunty/karmic?
[01:20] <lifeless> Mine is constantly 10
[01:20] <lifeless> or 11
[01:20] <lifeless> but no IO, plenty of cache, cpu at 1% use
[01:20] <lifeless> oh nevermind, it'll be a stalled sfs process
[06:40] <dholbach> good morning
[06:58] <robert_ancell> any karmic users here?  What is the contents of your /usr/include/linux/errno.h?
[06:58] <robert_ancell> mine points to asm/errno.h which does not exist
[06:59] <lifeless> robert_ancell: you're missing libc-dev or something I suspect
[06:59] <lifeless> or being hit by a toolchain transition
[06:59] <lifeless> <- guessing
[06:59] <hyperair> there are ftbfs errors regarding that particular header
[07:00] <robert_ancell> hyperair: ouch
[07:00] <hyperair> yeh ouch indeed.
[07:00] <hyperair> gnomeui is having issues
[07:00] <hyperair> rather, stuff depending on gnomeui
[07:01] <robert_ancell> hmm, I was going to use the PPA but that will have the same problems right?
[07:02] <hyperair> indeed.
[07:02] <dholbach> robert_ancell: try asking the guys in #ubuntu-kernel - they should know what's going on
[07:02] <dholbach> ... even if I suspect that most of them are sleeping right now
[07:03] <robert_ancell> dholbach: yeah, it's friday afternoon.  I figure it will be fixed by monday :)  I'll go drink beer instead
[07:03] <ajmitch> dholbach: it's a known issue, Stuff needs to be done on the buildds I heard :)
[07:03] <dholbach> ajmitch: oh wow
[07:06] <StevenK> It's a findutils bug that impacted on the linux-libc-dev binary package
[07:30] <geser> robert_ancell: it's bug 373214
[07:30] <robert_ancell> geser: thx
[07:33] <lifeless> robert_ancell: oh right, you're in aus:)
[07:33] <lifeless> beer sounds good about now ;)
[07:34] <robert_ancell> lifeless: it's rapidly approaching beer o'clock
[07:34]  * robert_ancell rubs it in for those who have a day to go
[07:34] <lifeless> indeed. and we fly 10000 to actually meet soon :P
[07:39] <Hobbsee> slangasek: I did not.
[07:40] <slangasek> Hobbsee: right - Riddell confessed :-)
[07:40] <Hobbsee> slangasek: oh, fair enough.  I'm just looking through my highlights ;)
[07:40] <Hobbsee> slangasek: I hope you didn't make him walk the plank?
[07:41] <slangasek> no, I just demoted him to multiverse temporarily
[07:41] <Hobbsee> haha
[07:41] <Hobbsee> oh dear
[07:42] <pitti> Good morning
[07:42] <pitti> slangasek: libltdl-dev> I didn't
[07:42] <pitti> doko: nice! is it in c-mismatches?
[07:45] <StevenK> slangasek: Along with all of KDE?
[07:45] <slangasek> hah, twitch :)
[07:45] <ScottK> It would improve the quality of translations.
[07:46]  * StevenK grins
[07:50]  * pwnguin gets to attend a public meeting about garmin's use of linux
[07:50] <pwnguin> anyone have a question they want answered?
[07:51] <Hobbsee> pwnguin: apart from the obvious ones?  No.  I'd love to know what the answers to the obvious questions are, though.
[07:52] <Hobbsee> if there's a URL from it
[07:52] <pwnguin> i doubt it will be publicly recorded
[07:52] <Hobbsee> darn
[07:53] <pwnguin> but what are the obvious questions?
[07:54] <Hobbsee> pwnguin: which devices do they use linux in, what are their future plans with linux and their devices, whether people will be able to mod them / write plugins etc for them, etc, etc, etc
[07:57] <pwnguin> Hobbsee: http://developer.garmin.com/linux/ i'll let you know if they mention a device that isn't one of those
[07:58] <Hobbsee> pwnguin: ah, sweet!
[10:35] <pitti> anyone got a Sony laptop here?
[10:37] <amitk> ping manjo when he gets online in a few hours if you don't find anybody
[10:37] <amitk> pitti: ^
[10:37] <pitti> amitk: ah, thanks
[10:42] <pitti> directhex: congratulations for your motu badge! well done!
[10:42] <pitti> cjwatson, smb: hm, why does the new linux upload bump abi?
[10:42] <pitti> if it's just a rebuild?
[10:43] <smb> pitti, because i did not found/look far enough/trust the last abi files
[10:43] <directhex> pitti, thanks. i still need to bug you over stuff in main though ;)
[10:43]  * cjwatson has no idea but doesn't care enough to worry
[10:43] <pitti> smb: fair enough; I was just curious
[10:43] <cjwatson> ABI changes are cheap enough at this point
[10:43] <smb> pitti, So I bumped abi to be sure it passes the abi checks
[10:43] <pitti> yeah, we just need to watch out for NEWing
[10:44] <cjwatson> though it does mean NEW, but meh, lost in the noise of having to deal with the whole thing manually
[10:44] <pitti> thanks for getting this fixed
[10:44] <dholbach> cjwatson, smb: YAY! :)
[10:46]  * TheMuso suspected there would have been an ABI bump for ports also, but avoided enabling checks since all ports kernels are not yet setled.
[10:46] <TheMuso> anybody else getting LP timeouts?
[10:46] <pitti> intermittently, yes
[10:47]  * TheMuso can't seem to view source package pages, i.e lp.net/ubuntu/+source/linux
[10:47] <TheMuso> hrm working now
[10:50] <TheMuso> anyway I'm off for the evening, will check in tomorrow morning in case anything is needed ports wise, but I think things should be fine.
[10:51] <directhex> had intermitent issues with LP since last night. check /topic in #launchpad
[10:54] <Laney> What's up with these "asm/socket.h: No such file or directory" errors? Seen them failing a few builds now.
[10:54] <TheMuso> Laney: linux-libc-dev breakage.
[10:54] <james_w> bug 373214
[10:54]  * TheMuso thinks a /topic tweak is in order.
[10:55] <Laney> yes, it seems to be affecting builds all over the shop
[10:55] <Laney> james_w: ta
[10:56] <amitk> TheMuso: More correctly, findutils breakage that caused a linux-libc-dev
[10:56] <amitk> breakage
[10:56] <TheMuso> amitk: yes, but linux-libc-dev being broken is enough for most I would think. :)
[10:57] <TheMuso> anyway, really off.
[10:59] <apw> on an upgrade would i expect to be seeing linux-generic being uninstalled?
[10:59] <apw> (on jaunty)
[11:00] <slangasek> are you using jaunty-proposed?
[11:01] <apw> yes using -proposed
[11:03] <slangasek> apw: then it's not surprising; let me check whether the binaries are all built now and ready to be accepted from NEW
[11:03] <apw> slangasek, how would lacking binaryies trigger a meta to be removed?
[11:04] <slangasek> the meta packages are currently uninstallable in -proposed, so if you're using the package manager in a way that tells it it's ok to remove packages...
[11:04] <apw> i am using it in the default way, it said a partial update was the only way forward, and i said yes
[11:04] <apw> as encouraged to do by the defaults
[11:05] <slangasek> anyway, lrm/lbm accepted now, which should fix linux-generic with the next publisher cycle
[11:05] <apw> (with my behaving like a non-clued up user hat on)
[11:05] <apw> i assume once i had lost linux-generic i wouldn't have got it back... sounds problematic for those users
[11:05] <slangasek> yeah, I've never quite understood why update-manager calls that a "partial" upgrade; half the time it fails to find a solution at all for me, whereas if I click 'close', it lets me do a real, partial upgrade
[11:06] <apw> yeah ... i think there is some kind of bug in there offering that to normal users without a fight
[11:11] <cjwatson> (obviously if your build doesn't involve compiling anything then it won't fail. I don't care enough to fine-tune the topic)
[11:14] <smb> slangasek, Were the meta package in error or did something else go wrong?
[11:16] <smb> slangasek, Have to be off now, but if there is anything that should get back into the linux-meta packages, let me know
[11:17] <slangasek> smb: no package errors; we just needed some jaunty-proposed NEW processing, which is done now
[11:17] <smb> slangasek, Ah, ok. Thanks
[11:29] <apw> cjwatson, i wonder if you would have some minutes to talk about that kexec reboot bug (bug 251242) today
[11:34] <cjwatson> apw: ah yes. I have a PDR panic day today, but have queued up that bug to look at the debdiffs therein
[11:34] <apw> cjwatson, heh know _that_ panic ... no worries if busy it'll wait
[13:43] <geiseri_> hi i am having problems creating my own allternates installer.  it gets pretty far but bombs out with an error of "Couldn't find task standard"
[13:43] <geiseri_> is there anyone who would know more about this? google was not very helpful
[13:44] <geiseri_> i think i may have missed a step, but im not sure where...
[13:52] <astrolite> any developers of ubuntu-vm-builder here?
[13:53] <cjwatson> geiseri_: it's looking for sections with "Task: standard" in the Packages file - if you're missing those then perhaps you generated your own Packages file but didn't use the override file from archive.u.c/ubuntu/indices/ as input?
[13:55] <geiseri_> yes, i created my own... but i did not include the indices.
[13:55] <cjwatson> that'll be your problem then
[13:55] <geiseri_> i can download that or do i need to generate that if i am using my own package set
[13:56] <cjwatson> start out with the downloaded ones, generating your own is a bit complicated
[13:56] <geiseri_> okay
[13:56] <cjwatson> you may need to edit them a bit
[13:57] <geiseri_> okay
[13:57] <geiseri_> ill start there
[13:58] <geiseri_> what files will i need?  all of them fro my dist?
[14:00] <liw> astrolite, #ubuntu-virt might be a better place to find those people
[14:00] <astrolite> liw: ok, thanks!
[14:07] <geiseri_> cjwatson: where would be the documentation no how to generate my own indices files?
[14:07] <geiseri_> or is it easier to include the tasksel in my Packages file?
[14:07] <geiseri_> err Task: standard?
[14:16] <cjwatson> geiseri_: I don't know of any documentation on the subject, but the format should be clear from looking at the first
[14:16] <cjwatson> file
[14:16] <cjwatson> geiseri_: apt-ftparchive(1) documents how to refer to the index files
[14:17] <cjwatson> geiseri_: if you do that properly in your apt-ftparchive configuration, then it will include appropriate lines in Packages
[14:18] <cjwatson> geiseri_: you'll need all the files for your distribution - the ones with ".extra." in the name include Task fields, while the others deal with getting Priority and Section correct
[14:18] <cjwatson> (the latter is mostly rather less important but does matter in some cases)
[14:19] <geiseri_> okay ill read up on ftparchive... i have a feeling i may be making this harder than it needs to be
[14:20] <geiseri_> because im using my local file based package repo
[14:21] <lamont> kernel is building on the afflicted architectures now (linux-libc-dev ftw or some such)
[14:30] <geiseri_> cjwatson: okay i think im still missing something here... apt-ftparchive generates the indices files? or it just creates a Packages file that causes me not to need them?
[14:31] <cjwatson> apt-ftparchive generates the Packages files, using the .debs themselves and also the files from /ubuntu/indices/ as inputs
[14:31] <cjwatson> the installer does not itself use the files from /ubuntu/indices/ directly
[14:32] <geiseri_> ah, so really i need the indices files to include when i run the scanpackages then
[14:33] <cjwatson> dpkg-scanpackages is what we used to use before we had apt-ftparchive; I don't think it supports "extra overrides" (which contain Task fields)
[14:33] <cjwatson> (well, for values of "we" = Debian)
[14:34] <geiseri_> okay, so im better off to use apt-ftparchive then
[14:36] <Awsoonn> hi guys, bug 312396 is cramping my workflow and I would like to have some guidance in fixing it. Who would be the best person to talk to?
[15:07] <cjwatson> Awsoonn: judging from the upstream bug, http://git.gnome.org/cgit/gvfs/commit/?id=4e49395240190526e is supposed to fix it
[15:30] <Awsoonn> cjwatson: do you think it would be a bad idea to just get the latest version from git and make install?
[15:32] <cjwatson> Awsoonn: I wouldn't like to say, since I have not looked at the changes in detail; it's entirely possible that that would cause problems
[15:32] <pitti> infinity: can we do a mass give-back of failed karmic builds after the new kernel is in?
[15:32] <cjwatson> pitti: lamont's going to
[15:32] <Awsoonn> I see there are 4 patches on it
[15:32] <pitti> cjwatson: nice, thanks
[15:32] <cjwatson> (infinity is off sick, I think)
[15:32] <pitti> infinity: uh, get well soon!
[15:32] <cjwatson> Awsoonn: if it were me, I'd backport the change
[15:33] <Awsoonn> so just make a patch of that one change and make a new patch based on it?
[15:33] <cjwatson> that would be the approach I'd take, yes
[15:33] <cjwatson> and report back to the bug if that solves it, of course
[15:33] <Awsoonn> cool, and adding a patchfile to the patch dir will automagicly cause it to be applied when built right?
[15:34] <Awsoonn> if that makes sense
[15:35] <cjwatson> Awsoonn: depends on the patch system; sometimes there's a '00list' or 'series' file that needs to be changed too
[15:36] <Awsoonn> it does have a series file, so it looks like I should add it ther too, ok. I"m getting the idea now. :)
[15:37] <Awsoonn> when I build the package with the patch added should I just use .configure make make install or do I need to make a package of it before installing?
[15:38] <Awsoonn> i hope you dont mind so many questions. I really want to be MOTU someday so I'm still learning as much as possible. :P
[15:42] <cjwatson> Awsoonn: if it were me, I would make a package of it (so also increment the version number in debian/changelog slightly)
[15:43] <cjwatson> it's entirely possible for packages to lay files out differently from 'make install'
[15:45] <Awsoonn> that is what I was fearing, so I will go the package route, thank you cjwatson !
[15:45] <cjwatson> upload queue index numbers have passed the wow million mark - wow
[15:45] <cjwatson> err, the one million mark
[15:45] <Awsoonn> I think you were right the first time :)
[15:50] <pitti> cjwatson: what was the 1.000.000th upload?
[15:50] <pitti> (and wow! indeed)
[15:51] <amitk> pitti: manjo is here now. Hit him with your Sony fixes ;)
[15:51] <pitti> manjo: hello!
[15:51] <manjo> hi
[15:51] <manjo> referesh my mem pls ?
[15:52] <pitti> manjo: do you have some minutes to try out a new udev-extras package for sony fn key handling?
[15:52] <pitti> manjo: http://martinpitt.wordpress.com/2009/05/08/devicekit-update-future-handling-of-fn-key-maps/
[15:52] <pitti> manjo: unfortunately the packages in my PPA didn't build yet (buildds blocked due to kernel bug)
[15:52] <pitti> manjo: but you can build it from the git branch (http://lists.freedesktop.org/archives/devkit-devel/2009-May/000171.html)
[15:52] <pitti> manjo: I'm interested in whether this package, and hal-info keymaps disabled, works on sony vaios
[15:53] <pitti> I need to disappear for 20 minutes for physiotherapy; bbl
[15:53] <manjo> pitti, my wife took the laptop with her to work... is it ok if I give you results on monday ?
[15:54] <manjo> amitk, ?
[15:55] <cjwatson> pitti: what were the odds ... a language pack
[15:55] <cjwatson>  1000000 | -B | language-pack-gnome- | 1:9.04+20090504      | 43 hours
[15:56] <cjwatson> language-pack-gnome-om actually
[15:56] <cjwatson> though confusingly something tried to upload that to jaunty, not jaunty-proposed
[15:56] <cjwatson> ArneGoetje: is langpack-o-matic still targeting jaunty rather than jaunty-proposed in its changelogs, by any chance?
[15:58] <cjwatson> ArneGoetje: never mind - I see now that it was actually a PPA upload. Pretend I never said anything. :-)
[16:00] <ion_> pitti: Could you put the udev-extras package to a separate section in your PPA? I’d feel more easy about adding it to sources.list that way.
[16:00] <ion_> I see that it’s the only package in yourppa/karmic, but that can change. :-)
[16:00] <cjwatson> pitti: oh, is *that* why you have enormous LP karma? it still seems to think all language packs are uploaded by you
[16:00] <cjwatson> pitti: at least to the ubuntu-langpacks PPA
[16:13]  * lamont goes to play with karmic
[16:20] <jeki> Can anyone look at this report? https://bugs.launchpad.net/ubuntu/+source/app-install-data-ubuntu/+bug/368580
[16:27] <pitti> manjo: absolutely; thank you!
[16:27] <manjo> k
[16:27] <pitti> cjwatson: a PPA?
[16:27] <pitti> ah, right
[16:27] <pitti> cjwatson: oh, we get karma for uploads now?
[16:28] <cjwatson> I think so
[16:28] <pitti> Maintainer: Language pack maintainers <language-packs@ubuntu.com>
[16:29] <pitti> timestamp: Thu 2008-02-14 14:50:13 +0100
[16:29] <pitti> ^ date of the change
[16:29] <pitti> I can set it to -core-dev, but I'd really keep it as that alias
[16:29] <pitti> just curious why I'd get the karma for it personally
[16:32] <cjwatson> dunno, I was just looking at the display on ~ubuntu-langpacks/+archive/ppa
[16:33] <pitti> I wonder why I got the Karma then, and ArneGoetje didn't
[16:33]  * pitti files a bug
[16:34] <cjwatson> BTW I haven't actually checked whether you got karma for it
[16:34] <cjwatson> I just saw that the uploader was listed as pitti
[16:34] <pitti> cjwatson: ~pitti/+karma shows an abysmal soyuz component; it could only be that
[16:35] <cjwatson> you can't mean abysmal :)
[16:35] <cjwatson> unless soyuz karma is negative
[16:36] <pitti> right, seems I slightly misunderstood the word
[16:36]  * pitti looked into dictionary now and adjusted his vocab
[16:37] <pitti> like "scary"
[16:37]  * cjwatson wonders if the opposite of abysmal should be empyrean
[16:37] <cjwatson> perhaps not :)
[16:38] <cody-somerville> lol
[16:38] <pitti> anyway, bug 373772
[16:38] <pitti> I want to compete on fair terms :)
[17:18] <calc> looks like the archive will be usable again in a few hours :)
[17:18] <calc> i386/lpia have linux built now
[17:18] <cjwatson> yeah, lamont and I (mostly lamont) have been nursing things through
[17:19] <cjwatson> powerpc is done, amd64's nearly done
[17:19]  * calc hugs cjwatson and lamont :)
[17:19] <calc> looks like ia64 failed for a strange rason
[17:19] <calc> er reason
[17:19] <cjwatson> no it didn't, ia64 is built from linux-ports
[17:19] <calc> oh i see
[17:19] <cjwatson> and never had this particular problem in the first place (by luck, I assume)
[17:19] <cjwatson> sparc was never broken either
[17:24] <lamont> cjwatson: and IA64 is WINNING on the shortest-queue-depth competition. whoda thought?
[17:24] <cjwatson> it had all that time of being non-broken to catch up
[17:24] <geiseri_> if i am generating my iso image from a script is it better to just inject my preseed file right into the initrd vs putting it on the cdrom filesystem?
[17:25] <cjwatson> hmm, I clearly should have published lpia rather than waiting for amd64 - oh well, it really is nearly done now
[17:25] <geiseri_> or is it better to put the first three questions on the boot arguments
[17:25] <cjwatson> geiseri_: if you're rebuilding the initrd *anyway*, then you might as well inject it in there, but otherwise I'd put it on the cdrom filesystem and edit boot arguments
[17:25] <cjwatson> the only "better" about it is convenience for you
[17:25] <geiseri_> okay
[17:27] <shodges> hey, does anyone know of a small command-line utility that wraps the XGetInputFocus function for X11?
[17:27] <shodges> I want to retrieve the ID of the window in focus, but preferably using a tool that is existing on the system already...
[17:30] <shodges> My searching so far has retrieved nothing, I've written my own program as a test, but I need to support remote Ubuntu systems over SSH, so transmitting the the binary program over the wire is a less desirable than just piggy-backing on an existing utility
[17:53] <Awsoonn> cjwatson: I was able to manually apply the changes and it works! but what command should I use to generate a patch for it that i can put in the debian folder?
[17:55] <Awsoonn> first I guess I'm assuming that I'm not allowed to modify anythign outside the debian directory, correct?
[17:56] <cjwatson> depends on the patch, I think you should perhaps read documentation under wiki.ubuntu.com/UbuntuDevelopment and wiki.ubuntu.com/MOTU which will be ultimately more rewarding that asking me :)
[17:56] <cjwatson> s/that/than/
[18:02] <cjwatson> lamont: publisher's running for the linux* packages that have made it so far, BTW
[18:02] <cjwatson> I verified that the diffs against older linux-libc-dev seemed reasonable
[18:03] <lamont> yay
[18:04] <apw> can anyone tell me where i might find the uptodate source for gnome-power-manager ... both jaunty and karmic point me to the same bzr branch which seems to have no releveance to either
[18:05] <cjwatson> well 'apt-get source gnome-power-manager' is always up to date - ask the most recent uploader in its changelog
[18:06] <apw> cjwatson, thanks ... i knew that the apt-get source was always reliable, but it bitches at me and tells me not to use that ... will hastle someone :)
[18:07] <apw> seb128, pitti you have both updated gnome-power-manager recently.  the package claims to be in bzr but the reference there seems bogus and out of date... what did you use just the package?
[18:07] <cjwatson> if the branch is already out of date, the hassling is not directed at you ...
[18:08] <apw> cjwatson, heh yeah :)  but i don't want to make it worse
[18:08] <seb128> apw: what bzr did you use?
[18:08] <apw> the one it pointed me to i think in the debian/control file
[18:08] <seb128> which one is that?
[18:08] <seb128> let me have a look
[18:08] <apw> https://code.launchpad.net/~gnome-power-manager-team/gnome-power/trunk
[18:08] <seb128> ok
[18:08] <apw> but that as 2.5.99 on it
[18:09] <apw> and neither jaunty nor karmic are at that version
[18:09] <seb128> it's lp:~ubuntu-desktop/gnome-power-manager/ubuntu
[18:09] <seb128> now
[18:09] <apw> for which karmic or jaunty?
[18:09] <seb128> dunno about karmic
[18:09] <seb128> but we usually don't make different versions
[18:10] <seb128> we just have a trunk which has the unstable version
[18:10] <apw> they are at rather different versions right now
[18:10] <seb128> no they are not
[18:10] <seb128> that's the same project
[18:10] <seb128> we don't have an hardy bzr, an intrepid bzr, etc
[18:10] <seb128> just trunk
[18:10] <apw> gnome-power-manager | 2.24.2-2ubuntu8 |        jaunty | source, amd64, i386
[18:10] <apw> gnome-power-manager | 2.26.1-0ubuntu1 |        karmic | source
[18:11] <apw> that tip can't be both?
[18:11] <seb128> no, as said it's current unstable
[18:11] <seb128> unstable = karmic
[18:11] <seb128> we don't keep stable series in a different bzr, we just keep upgrading the bzr
[18:11] <seb128> if you need to do a sru apt-get source the jaunty version and debdiff on that
[18:11] <apw> right so ... to make a change in jaunty, should i just produce a debdiff or should i make a new bzr branch off somwhere in history myself
[18:11] <apw> seb128, ok thanks
[18:12] <seb128> you're welcome
[18:12] <seb128> we don't do enough sru uploads to outweight the cost to carry several bzr versions, etc
[18:12] <apw> i'll strip the vcs link for jaunty too at the same time
[18:12] <seb128> sru should be minimal changes if you aim for that
[18:13] <seb128> I'm not sure starting doing cleaning is a good idea
[18:13] <apw> i would have hoped a branch in bzr would be next to free.  but whatever you are doing is ok with me
[18:13] <apw> well having stale information in there is rather confusing ... it pointed me to bzr, when we arn't using it, and to the wrong one even so
[18:13] <apw> but your call, i'll ignore it
[18:15] <Awsoonn> apw, you may concider submitting your minimal debdiff for the sru and a second one with the updated link for karmic or something that.
[18:15] <seb128> apw: it's probably next to free, we just don't have a policy for naming, where to store those, how to update the vcs field in control, etc
[18:15] <Awsoonn> seb128: feel free to correct me on that.
[18:16] <seb128> apw: since often we will switch to a new unstable without touching the stable source
[18:16] <seb128> ie we work on jaunty, the bzr used is trunk and that's in the uploaded sources
[18:16] <seb128> then karmic open
[18:16] <cjwatson> I'm fine with a Vcs-Bzr correction in an SRU, personally
[18:17] <apw> seb128, yep some process required for sure.  i would have thought naming by series at the time of release would be appropriate
[18:17] <cjwatson> apw: it's not worth putting lots of effort into putting that in place across the board now - we'll get it once we switch to the new source package branches scheme that james-w and others are working on
[18:17] <apw> probabally something someone should bring up at UDS with a view to producing guidance
[18:17] <seb128> apw: you would need to reupload everything to change the vcs
[18:17] <cjwatson> it'll then be lp:ubuntu/jaunty/gnome-power-manager etc.
[18:17] <apw> cjwatson, there is a new scheme ...
[18:18] <cjwatson> and probably overrides to set Vcs-Bzr
[18:18] <cjwatson> apw: http://wiki.ubuntu.com/DistributedDevelopment et al
[18:18] <apw> cjwatson, that makes a lot of sense i suspect
[18:18] <apw> cjwatson, sounds like its already done
[18:18] <cjwatson> already extensively discussed, not quite done but we're cloe
[18:18] <cjwatson> close
[18:18]  * apw buts out of that one then :)
[18:19] <seb128> the discussions are for a scheme for the whole archive
[18:19] <cjwatson> right, which will account for this case
[18:19] <seb128> the current bzr packaging is not consistent accross the board
[18:19] <apw> sounds like something to stay well clear of being blamed^Winvolved in
[18:19] <seb128> ubuntu-desktop is not an heavy bzr user and we picked easy scheme on the way
[18:19] <seb128> it's probably far from perfect but work for what we have to do usually
[18:20] <seb128> ie we usually focus on jaunty, spend some times on sru, then switch to karmic
[18:20] <apw> seb128, no what you are doing is completely fine.  i care not to be fair, just as someone bumping into your package i am not finding it easy.  in fact this is the second time and its moved every time :/
[18:20] <seb128> that's the first sru done after a karmic change, ie usually one bzr fits the work
[18:21] <seb128> apw: universal rule is "apt-get source, change, debdiff" and open sponsor request
[18:21] <seb128> then let the packagers deal with their bzr etc
[18:21] <apw> and get whined at for ingnoring the bzr line (in my experience)
[18:21] <seb128> people usually complain when somebody upload without considering bzr
[18:22] <seb128> for sponsoring a debdiff should not be an issue
[18:22] <apw> but cool.  i was about to do the right thing, so all is good, which was to push a debdiff to launchpad and ...
[18:23]  * Awsoonn is now hungry
[18:25] <Awsoonn> sorry to interupt, but when I built my package and installed it appears another package requires a dependancy update to mach my new version. when I submit to LP do i ned to produce a debdiff for every package that needs a bump?
[18:26] <cjwatson> that's very odd; such dependencies (that require changes when you *increase* a version) are rare in the extreme. Can you give specifics, please?
[18:27] <Awsoonn> yea, I and hitting gvfs with that patch, and now libglib2.0-dev seems to be missing a dep
[18:29] <Awsoonn> strangly enough gvfs is not one it's depends. so i'm really confused there..
[18:30] <seb128> Awsoonn: could you copy the error on pastebin.ubuntu.com?
[18:31] <cjwatson> you definitely need to be specific about the exact error message, yes
[18:32] <calc> hmm did i386 not get published yet?
[18:32] <cjwatson> it's working on it
[18:32] <cjwatson> the publisher is not all that quick, be gentle with it
[18:32] <calc> ok
[18:32] <cjwatson> I think the guts of it are done now, but it still has to run germinate before poking the mirrors
[18:33] <Awsoonn> I'll need some help here, when I rebooted after installing the new gvfs update-manager put an error in my notification area and says  Error: BrokenCount >0 This usually means that your installed packages have unmet dependancies.
[18:33] <Awsoonn> http://ubuntu.pastebin.com/m10bdaae9
[18:33] <cjwatson> run 'dpkg --configure -a' in a terminal and paste.ubuntu.com what it says
[18:34] <Awsoonn> kk
[18:35] <Awsoonn> ohh cjwatson that is very usefull. I think i have found the problem. :)
[18:37] <Awsoonn> when I installed all of my .debs that were producded from pbuilder I mistakenly installed all of them, including a -dev package. It didn't automagicly pull in teh dependancies since I used dpkg -i to install it and was now complaining that libgvfscommon-dev needed some dependancies. :)
[18:40] <cjwatson> dpkg -iO is your friend
[18:40] <cjwatson> (only install packages that were already installed)
[18:40] <Awsoonn> oh, yea that would have been good to know indeed
[18:42] <calc> cjwatson: hmm is -i0 documented anywhere? i didn't see it in the manpage
[18:43] <cjwatson> calc: O not 0
[18:43] <cjwatson> oh
[18:43] <cjwatson>        -O, --selected-only
[18:44] <cjwatson> linux-libc-dev fixed for most architectures (not armel/hppa yet), relevant buildds back to auto
[18:44] <calc> ok
[18:44] <cjwatson> give-backs have been queued, please tell me if you still see failures that indicate missing asm/*.h headers (do not tell me about any failure you happen to see!)
[18:44]  * calc definitely needs new glasses
[18:45] <calc> cool :)
[18:45] <cjwatson> and the publisher's back to auto as well
[18:53] <pitti> seb128: hm, I have used bzr+ssh://bazaar.launchpad.net/~gnome-power-manager-team/gnome-power/trunk
[18:53] <pitti> apw: ^
[18:54] <pitti> seb128: and that branch reflects what's in karmic
[18:54] <seb128> pitti: ok, apparently that's not uptodate
[18:54] <pitti> hm
[18:54]  * pitti pushes
[18:54] <pitti> oops, sorry
[18:54] <seb128> and I though we agreed to move it to ubuntu-desktop bzr?
[18:54] <seb128> not that I really care
[18:54] <pitti> seb128: can do, I don't mind much; would make sense
[18:54] <pitti> apw: so, if you uploaded something already, I'll just commit it
[18:55] <seb128> but to have a consistent namespacing
[18:55] <pitti> apw: anyway, it's current now
[18:55] <pitti> sorry
[18:55] <apw> pitti, nothing has happened, we are good
[18:55] <seb128> pitti: he's working on a jaunty sru so it will not be really useful
[18:55] <pitti> okay
[18:55] <pitti> apw: I went through my AH talk and ignored IRC
[18:55] <pitti> ah
[18:55] <seb128> which leaded to a discuss about stable versions and bzr
[18:55] <pitti> feel free to create a bzr branch if you prefer
[18:55] <pitti> if not, just ignore it
[18:55] <apw> yeah i am happy.  and know what to do
[18:55] <calc> yipee new linux-libc-dev is now available from mirrors :)
[18:56] <pitti> \o/
[18:56]  * calc rebuilds OOo locally to track down the other bug
[18:58]  * calc hopes to have OOo 1:3.1.0-1ubuntu1 done today if he can resolve the OOo gcj issue
[18:58] <pitti> oh, it's released? nice
[18:59] <calc> pitti: yea was released late wednesday but we then had the linux-libc-dev headers problem, and some sort of weird failure in building OOo due to gcj on a couple arches
[19:07] <Awsoonn> I'd like to share a bit of happienss in my world with you all... http://ubuntu.pastebin.com/d66e916ad
[19:10] <mterry> yay for linux-libc-dev, may you never die again
[19:11] <lamont> mterry: there have been some more interesting events in the past, to be sure, though
[19:12] <mterry> lamont: Fine.  How about, "May we live in boring times", then.  :)
[19:13] <lamont> heh
[19:14] <lamont> "oh meh.  rebuild the archive and then throw the old stuff away. kthx" being my personal favorite.
[19:14] <mterry> :)
[19:24] <maco> so uh, when syncing has the archive broken six-ways-to-tuesday and pbuilder can't pull dependencies does it make sense to test that packages builds by using jaunty?
[19:30] <cody-somerville> maco, sure
[19:31] <maco> ok thanks
[19:31]  * maco waits
[19:40] <geiseri_> grmbl... okay my installer starts now but it keeps complaining that ppoe is not installed.... even though i dont need it... did i screw something up in my preseed file?
[19:50] <geser> maco: but be aware that it might fail in karmic even if it builds in jaunty
[19:50] <maco> this early even?
[19:50] <maco> i didn't think they'd diverged that far yet
[19:51] <geser> new library versions or gcc-4.4 comes to mind
[19:53] <cody-somerville> Should one use ${source:Version} or ${binary:Version}? ${binary:Version} will only ever mismatch ${source:Version} if the binary specifies a specific version, right?
[19:53] <james_w> cody-somerville: or binary rebuilds in Debian
[19:54] <cody-somerville> james_w, so I should use ${binary:Version} for arch:all packages?
[19:54] <james_w> any -> all should be source:Version
[19:55] <james_w> any -> any should be binary:Version
[19:55] <cody-somerville> okay
[19:55] <cody-somerville> thanks
[19:55] <james_w> all -> any should be source:Version
[19:55] <james_w> I *think*
[19:55] <james_w> I know lintian knows the rules
[19:56] <james_w> the last shouldn't be an exact dependency though
[19:56] <geser> cody-somerville: http://lists.debian.org/debian-mentors/2006/09/msg00230.html and http://wiki.debian.org/binNMU should help you
[19:56] <cody-somerville> Thanks :)
[19:57] <james_w> *phew*
[19:59] <cody-somerville> guh
[19:59] <cody-somerville> This is going to get hairy
[20:00]  * cody-somerville is fixing a package with 46 occurrences of ${Source-Version}
[20:00] <cody-somerville> and mismatch of any and all packages
[20:01] <cody-somerville> Hopefully lintian will help me
[20:02] <cody-somerville> sweet, it does. :)
[20:05] <cody-somerville> james_w, geser: Whats more correct? Lintian suggests to do (>= ${source:Version}) instead of using ${binary:Version}.
[20:06] <geser> it probably depends on the use-case
[20:07] <cody-somerville> ok
[20:07] <calc> cody-somerville: >= ${source:Version} probably is better since it won't break cases where debian has to do binary NMU's (At least I think that is why there is a difference)
[20:07]  * cody-somerville nods.
[20:08] <geser> calc: but wouldn't that break -dbg packages? as you could use the -dbg package with a newer package
[20:09] <Awsoonn> now that I have a debdiff for bug #312396 uploaded should I subscribe someone or e-mail someone?
[20:09] <calc> geser: i'm not sure... wouldn't the dbg package be rebuilt as well in the debian case when a binary NMU is done?
[20:10] <calc> geser: the issue (i think) that source:Version vs binary:Version tries to solve is when there are dependencies between any and all packages in the same source
[20:10] <geser> calc: they would get rebuilt but the dependency wouldn't force to have matching versions installed
[20:12] <cody-somerville> should an all -> all use source or binary version?
[20:12] <calc> geser: ah well that is a good point in that -dbg packages probably should have binary:Version depends instead of source:Version, other things in particular any vs all packages shouldn't
[20:12] <calc> cody-somerville: this is probably documented somewhere better than just going by my opinion :)
[20:12] <calc> cody-somerville: though i think it should be safe using either for a all -> all dependency
[20:13] <calc> cody-somerville: was lintian telling you to use source:Version on dbg packages that depend on other any packages?
[20:13] <calc> if so that is probably a bug
[20:13] <calc> although if it isn't i would like to hear the reasoning for that :)
[20:13] <cody-somerville> No
[20:13] <geser> source:Version would be more correct but as there aren't any binNMUs for arch:all packages binary:Version should also work
[20:13] <cody-somerville> Its complaining about meta packages
[20:14] <cody-somerville> ex., not-binnmuable-all-depends-any pike7.8 -> pike7.8-core
[20:14] <calc> ok yea that makes sense
[20:14] <calc> any time you cross the all<->any line you don't want a binary:Version (afaik)
[20:15] <calc> or even a source:Version without the >= for that matter
[20:15] <cody-somerville> Won't the source version stay the same though?
[20:15] <cody-somerville> (everything is built out of the same source package)
[20:16] <infinity> cody-somerville: The arch:all package might not get rebuilt in a binNMU
[20:16] <infinity> cody-somerville: We don't actually DO binNMUs in Ubuntu, mind you, because all this mess annoys me.
[20:16] <cody-somerville> won't the source version for both the rebuilt any package and the not-rebuilt all package be the same though?
[20:16] <infinity> cody-somerville: But the correct thing for all->any is "Depends: package_any (>= SourceVersion)"
[20:17] <infinity> cody-somerville: No, source version gets the binNMU version on a rebuild.
[20:17] <infinity> cody-somerville: binNMU isn't magical, it just increments the source version and pumps through sbuild.
[20:17] <cody-somerville> I thought binNMU was just bumping the binary version and not the source version *specifically*.
[20:17] <geser> cody-somerville: yes, but you would probably be more strict than necessary if you use = source:Version
[20:18] <infinity> cody-somerville: There's no way to do what you think it does.
[20:18] <infinity> cody-somerville: binNMU is literally forcing the source version to rev slightly, then rebuilding.
[20:18] <infinity> geser: "= source:Version" breaks, period.  It's not just "too strict".
[20:18] <calc> infinity: you can rev the output version without changing the source version
[20:18] <cody-somerville> infinity, I thought the whole point of specifying the version of the source package was to allow for the binary version to mismatch the source version
[20:18] <calc> infinity: OOo does that itself
[20:19] <calc> infinity: at least for the case where source version != binary version
[20:19] <infinity> calc: You can specify versions yourself.  That's not what I'm talking about. :P
[20:19] <calc> infinity: ok
[20:19] <infinity> calc: The binNMU process literally just says "now our source version is 1.2.3-4+b1" and rebuilds.
[20:19] <infinity> calc: What your rules file does with that source version is up to you, obviously. :)
[20:20] <calc> infinity: won't that cause problems if a package has binary packages that has source:Version in it though?
[20:20] <calc> infinity: eg (package all) >= source:Version ?
[20:20] <infinity> cody-somerville: Yes, binary package versions and source versions can mismatch, and often do (see gcc-defaults for some serious fun there), but we're talking about different things here.
[20:21] <cody-somerville> oh, okay
[20:21] <infinity> calc: Hence why lintian has checks to make sure you don't use relationships that break on binNMUs. :P
[20:21] <infinity> calc: And now we've come full circle!
[20:21] <calc> infinity: hmm i thought it was suggesting to cody-somerville to put those in
[20:21] <calc> infinity: instead of using eg (package all) binary:Version
[20:22] <cody-somerville> It says to do: Depends: arch_any (>= ${source:Version})
[20:22] <calc> infinity: if it actually increments the source:Version then that would break any kind of dependency on arch all packages form an arch any package that tries to do a version
[20:22] <calc> cody-somerville: ok
[20:22] <infinity> calc: any->all should pretty much never have a strict source-version dep, no.
[20:23] <infinity> calc: all->any can have a source-version dep, but it needs to be >=
[20:23] <calc> infinity: any-
[20:23] <infinity> cody-somerville: Yeah, for your use case, that's correct.
[20:23] <calc> infinity: any->all is common on packages who have their shared data split out though, so was that case really not catered for?
[20:23] <infinity> calc: If you look at such cases, they never have strict deps.
[20:23] <cody-somerville> infinity, Would you be kind enough to review my control file after I sort out all the binNMU errors out from lintian?
[20:24] <calc> ah, well seems pretty boneheaded since that can easily cause major problems if not even the same upstream version is installed of the shared data :\
[20:24] <infinity> calc: (First case I could think of, readline... libreadline5 has an unversioned dep on readline-common)
[20:25] <infinity> calc: Like I said, there are reasons why I *always* push back against people who want to do binNMUs in Ubuntu, and it's not because I couldn't implement it in short order.
[20:25] <infinity> calc: It's all very messy for very little reward, IMO.
[20:26] <calc> infinity: yea
[20:26] <infinity> calc: From the any->all data perspective, though, my best solution (and I've done this in the past) is "Depends: foo-data (>= $Upstream-Version)"
[20:26] <infinity> calc: THat should tend to get you the correct data for the runtime, but not worry about debian revisions and other pain.
[20:27] <calc> is Upstream-Version a defined variable or something you have construct yourself?
[20:27] <infinity> There are lots of pre-defined ones now, and that may exist somewhere... I construct it myself, though.
[20:27] <calc> ok
[20:28] <\sh> a bit late...but congrats to 9.04...I was busy to congrats you all during release time :)
[20:30] <Laney> congrats to you, \sh!
[20:30] <cody-somerville> infinity, How does this look? http://pastebin.ubuntu.com/167087/
[20:31] <\sh> Laney: thx :)
[20:31] <infinity> Wow, pastebin.u.c has markup for control files?
[20:32] <infinity> Or maybe it just sees it as rfc822 and goes from there.
[20:32] <cody-somerville> infinity, sure does :]
[20:32] <infinity> cody-somerville: How is this changed from grendel's original control files?
[20:33] <infinity> cody-somerville: (I have a hard time believing his have been horribly broken for years...)
[20:33] <cody-somerville> infinity, They were all =${Source-Version}
[20:35] <cody-somerville> And the standards version was 3.6.2.1
[20:35] <infinity> cody-somerville: At a glance, it looks fine to me.
[20:35] <cody-somerville> infinity, Awesome, thanks
[20:41] <cjwatson> geiseri_: make sure your Packages file is sorted alphabetically by package. (Yes, really - there's a bug filed about this somewhere ...)
[20:42] <cjwatson> geiseri_: bug 362989
[20:43] <cjwatson> geiseri_: you can just take ppp-udeb off your image as another convenient workaround; you almost certainly don't need it
[20:45] <cjwatson> hppa buildds back on auto
[21:05] <cjwatson> infinity: could you do a mass give-back on ia64 and sparc? they weren't affected by the linux-libc-dev breakage, so lamont didn't do a give-back on them, but there was an earlier problem there which made little things like debhelper and gettext uninstallable (due to some component override breakage) and so I think a give-back would be worthwhile
[21:05] <infinity> cjwatson: Doing.
[21:06] <cjwatson> ta. I eventually figured it was probably a waste of time having me click around ...
[21:06] <infinity> cjwatson: Done.
[21:07] <cjwatson> hmm. can I do a mass give-back, seeing as I'm an archive admin and in launchpad-buildd-admins? or does it need direct access to the buildds?
[21:08] <infinity> cjwatson: You can probably do it, yes.  But you'd totally make me redundant if you did! :P
[21:08] <cjwatson> heh
[21:08] <infinity> Wow.  My brain just shot way in the past.  That can't be healthy.
[21:08] <cjwatson> (in theory, I know how to do manual builds of single packages on the buildds. that doesn't mean I want to.)
[21:08] <infinity> drescher.ubuntu.com: forward host lookup failed: Unknown host
[21:08] <infinity> ^-- Seriously, what now?
[21:09] <infinity> cjwatson: Anyhow, "buildd-mass-retry" as "lp_buildd" is the command you'd be after.
[21:10] <infinity> cjwatson: Seems to work from cocoplum just as well as cesium, so.. *shrug*
[21:10] <infinity> cjwatson: (And it behaves kinda poorly without arguments, so at least throw it a --help)
[21:10] <cjwatson> fair enough, thanks
[21:52] <jdstrand> slangasek, Riddell, kirkland, StevenK: has syncbugbot been working for you guys lately? it is failing with "message: An internal server error occurred. Please try again later."
[21:52] <slangasek> jdstrand: it worked for me on Monday, after I grabbed a fresh lpcookie
[21:52] <slangasek> LP had logged me out, the week before
[21:53] <slangasek> kirkland said it wasn't working for him after a cookie change, though, so maybe something else is broken since Monday
[21:53] <jdstrand> slangasek: yeah, I saw you mentioned that, but the sum on my cookie is the same
[21:53] <jdstrand> hrm...
[21:53] <cody-somerville> Whats the best way to deal with a package that requires its self to build?
[21:53] <slangasek> care to give me a bug num for one you're trying to sync, I'll see if it works for me?
[21:53] <jdstrand> slangasek: 371796 -f
[21:53] <slangasek> cody-somerville: the best way is to fix it so it doesn't require that. :)
[21:54] <slangasek> cody-somerville: the other option is to ask for manual bootstrapping by the buildd admins
[21:54] <slangasek> jdstrand: WFM
[21:55] <cody-somerville> slangasek, Does python require its self? I'm working on packaging pike7.8 and one of its module (which is included as part of pike) seems to require pike for a script it runs or something.
[21:55] <slangasek> python does not.
[22:15] <Adri2000> Keybuk: you around?
[22:16] <calc> what is the buildd url on lp?
[22:17] <cjwatson> calc: which buildd url?
[22:18] <calc> i guess i was looking for launchpad.net/builders
[22:18] <cjwatson> that's one possible meaning, yes :)
[22:18] <calc> ok :)
[22:18] <cjwatson> I thought you might have meant URLs for particular builds
[22:18] <calc> wow big queues
[22:19] <cjwatson> yeah, the give-backs will take a while to churn through
[22:49] <Adri2000> Keybuk: never mind
[22:49] <calc> ugh this OOo test build is taking forever :-\
[22:51] <Nafallo> calc: you act surprised?
[22:57] <calc> Nafallo: well it is taking longer than i expected, at 3.5hr and still unknown amount of time left
[23:23]  * TheMuso sighs in relief at the new ports kernel working.
[23:27] <calc> it finally finished and failed in the same way again
[23:27] <calc> it builds on amd64 but not on i386/lpia due to claim that libgcj.spec missing
[23:27] <calc> doko: ^
[23:28] <calc> /usr/bin/gcj -c -g -O2 -fPIC -findirect-dispatch -fjni LuceneHelpWrapper.jar.1.jar -o LuceneHelpWrapper.jar.1.o
[23:28] <calc> gcj: libgcj.spec: No such file or directory
[23:28] <calc> but its there: /usr/lib/gcc/i486-linux-gnu/4.4/libgcj.spec