[00:01] <SpamapS> broder: haha ok :) I think just a simple "hey thanks for the patch, we fixed that in 11.10 in this bug report" comment suffices + marking it as a duplicate.
[00:01] <SpamapS> broder: 1 2 3 NOTIT
[00:02] <broder> SpamapS: :-P. ok, i'll deal when i get home from work, then
[00:04] <TheMuso> @pilot in
[00:49] <infinity> cjwatson: If you feel a strange urge to make d-i work with omap4 tonight, it should work as of, well... Now.
[00:49] <infinity> cjwatson: if not, I'll do it tomorrow. :)
[00:49]  * infinity is, shockingly, not working past quitting time tonight.
[00:51] <cjwatson> Not tonight, darling, I've got a headache^Wset of germinate uploads to do
[01:29] <micahg> what's the proper way to defer startup of a service in upstart w/out depending on the display manager starting
[01:29] <broder> defer until what?
[01:30] <micahg> I guess either the display manager starts or other more critical services are done, I guess
[01:31] <broder> i'm not sure that upstart acknowledges the concept of differing importance of services
[01:31] <micahg> was taking a look at merging pppconfig
[01:33] <micahg> infinity: wait a second, if something's in the minimal task, I thought we didn't need to depend on it
[01:34] <cjwatson> micahg: no, that's only packages that are Essential: yes
[01:34] <cjwatson> infinity's fix wasn't theoretical; his build chroots are <minimal.
[01:35] <cjwatson> or rather, neither a subset nor a superset of minimal
[01:40] <micahg> cjwatson: ah, ok, not sure where I heard that before then
[01:41] <cjwatson> There are various misunderstandings of this floating around :-(
[01:41] <cjwatson> Have been for a long time.
[01:43] <micahg> cjwatson: so, how do xz/lzma debs work then?
[01:44] <cjwatson> micahg: hmm?
[01:44] <broder> micahg: dpkg has a dependency on xz-utils
[01:44] <broder> (pre-depends, even)
[01:44] <cjwatson> micahg: dpkg is Esential: yes and Pre-Depends: xz-utils
[01:44] <cjwatson> snap
[01:44] <cjwatson> Essential isn't transitive
[01:45] <micahg> cjwatson: ah, that's the other half of the trick :), ok
[01:45] <cjwatson> I mean, not transitively closed.  Essential packages can depend on packages that are non-Essential (all such packages would be Priority: required, but the reverse is not true)
[01:45] <micahg> but inherently, we shouldn't rely on something being available unless it's Essential:yes
[01:46] <broder> if you're using it directly, no
[01:46] <broder> if the essential tool you're using relies it, that's an implementational detail and not your problem
[01:46] <micahg> right, ok
[01:47] <micahg> so if I'm using lzma/xz directly, I should depend on what I need, but WRT dpkg being able to use it, that's implementation
[01:48] <cjwatson> exactly
[02:06] <psusi> question.. since xz is required now anyhow, why is initramfs-tools still defaulting to using gzip?
[02:41] <TheMuso> psusi: Who maintains ureadahead in Ubuntu these days? have they had a look over your ureadahead changes?
[02:41] <psusi> TheMuso, tag, you're int ;)
[02:41] <psusi> seriously... since Keybuck left, nobody wants it
[02:41] <TheMuso> psusi: lol! I think not.
[02:42] <psusi> that's why I held off proposing a change for 11.04, then I kind of forgot about it
[02:42] <TheMuso> psusi: Perhaps it may be worthwhile putting these changes in a PPA, and put out a call for testing. I don't feel comfortable uploading this change unless its been tested/looked over by a few people who know the code.
[02:42] <psusi> I poked him a few times to see if he wanted to merge the changes to his upstream project that lp still says is his... he doesn't seem interested
[02:42] <psusi> in maintaining the upstream that is
[02:42] <TheMuso> Right.
[02:43] <psusi> he just kept saying that keybuck@ubuntu.com was dead or something
[02:43] <psusi> I did that 12 months ago ;)
[02:43] <TheMuso> Ok.
[02:43] <TheMuso> And?
[02:43] <TheMuso> Any responses good or bad?
[02:43] <psusi> got a few people giving me positive feedback on the forums
[02:44] <psusi> of course, I'm now banned from the forums due to a power mad admin not liking his decisions questioned and their governing board apparently not functioning anymore... they don't have meetings and ignored the issue when I kept putting it to them on the ml...
[02:45] <TheMuso> Right.
[02:46] <TheMuso> I take everthing from the forums with a grane of salt anyways.
[02:46] <TheMuso> everything
[02:46] <TheMuso> Having said that, I practically never read the forums.
[02:46] <psusi> yea, it was mostly a time waster for me anyhow... I like askubuntu better now anyhow
[02:47] <psusi> at any rate, I originally made the changes in maverick, and posted them to my ppa... got a few positive feedback... then ran it myself in natty for a while... then forgot about it
[02:47] <psusi> just realized yesterday when I was looking over my branches on lp that I never did get it merged...
[02:48] <JackyAlcine> psusi: +1
[02:48] <TheMuso> Right.
[02:48] <JackyAlcine> askubuntu's so much better.
[02:49] <psusi> I can tell you this; I spent many hours last year staring at blocktrace logs working on that ;)
[02:49] <broder> seems like jhunt would be the obvious person to review ureadahead changes these days
[02:49] <TheMuso> psusi: Given our focus on testing this cycle, I'm not sure if I want to be the one who screws people's systems up. Yes I know you have run it for a while, but was testing carried out on different systems with rotery and SSD drives?
[02:49] <psusi> and I also was playing with using e2defrag to pack the files tight at the start of the disk to make it even better
[02:49] <psusi> yes
[02:49] <psusi> I have 3 rotational and one ssd
[02:50] <psusi> mixing lvm, regular partitions, and dmraid ;)
[02:50] <TheMuso> Ok
[02:50] <psusi> hrm.. I guess I should go make sure it doesn't break anything on btrfs though
[02:50] <psusi> it shoulnd't, but not tested yet I guess
[02:50] <TheMuso> Actually, thats a good point.
[02:51] <TheMuso> But it begs the questino how much we support BTRFs at this stage.
[02:51] <TheMuso> As in, helping users with problems, support contracts etc.
[02:51] <psusi> not much I think ;)
[02:51] <psusi> but I have been playing with it a lot lately... aside from the dpkg/fsync issue, it's frigging awesome
[02:52] <broder> "aside from hanging my entire machine for 10+ seconds at a time whenever i do anything with dpkg"
[02:52] <psusi> hehe... I just wrap it in libeatmydata now automatically... makes it twice as fast on ext4 too
[02:53] <psusi> I worked up a patch to give dpkg a --force switch to disable all the fsync calls too, but debian doesn't seem to like the idea
[02:53] <psusi> makes it very snappy and can easily be done automatically with the apt-btrfs-snapshot package after it makes a snapshot of the root fs before it starts having dpkg upgrade/install packages
[02:54] <psusi> I was thinking of doing that, and making grub smart enough to fall back to the snapshot if the system crashes during the upgrade
[02:56] <psusi> it is pretty damn cool though, to be able to install natty, make a snapshot, install the hundreds of upgrades, then decide you're going to roll back... reboot, and 20 seconds later, you're back to base install being prompted that there are 300 upgrades available ;)
[02:56] <TheMuso> Yeah that is cool.
[02:57] <psusi> I made some improvements last week to this nifty btrfs-gui utility too that helps visualize the fs layout
[02:57] <TheMuso> So... I am wondering what to do next. I'd like to see this get in, but I don't feel comfortable uploading it. I guess I could build it here, and run it for a little while to see what happens...
[02:57] <psusi> TheMuso, that works ;)
[02:58] <TheMuso> Yeah I know it works, but I've never been a fan of WFM tests.
[02:58] <psusi> TheMuso, add a comment saying you're testing it for now... maybe someone else will do the same... even if it doesn't end up getting merged by anyone this cycle, if a few devs end up testing it and saying it looks good, should be an easy merge for 12.10 as soon as it opens
[03:00] <psusi> or maybe merge it, but pull it back out for final beta, just in case?  at least that way it gets plenty of testing between now and then
[03:00] <TheMuso> Yeah, will leave a comment for now I think.
[03:01] <TheMuso> psusi: Actually, it FTBFS for me...
[03:02] <psusi> roh roh... I guess I didn't actually test it on precise, I'm still running oneiric
[03:09] <TheMuso> heh
[03:09] <psusi> I wonder what changed...
[03:10] <psusi> guess I'll have to work on that
[03:12] <TheMuso> Are you doing that now, or should I move onto something else and come back later?
[03:13] <psusi> move on... I'm trying to write a new parted test suite test to get some patches merged upstream right now
[03:14] <TheMuso> Ok no worries.
[03:16] <TheMuso> psusi: BTW I also referred your parted branch to cjwatson, as he knows that code far better than I do. Hell I can't even remember much about the linux device-mapper code that I touched back in 2008. :)
[03:17] <psusi> I figured ;)
[03:18] <psusi> I'm really excited about finally not having to tell people they need to boot from the livecd to use gparted
[03:22] <TheMuso> Cool.
[03:23]  * psusi beats this test suite into submission
[03:33] <psusi> damnit... how did you get a shell expression to substitute a variable, then append more text?  I thought it was {$foo}bar, but that seems to be leaving in the P{
[03:33] <psusi> {} rather
[03:36] <TheMuso> psusi: Is $(commands-here etc) what you want?
[03:36] <psusi> TheMuso, no.. I want to test for the existence of /dev/foop1 when DEV=/dev/foo, so I want $DEV+"p1"
[03:38] <psusi> oddly, $devp1 seems to work, though that doesn't seem to be a good idea... what if there were a variable named devp1?
[03:40] <stgraber> psusi: ${var}text
[03:41] <stgraber> stgraber@castiana:~$ blah=abc
[03:41] <stgraber> stgraber@castiana:~$ blahvar=test
[03:41] <stgraber> stgraber@castiana:~$ echo ${blah}var
[03:41] <stgraber> abcvar
[03:42] <psusi> DEV=/dev/sda echo ${DEV}1
[03:42] <psusi> just spits out "1"
[03:43] <psusi> I thought that was how it was done, but it just is't working for me...
[03:43] <stgraber> just like "DEV=/dev/sda echo $DEV" will spit out nothing
[03:44]  * psusi just had the world turn upside down
[03:45] <stgraber> my understanding is that $DEV is substitued before echo is actually called
[03:45] <psusi> you mean before the assignment?
[03:46] <stgraber> right
[03:46] <stgraber> so if you do it in two steps it works fine
[03:46] <psusi> bah.... damn shell ;)
[04:04] <TheMuso> @pilot out
[04:49] <pitti_> good morning
[06:24] <pitti_> cjwatson: want me to do a d-i upload for the bumped omap4 kernel? (I guess it couldn't hurt for me to actually get some practice how to do that)
[06:27] <micahg> pitti_: quick question, any extra checking I need to do before uploading something from core?  I test built and tried running it
[06:27] <pitti_> micahg: sorry, which "core"?
[06:27] <micahg> pitti_: sorry, it's libvdpau
[06:28] <pitti_> micahg: oh, your core-dev application got approved?
[06:28] <micahg> pitti_: yep :)
[06:28] <pitti_> micahg: congrats! well earned
[06:28] <pitti_> (FWIW, I thought you had been core-dev for ages already :) )
[06:28] <micahg> pitti_: thanks!
[06:29] <pitti_> micahg: no extra formal checks, no; just "don't upload something broken", as usual :)
[06:29] <micahg> ok, great
[06:31] <pitti_> RAOF: hey Chris, how are you?
[06:57] <pitti_> cjwatson: I committed the actual ABI bump to bzr, but I'll wait for your guidance how to build the source package from bzr
[07:00] <pitti_> cjwatson: when I just run debuild, I get http://paste.ubuntu.com/762512/ (NB I didn't tag the release yet); do I need to run anything else like pulling in udebs or other sources, etc?
[07:22] <pitti_> jamespage: I fixed poppler-sharp harder and will then upload another rebuild of pdfmod; now the remaining poppler-glib6 rdepends are all due to the dropped poppler_page_render_to_pixbuf(); yay for copy&pasting code there :(
[07:35] <TheMuso> micahg: Oh congrats.
[07:35] <micahg> TheMuso: thanks :)
[07:54] <dholbach> good morning
[07:59] <pitti_> wendar: any progress with the magics++ FTBFS? do you need some help there?
[08:01] <wendar> pitti: it's done, submitted upstream to Debian
[08:01] <wendar> pitti: the guy said he'd apply it over the weekend, then we can sync
[08:01] <pitti_> wendar: oh, nice! well done
[08:02] <pitti_> jamespage: ^ that'll resolve the remaining libgrib-api-0d-1 NBS, so let's ignore this for now
[08:08] <pitti_> jibel, jamespage: current server tests failed due to uninstallable grub-pc and language-pack-en; I really don't see how this happened, though, they both have been installable in the past few days
[08:09]  * pitti_ downloads server ISO and tests for himself
[08:09] <doko_> infinity, gcc builds currently fail in stage2 (gcc-snapshot, gdc-4.4, ...)
[08:09] <pitti_> jibel, jamespage: the image's report.html is clean as well
[08:14] <jibel> pitti_, good morning. looking
[08:14] <pitti_> jibel: I'll try to reproduce it locally
[08:18] <jibel> pitti_, I'm replaying a server amd64 default install
[08:22] <jibel> pitti_, grub failed to install
[08:22] <pitti_> jibel: presumably due to the failure to instsall grub-pc?
[08:24] <jibel> pitti_, right, but the vm shutdown before I had time to look further. I'll mount the disk and search what's wrong
[08:26] <jibel> Dec  7 08:21:49 in-target: Errors were encountered while processing:
[08:26] <jibel> Dec  7 08:21:49 in-target:  /var/cache/apt/archives/language-pack-en-base_1%3a11.10+20111006_all.deb
[08:26] <jibel> Dec  7 08:21:49 in-target: E
[08:26] <jibel> Dec  7 08:21:49 in-target: :
[08:26] <jibel> Dec  7 08:21:49 in-target: Sub-process /usr/bin/dpkg returned an error code (1)
[08:27] <jibel> pitti_, bad news
[08:27] <pitti_> EINVAL?
[08:27] <jibel> pitti_, Dec  7 08:21:49 in-target:  failed in write on buffer copy for backend dpkg-deb during `./usr/share/locale-langpack/en_GB/LC_MESSAGES/libnih.mo': Invalid argument
[08:27] <pitti_> bah
[08:27] <pitti_> so that's on amd64, too
[08:27] <pitti_> just a lot less often
[08:27] <jibel> apw, ^
[08:31] <pitti_> jibel: ah, will search for that in the syslog next time, thanks
[08:33] <jibel> pitti_, np. if dpkg and ubiquity are affected on both arch that will become a problem for daily testing
[08:35] <pitti_> soren: do you have a particular interest in updating user-mode-linux for 3.2.0? it's currently unbuildable, so I removed the binary for now
[08:35] <pitti_> soren: if it's obsolete, I can remove the package, too
[08:38] <soren> pitti_: I do, I just haven't gotten it to work yet.
[08:38] <micahg> doko_: remember bug 899315 and --as-needed, the guy responded saying that the symbols aren't used except by a plugin so they'll get stripped even in the correct order, but isn't this what dlopen is for, or is that asking too much for a distro patch?
[08:38] <slomo> ogra_: pong
[08:39] <slomo> ogra_: next time with some context please :)
[08:39] <soren> pitti_: You deleted the binary already?
[08:39] <pitti_> soren: yes, as it's unbuildable
[08:39] <pitti_> but I kept the source
[08:40] <micahg> pitti_: if you're in the mood for going removal happy, I have bug 891484 :)
[08:41] <soren> pitti: Well, yeah, but when did we start blowing away binaries of packages that ftbfs?
[08:41] <soren> pitti_: I mean, sure, if we were close to release or something, but now?
[08:42] <pitti_> well, our goal is to drive NBS to zero and keep it that way
[08:42] <jibel> pitti_, I ran 3 installations of server amd64 and they all failed in "Unpacking language-pack-en-base" during the extraction of a .mo file but a different one each time.
[08:42] <pitti_> it prevents us from accidentally releasing with an unbuildable binary if we forget to fix it
[08:42] <soren> pitti_: ?!? How is this NBS?
[08:42] <pitti_> soren: linux-source-3.0.0 does not exist any more, so u-m-l can't be built
[08:42] <pitti_> soren: FTBFS for u-m-l, sorry
[08:43] <micahg> pitti_: FWIW, I would think it reasonable to give someone a little time to fix before removing the binary (unless we're close to a milestone)
[08:43] <soren> pitti_: It just seems quite heavy handed at this stage.
[08:43] <micahg> and even with the milestones, I think that should come with an announcement so people are aware
[08:44] <pitti_> well, can do, but we don't really have a tracker for these
[08:44] <pitti_> we could file release critical bugs and hope that someone picks them up
[08:44] <micahg> pitti_: file a bug with a new tag that can go on a report?
[08:44] <pitti_> but it would be wrong to actually nail down someone to fix some universe package
[08:44] <pitti_> and removing just the binary doesn't actually block people from uploading or introduces source NEW or so
[08:45] <micahg> pitti_: you can file the bug and subscribe the last uploader or 2
[08:45] <micahg> pitti_: it does prevent someone from using the app in the devel release
[08:46] <soren> pitti_: It doesn't block people from uploading a new u-m-l, no, but it could certainly block other things. I have some tests that involve u-m-l that now won't work.
[08:46] <pitti_> (bug 901118 )
[08:47] <pitti_> soren: ok, so maybe this was a little premature, sorry; we started doing that in oneiric when we started the goal of actually not releasing with FTBFS packages
[08:49] <soren> pitti_: I'm pretty sure u-m-l somehow evaded that effort in Oneiric.
[08:49] <soren> pitti_: It wasn't until less than a week before release I finally cracked it and got it work with 3.0.0.
[08:49] <pitti_> soren: it is buildable in oneiric, as oneiric does ship l-source-3.0.0
[08:50] <soren> pitti_: Yes, and up until 4 days before release, it depended on l-s-2.6.38.
[08:50] <pitti_> soren: right, that happened with quite a lot of packages; their binaries got removed, and the ones which actually got fixed just reappered
[08:51] <pitti_> micahg: removals> doing
[08:51] <micahg> pitti_: thanks
[08:54] <micahg> infinity: I finally got to an armhf FTBFS build log and sync'd the (hopefully) fix :)
[08:54] <cjwatson> pitti_: no, that's all you need and there's nothing special about building a d-i source package from bzr, but I'd like to add armhf/omap4 while we're there
[08:54] <cjwatson> now that it's in the archive
[08:54] <pitti_> cjwatson: ok, so that's just for ubiquity
[08:54] <cjwatson> yeah, ubiquity is weird
[09:03] <jamespage> pitti_: I did a few more uploads for the libpoppler-glib8 transition last night
[09:03] <cjwatson> pitti_: uploaded now
[09:03] <pitti_> jamespage: ah, thanks; i. e. the ones that just needed a rebuild?
[09:03] <jamespage> the remaining few need patches as they all use the gtk API in poppler which disappears in 0.18
[09:03] <cjwatson> (d-i)
[09:04] <pitti_> jamespage: I'm still without email, so I can't follow -changes@ ATM
[09:04] <pitti_> cjwatson: cheers
[09:04] <jamespage> pitti_, yep - thats right
[09:04] <pitti_> jamespage: right; we probably need to do some copy&pasting there, to counteract http://cgit.freedesktop.org/poppler/poppler/commit/?id=149b7fec4
[09:04]  * pitti_ sighs at this
[09:04] <pitti_> jamespage: we have a patch like that in gimp now
[09:05] <pitti_> jamespage: I did a few more syncs/uploads/binNEW this morning, and after cjwatson's d-i upload NBS should clear up a lot
[09:05] <pitti_> jamespage: do you want to do the libcegui-mk2-1 transitions? (presumably just rebuilds)
[09:06] <jamespage> pitti_: sure - leave it with me
[09:06] <pitti_> jamespage: ok; I suppose we'll divide the poppler porting between us in the next days then
[09:06] <jamespage> pitti_: ack
[09:09] <apw> jibel, pitti_, i have at least identified the underlying issue.  i think i have a fix for it which i am discussing with upstream currently.  it is possible a wholesale backout of some new code may be on the cards.
[09:09] <apw> jibel, if i get you a ker
[09:09] <micahg> pitti_: thanks for the removals, is there any other info you need in those bugs in general?  (I'll try to do a run at least monthly to keep those extensions out of the archive)
[09:09] <pitti_> apw: oh, that sounds promising; OOI, what is it?
[09:09] <apw> jibel, if i get you a kerel with a fix is that something we can test easier
[09:09] <pitti_> apw: it at least seems that the whole python part is irrelevant, so it's really write()
[09:10] <pitti_> apw: I suppose, jibel now has a jenkins set up to exercise/reproduce this
[09:10] <apw> pitti_, an issue with handling of partial writes at the very begininning of files, the code which tried to sanitise the buffers before return misses
[09:10] <pitti_> micahg: not for my purposes, I know the context
[09:10] <micahg> thanks
[09:11] <pitti_> apw: ah, so it's not a problem with cache handling? I tried VMs with little memory, but it didn't reproduce more often there
[09:11] <apw> pitti_, i don't believe any data is at risk, just buffers are attempted to be dropped, and we try and drop one whic
[09:11] <apw> which was never made
[09:11] <jibel> apw, I've a VM setup to reproduce this. I can update the kernel easily on it.
[09:11] <apw> pitti_, i think they key is speed, the faster the host the better, which is why we see it more on VMs, the disks are soooo much quicker on a fast host than real spindles
[09:12] <apw> pitti_, and is why i couldn't reproduce it on my laptop, my build monster could repro it 99% of the time like jibel's (which i assume is a biggie)
[09:12] <apw> jibel, ok will get you a test kernel shortly
[09:13] <jibel> apw, that would explain why we can reproduce it very frequently on our big boxes in the test lab
[09:13] <jibel> apw, thx
[09:14] <pitti_> apw: ah, and since I have SSD, it was only seldom for me, too, supposedly
[09:14] <apw> jibel, yeah, i was stumped for a bit till i got sick of my laptop going soooo slow and booted up one of my test boxes, there it was impossible to install the VM to have a test, i had to copy it over
[09:24]  * pitti_ does a process-removals run
[09:25] <pitti_> there, boost1.42 finally gone
[09:25] <micahg> \o/
[09:26] <pitti_> (only one remainging rdep, toonloop, rebuild uploaded)
[09:27] <doko> mvo, E: Internal Error, AutoRemover broke stuff
[09:28] <doko> multiarch issue, how can I just remove the offending package?
[09:30] <mvo> doko: uhh, is that on your machine? what was the command you run? what does -o Debug::pkgAutoRemove=true output (a lot probably)
[09:30] <doko> mvo: see query
[10:13] <YokoZar> dput by sftp broken?  launchpad refusing ssh connections
[10:16] <YokoZar> ...and it's already fixed
[10:21] <pitti_> Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -> shall I demote mysql-5.1 to universe, or keep it there as a reminder to do the remaining transitions?
[10:21] <pitti_> Daviey: there's also the option of removing it now, then the remaining rdeps will appear on http://people.canonical.com/~ubuntu-archive/nbs.html
[10:22] <pitti_> Daviey: but of course that'll firmly commit us to fully complete the transition (I suppose we want to do that anyway, though)
[10:26] <apw> jibel, ok http://people.canonical.com/~apw/lp894768-precise/ the 0916 kernels there should have the proposed fix if you could bash them
[10:26] <infinity> doko: I'm assuming the gcc* builds that fail are lacking the linker path patch.
[10:26]  * pitti_ sends apw a big hug and a bottle of beer
[10:26] <infinity> doko: So, stage one builds a new binary with the incorrect interpreter, and stage two tries to run it and it fails, cause, well, that interpreter doesn't exist. :P
[10:27] <Daviey> pitti_: Unless it's causing an issue, i'd like to defer judgement to SpamapS.  He is driving this, too many cooks etc.
[10:27] <pitti_> Daviey: no, it's not urgent, I was just wondering; thanks
[10:27] <Daviey> super.
[10:28] <doko> infinity, right, seen that at least for gcc-snapshot
[10:28] <doko> infinity, and need to add this to ghdl, gccxml (?)
[10:28] <infinity> doko: Look like what's happening in gdc too: "configure: error: cannot run C compiled programs"
[10:28] <doko> yes, will merge that from debian
[10:29] <infinity> doko: I guess anything that's technically "just another gcc frontend in a split source package" will need the patch.
[10:29] <doko> infinity, can you build ghc using the debian binaries in your archive?
[10:29] <doko> probably the linker changes are needed there too. didn't check ocaml
[10:30] <infinity> doko: Did markos build ghc in Debian?  If so, yeah, I can cross-strap it here.
[10:30] <infinity> doko: (After I sleep)
[10:31] <doko> infinity, yes, it's in the ports archive. I'll start a build here
[10:31] <doko> libreoffice doesn't work yet
[10:31] <infinity> Dang.
[10:32] <infinity> And we were doing so well in main too.
[10:32] <Laney> oh, thanks for ghc; I saw the depwait
[10:33] <infinity> doko: Don't worry about ghc, I'll kick it off before I go to bed.
[10:34] <doko> going back to gnat ...
[10:35] <doko> Laney, infinity: any idea about fpc?
[10:35] <Laney> the pascal thing? not really
[10:36] <infinity> fpc may need porting.  Pretty sure it's not been done in Debian yet.
[10:37] <Laney> nothing in ports, possibly because it is in p-a-s
[10:38] <doko> yes b-d's on itself
[10:38] <Laney> http://lists.freepascal.org/lists/fpc-devel/2011-September/025911.html
[10:40] <Laney> (and following)
[10:40] <Laney> → not ported
[10:44] <infinity> ghc building.  Nap time.
[11:10] <doko> Laney, are you know comfortable with these kind of build failures? ;-P https://launchpad.net/ubuntu/+source/libdap/3.11.1-9/+build/2964286
[11:12] <l3on> hey gusy... each package with xz compressor needs a Pre-Depends: dpkg (>= 1.15.6), right ?
[11:12] <l3on> *guys
[11:16] <Laney> doko: argh!#
[11:19] <Laney> is nobody running debian rebuild tests any more?
[11:19] <micahg> l3on: with xz debs, yes
[11:19] <l3on> micahg, thanks :)
[11:20] <Laney> lucas: ^ did your minions fall away or is there one coming up soon?
[11:20] <micahg> Laney: ISTR lucas asking for help and the request falling on deaf ears
[11:20] <Laney> no, some other people did run them
[11:23] <OdyX> there are some people processing the logs now, but actually running the rebuilds is still (AFAIK) in lucas' hands.
[11:23] <Laney> I suspect that is the more automatable part anyhow
[11:40] <l3on> pitti_, hey! I'm looking at gnome-applets, can I do the merge ?
[11:41] <pitti_> l3on: of course, thanks!
[11:41] <l3on> :)
[11:41] <pitti_> l3on: it's maintained in lp:~ubuntu-desktop/gnome-applets/ubuntu, perhaps you can do a merge proposal?
[11:42] <pitti_> yay, I'm through with process-removals, after only 2.5 hours or so
[11:42] <l3on> ah... I'm doing it in the classic way... bug :)
[11:42] <pitti_> l3on: ok
[11:50] <pitti_> lamont, elmo: any chance to kill the glib2.0 build on zirconium? it's once again stuck in an infinite loop in the test suite
[11:58] <pitti_> cjwatson: I finished the ttf-* -> fonts-* transition as far as Debian did it (syncs, removals, seed changes, etc.); this changed some names in platform/installer-gtk; does this need corresponding changes in d-i/ubiquity?
[12:00] <sladen> pitti_: there's our fonts to do aswell, when I get some firm guidance from other pkg-fonts people about exactly what they want
[12:07] <lucas> Laney, micahg, OdyX: it's still up to me to run the rebuilds, but others have been processing the logs. Nobody asked me for fresh logs recently, so it's true that I did not run any rebuild recently.
[12:08] <cjwatson> pitti_: d-i build/pkg-lists/ might need some changes
[12:08] <pitti_> cjwatson: ok, will change it there as well; I kind of assumed it would be generated from the seeds
[12:12] <pitti_> cjwatson: committed; I'll upload it once fonts-sil-abyssinica-udeb gets published; thanks!
[12:37] <MSK> i am interested in contributing an application software to ubuntu. how do i get started?
[12:45] <ubuntu_love> how do i get started to contribute an application to ubuntu
[13:07] <hrw> eglibc maintainers: can you take a look at http://bazaar.launchpad.net/~hrw/ubuntu/precise/eglibc/fix-hardening-for-cross-builds/revision/239 and give opinion?
[13:20] <smoser> barry, here now. i'm guessing you were pinging regarding the python-boto
[13:20] <smoser> i can upload that, and thank you for reviewing.
[14:44] <l3on> cjwatson, around ? I would like to talk with about the importance about have "Pre-Depends: dpkg (>= 1.15.6)"
[14:45] <l3on> I wrote a very spartan pyscript that looks for packages don't have this, I found many of them...
[14:46] <tumbleweed> l3on: that contain data.tar.xz ?
[14:46] <l3on> yes
[14:55] <l3on> tumbleweed, for example... packagesrc colord has colord_0.1.12.orig.tar.xz
[14:55] <tumbleweed> l3on: this is about xz compression in binaries, not sources
[14:55] <tumbleweed> i.e. debs with xz compressed contents
[14:56] <l3on> tumbleweed, ahhh... :)
[14:57] <l3on> tumbleweed, could you provide me an example ?
[14:57] <tumbleweed> l3on: dovecot
[14:58] <l3on> I thought that if a source has something with *.xz, binaries should have the Pre-Depends
[14:58] <tumbleweed> no, they are unrelated
[14:58] <stokes_> _jmp_: o/
[15:02] <l3on> tumbleweed, for example... libparse-http-useragent-perl has the Pre-Depends
[15:02] <l3on> what have I look for ?
[15:02] <l3on> → http://debomatic.debian.net/precise/pool/libparse-http-useragent-perl_0.33-1ubuntu1/libparse-http-useragent-perl_0.33-1ubuntu1.contents
[15:04] <tumbleweed> l3on: http://paste.ubuntu.com/762791/ <- note the data.tar.xz
[15:05] <l3on> ah ok :)
[15:05] <l3on> do you think we have some package without the Pre-Depends ?
[15:06] <tumbleweed> no, the builds would have failed to upload
[15:06] <l3on> ah ok, thanks tumbleweed  :)
[15:08] <soren> What is it that mounts a tmpfs on /run?
[15:09] <soren> Oh.
[15:09] <soren> Found it.
[15:09] <soren> (mountall (due to the hidden fstab in /lib/init))
[15:14] <cjwatson> l3on: I don't think you need to do any of this.  I know that there are no outstanding problems of this kind in precise, because I've been squashing every single one of them as I see them show up in the "Failed to upload" state.
[15:39] <kees> hrw: that seems sane to me. I still wish we could build without those disabled.
[15:45] <hrw> kees: ok, so will propose for merging
[15:56] <SpamapS> pitti_: ping, ahead of the actual micro release exception for OpenStack, I was thinking we'd waive the normal rules and let the diablo stable branch uploads into oneiric-proposed.. we can delay their entry into -updates until the TB weighs in on their application for a microrelease exception.
[16:00] <pitti_> SpamapS: ok, we'll review it like a normal SRU then
[16:02] <SpamapS> pitti_: its 25 distinct bugs
[16:02] <ScottK> SpamapS and pitti_: working on KDE 4.7.3 for oneiric-proposed.  We're going to do it in two parts: l10n and the core apps.  We will also need to sort out updating soprano as upstream has VERY strongly recommended updating it with 4.7.3 (it's a KDE support package, so not formally covered under the release exception, but I think it needs to get in this time).
[16:02] <pitti_> SpamapS: do we have a large-ish test suite for these packages?
[16:02] <SpamapS> pitti_: the patch is very large, but *VERY* well tested upstream.
[16:03] <pitti_> ScottK: ok, thanks for the warning
[16:03] <SpamapS> openstack has a ridiculous amount of testing
[16:03] <SpamapS> pitti_: yes, thats why I think they're a slam dunk for the micro release exception
[16:03]  * SpamapS goes afk.. brb
[16:12] <broder> ooc, are there any docs on the form an RM bug should take? (looking for something to point somebody else at)
[16:13] <pitti_> broder: there's no form or so; describe the reason, check rdependencies, and subscribe ubuntu-archive
[16:13] <broder> ok
[16:14] <SpamapS> pitti_: ok back.. so anyway, the last upload they did I rejected because the diff was pages and pages long
[16:14] <SpamapS> pitti_: but they definitely match up with the MRE process exactly.. heavy upstream testing, supported "fixes only" stable releases.
[16:14] <hallyn> pitti: could you drop the libvirt-bin uploads for lucid-proposed and maverick-proposed (versions 0.7.5-5ubuntu27.21 and 0.9.2-4ubuntu15.2, which I think have not yet been accepted)
[16:15] <pitti_> hallyn: you mean libvirt?
[16:15] <hallyn> pitti_: yeah
[16:16] <pitti_> hallyn: rejected lucid upload, no upload for maverick
[16:16] <pitti_> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1
[16:16] <hallyn> drat!  i meant oneiric, not maverick
[16:17] <pitti_> hallyn: *flush*, gone
[16:17] <hallyn> pitti_: thanks!  now i just need to put out the precise fire
[16:20] <jibel> apw, I can't reproduce the EINVAL bug with kernel 201112070916.
[16:20] <pitti_> jibel, apw: \o/
[16:20] <jibel> apw, I let the test run 50 rounds with and without cpu and disk activity and no crash
[16:21] <jibel> so looks good
[16:21] <apw> jibel, most excellent, will see about gettting soemthign commit while we wait for upstream to decide
[16:22] <cking> nice one apw
[16:24] <pitti_> really, it's still a totaly miracle for me how you guys debug somethign like this
[16:24]  * pitti_ bows
[16:25] <pitti_> (and my typing sucks more and more after 11 hours on the computer, argh)
[16:26] <apw> pitti_, your own stuff is always easier ... but primarily using brute force, i have build and booted about 20 or so kernels to track this puppy down
[16:26] <apw> a fast builder is essential
[16:27] <pitti_> apw: yeah, bisecting would be pretty much the only thing that would come to my mind, if it wouldn't take two hours to verify each step
[16:27] <apw> pitti_, in this case we had some luck in that it is not normal to return EINVAL from write, so it was a detectible and therefore debuggable issue
[16:40] <pitti_> seb128: bah, the new <glib.h> enforcement is nasty
[16:40] <pitti_> seb128: I'm trying to fix awn-extras
[16:40] <pitti_> but the part that includes parts of glib is in the vala-autogenerated .c source, so I can't patch it :(
[16:42] <broder> pitti_: the includes to use come from the .vapi file, so you should be able to edit /usr/share/vala-0.14/vapi/glib-2.0.vapi
[16:42] <broder> (vapi/glib-2.0.vapi in the vala source)
[16:42] <pitti_> that seems fine, though
[16:42] <pitti_> oh no, there it is
[16:43] <pitti_> glib.h,glib/gi18n-lib.h
[16:43] <pitti_> broder: thanks, will do that
[16:43] <seb128> pitti_, we should maybe backport a patch in our vala if there is one needed
[16:44] <pitti_> yes, I'll check this upstream
[16:44] <seb128> pitti_, check if that's maybe fixed in .1, I just uploaded that vala update
[16:45] <ant30> Hi, any body knows about sane-pnm (debugging module scaner) on oneiric or +1
[16:47] <pitti_> seb128: I'll fix debian/watch for .tar.xz
[16:47] <seb128> pitti_, oh, I forgot that right, thanks
[16:47] <pitti_> seb128: how did you get the source?
[16:47] <seb128> pitti_, wget
[16:48] <seb128> I usually use the gnome ftp list emails and just wget the url
[16:48] <seb128> I got used to that because at some point the watch integration stuff was downloading the tarballs twice
[16:48] <seb128> I should check if that's still the case
[16:49] <pitti_> seb128: ok, not fixed in 0.14.1
[16:50]  * pitti_ checks trunk
[16:50] <seb128> pitti_, we could also distro patch the single requirement out of glib
[16:50] <seb128> pitti_, it's not something we technically "need"
[16:50] <seb128> i.e I don't think it solved anything for us
[16:50] <pitti_> also not fixed in vala trunk
[16:50] <seb128> we might maybe just avoid the work for this cycle
[16:50] <pitti_> seb128: yeah, it'll just cause tons of FTBFS :(
[16:51] <pitti_> it's somethign nice for jhbuild and upstream devs
[16:51] <pitti_> I'll report a bug against vala
[16:51] <seb128> pitti_, http://git.gnome.org/browse/glib/commit/?id=7455dd370eb37ce3b0b409ff6120501f37b50569
[16:51] <pitti_> but +1 for dropping the #error for now
[16:52] <pitti_> seb128: I guess we could just turn #error into #warning to get an one-line patch?
[16:52] <seb128> wfm
[16:53] <seb128> it's probably easier that playing catchup on what they will change
[16:53] <seb128> that->than
[16:53] <seb128> pitti_, well it seems you will need to do it in each .h still?
[16:54] <pitti_> I think it comes from /usr/include/glib-2.0/glib/gmacros.h:32
[16:54] <pitti_> well, at least that's what I stumbled over, seems like a common include
[16:55] <pitti_> seb128: ah, you are right :(
[16:56] <seb128> pitti_, the commit says they do single include warnings since 2.17 which is years old, are we sure that's a very common issue?
[16:56] <pitti_> I've seen it in two different packages now since I upgraded to 2.31 again today
[16:57] <pitti_> I might just have been unlucky, of course
[16:58] <seb128> pitti_, what include was it?
[16:59] <pitti_> filed as gnome bug 665739
[16:59] <slangasek> doko: what uploads are needed for libjpeg-turbo?
[17:00] <pitti_> seb128: I'll send a patch there and upload vala for now; but we should still keep reverting this as an option if it causes too much failure IMHO
[17:00] <doko> libjpeg-turbo, and libjpeg8, prepared by tgall_foo
[17:01]  * tgall_foo appears
[17:01] <seb128> pitti_, $ find . -name *.h | xargs grep include | grep "#include <glib/"
[17:02] <seb128> pitti_, did that on my disk with 164 different subdir in my ubuntu packages checkouts dir, I found only awn which has issues
[17:02] <slangasek> doko: ok, just the two packages then?  that doesn't sound too bad :)
[17:02] <slangasek> doko: I was worried when you said "uploads" that reverse-deps needed rebuilt or something
[17:03] <seb128> pitti_, it doesn't seem very common, at least in the default install desktop set, I think I've most of it covered on my disk
[17:03] <doko> slangasek, no, just replacing the jpeg implemenation. it should work fine (tm)
[17:03] <slangasek> right :-)
[17:03] <pitti_> seb128: why do you only consider .h files?
[17:03] <seb128> pitti_, "find . -name *.h | xargs grep "#include <glib/"" is probably easier ;-)
[17:03] <pitti_> seb128: yes, I'm working on awn-extras ATM
[17:03] <bdmurray> slangasek: so multiple languages are affected by bug 898787?
[17:04] <pitti_> seb128: but good to know
[17:04] <slangasek> bdmurray: yes - we can probably scrape the relevant language info from each of the reports
[17:04] <bdmurray> slangasek: of the bug reports or ...?
[17:04] <seb128> pitti_, it's running for .c now, I could have done both in one run indeed ;-)
[17:04] <slangasek> bdmurray: the bug reports, yes - that's where I found sv_SE for the one
[17:05] <seb128> pitti_, same for .c, only awn that I can see
[17:05] <pitti_> cool
[17:05] <pitti_> and vala stuff can be fixed in one go
[17:05] <seb128> pitti_, let's wait a bit see how it goes, if it turns to be an issue we can turn if off
[17:06] <pitti_> seb128: I had one other rebuild yesterday which failed, someting in the poppler chain
[17:07] <seb128> pitti_, well I'm sure we will have some issues out of the desktop set
[17:07] <seb128> pitti_, GNOME seems to be well disciplined on fixing that sort of stuff, other upstreams might care less
[17:08] <pitti_> seb128: yeah, using jhbuild as a developer helps a lot with that
[17:09] <seb128> pitti_, oh btw, it's 6pm you really should stop working :p 6am to 6pm is enough ;-)
[17:09] <seb128> pitti_, you make me feel bad for starting hours later than you if you don't finish hours earlier than me :p
[17:10] <pitti_> heh
[17:10] <pitti_> seb128: I took a long break two hours ago, 'sok
[17:10] <seb128> ;-)
[17:10] <pitti_> I think I got awn-extras to build, just one remaining thing
[17:11] <pitti_> so that, forward vala patch to gnome, upload vala, upload awn, then done :)
[17:13] <pitti_> built! yippie
[17:22] <nxvl> pitti_: i'm trying to sync virt-viewer and i get a "package is blacklisted" message from syncpackage, how can i check why is it blacklisted?
[17:24] <nxvl> pitti_: or who should i poke
[17:24] <cjwatson> nxvl: It has Ubuntu modifications.  You need to use -f
[17:24] <Laney> it is syncpackage telling you that there's an ubuntu diff
[17:25] <Laney> what did the message say?
[17:25] <pitti_> nxvl: it's not blacklisted in dak; does it really say "blacklisted"?
[17:25] <Laney> https://launchpad.net/ubuntu/precise/+localpackagediffs?field.name_filter=virt-viewer&field.package_type=all&field.package_type-empty-marker=1
[17:25] <nxvl> cjwatson: oh, that's the blacklisting for? that's what i wanted to make sure before i force it
[17:26] <nxvl> pitti_: http://paste.ubuntu.com/762936/
[17:26] <nxvl> pitti_: but cjwatson might just posted the answer
[17:26] <pitti_> nxvl: so, not blacklisted in DAK; I suppose it's blacklisted in Launchpad's brain
[17:26] <Laney> I just linked that.
[17:27] <nxvl> pitti_: yay for lp
[17:28] <cjwatson> Right, so it told you what option to use, it was just unclear about why.  (I'm pretty sure there's a bug about this.)
[17:28] <Laney> it's actually fixed in newer versions to ignore that
[17:29] <nxvl> cjwatson: yes, indeed, i just wanted to make sure it was blacklisted because of the ubuntu changes and not really blacklisted because something else
[17:29] <nxvl> cjwatson: thanks!
[17:29] <jamespage> cnd: python-libavg has been dropped from the archive in precise which puts a question mark over empcommand - is this something that you want to see in the archive still?
[17:31] <pitti_> cnd: we can also reintroduce libavg as an ubuntu-only package, when we need it (it was removed in Debian and we followed suit)
[17:36] <cnd> pitti_, jamespage: ubuntu's libavg was different than debians
[17:37] <cnd> ubuntu's was being maintained by libavg directly, with my help
[17:37] <pitti_> cnd: ok, so we should reintroduce it?
[17:37] <cnd> pitti_, yes please
[17:38] <pitti_> cnd: ok; sorry for the hassle
[17:38] <cnd> pitti_, np, it's a corner case :)
[17:41] <pitti_> jamespage: hrmpf, awn-extras is FUBAR; I'll continue this tomorrow
[17:41] <pitti_> hm, is it just me, or is uploading packages really slow today?
[17:41] <pitti_> jamespage: I'm uploading libavg, and then call it a day
[17:42] <jamespage> pitti_, I think it is a bit - I had put it down to my ADSL upstream being slow
[17:50] <pitti_> cnd, jamespage: libavg source NEWed, will binNEW later when it's built
[17:51] <jamespage> pitti_, thanks!
[17:51] <seb128> jamespage, pitti_: uploads are slow today, I dputed from a canonical box to avoid downloading and uploading a tarball from here and it was slow as well
[17:51] <pitti_> hmm
[17:51] <pitti_> Package: python-libavg
[17:51] <pitti_> Architecture: i386 amd64
[17:51] <pitti_> jamespage: ^ how come that empcommand is also broken on armel/powerpc?
[17:51] <pitti_> cnd: ^
[17:52] <pitti_> it seems libavg was only available on i386 and amd64 before
[17:52] <pitti_> jamespage: so we might need to fix empcommand to be on those two arches, too
[17:52] <pitti_> instead of arch: all
[17:52] <pitti_> or build libavg on arch: any if possible
[17:52] <jamespage>  pitti_: it looks like there is a really old version of libavg in for armel,powerpc
[17:52] <jamespage> 1.0.1-1ubuntu4
[17:53] <pitti_> but there can only be one version of libavg
[17:53] <pitti_> unless you copy/rename the source
[17:53]  * pitti_ waves good night, cu tomororw
[17:54] <cjwatson> jamespage: we aren't always great at removing stale binaries when architectures stop being built
[17:54] <pitti_> oh, that wouldn't hit the NBS report?
[17:54] <pitti_> i. e. if you change a package from all/any to e. g. i386 amd64?
[17:55] <cjwatson> I'm not sure it necessarily dodes
[17:55] <cjwatson> *does
[17:55] <pitti_> or it did and we just didn't clean it up so far?
[17:55] <cjwatson> just going from empirical evidence I've vaguely noticed ...
[17:55] <pitti_> ok, thanks
[17:56] <pitti_> anyway, that's all "tomorrow" stuff; good night everyone!
[17:56] <pitti_> I'm still server-less and thus without IRC proxy and mail FYI :(
[18:42] <RoAkSoAx> can an AA please process gfs2-utils from the new queue?
[18:46] <tsdgeos> hi, why is there no xcb-xinput-dev  ?
[18:47] <tsdgeos> are we blocking it for any particular reason?
[18:48] <micahg> cnd: re libavg, is there any reason why it couldn't be maintained in Debian as well?  The RC bugs were things that we would've fixed along the way anyways (binutils-gold and boost transition)?
[19:06] <cnd> micahg, the libavg team wanted to maintain it, and they felt they were not fit to maintain it for debian
[19:07] <cnd> they came to the utouch team showing us how they had integrated multitouch
[19:07] <cnd> so it seemed silly to turn them away
[19:07] <cnd> so I helped them get it packaged for ubuntu
[19:07] <cnd> the libavg team only runs ubuntu, no debian installs
[19:08] <cnd> there's no reason it couldn't be maintained in debian, it just wasn't a feasible option at the time
[19:08] <cnd> tsdgeos, there's no such thing as xcb-input-dev because xcb doesn't support XInput yet :(
[19:09] <micahg> Laney: or tumbleweed ^^ is there anything we can do in this case?  would it be better to blind upload to Debian (I assume the sponsor will build test at least) or just have the package in Ubuntu?
[19:09]  * broder maintains a package in debian in spite of not having any debian installs
[19:09] <broder> (just debian chroots)
[19:10] <tumbleweed> micahg: I mailed the ubuntu uploader about this too
[19:10] <tumbleweed> the bug for filing its removal from debian clearly noted that there was active maintainance in UBuntu, and offered sponsorship
[19:11] <micahg> cnd: ^^ so, would you be willing to move the maintenance to Debian then, might get a few more bugs?
[19:11] <tumbleweed> broder: ...I only have one Ubuntu install... (and don't do much real work on it :P )
[19:11] <cnd> micahg, I personally don't have enough time to move it to debian :(
[19:12] <cnd> at least, not in this cycle
[19:14] <tsdgeos> cnd: are you sure? i have someone here in archlinux that says to have that file
[19:14] <tsdgeos> or is the file there but just does nothing?
[19:16] <cnd> tsdgeos, 99% sure
[19:16] <cnd> unless it's something that was created in the past two months
[19:17] <tsdgeos> cnd: http://xcb.freedesktop.org/manual/group__XCB__Input__API.html ?
[19:21] <cnd> tsdgeos, http://lists.freedesktop.org/archives/xcb/2010-August/006414.html
[19:21] <cnd> I think that is still the case
[19:21] <tsdgeos> ok
[19:21] <cnd> but I could be wrong
[19:22] <cnd> tsdgeos, you should ask on xorg-devel@lists.x.org or on #xcb
[19:22] <cnd> if you want to be sure
[20:02] <stgraber> Is it just me or is upload.ubuntu.com horribly slow today? (as in, multiple minutes for a few KB to upload)
[20:02] <stgraber> (latency looks good and I didn't notice any slowness on anything else in the DC)
[20:06] <broder> pitti and jamespage were complaining earlier
[20:08] <stgraber> good, not just my broken internet then :)
[20:14] <hallyn> stgraber: it's not jsut you
[20:15] <hallyn> and now i'm about to upload a new qemu-kvm .orig.tar.gz.  this is gonna be painful
[20:22] <stgraber> hallyn: yeah, so far I pushed really small packages, next ones are a few SRUs for Edubuntu, these are ~10MB so won't be as much fun :)
[20:45] <kees> where did the launchpad.net/bugs/NNN short-cut go?
[20:45] <broder> kees: wfm, though i've started using pad.lv/NNN instead
[20:45] <jelmer_> kees: still seems to work here
[20:47]  * kees scratches his head
[20:47] <kees> ah! it's not there for http.
[20:47] <mdeslaur> kees: huh? wfm
[20:48] <kees> mdeslaur: it wasn't for me.
[20:48] <infinity> Yeah, works over http too...
[20:48] <infinity> kees: Still, Martin's pad.lv is less typing. :)
[20:48] <kees> weird. not it works.
[20:48] <kees> *now
[20:49] <mdeslaur> kees: must be your arp-spoofed default gateway
[20:49] <kees> hrm. chromium doesn't show failed connection attempts.
[20:49] <kees> I wonder if my vpn broke DNS for a minute or something
[20:50] <kees> and https must have triggered a re-pinning or something.
[20:50]  * kees shrugs
[20:50] <hallyn> cyphermox: the libnl3 fix for bug 856209, is there a reason not to forward that to debian?
[20:50] <cyphermox> hallyn: yes, now there is ;)
[20:51] <cyphermox> hallyn: I'm working with Heiko Stuebner to get libnl3 3.2.3, which should be in experimental real soon; and includes that fix
[20:52] <cyphermox> unless you're running in a debian issue with this? but NM was afaik the only thing affected, and mbiebl is also very eager to get the new libnl3 in debian
[20:53] <hallyn> cyphermox: ok, cool!  I was just considering syncing from sid to get rid of the classid warning with netcf
[20:54] <hallyn> i can wait for a better sync :)   thanks much
[20:54] <cyphermox> ah, but we should indeed fix this
[20:54] <cyphermox> merge maybe?
[20:54] <cyphermox> actually, give me a second, I think I've already looked at it, and there's an issue with that debian revision anyway
[20:54] <hallyn> sure, should be trivial, but how soon will the 3.2.3 be coming?
[20:54] <hallyn> oh
[20:55] <cyphermox> soon depends on how fast d-i, wpasupplicant and others can be fixed (transition from libnl3-dev to (libnl-3-dev and maybe others))
[20:55] <hallyn> cyphermox: ok, well netcf doesn't *break* bc of it, it just spits out warnings
[20:56] <cyphermox> hallyn:   * debian/libnl-3-200.install: netlink config files should be installed to /etc/libnl, not /etc/libnl3.
[20:56] <cyphermox> that seemed to be important, the files in /etc/libnl3 wouldn't get searched for anyway
[20:57] <cyphermox> so if you want to fix it (and I think we should), it's just a matter of installing the classid and that other data file to /etc/libnl
[20:57] <cyphermox> hallyn: or I can take care of it
[20:58] <hallyn> cyphermox: whatever is your preference.  Well, if you don't mind, I'll leave it to you :)
[20:59] <cyphermox> hallyn: ok ;) I'll re-test it just in case, but I'm pretty sure the files didn't get read if they were in /etc/libnl3
[21:01] <hallyn> cyphermox: thanks again
[21:11] <bdmurray> @pilotin
[21:11] <udevbot> Error: "pilotin" is not a valid command.
[21:11] <infinity> bdmurray: Every day, you're pilotin'?
[21:12] <bdmurray> I'm plotin everyday
[21:12] <RoAkSoAx> TheMuso: ping
[21:13] <bdmurray> @pilot in
[21:15] <kees> infinity: thanks, now I have to get that earworm out of my head
[21:15] <infinity> kees: Try tweezers.
[21:15]  * kees will use Nyan Cat
[21:16]  * infinity has had Tim Minchin's "If I Didn't Have You" stuck in his head for days.
[21:17]  * kees is worried
[21:18] <kees> infinity: heh, this is good :)
[21:20] <bdrung> tumbleweed: ubuntu-safe-to-upload is a long name. what about "safe-ubuntu-upload"?
[21:21]  * micahg thought it was going to change to is-seeded
[21:24] <tumbleweed> yeah, that's probably a reasonable name for it
[21:26] <hallyn> hm, can't get to lp right now
[21:29] <slangasek> ScottK, cjwatson: I'm not sure what pitti did the other day to fix the langpack problem, but I still see a lot of langpacks in oneiric-proposed that have not been copied to oneiric-updates, and they're *not* showing up as candidates on http://people.canonical.com/~ubuntu-archive/pending-sru.html
[21:29] <ScottK> slangasek: AFAIK he copied the one I was missing (It was the KDE en base one, whatever that's called)
[21:29] <ScottK> I don't think he did anything else.
[21:29] <slangasek> ok
[21:30] <bdmurray> is pending-sru tied to bugs?
[21:30] <slangasek> bdmurray: tied how?  It tries to grab a list of SRU bugs from the .changes files and track their verification status
[21:30] <slangasek> oh, you mean, does it depend on there being bugs in the changelog for a package to show up there?
[21:31] <bdmurray> yes
[21:31] <slangasek> it doesn't - but language packs are special cased anyway
[21:31] <slangasek> and the special-casing keys on the English langpack
[21:31] <seb128> slangasek, I don't know the details but I will mention that anyway in case:
[21:31] <seb128> https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA
[21:32] <seb128> slangasek, it seems they upload all locales to proposed but move to updates only the one verified by their team doing the translations
[21:32] <slangasek> seb128: right, well, the current problem is that only some packages were copied to -updates for each language, making some of them uninstallable
[21:32] <slangasek> can't copy language-pack-$foo-$lang without also copying language-pack-$foo-$lang-base, etc
[21:32] <seb128> slangasek, ok, that's where I step out and pretend I was not there ;-)
[21:33] <bdmurray> seb128: why was the sponsors subscribed to bug 886205?
[21:33] <seb128> bdmurray, because of https://launchpadlibrarian.net/84431732/rc-sysinit.conf.diff ?
[21:33] <slangasek> seb128: https://wiki.ubuntu.com/Translations/LanguagePackUpdatesQA is completely outside the standard SRU process and this is the first I've heard of it as a member of ubuntu-sru... do you know who's managing this publication process?
[21:33] <seb128> bdmurray, why shouldn't sponsor be subscribed?
[21:34] <doko> infinity, we should have finished the armhf builds before new glib/gtk uploads :-/
[21:34] <bdmurray> I thought the sponsors team was more for debdiffs than just diffs
[21:34] <bdmurray> and that the ubuntu-reviewers team was for patches
[21:34] <seb128> slangasek, no, I just know that a "Kenneth Nielsen" does call for testing and thanks for testing emails to ubuntu-translators@lists.ubuntu.com listing that wiki
[21:35] <seb128> slangasek, so it seems their process is "publish to proposed, call for testing on the translator list, move things which get validated"
[21:35] <seb128> slangasek, but I'm not well informed, it's my view as an external watcher
[21:35] <seb128> bdmurray, we have some thousand said "patches" in launchpad and ubuntu-reviewers is pretty much stalled
[21:36] <seb128> bdmurray, I try to push things that seems like they would be useful to sponsors so they get a chance to make it in
[21:36] <bdmurray> seb128: okay, I was asking because I was worried by bug bot had made a mistake
[21:36] <seb128> bdmurray, it usually works fine, most sponsors are happy to sponsors patches which are not debdiff and we got quite some fixes uploaded this way
[21:37] <slangasek> SpamapS: ^^ hi, is there some under-documented policy for langpack SRUs being followed nowadays?
[21:37] <seb128> bdmurray, they is lot of noise and useless stuff in the review team queue though, I usually spend an hour to take 15 out of the most recent hundred or something
[21:37] <bdmurray> seb128: sure, that makes sense to me
[21:37] <seb128> bdmurray, great ;-)
[21:44] <bdrung> tumbleweed: there are still merge markers in this branch
[21:45] <tumbleweed> bdrung: ok, let me clean it up and rename it...
[21:49] <SpamapS> slangasek: I had wondered the same thing last cycle when a similar flood of SRU's arrived for natty.
[21:52] <slangasek> SpamapS: well, historically the SRUs are all batch-processed... but something else has happened this time and I'm not sure what
[21:53] <bdmurray> where did the packaging guide go?
[21:54] <slangasek> SpamapS: there was an SRU regression alert a week ago because of resulting uninstallabilities, and I've just tracked down another 3 packages that had the same problem :/
[21:55] <SpamapS> slangasek: ugh
[21:56] <seb128> bdmurray, http://developer.ubuntu.com/packaging/html/
[21:56] <bdmurray> seb128: thanks
[21:56] <seb128> yw
[22:03] <broder> bdmurray: oh, sorry - i meant to deal with bug #886205 last night and forgot. i'll do so now
[22:03] <tumbleweed> bdrung: done
[22:04] <seb128> broder, thanks ;-)
[22:09] <bdrung> tumbleweed: "audacity's binaries are not seeded" is a full sentence
[22:09] <bdrung> tumbleweed: the seeded list isn't nicely formatted
[22:09] <bdrung> maybe use more lines
[22:11] <tumbleweed> bdrung: micahg was complaining that there was too much duplicated output when I used more lines :P but I can do something inbetween :P
[22:11] <ScottK> Use both more and fewer lines.  That will make everone happy.
[22:11] <broder> Not me. I want exactly the same number of lines
[22:11] <bdrung> tumbleweed: maybe with a switch
[22:12] <tumbleweed> noooo
[22:12] <bdrung> --long
[22:12] <bdrung> ubuntu-upload-permission output looks nicer
[22:12] <ScottK> tumbleweed: Make the option --bdrung
[22:13]  * tumbleweed should have named wrap-and-sort's -s  --stefanor
[22:13] <doko> In file included from ../../src/ario-util.h:21:0,
[22:13] <doko>                  from ario-filesystem.c:28:
[22:13] <doko> /usr/include/glib-2.0/glib/gslist.h:28:2: error: #error "Only <glib.h> can be included directly."
[22:13] <doko> seb128: ^^^ what is the recommend recipy to fix this?
[22:14] <doko> seeing ~100 build failures because of this
[22:15] <seb128> doko, what the message say
[22:16] <seb128> doko, just include glib.h, not the individual ones like gslist.h
[22:16] <doko> seb128, I do see 100 build failures for the time after glib was uploaded. so this will turn into some hundreds in the end
[22:16] <seb128> doko, we discussed it with pitti, see log around 19h european time
[22:16] <seb128> doko, we discussed whether revering it, seems like we should do it
[22:16] <seb128> doko, the commit upstream is http://git.gnome.org/browse/glib/commit/?id=7455dd370eb37ce3b0b409ff6120501f37b50569
[22:17] <seb128> doko, basically that's a warning since 2.18, which means since 8.10, upstream though most softwares would have been fixed in 3 years, seems not
[22:17] <doko> seb128, please could you revert it for now? it really hurts the armhf bootstrap
[22:18] <seb128> doko, ok, we were discussing it with pitti earlier as said but we were unsure if that was a frequent issue, good to get some datas, sorry that it has been hitting you in your work :-(
[22:18] <doko> seb128, I'm fine to do a test rebuild with this upstream change, but getting this untested into the archive is the wrong way
[22:19] <seb128> doko, we didn't get this in the archive, we got a new glib where they enforced something which was a warning for 3 years
[22:19] <seb128> well we got it, but we didn't mean to break stuff
[22:19] <seb128> it was just part of a new glib version
[22:19] <doko> yeah, so please could you revert it for now, at least until armhf is built?
[22:19] <seb128> I'm on it
[22:19] <doko> thanks
[22:20] <seb128> you're welcome
[22:20] <bdrung> ScottK: --bdrung or the env variable WORLD_DOMINATOR is set to true :D
[22:20] <seb128> sorry for the issues
[22:26] <tumbleweed> bdrung, micahg: http://paste.ubuntu.com/763211/ compromise?
[22:26] <cjwatson> hallyn,stgraber: we should have escalated that upload slowness earlier :-(
[22:26] <cjwatson> hallyn,stgraber: seems that it was an early warning sign of impending LP lots-of-stuff-falling-over that we failed to pass on
[22:27] <tsdgeos> cnd: you are in the xcb channel, but i'll repeat it here "does xcb support xinput?" <pharris> Most of it.
[22:27] <bdrung> tumbleweed: yes
[22:28] <doko> infinity, ^^^ now that hubbard is turned to manual and after the glib update it would be good to give back all armhf builds
[22:28] <bdrung> tumbleweed: i maybe would start the line always with the binary package, e.g. glibc-doc (from eglibc) is seeded in:
[22:28] <infinity> doko: Yeah, can do.
[22:28] <infinity> doko: Why manual hubbard, though?
 hmm, https://launchpadlibrarian.net/86854809/buildlog_ubuntu-precise-armhf.acetoneiso_2.3-1ubuntu1_FAILEDTOBUILD.txt.gz
 Architecture: linux-any
 isn't this handled by soyuz?
 doko: We patched sbuild last week to use the chroot's dpkg-architecture.
 That version of sbuild isn't out everywhere.
[22:29] <infinity> Oh, bah.
[22:29] <infinity> doko: Someone swapped hubbard to armhf. :(
[22:30] <infinity> doko: Any idea who?
[22:30] <infinity> doko: It should be armel until the updates.
[22:30]  * infinity fixes.
[22:30]  * doko avoids the question
[22:30] <infinity> So, it was you?
[22:30] <doko> infinity, ENOPERM
[22:30] <infinity> You have perms...
[22:31] <wgrant> infinity: 'twasn't me.
[22:31] <infinity> Did you give back all of hubbard's failures?
[22:31] <infinity> Well, all the ones due to that? :P
[22:32] <infinity> Doesn't matter if I'm doing a mas-give-back after glib2.0 anyway, I guess.
[22:33] <doko> I assume so
[22:34]  * cjwatson does a quick grep for those failures
[22:34] <lardman|home> evening, I'm trying to boot an ARM core image and can't seem to find what the username:password combo should be, any hints?
[22:35] <infinity> lardman|home: There isn't one.
[22:35] <infinity> lardman|home: You can't just boot core as-is, you need to set up either a password for root or create a user, or seed in an installer to do those for you.
[22:35] <infinity> lardman|home: It's meant as a small rootfs to build on top of, not a bootable system.
[22:35] <lardman|home> infinity: ah I see
[22:36] <lardman|home> sure, I'd installed some other packages but didn't think to create a user, my fault
[22:37] <lardman|home> thanks
[22:38] <infinity> lardman|home: If you have no actual need for users (plenty of embedded systems run as root only, for instance), you could just chroot in and run passwd for root.
[22:38] <lardman|home> infinity: it's a direct boot on a Samsung Galaxy Tab, so I will need to login somehow
[22:39] <lardman|home> I'll chroot on my pc and give root and password and go from there
[22:39] <hallyn> drat.
[22:40] <cnd> tsdgeos, argh, he quit before I could ask a follow up
[22:40] <cnd> I'm wondering if it's still disabled by default
[22:40]  * infinity taps his foot and glares at this GHC build still going.
[22:40] <cnd> if not, then it should be packaged up in debian
[22:40] <infinity> I guess I should be happy that it hasn't failed...
[22:41] <doko> infinity, with the give back you'll get the gdc rebuilds for free
[22:41] <cjwatson> infinity,doko: I've given back the five linked from the ubuntuwire index (acetoneiso advi afterstep anjuta open-invaders)
[22:41] <doko> \o/
[22:45] <cyphermox> hallyn: there's a merge bug and branch up for sponsoring; bug 901438
[22:45]  * cyphermox -> dinner
[22:50] <hallyn> cyphermox: great, looks good, thanks.
[23:52] <Juayz> Hello
[23:53] <Juayz> is there support for Malay Brunei language in ubuntu?
[23:58] <slangasek> Juayz: information about Ubuntu language support in general can usually be found at https://translations.launchpad.net/ubuntu.  However, it doesn't appear that there's a recognized international language code for "Malay Brunei" at all, making it impossible for me to say if there's any support for that - is this language known by another name?
[23:58] <slangasek> alternatively, if you happen to know the ISO code for this language...
[23:59] <Juayz> Melayu Brunei
[23:59] <Juayz> this is the official Malay language of the State of Brunei