[00:11] can someone review python-jsonschema its been sitting in new for a while now and its needed for glance [00:37] Someone mentioned at UDS there's a way to tag patches as forwarded (or not or notneeded) to Debian, separately from forwarded upstream. I don't see this immediately in the packaging guide or in DEP-3, what's the syntax? [00:38] geofft: Bug-Debian: ... [00:38] I see the Bug-Debian etc. field. I guess that's usable for the same thing [00:39] the debian bug is the appropriate place to forward the patch, so if you are mentioning the bug, you shuold forward the patch there too. [00:39] Hrm. I would have interpreted Bug-Debian as "this fixes this Debian bug", not as "the pull request for this patch is this Debian bug", but there's not a huge difference [00:40] Debian doesn't have pull requests [00:40] i.e. if you have a wishlist feature request that doesn't solve an existing bug. I guess you should go file a wishlist bug, yeah [00:40] (unless the packaging is in a non-alioth-hosted VCS somewhere that does) [00:40] The one thing that Bug-Debian doesn't provide is a "not needed" option [00:41] then you are going to mention that it's ubuntu-specific in the Description and have a Fowarded: not-needed, anyway [00:41] the way you forward a patch to debian is by opening a bug, with a patch... [00:41] oh, and I see that the implicit value for Forwarded is conditional on the Bug field. [00:42] okay, I can see that way of thinking [00:42] well, you could have Ubuntu-specific patches that should get forwarded upstream, e.g. if Ubuntu has some random person's patchset and Debian doesn't [00:43] fair enough, but that's non-ideal in the first place :) [00:43] first example that comes to mind is a patch to overlayfs; Debian doesn't need it forwarded but upstream does [00:43] (the kernel is special, admittedly, but you can imagine it happening elsewhere) [00:44] If it's suitable for upstream, it's suitable for Debian (except in the case of software that just isn't *in* Debian, which renders the above conversation moot). [00:44] If it's not suitable for other downstreams, it's not suitable for upstream. [00:45] I think the other suboptimality might be that you could use Bug-Debian to say "this fixes this Debian bug, but I didn't actually make a comment on the Debian bug saying as much" [00:45] but then you're just being a jerk. [00:47] we mostly enforce that socially [00:49] yeah, fair enough, I'm convinced that Bug-Debian is what I actually care about and the exceptions are sufficiently rare === jalcine is now known as Jacky === pp7 is now known as malkauns [02:39] barry: yay (re launchpadlib py3k porting INPROGRESS) [02:45] and we're getting queue control! [02:47] orly? I missed that [02:47] broder: I'm only working on upload permissions so far [02:48] But it's a start [02:48] Haven't quite figured out how it works when people have queue admin for only part of a queue; no doubt I'll get there ... === scarneiro_ is now known as scarneiro [03:06] tumbleweed: i just saw cjwatson mark the relevant bug as in progress :) [03:07] broder: bug 648611 (kind of mistitled) is the bug for the queue admin side of it [03:07] Launchpad bug 648611 in Launchpad itself "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611 [03:07] oh, hmm [03:07] i wonder why i decided that bug #914779 was exciting [03:07] Launchpad bug 914779 in Launchpad itself "Pocket maintainers cannot always upload to their pocket" [Low,In progress] https://launchpad.net/bugs/914779 [03:08] i guess that's for ubuntu-backporters should be able to upload to all of -backports? [03:08] kind of stopped caring once i got core-dev :-P [03:08] Ye [03:08] s [03:09] And other such things; ultimately it should let us get rid of the hardcoding of ubuntu-security in LP [03:09] Though that requires a bit more considerably more complicated work [03:10] Anyway, the DB column is the same for upload and queue admin, I just didn't want to try to do both in the same branch [03:16] cjwatson, is there *any* part of ubuntu you don't work on? ;) [04:08] siretart: oh i must have missed that further in the log, i'll re-read the rest. as for the internal copy of ffmpeg, they have some code they have forked for now that their delta doesn't make sense upstream but they need internally when used with DVB of sorts [04:08] so while it is possible to link to a system ffmpeg it will certainly break [04:09] StevenK, woot [07:42] cjwatson, hi, is there a clean way in grub-mkconfig snippets to modify an existing line in an already generated part of the config file - to remove a boot cmdline argument to be precise? [07:44] to be even more precise the vthandoff=7 part should be deactivated in a custom build and currently a grub-mkconfig hook is sedding the grub.cfg.new file but that does not always work [08:09] does anyone know if a feature like https://www.youtube.com/watch?feature=player_detailpage&v=TRIyqLrwXVY#t=4s is planned? [08:10] (ie dragging to the corner to get the window to lock to 1/4th of the screen) [08:12] Kalidarn: that's already doable with compiz (grid plugin) [08:13] oh awesome, last time i used ubuntu you could only do 1/2 a screen like in windows 7. [08:14] Kalidarn: download the compizconfig-settings-manager and change the resize actions in the grid plugin: http://img.xrmb2.net/images/271735.png [08:15] ah, thankyou very much. [08:15] np :) [08:19] Kalidarn: be *careful* [08:20] Kalidarn: ccsm can really break unity [08:21] fair enough, i'll know what caused it to break if it does. [08:45] mm, i wonder hwo 11/close [08:45] oops === Mez_ is now known as Mez [10:53] * apw just did an install and at the end it says 'downloading langpacks' and later 'installing langpacks' but if i look its actually also installing libreoffice en-toto, is that expected [11:04] apw: suspect you might find that's an upgrade [11:05] janimo: in general, no - the text has already been generated but there's no guarantee that it's been flushed [11:06] janimo: if you don't mind changing gfxpayload as well, you could just emit 'set linux_gfx_mode=text' perhaps [11:14] jquery-ui-themes wins the prize for today's silliest binary package names. [11:14] I: jquery-ui-themes -> libjs-jquery-ui-theme-hot-sneaks_1.8.18+dfsg-1. [11:14] I: jquery-ui-themes -> libjs-jquery-ui-theme-le-frog_1.8.18+dfsg-1. [11:14] I: jquery-ui-themes -> libjs-jquery-ui-theme-swanky-purse_1.8.18+dfsg-1. [11:23] cjwatson, would set linux_gfx_mode=text imply a non-graphics splash? [11:30] janimo: No, just a text-mode handover from GRUB to the kernel [11:33] cjwatson, would this make the change to vthandoff unnecessary? [11:33] I think the issue with vthandoff was it caused black screen with a poulsbo-like driver [11:33] tseliot, ^ ? [11:35] janimo: 'set linux_gfx_mode=text' has two effects: it causes 'set gfxpayload=text' rather than 'set gfxpayload=keep', and it drops vt.handoff=7 === yofel_ is now known as yofel [11:40] It'd be great if somebody in the MIR team could review jbigkit (bug 993304); it's blocking a few things now. [11:40] Launchpad bug 993304 in jbigkit (Ubuntu) "[MIR] jbigkit" [Undecided,New] https://launchpad.net/bugs/993304 [12:21] cyphermox, hey ... i have a pile of machine on my local lan which keep disconnnecting and reconnecting to the network (its an ipv4/ipv6 dual stack), the first thing i see is NM saying device state change to failed due to ip-config-unavailable; am wondering if you have any advice as to how to debug [12:40] janimo, cjwatson: it's the gfxpayload=text part that I'm trying to avoid [12:44] tseliot: so just emitting 'set linux_gfx_mode=text' is probably what you want to do [12:47] cjwatson: well I would need 'set linux_gfx_mode=keep' but how would you suggest that I do it? [12:48] Oh, sorry, misunderstood [12:48] =keep will leave you with vt.handoff=7 by default [12:49] I assume you're trying really really hard to avoid modifying /etc/grub.d/10_linux directly, since that's easier than this hackery [12:49] But you *could* perhaps redefine the gfxmode function in a later grub-mkconfig hook [12:49] yes, probably that's the easiest [12:49] To just something like [12:49] function gfxmode { [12:49] set gfxpayload="$1" [12:49] } [12:50] pitti: Am I right in thinking that ~lp_queue/manual-queue/ was only ever used for langpack uploads, and that we no longer do them that way? [12:51] There was a rejected set of langpack uploads in there from something like 2007, which I removed, and nothing else in evidence [12:56] "/usr/include/i386-linux-gnu/bits/string3.h:103:1: error: inlining failed in call to always_inline 'strcpy': function not inlinable" is this an error in the package itself? or somewhere else? and how to fix it? [12:56] https://launchpadlibrarian.net/104397135/buildlog_ubuntu-quantal-i386.libcitadel_8.05-1_FAILEDTOBUILD.txt.gz is the build log [13:08] apw: i'll have a patch for you to test in a few minutes [13:20] cjwatson: where would I call that function from? [13:20] gfxmode [13:23] tseliot: You don't need to, the fragments generated by 10_linux do so [13:24] cjwatson: but wouldn't I still get vt.handoff=7 this way? [13:25] tseliot: Not if you redefined gfxmode to not set vt_handoff to anything [13:26] cjwatson: ok, I get it now. Thanks [13:28] cjwatson, but redefine it in a hook prior to 10_linux so it takes precendence? === rsalveti` is now known as rsalveti === tkamppeter_ is now known as tkamppeter [14:09] is merges.ubuntu.com being fully deprecated now? [14:10] roaksoax: Not at all! [14:11] roaksoax: It's just having hardware trouble which I've been trying to work through with IS. It looks as though it'll need a replacement machine. [14:11] cjwatson: ah! I see now. I was just wondering why the lists were outdated! But thanks for the clarification! :) [14:12] roaksoax: not that I know of, I know that is has (had?) hardware issues [14:13] cjwatson: would it be possible to add a note about it on the MoM frontpage till it got fixed? [14:21] cjwatson: would it be more straightforward to move merges to the cloud somehow? [14:22] slangasek: we need persistent storage for the results, but the cloud can do the merge attempts. [14:22] right [14:24] * xnox cloud tends to have holes in the floor, which make valuable files drop off the cloud. [14:24] slangasek, cjwatson: merges needs to be a trusted machine, since some people rely on the tarball that is generated. Else, we need to throw the tarball away and just keep the report. [14:25] mdeslaur: I didn't mean /that/ cloud ;) [14:26] if rossetta is emailing me about errors in translation templates from a recent package I uploaded.... do i have to deal with them? [14:26] xnox: generally no - they're usually upstream issues that you don't need to do anything about [14:26] slangasek: just making sure :) [14:27] xnox: if you *touched* the translations and are now getting errors, you should worry about it :) [14:28] geser: good idea; done [14:29] slangasek: On 2012-05-17 07:33z (2 hours 55 minutes ago), you uploaded a file with [14:29] Catalan (ca) translations for grub in Ubuntu Precise package "grub2" to [14:29] Launchpad [14:29] Does mom download all sources from D + U? [14:29] slangasek: the main difficulty, aside from sheer awkward size, is that merges needs to keep a lot of source packages around which are no longer in any current archive to serve as base revisions; not to mention archived patches and the like [14:29] * xnox somehow thinks catalan speaking users just might use sudo over the next 5 years. [14:29] xnox: I think that one is ignorable [14:29] xnox: yeah... maybe that's cjwatson's problem? :) (grub2) [14:29] cjwatson: right [14:30] there are a few things that Rosetta more or less legitimately whines about that I haven't bothered fixing because it involves liaising with upstream translators and it didn't look that important; and I think possibly also some cases where it was just being pedantic [14:30] * xnox notes down "if in daubt, `maybe that's cjwatson's problem?`" [14:30] Laney: only given series in each, but yes [14:31] xnox: ... [14:31] * xnox rips the paper apart. [14:31] * Laney saw something about block storage somewhere … [14:32] yeah, it might be doable now that canonistack does block storage, but I'm not about to move an important production service to it until others have shaken out the bugs first :) [14:32] * slangasek nods :) [14:32] I was thinking as an interim until the hardware is acquired [14:33] msgfmt didn't give any error... [14:33] Laney: given its apparent I/O problems, I'm not sure I could transfer the current state to the cloud without IS help anyway [14:33] * xnox is ignoring that translation file [14:33] MoM isn't desperately cloudy right now; it could be, but if it were actually going to take advantage of the cloud properly it would need to be refactored rather a lot [14:33] not to say that wouldn't be a good idea [14:34] cjwatson: Can it not recreate its own state? Or do you think that would be too network heavy? [14:34] * Laney would be willing to give the current code a spin [14:34] It needs to have its pool available for base revisions [14:35] In general it cannot recreate its own state entirely from scratch [14:35] ah, so it can't use snapshots / LP to download old stuff [14:35] so I was thinking about hibernation [14:35] I'm not sure how the kernel does it. :| [14:35] Not at the moment, and it's possible not everything is available on either; I've certainly seen cases in the past where casey was the only thing I could find that had managed to retain something [14:36] I can believe that it wouldn't get 100% coverage [14:36] I don't know exactly what the problem is, but doing a full run causes it to reboot, so I have no confidence that I could rsync off the data; but I gather the problem is more likely to be RAM or RAID controller or something, not the disks themselves [14:36] So I'd rather wait for IS and continue to hassle them :) [14:38] for a rough outline my thinking is: 1) Prepare the system (flush all buffers, finish fetching I/O from hardware, etc); 2) Stop scheduling all user applications; 3) Flush all buffers and page cache; 4) Remount read-only everything except the target for /hiberfile; 5) Flush all application RAM to /hiberfile (through LZO or LZ4); 6) extend /hiberfile to hold kernel RAM; 7) RO-mount the file system; 8) Flush kernel memory to /hiberfile [14:39] that's probably completely different from what the kernel actually does :| [14:40] although I think being able to flush to a dynamically created hibernation file and (OPTIONALLY--good for 32GB RAM and slow hard disk, not so good for SSD or SCSI-RAID etc) compressing the data as it's written out would be useful [14:40] * Bluefoxicy rambles about nothing interesting [14:41] Bluefoxicy: what are you trying to achive? [14:41] xnox: I think it'd be nice to be able to hibernate without a swap partition, or with a swap partition that currently has too much swapped onto it to take on all of RAM [14:42] uwin 41 [14:43] xnox: This is already possible--you can hibernate to a swap file; but more interesting would be swapping to a dynamically created file (i.e. not a swap file), and the potential applications for compressing the hibernation file may be interesting (compression may be slower than just writing to disk; then again disk may be too small to hold 5-10 gigs of hibernation data) [14:44] I think on MY system compressing would be slower than writing straight, because I have an SSD with a SandForce chipset that compresses data on-the-fly to improve throughput anyway--compressing stuff before writing it to disk actually slows my disk access [14:44] Bluefoxicy: i always have swap as twice my RAM, exactly because of failing to swap. Usual and rude answer is "you should be using LVM and just extend your swap partition". [14:44] I don't have fancy drives. [14:44] I do have full disk encryption with LUKS [14:44] good luck, sounds like a reasonable cause. [14:44] xnox: I just use zram [14:45] (by the way, don't ever load the zcache module: it doesn't actually do anything--as I understand it should work compiled it, but does not work as a module--and it completely destroys the kernel's ability to manage page cache) [14:46] nice ! =) [14:46] * xnox goes to blog 'how to load zcache module to make your ubuntu run faster' [14:46] http://article.gmane.org/gmane.linux.ubuntu.devel.discuss/13766 <-- this is me [14:46] * xnox wait a second! [14:46] haha [14:47] maybe i should read -discuss.... [14:47] seriously, when I had zcache loaded my kernel kept purging cache down to like 150MB and then struggling with all the extra disk access, with a gig of free RAM sitting around :P [14:47] things got very slow [15:23] tremolux: hi, are you guys by chance able to marshall some SRU testing resources for this software-center update? [15:25] tremolux: it's a very large delta with a lot of different bugs, and per the SRU process we should be trying to get validation for each of them; I fear this SRU may stall without a concerted effort to validate, which would be unfortunate given that it fixes a lot of top crashers [15:34] cjwatson: \o/ [15:34] we'll see if it works for other people ;) [15:34] :) [15:54] cyphermox: once we have this connectivity check thing in place, what are your thoughts on me backporting it to 12.04? GNetworkMonitor is causing me lots of pain. [15:55] ev: this fills me with fear [15:55] haha [15:55] oh dear [15:55] ev: connectivity checking has already been included functionally, it's just not enabled by default [15:56] especially for something that will go poll a website, I much rather doing this only in quantal [15:56] okay [15:59] I might drop it anyway. libcurl will still fail, so we wont actually lose the report. [16:07] slangasek: hey! yes, I was going to give it another day or two to wait for other folks to verify, then I was going to go through any remaining ones myself so that we don't delay past the initial window [16:08] slangasek: I think we can marshall the esteemed davmor2 to help as well [16:08] tremolux: hurrah :) [16:08] slangasek: :D [16:09] * tremolux is dying for USC to no longer have the top crasher on errors.ubuntu.com ;) [16:32] mdeslaur: did lintian build for you yesterday? [16:34] mdz,pitti,kees,stgraber,soren: just found mail in the TB moderation queue about a catch-up with the CC in their meeting starting in 25 minutes ... can any of you attend? I might be able to be at part of it but possibly not all, so it would depend where we are in the agenda [16:35] also the TB has been fairly quiet lately so not sure I have much to say :) [16:37] cjwatson: I won't be able to make it, at least not the first half hour or so [16:40] anyone know where the script is for the liveCD boot system? [16:40] I want a peek at it [16:40] particularly the part that mounts the /cow [16:40] casper [16:40] (which right now is just tmpfs) [16:40] specifically you probably want scripts/casper there [16:41] k [16:41] cjwatson, I can [16:41] * Bluefoxicy apt-get src casper [16:42] cjwatson: trivia #2: why 'casper'? [16:42] mdz: thanks - I'll try to sit in if I can [16:43] Bluefoxicy: I blame mdz :) [16:43] it's not really analagous to Norton Ghost or anything [16:43] it was a friendly ghost reference, because it did weird magic [16:43] I think [16:43] ah [16:43] more or less [16:43] and Sardra would have been less appropriate because Sardra is an a-hole [16:44] (A wizard did it) [16:45] cjwatson, the fridge calendar disagrees with the email :-/ [16:45] is that a WoW reference? in that case, not to mention that ~nobody had heard of Sardra when casper was written [16:45] mdz: imagine my surprise [16:46] cjwatson: 8 bit theater, a running gag is that a certain small boy is repeatedly subjected to horrible, horrible things as consequence of everything the main characters do [16:46] perhaps the CC meeting would be a good place to propose abolishing all forms of scheduling except one [16:46] so he becomes the most powerful wizard in existence, returns to the beginning of the universe, and attempts to become god by commanding it and remaking the universe WITHOUT those guys [16:46] this fails so he just takes to doing horrible things to them [16:46] cjwatson: btw, you should post to u-d@ about the ubiquity port :) [16:47] micahg: lintian? [16:47] barry: oh yeah [16:47] cjwatson: feel free to make it a veiled call for volunteers [16:47] cjwatson: Yes, please, include a diffstat and make sure we all feel appropriately inadequate! ;) [16:47] mdeslaur: yes, you sponsored it :) [16:48] micahg: oh, is that one of the syncs? no idea [16:48] * broder perks up at mention of lintian [16:48] mdeslaur: umm, it didn't build :) [16:48] micahg: oh well [16:48] micahg: Did you happen to retry it already? [16:49] infinity: failed locally as well :) [16:49] micahg: Same ENOSPC failures? [16:49] Oh, wait. [16:49] *cough* [16:49] micahg: would be nice if we'd get build failure emails [16:50] mdeslaur: there's a bug for that (syncs don't send build failure e-mails) [16:50] micahg: how's it failing? [16:51] Bug #902114 [16:51] Launchpad bug 902114 in Launchpad itself "When sponsoring using copyPackage, the sponsored person is not sent email from Soyuz" [Low,Triaged] https://launchpad.net/bugs/902114 [16:52] mdeslaur: one of the tests is failing [16:52] I think you mean bug #862251 [16:52] Launchpad bug 862251 in Launchpad itself "Sync requester doesn't receive build failure emails" [High,Triaged] https://launchpad.net/bugs/862251 [16:52] micahg: that bug is for the sponsored person to get the email [16:53] Actually looked more like fakeroot failing. [16:53] * infinity waits for it to fail again. [16:53] does the sponsor get the FTBFS mail for normal uploads? [16:53] Laney: yes, that's the bug I was looking for [16:53] infinity: yeah, I think you're right [16:56] mdeslaur: just a reminder to test build before sponsoring :) [16:56] micahg: yeah, I'll definitely keep away from sponsoring next time :) [16:57] Actually, there are a ton of failures in the test suite... [16:57] *sigh* [16:57] this seems to be a common recurrence with lintian every release [16:58] Well, if I'm reading the changelog correctly, this one might have dropped Ubuntu support and forced us to modify it anyway, unless the maintainer was kind enough to include an Ubuntu-specific DB for his new generic derivatives handling. [16:59] * infinity hasn't grabbed the source yet to see. [16:59] wait, huh? [16:59] the stuff niels did was ubuntu friendly [16:59] micahg, infinity: sorry about that, I didn't usually test build syncs before, but I'll be more careful [16:59] (i.e. the purpose of that code was so that we no longer threw tags about original-maintainer) [17:00] + [NT] Remove Ubuntu specific handling of distribution names. [17:00] Instead replace it with a more generalized one that derivatives [17:00] can reuse by extending vendor specific data files. [17:00] right [17:00] and the data files are in there [17:00] broder: I'm not implying that those changes are unfriendly, just that they require ubuntu-specific files to be there, and I didn't check to see if they are, or if we're expected to tack them on. [17:00] lintian.uw.o is currently running with something ~2 commits older than the release [17:00] broder: Ahh, kay. [17:00] so lintian itself works, even if the test suite doesnt' [17:01] The hardening failures in the testsuite seem pretty obvious (the baseline expectation is just plain wrong for Ubuntu compilers). [17:01] Other failures looked a bit more confusing. [17:01] can you pastebin a log? [17:01] The build's still running. [17:02] When it's done, it'll be in the "pastebin" called the "launchpad librarian", referenced from https://launchpad.net/ubuntu/+source/lintian/2.5.7/+build/3493637 :P [17:02] heh [17:03] mdeslaur: thanks, at this point of the cycle, I think it's more about encouraging good practices than the actual failure as we'd probably have gotten it next week some time [17:06] mdz: well, now I'm completely confused, since there's been no activity in -meeting either at the fridge time (which also == the usual obvious UK DST misinterpretation of the mail) or the mailed time [17:06] micahg: I didn't think building locally when syncing was a good practice. Would help if this was documented somewhere. [17:06] cjwatson, indeed. I just sent an email [17:07] I wonder if they were expecting a response and canceled it when they didn't receive one [17:07] mdeslaur: hmm, okay, /me wonders where syncing is documented at this point [17:07] SyncingAndMerging hopefully [17:08] Hm, maybe not, memory like a thing with holes in [17:09] mkfs.ext2 is valid from casper? [17:09] or is that not in $PATH at that time? [17:15] hi [17:18] micahg: ah, here's the docs: https://wiki.ubuntu.com/SyncRequestProcess [17:18] Can an archive admin review python-jsonschema please? [17:18] micahg: I'll add info about a local build to the wiki [17:19] mdeslaur: it's already implied, but a test build of some sort should really be done, thanks [17:19] micahg: implied by what? [17:19] * micahg is reluctant to say required and isn't sure why [17:19] Sometimes the sponsor requires a build log of the Debian package compiled in the Ubuntu release as proof that the new Debian version still compiles in Ubuntu. [17:20] that implies a requirement of still building in ubuntu to be sync'd [17:20] Bluefoxicy: easy test: boot with break=casper-bottom, and you get a shell so you can look [17:20] * Laney thought it was accepted best practice to test build all uploads (sponsored or not) [17:20] cjwatson: nice [17:20] Laney: well, I do test build uploads, but I wasn't test building syncs [17:20] Laney: only for certain people :) [17:21] not all people follow best practice :P [17:21] true [17:21] * infinity admits that he doesn't always test-build syncs, but does watch to make sure they don't fail. [17:21] mdeslaur: any special reason for this? as syncs are similar to uploads [17:21] http://pastebin.com/dfabCsAU [17:22] man, i had forgotten how intense the lintian test suite is [17:22] cjwatson: any way I can break into the shell BEFORE casper is executed so I can replace the script and see what happens? [17:22] geser: no special reason, it just didn't occur to me that syncs were supposed to be handled differently than autosyncs [17:22] or do I need to build a livecd and boot it in VirtualBox to find out? [17:23] my, Lintian's test suite takes rather a long time to ru [17:23] n [17:23] (the diff above is my first, untested attempt to tell casper to use a zram device instead of tmpfs for the /cow and copy-to-RAM, with ext2 being the filesystem of choice) [17:24] (the advantage is that these are compressed and so take up less RAM) [17:24] mdeslaur: for me syncs are a special kind of uploading, so I test-build them like I do before uploading a package [17:25] geser: yes, I agree I should have been doing that, and will from now on...It just didn't occur to me before [17:27] Bluefoxicy: you could just zcat | cpio -it the initrd and see what it contains [17:27] Bluefoxicy: oh, misread - you can break=mount IIRC [17:27] * micahg hugs mdeslaur [17:28] yeah [17:28] though you don't have many tools, so sometimes rebuilding is easier [17:28] * mdeslaur hugs micahg back [17:29] hahavvv [17:29] there's no editor [17:30] well that's not a problem [17:31] * Bluefoxicy mounts the squashfs from the medium, uses the tools there >:D === Ursinha` is now known as Ursinha [17:32] micahg, broder: Alright, lintian failed again on the buildds, this time without crazy fakeroot issues (that must have been some other transient oddity). [17:35] infinity, broder: is one of you already taking a look, or shall I poke at it? [17:36] i am not currently taking a look [17:36] Bluefoxicy: there is sed, which is occasionally useful with a bit of creativity; but yeah, no full-screen editor [17:36] i can take a look later if you'd like [17:36] mdeslaur: I was just rebuilding to see if a previous issue was reproducible, I'll leave it to you to fix the current issues. :P [17:36] mdeslaur: I'd suggest pushing back on AnAnt to look at it [17:36] might be worth pinging nthykier in #debian-qa on oftc to see if he can hel[p [17:37] (The hardening failures are obvious, some of the others look slightly less obvious at first glance) [17:37] yeah, I'm trying to figure out the apache2-modules failure [17:40] hah, lintian is FTBFS on debian too [17:40] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673198 [17:40] Debian bug 673198 in lintian "lintian: The 2.5.7 source package is missing files (causing FTBFS)" [Serious,Open] [17:40] stgraber: http://debblog.philkern.de/2012/05/lazyweb-question-how-to-avoid-leaking.html lxc ? [17:40] mdeslaur: Alternatively touch t/tests/apache2-modules-general/skip will make Lintian skip the test, which should be fine until the next upload [17:41] mdeslaur: Oh, that's comforting. One more reason why Debian needs to switch to source uploads. [17:41] debfx: awesome, thanks [17:41] that's the problem with Debian and arch:all packages, no clean build env [17:42] micahg: Yeah, see, speaking of people's "best practices" for syncs above, one of the first things I do is check buildd.debian.org logs. Which is useless for arch:all. [17:42] infinity: yeah, I like to do that as well [17:44] helps on non-x86 archs [17:45] xnox: yeah, something like http://www.stgraber.org/2010/12/12/having-fun-with-containers/ (back when arkose was called sandbox). The only issue is that it needs root privileges... [17:45] xnox: you could also do something similar by directly using lxc-unshare -s PID [17:45] xnox: but that'll all be a lot more secure once we have the user namespace in the kernel and these no longer require root access [17:47] just to realise that the build log for the arch you're interesting it doesn't exist because that's the arch the DD uploaded [17:49] I vaguely recall hearing once that there was an interface whereby a DD could post their own build log, but of course hardly anyone does [17:49] Yes, it's a tricky and high tech interface called "email". [17:50] Though, it's been so long since I was a buildd admin, I now forget where the emails get sent. :P [17:51] Yeah, I also find that I just send e-mails addressed to Santa Claus and they get where I meant them to go [17:52] ;) [17:52] Alternatively, "nobody remembers the right address" :-) [17:53] - [cjwatson] Port ubiquity: DONE [17:53] + [cjwatson] Port ubiquity: INPROGRESS [17:53] barry: hmm? [17:53] barry: (also, sent that mail now) === charles_ is now known as charles [18:01] * Bluefoxicy fixes a few bugs. [18:02] well it ALMOST worked (besides that I had to cp mkfs.ext2 out of the squashfs) [18:02] it's notably possible to mount the squashfs early and run /filesystem.squashfs/sbin/mkfs.ext2 ... all the libraries it needs are in /lib on the initrd [18:02] still best to use LD_LIBRARY_PATH when running binaries from a different fs [18:03] even if it happens to work at the moment - we learned that lesson in d-i a while bac [18:03] k [18:06] not to self: never touch lintian again [18:12] cjwatson: i think it doesn't matter anyway ... tmpfs swaps, this is silly. Just using zram as swap would accomplish the same goal methinks [18:12] cjwatson: maybe the work items got out of sync in our browsers? [18:13] cjwatson: thanks for the email [18:13] i installed chromium, brought the universe repository down ... there's about 400MB in /cow now and it's taking up 66% of its original size (the actual file data takes up 56%) [18:13] so this isn't great anyway [18:13] * Bluefoxicy scraps this as wasted effort. [18:14] barry: ah well, fixed now [18:14] * barry remembers to refresh the page before editing it [18:14] hmm, multiarch breaks a symlink installed by libqt4-dev it seems [18:14] shame there's no collision detection [18:14] no idea why the symlink is there at all though [18:15] yeah [18:26] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh [18:27] slangasek, lp #1000541 is assigned to you (and you fixed it for precise-proposed) but it's in the sponsoring queue with a patch from someone else that looks ok; shall I go ahead and upload it for quantal or would that mess you up? [18:27] Launchpad bug 1000541 in ia32-libs (Ubuntu Quantal) "ia32-libs-multiarch depends on gstreamer0.10-fluendo-mp3, causing problems when installing packages from partner" [Medium,Triaged] https://launchpad.net/bugs/1000541 === skaet_ is now known as skaet [18:48] slangasek, I'll go ahead and send the fix for quantal [18:52] bryceh: ia32-libs was going to be pocket-copied from precise-proposed to quantal [18:52] I don't think there's any point in fixing separately for the two, since it's a metapackage [18:53] slangasek, ah, too late [18:53] pfft [18:54] bryceh: did you increment the version number in the changelog? Otherwise it'll be rejected and I still win ;) [18:55] slangasek, 20090808ubuntu36 [18:55] didn't change it from the supplied patch [18:55] right, that's the version number I already used for -proposed because I knew it was going to quantal [18:56] so I'll pocket-copy now [18:56] (done) [18:56] you and your silly archive admin powers [18:56] ;) [18:57] there's a surprisingly large amount of not valid sponsor items in the queue today :-/ [18:57] i hope the one i pre-reviewed before telling the person to submit it isn't one of them [18:58] well, with 79 items, I'd hope some are valid :) [19:00] 0 for 4 so far [19:00] bryceh: if there are some you want to see off the queue, ping me with the URL and the status you want (Work in progres / Rejected / Merged) [19:00] oh good, her package did get sponsored and is in -proposed [19:01] Hi, I was wondering for the correct value to insert into the gtk settings.ini file for gtk-shell-shows-app-menu and gtk-shell-shows-menubar. For gtk-shell-shows-app-menu, the documentation says to use something that evaluates to TRUE, but we've tried "true", "TRUE", and 1 with an exception in my xsession-errors (asking here due to the canonical gtk fork) [19:01] stgraber, yeah https://code.launchpad.net/~jeffreytremaine/ubuntu/precise/balazarbrothers/fix-829819/+merge/106110 needs off the queue; already got taken by debian and we'll just sync it in (just a typo fix) [19:01] stgraber, thanks [19:03] bryceh: actually, just mark them as disapproved and I'll do a mass cleanup tomorrow morning during my shift, will be easier that way I guess [19:04] stgraber, ok sounds good [19:05] The error we get is "Key file contains key 'gtk-shell-shows-menubar' which has a value that cannot be interpreted" [19:06] cjwatson: hmm, seb128 pinged bug #900526 about stalled SRUs... did we intend to have any further SRU verification for !lucid? Not sure if we should kick those back out as "not worth it", push them without further verification, or rustle up the testing resources [19:06] Launchpad bug 900526 in debian-installer-utils (Ubuntu Hardy) "d-i fails to divert initctl when upgrading packages during install" [High,Fix committed] https://launchpad.net/bugs/900526 [19:16] does quantal auto-sync from testing or unstable? [19:21] bryceh: can you do a quick sponsoring of "syncpackage libmemcached"? libmemcached 1.0.6-1 fixes the FTBFS in quantal. (or do you prefer a bug for it?) [19:22] If there's a better place to ask this sort of question, I'll be happy to ask there [19:28] geser, a bug would be helpful yes [19:29] geser, for some reason syncpackage fails to run for me. Trying to get it sorted, but if I don't, the bug will be there for someone else to do [19:29] farkerhaiku: maybe True [19:29] farkerhaiku: since python likes that capitalization... [19:30] maco: I'll give that a shot [19:30] (i'm just guessing) [19:30] bryceh: I'll sync it. [19:30] geser: Don't bother with a bug. [19:30]