=== dendrobates is now known as dendro-afk === asac_ is now known as asac === ScottK2 is now known as ScottK === aldeka_ is now known as aldeka === FourDoll1rs is now known as FourDollars [03:23] my cups client computer sees the shared printer on the cups server, but when attempting to print, the job is sent and nothing happens. === bkerensa_ is now known as bkerensa|laptop === bkerensa|laptop is now known as bkerensa_ === dendro-afk is now known as dendrobates [05:39] Good morning === htorque_ is now known as htorque === fasta__ is now known as fasta === SWAT__ is now known as SWAT [07:11] I have a package and two dependency packages which are new to ubuntu that I would like to file a feature freeze exception for. Should I submit one bug on launchpad for all three packages, or three separate bugs? [07:14] andy753421: I'd suggest using requestsync -e to file the requests and mention the main bug in the ones for the dependencies [07:14] andy753421: and the dependencies in the main one [07:16] micahg: wouldn't it be better to only have one bug? as either all 3 packages go in or none? === smb` is now known as smb [07:17] geser: well, if there are problems with any of the packages, it could get messy [07:18] * micahg should state that he is not a release team member [07:19] good morning [07:20] but you could see that in the one bug and don't sync the other parts by missing to check all three bugs [07:20] good morning dholbach [07:20] hey geser [07:21] geser: if sponsors aren't reading the bugs , don't we have bigger problems? [07:21] micahg: true [07:23] dear LP, please stop timing out; love, pitti [07:24] I wish the timeout would be raised at least for launchpadlib [07:24] scripts keep breaking because of it :/ [07:24] dholbach: I was visiting FroSCon this weekend and saw an interesting talk about "Perceptions of rudeness in Free Software communities" (http://programm.froscon.org/2011/events/717.html). The study was done on some Ubuntu forum threads. The talk was recorded but the recordings aren't online yet. [07:25] pitti: file bugs and sic bryceh on the LP team :) [07:25] it times out during searchTasks(), and I'm trying to run the retracer to reduce that very number of searchTasks() results :) [07:26] geser, thanks a lot for the pointer - I'll check it out [07:26] pitti, yeah the lplib timeouts have been annoying me as well [07:26] unfortunaetly there is no "limit" argument for searchTasks(), that'd be sufficient for me [07:26] if you ever find an oopsid, file a bug report on it; they always automatically set those to critical [07:27] x-lazr-oopsid: OOPS-2062O19 [07:27] ah, nice, it's part of the exception [07:27] will do [07:27] we'll probably move that to X-Oops-Id: soonish [07:28] pitti: we need to talk about apport & crash dump formats at some point. Maybe in 3-4 weeks? [07:28] lifeless: sounds good [07:28] pitti: searchTasks when you're iterating on a big set can end up with things that take *minutes*: raising the timeout there would have a very negative effect on LP as a whole [07:29] lifeless: do you know a workaround? [07:29] lifeless: something that just gives me the first 75 or 50 results or so? [07:29] don't iterate the entire batch :) [07:29] result = searchTasks()[:75] ? [07:30] anyhow, adeuring is -very- close to having something that will handle offsets much much better [07:30] it won't fix plain-poor queries but it will help large batches quite a bit [07:33] lifeless: [:75] is too late, though -- searchTasks() itself times out, not the iteration over the result [07:34] pitti: that means the first batch is failin [07:34] what are you searching for ? [07:36] lifeless: reproducer in bug 832566 [07:36] Launchpad bug 832566 in Launchpad itself "often times out on searchTasks()" [Undecided,New] https://launchpad.net/bugs/832566 [07:36] x-lazr-oopsid: OOPS-2062O19 [07:36] sorry [07:36] essentially: lp.distributions('ubuntu').searchTasks(tags='need-amd64-retrace') [07:37] ok [07:37] thats a dupe [07:37] its utterly buggered :( [07:40] lifeless: seems I can work around it by using "created_since='2011-08-01'", and then working my way backwards [07:40] cool === rickspencer3_ is now known as rickspencer3 === tkamppeter__ is now known as tkamppeter === mpt_ is now known as mpt [09:05] micahg: does this look alright? https://bugs.launchpad.net/ubuntu/+bug/832611 [09:05] Ubuntu bug 832611 in Ubuntu "Sync aweather 0.5-1 (universe) from Debian unstable (main)" [Undecided,New] === dholbach__ is now known as dholbach [09:10] i forgot the -e flag, so i added ubuntu-release manually afterwards.. [09:42] you should request those other syncs which need doing first separately [09:42] s/separately/explicitly/ [09:48] ah, you did :-) [11:25] janimo: have you actually uploaded livecd-rootfs 2.32? I don't see it in LP, but the branch is tagged [11:25] oh, maybe I'm just impatient. /me recalculates timezones [11:26] cjwatson, yes, uploaded a few seconds afetr bzr push [11:26] cjwatson, is there a recommended sequence? The other presumably :) ? [11:26] janimo, hello, could you take a look at the armel build of cogl? of course the configure-flags arent right yet http://anonscm.debian.org/viewvc/pkg-gnome/packages/experimental/cogl/debian/rules?r1=29484&r2=29483&pathrev=29484 [11:28] janimo, forgot this link https://edge.launchpad.net/ubuntu/+source/cogl/1.7.6-1/+build/2739607 [11:28] ricotz, I know we had issues with clutter in Ubuntu because of the backends [11:28] for some reason I thought cogl was part of clutter source [11:28] janimo, i cant build it myself [11:29] the cogl lib was split out from clutter [11:29] ok [11:29] and is now a dependency of it [11:29] I know with clutter we were waiting for an upstream fix that adds proper runtime backend selection (GL/GLES) [11:29] the patches in clutter were always messy [11:30] as we needed GLES/EGL to act as if it were GL/GLX but only at the .so naming level, even if the lib itself at the source level had certain assumtions - include file names IIRC [11:30] janimo, i removed quite all ubuntu patches for clutter since they were obsolelete or consider not-needed by upstream [11:30] janimo: no no, don't worry, you did it right, I just miscalculated the timezone and thought you'd uploaded an hour or more ago [11:30] janimo: push before upload is correct [11:30] ricotz, if they are obsolete that is great - if it means it builds fine with GLES2 on arm [11:31] (or rather, thought you'd tagged an hour or more ago) [11:31] janimo, yes, so that is why the configure flags specific for armel [11:31] cjwatson, ok. UDD still confuses me, and actually this was the first time I got it done with a single bzr uncommit. I am almost conversant in UDD now :) [11:32] janimo, it would be great if you could testbuild it with the changed configure-flags [11:32] and one bzr tags --delete, oh well [11:32] hmm, are environment variables not handed through from toplevel to bottom in live-build ? [11:32] generally should be [11:32] i added FLASH_KERNEL_SKIP=1 to the config a while ago, but flash-kernel is still executed [11:33] argh ! [11:33] ricotz, sure, I'll test and see if I find the issue [11:33] you forgot to export it [11:33] thinko ! ... update-initramfs is run chrooted [11:33] however - they aren't passed into the chroot [11:33] janimo, i could do it myself if there is a easy way to set up some armel-thing with qemu-system-arm? [11:33] I already abandoned that solution to that problem [11:33] no, i export it, but it doesnt seem to be hadned over by the chroot cmd [11:33] I thought I'd fixed it for you some other way [11:33] janimo, thanks [11:34] I definitely remember looking at that and I'm sure I ticked it off my list [11:34] well, i'll think about it, we werend in massive need of it until now [11:34] with the mx5 artch showing up it will try to update the buildd bootloader now though [11:34] *weren't [11:35] yes, I fixed it with a diversion in live-build [11:35] you might like to investigate why that isn't working [11:36] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630350 [11:36] Debian bug 630350 in live-build "divert flash-kernel aside while building the chroot" [Normal,Fixed] [11:37] it's possibly because lb_binary doesn't call lb_chroot_dpkg (and probably shouldn't) - I suggest you talk with Daniel Baumann about the best place for that diversion to go [11:37] a diversion is definitely a better way to handle this than an environment variable [11:38] ogra_: incidentally, you really don't export it, I checked, although that's irrelevant :) [11:38] cjwatson, oh, a diversion wont work anymore [11:39] it should do, it's just done in the wrong place ... [11:39] I suspect, anyway. I bet update-initramfs is being called in the lb binary phase? [11:39] its called from some lb_chroot_hacks script [11:39] pretty ugly that there is no function for it or some such [11:40] the diversion I added is in place when lb_chroot_hacks runs. [11:41] lb_chroot does (among lots of other stuff) lb_chroot_dpkg install; lb_chroot_hacks; lb_chroot_dpkg remove [11:41] lb_chroot_dpkg adds the diversion on install and removes it on remove [11:41] :q [11:41] (doh) [11:42] hmm [11:42] * ogra_ checks the logs again, i'm probably looking in the wrong place [11:43] bah, i indeed looked at a different update-initramfs call [11:43] the one in the hack script doesnt spill the error [11:45] where's the other call? [11:47] its manually added for ac100 in the build script in livecd-rootfs, i just need to make sure to export it inside the chroot call ... [11:47] that shouldnt be an issue, sorry for the noise, that was really silly [11:48] right, easy to add for that one case then [11:48] Daviey, RoAkSoAx: powernap currently wants to go to universe, is that intended? [11:49] please remove it from live-build/auto/config again to avoid anybody being confused into thinking that works [11:49] yep, will do [11:49] Daviey, RoAkSoAx: it's also uninstallable in main right now, don't know yet why [11:50] pitti: No, I've made RoAkSoAx aware.. and we are currently looking at directly seeding or making it a depends. [11:50] Daviey: ok, thanks === MacSlow is now known as MacSlow|lunch [11:51] pitti: I'd rather keep the seed minimal and rely on depends for that. [11:51] Daviey: well, powernap at least sounds like the kind of "top level pacakge/feature" which are appropriate for seeds [11:51] but your call [11:52] cjwatson: can I just remove the webbrowser dependency completely? a browser is kind of assumed these days [11:54] pitti: Yeah, previously it was included as it was a required depends of eucalyptus, the same requirement hasn't yet been added to openstack. So really, i wouldn't be too upset if it was demoted - but the fact that next cycle it will hopefully bounce back to required, makes it silly to demote IMO. [11:54] Daviey: right, we just need something to hold it in main, so seeding seems appropriate [11:55] pitti: ok, i'll add it now. [11:56] jbicha: no, packages must depend on anything they need outside the Essential set, and a browser is not Essential [11:56] jbicha: the fixed version should only be two characters away from your initial MP [11:57] cjwatson: ok [12:23] jelmer: i saw that you moved everything to lptools. when will you release lptools? the u-d-t branch pull will depend on the release of lptools. [12:24] jelmer: let me know if you need a review of that package and a debian sponsor. === renate is now known as glatzor_u [12:26] bdrung: I mainly need to coordinate with lifeless, who is the package maintainer of lptools in Debian [12:26] bdrung: jelmer is a dd ;-) [12:31] i wasn't aware that lptools is available in debian [12:35] ScottK: any luck with the k3b libav patch? [12:36] cjwatson: I didn't hear back. Let me ping my tester again (I'm in a $WORK meeting all day today with no DVD player handy). Thanks for double checking. [12:39] do any of you filter 'Branch linked' emails from launchpad? what are you looking at? [12:41] jelmer: packaging-dev 0.2 uploaded (which recommends lptools) [12:42] bdrung: awesome, thanks :) [12:42] np [12:42] jelmer: now it's time for you to make it worth recommending ;) [12:44] bdrung: :) I'll talk to lifeless about lptools in Debian this evening [12:44] great === amitk_ is now known as amitk [12:45] I think I might be able to use a combination of 'X-launchpad-bug-modifier: Launchpad Janitor (janitor)' and 'Message-id: ...@ackee.canonical.com>', but that seems both brittle and perhaps too heavy-handed... [12:46] jelmer: can you update the branch for u-d-t? [12:52] bdrung: to mention what we've just discussed you mean? [12:54] jelmer: to remove the last three moved tools. [12:55] * jdstrand attempts http://paste.ubuntu.com/673796/ [13:07] o scapy: python-scapy [13:07] [Reverse-Depends: powerwake-common] [13:07] Daviey: ^ ah, that's why it's uninstallable [13:08] Daviey: universe dependency [13:09] jdstrand: a bug asking for a header might be useful ;-) [13:09] or a more descriptive From: or whatever [13:13] Laney: yes [13:16] ricotz, it builds fine with that config option change, but at .deb creation it fails in dh_makeshlibs. That in turn is easily fixed by foloowing what it suggests. [13:16] where should I file the bugreport and the diff? Or shall I upload? === MacSlow|lunch is now known as MacSlow [13:19] pitti: what releases are we still running retracers for? [13:20] mdeslaur: right now, oneiric; once that has caught up, I'll configure it for lucid/maverick/natty as well [13:20] mdeslaur: it's now dead cheap to do so, but retracing the oneiric ones is more urgent at this point [13:20] gstreamer pipelines that used gconfaudiosink no longer work as this is not installed by default on oneiric, the obvious replacement (gsettingsaudiosink) is in gstreamer-plugins-bad and thus also not installed by default, will either one of these be included in the default install eventually? [13:20] pitti: ah, ok, thanks! [13:20] mdeslaur: as the reports deterioate fast (unlike the stable ones) [13:20] * jdstrand files bug requesting 'X-launchpad-bug-branch-linked' (or similar) in bug 832753 [13:20] Launchpad bug 832753 in Launchpad itself "please add email header for "** Branch linked..." emails" [Undecided,New] https://launchpad.net/bugs/832753 [13:20] pitti: thanks for fixing the oneiric one btw :) [13:21] jdstrand: actually, filtering these out wouln't be hard, but it's nontrivial to filter emails which *only* have that message without anything else [13:21] mdeslaur: my pleasure; was a 13 hour hack session yesterday to rewrite them, but I'm quite pleased with them now; it's sooo much easier [13:21] mdeslaur: in bug 832740 I also asked to get the new goodness into oneiric [13:21] Launchpad bug 832740 in apport (Ubuntu) "FFE: chroot-less apport-retrace" [Undecided,New] https://launchpad.net/bugs/832740 [13:22] pitti: yes-- I was trying to avoid a body search [13:22] and this is also why my current attempt is putting them in a folder, rather than deleting them :) I have no idea if my current recipe is too heavy-handed [13:22] roadmr, -gconf should be installed by default since gnome-media depends on it [13:23] seb128: oh, let me check again then, thanks for the heads-up! [13:25] roadmr, it's on the manifest of the daily livecd build [13:25] seb128, you're right, it's there. I just hadn't checked recently. Thanks and apologies, I should check things are still bad before asking :) [13:26] roadmr, no worry ;-) [13:28] ricotz, uploaded, thanks for the fix [13:31] janimo, thanks, to oneiric? [13:33] janimo, alright, i will add your changes to debian later for a 1.7.6-2 [13:39] pitti: ah [13:40] ricotz, yes, oneiric [13:41] ev, cjwatson: today's desktop CD boots straight into the live session, whereas previosu versions defaulted to the "install / try" dialog from ubiquity; is that intended or a bug? [13:41] bug [13:42] pitti: /var/log/installer/dm might have the error [13:42] ok, step 2: make kvm not freeze the guest when booting it [13:46] (EE) Failed to load module "vmwgfx" (module does not exist, 0) [13:46] (EE) vmware: Please ignore the above warnings about not being able to to load module/driver vmwgfx [13:46] (EE) open /dev/fb0: No such file or directory [13:46] ev: ^ is the /dev/fb0 error relevant? [13:46] nope [13:46] after that I see two DBUG statements for launching the a11y bus, then it ends [13:46] not to my knowledge [13:46] anything in syslog or /var/log/installer/debug? [13:48] http://paste.ubuntu.com/673825/ -> syslog; v/l/i/debug doesn't exist [13:48] cjwatson: is there a way to see if I blacklisted a card correctly in grub-gfxpayload-lists? (e.g. in some logs) [13:48] ev: actually I was trying to reproduce bug 831884 ; maybe that's related somehow [13:48] Launchpad bug 831884 in lightdm (Ubuntu Oneiric) "lightdm fails to start on Live CD on intel: [drm] failed to set drm interface version (plymouth race ?)" [Critical,Confirmed] https://launchpad.net/bugs/831884 [13:52] pitti: anything in /var/crash? :) [13:53] ev: oha :) _usr_bin_ubiquity-dm.0.crash [13:53] that _might_ be related :) [13:53] pitti: :-P [13:53] pitti: hey, did you guys get PowerNap seeded? [13:54] kirkland: hey, how are you? [13:54] kirkland: Daviey said he was going to [13:54] ev: bug 830061 [13:55] Launchpad bug 830061 in ubiquity (Ubuntu Oneiric) "ubiquity-dm crashed with AttributeError in run(): 'Pixbuf' object has no attribute 'render_pixmap_and_mask'" [High,Triaged] https://launchpad.net/bugs/830061 [13:55] pitti: hey man, good! yourself? [13:55] splendid, thanks! [13:55] tseliot: you can run whatever the hwmatch command is by hand and look at the exit code [13:55] pitti: kirkland thinks it's a desktop problem, suites me :) [13:55] pitti: thanks [13:55] tseliot: if you don't have access to the machine, there are no logs - grub doesn't write to the filesystem [13:55] ev: should've looked first, sorry for bothering [13:55] pitti: no worries at all; glad to help [13:59] cjwatson: and that hwmatch command is run by grub, isn't it? [14:03] cjwatson: I'm asking as I can't see anything in the grub-gfxpayload-lists package which could do it [14:08] tseliot: yes [14:08] /etc/grub.d/10_linux [14:09] anyone have thoughts on how i can create a static executable of http://paste.ubuntu.com/673848/ . [14:10] if I do so with simple 'gcc -static' the executable is 700k. [14:10] cjwatson: that's exactly what I was looking for. Thanks a lot [14:10] i just need to be able to make that ioctl call in a limited busybox environment (ie, no perl or python) [14:12] ev: it seems the ubiquity window grew recently? starting it on a 1024x600 netbook doesn't work well any more, the bottom button bar is missing and there is no way to resize it [14:13] pitti: indeed, I've noticed that as well. It's on my list of things to fix [14:13] ah, good; thanks [14:13] alt + click and drag for the meantime [14:15] doko_, might you have thoughts on above ? slangasek ? [14:15] smoser: might it be easieer to fix busybox? [14:15] *easier [14:15] :) [14:15] busybox *does* have what i need. [14:16] but ttylinux doesnt build with it, and i'm just re-bundling ttylinux. i wanted to avoid rebuilding it. [14:20] smoser: what do you mean, "Build with it"? [14:21] it seems like if buysbox's ip implementation already supports this, then you're set [14:22] as for the size of static builds, no idea except for running 'strip' [14:22] yeah, strip -s ran [14:22] and building with -Os [14:23] busybox already supports the 'ip' command, but the busybox built for ttylinux does not have that enabled. i'm really just stealing their root and re-purposing. [14:23] i dont want to re-build their entire distro or busybox if i can avoid it. [14:24] ah [14:25] i was hoping someone woudl point me at an easy to use pre-built uclinux tool chain [14:26] or some other trvial solution. [14:26] arent we actually using klibc's ip command in the initrd ? [14:27] i dont know. all my ubuntu initrds have busybox [14:27] they also have klibc :) [14:27] but i messed that up, it was ipconfig klibc delivers, not ip [14:28] i didn't realize klibc provided binaries. i thought just "kernel libc" [14:29] klibc-utils provides binaries iirc [14:30] yeah. i see that now. === tkamppeter_ is now known as tkamppeter [14:57] infinity: any idea if the new ghc6 makes https://launchpad.net/ubuntu/+source/haskell-lexer/1.0-2build1/+build/2548362 any more likely to succeed if retried? [14:58] slangasek: ghc6->ghc surely ... [14:59] (though OK, having looked at that log I don't know) [15:00] ah, it's no longer 6, is it, ok :) [15:04] slangasek:no idea, and stuck on a mobile phone in a doctor's office. :) === doko_ is now known as doko [15:05] Sweetshark, will you one more LO upload before the beta freeze? [15:07] Sweetshark: it'd be good if you could look over the entries in http://people.canonical.com/~ubuntu-archive/nbs.html where libreoffice binaries are depending on binaries that are no longer built from source, and see if any of your dependencies need tidying up [15:07] TIA [15:11] anybody know why mdadm has *no* udd branches at all? [15:13] SpamapS: yes [15:14] SpamapS: http://package-import.ubuntu.com/status/mdadm.html , and know you know aswell :) [15:14] now you* [15:15] Thats what the computer knows. Please translate to *human*. [15:16] infinity: i.e., "no idea sent from my iphone"? [15:16] * SpamapS has become woefully dependent on using branches [15:17] SpamapS: bug #248459 seems to be as far as it got. [15:17] Launchpad bug 248459 in Ubuntu Distributed Development "bzrlib.errors.DuplicateKey when importing debian" [Medium,Confirmed] https://launchpad.net/bugs/248459 [15:17] doko: Im trying to get one out. [15:18] jtaylor, could you keep the bug task and set it to invalid, so that I still the report for the package? [15:25] cjwatson: you didn't happen to push the recent grub-gfxpayload-lists natty upload to bzr? I've one more device id to add to the lenovo blacklist [15:27] doko: you mean keepass2? [15:28] jtaylor, yes [15:28] k set to invalid [15:28] Sweetshark, please apply my armel hack, if you don't have time for a proper solution [15:29] Is it ok to use /run directly in oneiric BTW? [15:30] Specifically in initramfs scripts [15:31] SpamapS: yes, but follow the dependency rules in http://wiki.debian.org/ReleaseGoals/RunDirectory [15:32] cjwatson: ty thats what I needed [15:32] tseliot: lp:~cjwatson/ubuntu/natty/grub-gfxpayload-lists/natty-proposed - that'll have to do [15:32] Sweetshark, hmm, maybe better remove the .so explicitly [15:34] cjwatson: oh, nice, for the SRU [15:35] Also, is it acceptible to just add -Wno-unused-but-not-set-variable to CXFLAGS to work around bug 829463? Seems like this late in the game introducing a big patch would be a folly. [15:35] Launchpad bug 829463 in mdadm (Ubuntu Oneiric) "mdadm version 3.1.4-1+8efb9d1ubuntu5 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/829463 [15:36] doko: that patch looks strange, why the added make call? [15:37] Sweetshark, I did say `hack', not `patch' [15:37] doko: ping, looking for a power user who can bump the score on https://launchpad.net/~unity-team/+archive/compiz-testing/+builds?build_state=pending [15:37] doko: yes, but still:why? [15:38] Sweetshark, to install the linker script [15:38] SpamapS: or nuke -Werror from orbit [15:39] dbarth, done [15:39] cjwatson: it really is the only way to be sure.. :) [15:39] SpamapS: although, yes, IMO killing the specific warning is acceptable too [15:39] doko, can you score https://launchpad.net/~ubuntu-desktop/+archive/ppa/+sourcepub/1909476/+listing-archive-extra as well? thanks [15:40] fyi, test rebuild on amd64 is done [15:41] doko: danke sehr! [15:41] seb128, done [15:41] doko, thanks [15:44] Sweetshark, ahh, I should check the return code from the first build ... [15:46] doko: my approach was: it seems the only reason those files are there is to unprelink them if they are prelinked, so as we are not prelinking anything on arm, not putting any files in the solver should work, shouldnt it? [15:46] Sweetshark, sure [15:46] at least sal builds fine without them [15:46] Sweetshark, we don't prelink on ony arch [15:53] anybody around who deals with wiki.ubuntu.com - I'm looking at openid integration with login.ubuntu.com on another moinmoin wiki [15:56] mtaylor: #ubuntu-website is probably where you want, and isd is the team. [15:56] Daviey: ah sweet. thanks [15:56] Daviey: and I just sent you a (very long) email [15:58] slangasek: hi, I've just requested an SRU for nvidia-common in Natty (bug #825259). This should save us a few crashes on dist-upgrade. The sooner the package gets in, the better. [15:58] Launchpad bug 825259 in nvidia-common (Ubuntu Oneiric) "File "/usr/lib/python2.7/dist-packages/NvidiaDetector/nvidiadetector.py", line 87, in __get_value_from_name v = int(name) - ValueError: invalid literal for int() with base 10: '173-updates'" [High,Fix released] https://launchpad.net/bugs/825259 [16:00] doko: attach'ed a simpler and a bit cleaner patch to the bug [16:04] Sweetshark, thanks, could you start a build on davis? [16:04] doko: I tried to, but got lots of 404s when trying to install deps :( [16:05] doko: Ill try again later. [16:05] cjwatson, is there are recipe for regenerating the casper initramfs correctly using initramfs tools ... i am trying to test a change in the compcache stuff [16:06] Sweetshark, running sudo apt-get update && dist-upgrade usually works. if not, ping the vanguard [16:06] doko: thanks for the tip, Ill give it a try. [16:07] apw: install casper, update-initramfs -u [16:07] (perhaps in a chroot ...) [16:08] apw, could you make sure that the kernel header issue is fixed in the next upload? leading to build failures [16:08] cjwatson: a shiny new hat for you to wear? grats :-) [16:08] cjwatson, ahh sensible yes [16:08] doko, there is a kernel header issue ? [16:08] doko, got a bug # ? [16:09] apw, bug #824377 [16:09] Launchpad bug 824377 in linux (Ubuntu Oneiric) "ftbfs on i386" [High,Confirmed] https://launchpad.net/bugs/824377 [16:11] doko, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+sourcepub/1909617/+listing-archive-extra please, and I'm done for today :-) [16:12] seb128, done [16:12] thanks [16:13] doko, it would be helpful to include the ftbs link [16:14] Laney: it's got a D on it [16:14] and a lovely swirl [16:17] doko, can you point me at the rebuild archive (i assume that is where this failure is) [16:19] apw, https://launchpad.net/ubuntu/+archive/test-rebuild-20110816/+build/2694433 === beuno is now known as beuno-lunch === dendrobates is now known as dendro-afk [16:28] tkamppeter: m2300w uploaded to Debian included most (if not all) your changes. [16:30] slangasek, about? you helped do the multiarch conversion on the kernel headers. am trying to work out how the include paths are modified for a build when multiarch is in play [16:32] apw: on the phone, but what's the issue? [16:34] slangasek, i have a build which includes asm/posix_types.h (i believe) and that is found in /usr/include/i386-linux-gnu/asm/posix_types.h just fine. it includes "posix_types_32.h" which then fails, this file is in the same directory [16:35] note is uses the #include "x" syntax [16:35] apw: is this a kernel build failing? [16:36] shouldn't be if it's looking at /usr/include, yah? [16:38] slangasek, this is a gnat compilation, it is using the linux-libc-headers (which are multiarch now), includes something which #includes which in turn includes which works, which in turn includes "posix_types_32.h" which does not [16:38] where the last two are in the same directory [16:39] so in part i am trying to work out how it even finds the asm stuff, i am presuming that we have -I/usr/include -I /usr/include/ on the default options ? [16:40] apw: right, I think doko was looking at the gnat issue already - it's because of the use of #include "posix_types_32.h" instead of #include , combined with a particular cpp option that gnat is passing [16:41] the /usr/include/, /usr/include/ are the built-in gcc/cpp path [16:41] slangasek, ok so this combination works ok in the normal run of the mill compilations, so as you say it must be gnat specific [16:41] slangasek, what option is it using? [16:41] no, it's specific to -I- [16:42] but gnat is passing the -I- option that causes "" #includes to *not* use the default behavior of looking in the same directory as the parent include [16:42] ok which means what ? [16:42] and we think its reasonable for us to cope with that ? [16:42] apw: the kernel headers should work even when -I- is used - i.e., all includes should be #include , not #include "header.h" [16:43] well it'd have saved me a bunch of time if any of this was in the bug === dendro-afk is now known as dendrobates [16:45] slangasek, thanks for the help, will go poke it [16:45] apw: ok, thank you :) [16:46] apw: fwiw, seems there are only two affected headers: unistd.h, posix_types.h [16:46] slangasek: are you ok with my changes ^^ [16:46] (grep '#[[:space:]]*include[[:space:]]\+"' /usr/include/i386-linux-gnu/asm/*) [16:47] tseliot: sorry, missed the highlight! let me see [16:47] slangasek, will have a poke about, we'll need to get this mantra fixed upstream [16:47] slangasek: thanks [16:50] tseliot: this is the SRU that's been uploaded? [16:54] slangasek: yes, the nvidia-common in natty-proposed is the one I mentioned in my SRU request [16:58] tseliot: the upload seems to include changes unrelated to this bug (e.g., the multiarch class) - that doesn't appear to be consistent with the SRU rules [16:58] tseliot: could you please cherry pick the upgrade-breaking bugfix? [17:00] slangasek: I had thought about doing that but ok. Do you mind if I also disable the kernel hook and the debconf interface (to be sure that the fix covers all cases)? === _LibertyZero is now known as LibertyZero [17:02] slangasek: the actual fix is just two lines of python code but I'd really feel more comfortable having these 2 things disabled/removed too ^ [17:03] this is the python fix: https://github.com/tseliot/nvidia-common/commit/fb38f30927173e45ead1c3d45afe6548d66c8eb1 [17:04] Hrm.. sponsor-patch should be able to figure out that I want to sign things with my default key.. [17:05] [rant] Has this lightdm thing heard of a cursor? [I feel better now!] [17:05] slangasek: and the other two changes that I mentioned are: https://github.com/tseliot/nvidia-common/commit/1cdb3ea13d912a9d28793d978c3173a8cb47a67d and https://github.com/tseliot/nvidia-common/commit/c025b9a57d0d2b2d93360ecc2b4ec8837db7a400 [17:10] tseliot: for removal of obsolete config files, we normally want to preserve any local changes the user might have made; unless there's a specific reason you believe no one would ever care about keeping a copy of local changes they might have made to this script, please see dpkg-maintscript-helper(1) [17:11] (and please pay close attention to the pre-depends: requirement if you use this interface) [17:11] tseliot: what's the rationale for getting rid of the debconf interface? [17:12] pitti: it is incredibly frustrating that a bug filed 16 hours ago has been closed invalid by the retracer because "some outdated packages were installed on [my] system at the time of the report". [17:13] pitti: actually, it seems most of what it complains about is *debugging symbol packages* being out of date - are we having a ddeb problem? https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/832454/comments/5 [17:13] Ubuntu bug 832454 in gnome-settings-daemon (Ubuntu) "gnome-settings-daemon crashed with signal 5 in xkl_process_error()" [Undecided,Invalid] [17:13] slangasek, well it's the reality [17:14] slangasek: it was meant to deal with the transition from some rather old nvidia driver packages (back when we still used diversions instead of alternatives) to new package names when users dist-upgraded from the command line. Now I don't think we need it any more. The debconf interface simply warned users when the old package were still installed [17:14] slangasek, no we don't, we just got a new gnome-settings-daemon between the time you sent your bug and the retracing [17:14] I didn't know dpkg-maintscript-helper though... [17:19] seb128: we got *lots* of new things between the time it was sent and the time the retrace happened; a 16-hour queue for retracing doesn't seem unrealistic even under normal circumstances, and having the retracer throw it out instead of pulling the old binary to get a backtrace makes for a really poor experience, especially on a bug like this that has literally been happening on my system daily for the past month [17:20] I understand the need to turf bugs that you're not going to get to, but the retracer's current behavior effectively makes it a waste of my time to file these with apport instead of getting the backtrace myself [17:20] anyway, there's also the output there saying that dbgsym packages are out of date, which is worrisome [17:21] i thought that there was no way to get ddebs for superceded packages === beuno-lunch is now known as beuno [17:22] I don't think the ddeb archive is even that smart - I thought it expired ddebs based on age [17:22] (it really needs to get integrated into LP...) [17:23] * slangasek upgrades gnome-settings-daemon, so that the next time it crashes he has a shot at getting it retraced [17:24] OdyX, thanks. About which of my changes are you in doubt whether you have included them? [17:25] slangasek: but, if you prefer, I'll pull in only the 2 lines fix. We're still going to get some unexplainable crashes when the kernel hook (and its debconf interface) kicks in though. [17:27] tseliot: it's fine to include those, just please use dpkg-maintscript-helper to properly dispose of the conffile [17:27] slangasek: that can't be right - there are still packages in the ddebs archive from the lucid release pocket [17:28]