[00:00] <SpamapS> infinity: so, is there a way to force the build host or should I just retry until it works?
[00:00] <StevenK> SpamapS: You can't, it can be done with a form of superpowers.
[00:01] <stgraber> SpamapS: you need someone in ~buildd to disable all the others, bump the score and enable just the one you want. I can do that for you if you want (need a build link and what builder you want)
[00:04] <infinity> SpamapS: I'll do it.
[00:04] <infinity> SpamapS: Was PHP?
[00:04] <SpamapS> stgraber: https://launchpad.net/ubuntu/+source/php5/5.4.4-3ubuntu1/+build/3676565 .. I fully expect an upload of php 5.4.5 in a week or two.. so this may be a problem again
[00:04] <SpamapS> infinity: ^^
[00:05] <infinity> SpamapS: It shouldn't be a problem by then, IS is reinstalling all the Pandas, now that we're sorted out PXE/preseed automagicness.
[00:05] <infinity> SpamapS: caph was our testbed.
[00:06] <SpamapS> ah cool :)
[00:06] <infinity> SpamapS: If you do run across that particular class of failure again, though, let me know.
[00:10] <SpamapS> infinity: ACK
[00:14] <infinity> Sweetshark: libreoffice-dbg probably shouldn't be depending on libreoffice-filter-binfilter if we don't build it anymore
=== ChanServ changed the topic of #ubuntu-devel to: Quantal Quetzal A3 prep | Archive: please upload to -proposed | 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:
[01:19] <infinity> stgraber: FFS.  Would you believe it's as simple as /etc/protocols not being there?
[01:20] <StevenK> Hahaha
[01:21] <infinity> And schroot doesn't show this problem because, despite not having netbase in the chroot, it "helpfully" copies the system one in.
[01:21]  * infinity head -> desk.
[01:23] <StevenK> infinity: Hahaha, it gets worse.
[01:25]  * infinity wonders what the odds are that xnox's issue was actually the same thing.
[01:25] <infinity> He should only be so lucky.
[01:26] <stgraber> infinity: oh, that'd explain it indeed ;)
[01:26] <infinity> Yeah, I spent all this time reducing to a perfect test case, just to strace and go "you've got to be kidding..."
[01:26] <StevenK> infinity: Build-Depends: netbase ? :-P
[01:26] <infinity> StevenK: Yeahp.
[01:27] <StevenK> Oh bloody hell, I was kidding.
[01:27] <StevenK> It's in build-essential!
[01:27] <stgraber> or promote netbase to essential?
[01:27] <infinity> I might be able to argue that libio-socket-inet6-perl should depend on netbase, but I haven't gone looking to see if that's universally true.
[01:27] <stgraber> that thing just contains 4 text files nowadays
[01:27] <infinity> StevenK: It's not build-essential.
[01:28] <StevenK> steven@undermined:~% apt-cache show netbase | grep '^Build'
[01:28] <StevenK> Build-Essential: yes
[01:28] <infinity> Erm.
[01:28] <infinity> Then we have a disconnect between the package and the task.
[01:28] <infinity> And the package is what's guaranteed to be installed.
[01:31]  * infinity wonders who changed one without the other.
[01:31] <StevenK> infinity: Oh, is that what happened?
[01:31] <infinity> StevenK: Well, the chroots all have the package installed, which is authoritative, and most certainly doesn't pull in netbase.
[01:39] <infinity> StevenK: So, build-essential hasn't been updated since 2010.  Whoever things netbase is build-essential is, frankly, wrong. :P
[01:39] <infinity> StevenK: (Though, we could certainly make the two match)
[01:40] <StevenK> It would save confusion
[01:41] <infinity> Well, I could just add netbase to all our chroots and scream "la la la" too, but I don't really want pollution in there until I get to the bottom of why there's a mismatch.
[01:42] <infinity> (And when I say b-e hasn't been updated since 2010, I mean in neither Debian or Ubuntu, so whoever's twiddling archive overrides doesn't quite grasp the disconnect(
[01:42] <infinity> )
[01:44] <infinity> And it's not build-essential in Debian, so we're the ones who are a bit wrong here.
[01:45] <stgraber> how are these packages building in Debian then?
[01:46] <infinity> stgraber: They're not.
[01:47] <infinity> stgraber: Well, this one failed on about half the buildds.  The others must have had either (A) dirty chroots, or hilariously (B) the above-mentioned sbuild/schroot setup that copies /etc/* junk into the chroot.
[01:51] <infinity> stgraber: It's entirely possible that netbase was mistakenly marked build-essential in unstable at one point, we mirrored the change in our overrides, some Debian buildd chroots got created that way, then they reverted it.
[01:51] <infinity> stgraber: So, those chroots would just keep upgrading netbase unless someone decided to rebuild them from scratch or go purging non-essential packages.
=== Amaranthus is now known as Amaranth
=== Beret- is now known as Beret
=== rsalveti` is now known as rsalveti
=== foxbuntu` is now known as foxbuntu
[03:36] <pitti> Good morning
[03:37] <pitti> mdz: hello; sorry, didn't make it to TB again; since it got moved another hour, it's a really bad time for me
[03:39] <RAOF> pitti: How do I make apport-retrace fly? ‘apport-retrace -v --sandbox system -o Xorg-dummy.crash /var/crash/_usr_bin_Xorg.0.crash’ doesn't seem to work; it ends up failing to find Contents.gz. Setting various different things (--cache-dir, --sandbox-dir) result in failing to find different things, mostly virtual_mapping.pickle
[03:46] <pitti> RAOF: I do recommend using a cache dir if you want to run that more than once, but in principle that looks good; do you have a pastebin of the output?
[03:46] <RAOF> http://paste2.org/p/2081338
[03:47] <pitti> urgh
[03:48] <RAOF> I can give you the other permutations if you like :)
[03:48] <pitti> RAOF: hm, I haven't tested --sandbox-dir a lot; that's mostly ev's
[03:48] <pitti> RAOF: does it work without this?
[03:49] <pitti> RAOF: the .pickle error looks like a real bug, but I never saw this before, which makes me think it's related to the permanent sandbox
[03:49] <pitti> RAOF: you don't really need that for your purposes, though
[03:49] <pitti> RAOF: I guess you want to start with --gdb, poke around, and once you got the magic gdb commands, retry with -o or -s?
[03:50] <RAOF> pitti: I tried it with all permutations I could think of; with --sandbox-dir, with --cache-dir, without both.
[03:50] <RAOF> Actually, I just want to check that the retraced bug looks right.
[03:51] <pitti> RAOF: and you always get the pickle error?
[03:51] <RAOF> No; I get the pickle error with... let me check.
[03:53] <RAOF> Pickle when I set sandbox and/or cache; /tmp/tmp48_gk_/Ubuntu 12.10/Contents-amd64.gz missing when I set neither.
[03:56] <pitti> http://mirror.internode.on.net/pub/ubuntu/ubuntu/dists/quantal/ has Contents.gz alright
[03:57] <RAOF> Oh, huh.
[03:57] <RAOF> It turns out I hadn't tried with *just* --cache; that works.
[03:58] <pitti> I usually use -S system -C <cache dir>
[03:58] <pitti> I'm reading the code now to see what's wrong with sandbox dir
[03:59] <pitti> looks like a missing mkdir
[04:07] <pitti> RAOF: right, so that can only happen with --sandbox-dir; I really don't think you want this, but thanks for pointing out
[04:08] <RAOF> Yeah, I probably don't.
[04:09] <pitti> RAOF: it should happen when you give a --sandbox-dir but no --cache-dir?
[04:09] <RAOF> It also happens when you give it a --cache
[04:09] <pitti> ooh, of course -- "system"
[04:10] <pitti> right, so --sandbox-dir with -S system; it does work with an actual sandbox config
[04:10] <pitti> which explains why ev hasn't seen this
[04:13] <RAOF> It also seems that it doesn't work if I *don't* pass --cache.
[04:14] <pitti> yep
[04:15] <pitti> ok, tests pass, fix committed
[04:15] <pitti> RAOF: http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2445 in case you want to apply locally; but just drop --sandbox-dir
[04:16] <RAOF> Yeah, that's what I've done.
[04:16] <pitti> RAOF: you want -S system -C ~/.cache/<whereever>, or -C /tmp/cache or so
[04:16] <pitti> sorry for the trouble
[04:16] <RAOF> That's ok.
[04:16] <hallyn> ubuntu-vm-builder shouldn't affect any cd spins right?
[04:16] <pitti> RAOF: perhaps I should add some more examples to the manpage?
[04:16] <hallyn> is there a tool i can run to check that?
[04:17] <pitti> $ seeded-in-ubuntu ubuntu-vm-builder
[04:17] <RAOF> pitti: Well, I only started playing with the other options because running apport-retrace without -C or --sandbox-dir didn't work.
[04:17] <hallyn> pitti: thanks!
[04:17] <pitti> hallyn: that even errors, it's not even in main
[04:17] <hallyn> pitti: right, not in main,
[04:17] <pitti> RAOF: ah, with the Contents.gz? do you have a pastebin?
[04:17] <RAOF> It has, however, somewhat dimmed my enthusiasm. It turns out that -core only accidentally makes Xorg usefully dump core; there's a SIGSEGV in the logging path :)
[04:18] <hallyn> pitti:  but lxc is not in main, but is seeded - wanted to make sure it wasn't like that
[04:18] <pitti> RAOF: phun!
[04:18] <pitti> hallyn: yes, all derivatives build from universe now, so it's still worth checking
[04:18] <pitti> hallyn: ah, sorry; the source package is "vm-builder", you need to run it with the source pkg
[04:18] <hallyn> ah
[04:18] <pitti> $ seeded-in-ubuntu vm-builder
[04:19] <pitti> vm-builder's binaries are not seeded.
[04:19] <hallyn> thanks!
[04:19] <pitti> $ seeded-in-ubuntu -b ubuntu-vm-builder
[04:19] <pitti> ubuntu-vm-builder is not seeded.
[04:19] <pitti> hallyn: ^ or -b
[04:19] <hallyn> cool
[04:21] <RAOF> pitti: Oh, urgh. *Now* it works without --cache? :/
[04:22] <pitti> RAOF: theory: you used the same --cache dir as in the run that failed over the broken virtual_mapping, and thus the cache dir got broken?
[04:22] <pitti> ah no, you got the Contents bug first
=== cpg is now known as cpg|away
[04:24] <RAOF> pitti: http://paste2.org/p/2081361 is what I got the first time.
[04:26] <pitti> argh
[04:29] <pitti> RAOF: http://paste.ubuntu.com/1107569/ should help, if you want to apply locally
[04:30] <RAOF> I'm happy using --cache.
[04:30] <RAOF> Thanks!
[04:30] <pitti> ok, good
[05:09] <RAOF> pitti: Oh! It seems that if you have apport-retrace installed, the crash dialog has a “Examine locally” button on it! That's totally awesome!
[05:11] <pitti> RAOF: thanks :)
[05:11] <pitti> RAOF: https://wiki.ubuntu.com/DebuggingProgramCrash
=== cpg|away is now known as cpg
[05:31] <RAOF> Oh, that's no fun at all.
[05:32] <RAOF> Apparently Xorg will SIGSEGV in the crash logging if and only if it's built with optimisations.
=== smb` is now known as smb
[05:32] <pitti> RAOF: do you get a reasonably useful backtrace for that at least?
[05:32] <RAOF> Oh, yes.
[05:33] <RAOF> The bit *above* there is fine.
[05:33] <RAOF> And when you build without optimisations it correctly abort()s, and generates a useful backtrace also.
[05:33] <pitti> I mean for the crash in the crash handler
[05:35] <RAOF> pitti: Not really. It *looks* like it's calling vsprintf with an out of bounds string format (in this case, it's 0x1c6f). However, the frame above that isn't useful. It's just ??, so there's a blank between <signal handler called> and VAuditF called with format string=0x1c6f.
[05:36] <RAOF> Hm. Which, suspiciously, is *also* the address of the va_args that gets passed in there.
[05:38] <RAOF> It's possible this is related to the attribute("noreturn") on one of these functions in the stack.
[05:42] <RAOF> ...
[05:45] <RAOF> No, I think the backtrace is totally ficticious. Nothing in the crash logging callstack actually *calls* VAuditF.
=== elky` is now known as elky
[07:01] <pitti> hm, a recent LP rollout seems to have disabled access to https://launchpad.net/builders when not logged in
[07:01]  * pitti goes to fix ddeb-retriever to work around that
[07:55] <jamespage> anyone know when doko might reappear?
[09:16] <Sweetshark> infinity: thanks for the hint, the fix will be though to reenable crappy old binfilter. It was removed on debian for quicker build times ....
[09:18] <cjwatson> infinity: The Build-Essential override is entirely automatic, generated from the expansion of the build-essential seed.
[09:34] <Sweetshark> s/removed/temp. removed/
[09:51] <cjwatson> Sweetshark: Have you had an opportunity to try +copy-packages since I switched on the async copy code?
[09:59] <Sweetshark> cjwatson: not yet
[10:01] <cjwatson> OK.  Let me know when you do - I'd like as much positive confirmation as possible so that I can move forward with removing the old code
=== cpg is now known as cpg|away
[10:40] <zyga> hrw, have you seen doko recently?
[10:41] <ogra_> zyga, vacation
[10:41] <zyga> ogra_, ah
[10:42] <zyga> ogra_, thanks, I'll check his schedule
[11:42] <bdrung> bdmurray: can you deploy the latest changes to lp:ubuntu-sponsoring?
=== MacSlow is now known as MacSlow|lunch
[12:23] <jamespage> infinity, when you are around can you give me a ping re glibc for quantal pls.
[12:42] <sgnb> how fprintf calls are turned into __fprintf_chk in Ubuntu? it doesn't seem to be #define...
=== _salem is now known as salem_
[12:47] <pitti> with -fstack-protector, which is enabled by default
[12:47] <cjwatson> sgnb: /usr/include/bits/stdio2.h
[12:47] <cjwatson> search for __fprintf_chk there
[12:47] <pitti> sgnb: sorry, not stack protector; presumably the -dFORTIFY.. bits
[12:47] <cjwatson> yeah, it's fortify
[12:47] <cjwatson> -U_FORTIFY_SOURCE if you have some strange reason to need to disable it
[12:50] <sgnb> I've a program that bugs because of that (and indeed, it behaves as expected with -U_FORTIFY_SOURCE)
[12:54] <sgnb> this fortify stuff doesn't happen in Debian... how to reproduce it there?
[12:59] <cjwatson> sgnb: -D_FORTIFY_SOURCE=2
[13:00] <cjwatson> sgnb: if your package were using the currently recommended dpkg-buildflags approach to get default build flags in Debian, it would happen there too :-)
[13:00] <cjwatson> sgnb: it's just that it's on by default in Ubuntu's compiler as well
[13:00] <cjwatson> <cjwatson@sarantium(sid) ~>$ dpkg-buildflags --get CPPFLAGS
[13:00] <cjwatson> -D_FORTIFY_SOURCE=2
[13:01] <sgnb> ok, found the issue (a missing volatile in inline assembly)
[13:01] <sgnb> thanks
=== MacSlow|lunch is now known as MacSlow
=== Guest49605 is now known as slank
=== slank is now known as Guest96367
=== cnd` is now known as cnd
[14:23] <hallyn> is there a 'debian/rules XYZ" command to go back from 'fakeroot debian/rules binary' to 'debian/rules build' (to avoid having to rebuild)?
[14:25] <hallyn> looks like rm -rf debian/*debhelper.log (and the debian/package dirs) worked
[14:28] <tumbleweed> hallyn: yeah, when I find myself in that situation, I hack out of it my hand
[14:28] <tumbleweed> echo -e 'dh_auto_build\ndh_auto_test' > debian/$binary.debhelper.log and lots of rm
[14:31] <ScottK> Won't make -f debian/rules clean do it?
[14:32] <geser> wouldn't that also remove the build files which should be preserved?
[14:32] <tumbleweed> ScottK: that does an upstream clean too
[14:33] <ScottK> Ah. Right.
[14:33] <ScottK> Missed that part of the request.
[14:33] <tumbleweed> if you're working on a package that takes 4 hours to build...
[14:33] <ScottK> Then I agree.
[14:33] <ScottK> Manual removal is the way.
=== dendrobates is now known as dendro-afk
[14:34] <geser> wouldn't calling "dh_prep" work too?
[14:35] <Laney> jodh: Hey ;-)
[14:36] <Laney> jodh: Do you know anything about the upstart activation patches we have in dbus? https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/dbus/quantal/files/head:/debian/patches/
[14:36] <tumbleweed> geser: IIRC dh needed its log files to tell it what to do next, but yes, that should do most of the work
[14:36] <Laney> like, are they still needed?
=== carif_ is now known as carif
[14:46] <carif> there used to be a package system-config-printer-tui that configured a printer without gnome or cups installed, does it still exist? I can't find it
[14:56] <pitti> I never heard of that (which doesn't mean it doesn't exist, of course)
=== Zic is now known as Guest51618
=== juarlex_ is now known as juarlex
=== dendro-afk is now known as dendrobates
[15:38] <bdmurray> pitti: why would a duplicate bug be in the apport signature database?
[15:40] <pitti> bdmurray: perhaps it was duplicated manually?
[15:41] <pitti> bdmurray: anyway, just running out, sorry; TTYL!
[15:41] <bdmurray> pitti: yes it was duplicated manually
=== yofel_ is now known as yofel
=== dendrobates is now known as dendro-afk
=== tkamppeter_ is now known as tkamppeter
=== deryck is now known as deryck[lunch]
=== dendro-afk is now known as dendrobates
[16:31] <ogra_> ivanka, haha, your tweet about the UX team hiring just made it into the installed slideshow :)
[16:31] <ogra_> *installer
[16:43] <ivanka> ogra_: haha! I am not sure that is a good thing though!
[16:52] <ogra_> ivanka, so it isnt the new "do a test install of ubuntu and get a job offer" programme ?
[16:53] <ivanka> ogra_: Sounds like one way to advertise :-)
=== juarlex_ is now known as juarlex
[17:23] <mterry> I'm experimenting with sbuild (rather than my native pbuilder), and it seems to not cache downloaded .deb files like pbuilder does.  Is that what --purge-deps controls?
[17:24] <micahg> mterry: apt-cacher-ng FTW :)
[17:24]  * mterry looks it up
[17:25] <mterry> ah
[17:25] <carif> mterry, will you recast pbuild-scripts with sbuild underneath?
[17:32] <wookey> Have UDS-N dates been set?
=== dendrobates is now known as dendro-afk
[17:51] <mterry> pitti, apport Build-Depends on python3-pykde4, which is keeping some kde bits in main.  Is it possible to drop that?  It looks like it runs tests at both build and via dep8?
[17:52] <infinity> wookey: UDS-N seems to be planning rather far in advance.
[17:52] <infinity> wookey: Or in the past, depending. ;)
[17:54] <highvoltage> Narwhals, narwhals, swimming in the ocean, causing a commotion, 'cause they are so awesome.
[17:57] <infinity> SpamapS: Say, watching the PHP build go by here, and there are a bunch of '-Wpointer-sign' warnings flying by.  That's almost certain to cause some sadness on ARM and PowerPC.
[17:57] <carif> mterry, pitti, et al, can debian binary packages have aliases? in other words several names for the same package?
[17:57] <infinity> SpamapS: Y'know, if you're in the mood for something to fix.
[17:57] <Myrtti> UDS-N?
[17:57] <wookey> erm R
[17:57] <wookey> the alphabet was never one of my strong suits
[17:57] <infinity> carif: Sort of, but no.
[17:57] <mterry> carif, yeah sorta.  Via virtual packages.  Like a binary package can Provide a different name
[17:58] <infinity> carif: You can have packages provide a package, but that can't be versioned.  Or you can have a metapackage that depends on the original, which can be versioned.
[17:58] <infinity> carif: For versioning reason, the latter is usually the choice used for transitioning from one name to another, but the former also has its place.
[17:58] <mterry> carif, for example, Both libtiff4-dev and libtiff5-dev exist, but one Provides libtiff-dev as an "alias" of sorts
[17:58] <wookey> I heard rumours that it was going to be in copenhagen next to Linaro Sprint, and as it'll be travel-arranging time any minute now It'd be useful to have that confirmed or denied
[17:59] <carif> mterry, infinity, ty;
[18:06] <infinity> wookey: I've heard similar rumours, but I don't know of any formal announcement of dates yet. :/
=== cpg|away is now known as cpg
[18:07] <infinity> wookey: It might work better for you to backchannel the request for clarification through Linaro, since they should have a better idea about what's going on that #ubuntu-devel. ;)
=== dendro-afk is now known as dendrobates
[18:14] <ahasenack> hi, are the build logs for packages that were uploaded to precise-proposed still available somewhere?
[18:14] <ahasenack> I'm looking into a missing .mo file (see https://bugs.launchpad.net/landscape-client/+bug/983096/comments/12)
[18:14] <ubottu> Launchpad bug 983096 in landscape-client (Ubuntu) "Mispelling of Landscape" [Low,Fix released]
[18:15] <stgraber> ahasenack: https://launchpad.net/ubuntu/+source/landscape-client then find the version number either on that page or in the publishing history, the build log should be there
[18:15] <SpamapS> infinity: re pointer-sign warnings in php, sure I'd be down for looking into them. Can you elaborate on what kind of sadness this causes?
[18:15] <ahasenack> stgraber: thanks, I'll take a look
[18:16] <infinity> SpamapS: Well, have you ever had a 1 turn into a 255 (or similar)?
[18:16] <infinity> SpamapS: Turns out that some things dislike that. ;)
[18:17] <infinity> SpamapS: (Basically, it's a byproduct of lazy programmers assuming char is the same on all arches, and using it interchangably with int for pointer arithmetic, which explodes on many non-x86 arches)
[18:18] <SpamapS> infinity: ok so its a "crazy wacked out stuff" problem
[18:19] <SpamapS> infinity: I'd be interested to see how much the test results differ on arm vs. x86, I bet there are a few problems already shown.
[18:19] <SpamapS> Maybe some day PHP will have 0 failing tests so we can fail the build on it. :-P
[18:19] <micahg> SpamapS: maybe the same can happen with mysql as well? :)
[18:20] <infinity> SpamapS: 0 failing tests in PHP was a goal of mine a decade ago.  And I almost got there.  I gave up when I realised that people commit code, with matching tests, that fails out of the box.
[18:20] <infinity> SpamapS: That was the last straw. :P
[18:20] <SpamapS> micahg: mysql does fail if the tests fail
[18:20] <infinity> SpamapS: No, MySQL fails if "too many" tests fail.
[18:20] <SpamapS> infinity: actually the PHP project has CI now
[18:20] <infinity> SpamapS: Which is hilarious.
[18:20] <infinity> SpamapS: Since it was no weighting for "important" versus "useless" tests, it just fails if N% break.
[18:20] <SpamapS> infinity: not sure they're gating yet, but they are filing bugs on new test failures
[18:20] <SpamapS> infinity: no, mysql fails if any tests fail
=== cpg is now known as cpg|away
[18:21] <infinity> SpamapS: That's... Very new.  As of when?
[18:21] <SpamapS> 5.1 had that
[18:21] <SpamapS> so "before my time"
[18:21] <infinity> If you're wrong, do I get beverages?
[18:21] <SpamapS> probably
[18:24] <infinity> Completed: Failed 5/1706 tests, 99.71% were successful.
[18:24] <infinity> ^-- Build goes on.
[18:24] <SpamapS> infinity: where's that?
[18:24] <infinity> The build fails when that dips below an "unacceptable" threshold.
[18:24] <infinity> Which is what happened when you had the SSL issues.
[18:24] <infinity> Other tests were failing too.  But the SSL stuff tipped the scales.
[18:24] <SpamapS> all the builds I see say All xxx tests were successful
[18:24] <infinity> That was an armhf build on quantal.
[18:25] <SpamapS> I am dumbfounded and feeling fairly betrayed ;)
[18:26] <SpamapS> ahhhh thats the warning rate
[18:27] <SpamapS> infinity: well I do stand corrected, but I believe those are tests which just produced some kind of warning, they didn't have mysqld crash or produce unexpected output
[18:27] <infinity> Failing test(s): sys_vars.rpl_semi_sync_master_enabled_basic sys_vars.rpl_semi_sync_slave_enabled_basic main.outfile_loaddata perfschema.func_file_io perfschema.func_mutex
[18:28] <infinity> I'd argue that failed is failed?
[18:35] <SpamapS> infinity: I think its just poorly worded, but I'll look into it.
[18:36] <SpamapS> --1
[18:36] <SpamapS> +255
[18:36] <SpamapS> nope you're right
[18:36] <SpamapS> infinity: ^^ perfect example. DOH
[18:36] <SpamapS> thats pretty serious actually
[18:37] <SpamapS> I wonder if I can set that threshold to 100%
[18:38] <SpamapS> bug 1028579 filed
[18:38] <ubottu> Launchpad bug 1028579 in mysql-5.5 (Ubuntu) "test suite run during package build should require 100% of tests to pass" [High,Triaged] https://launchpad.net/bugs/1028579
[18:39] <SpamapS> infinity: I'm sure we can find you something to drink at our next physical co-location.
[18:41]  * SpamapS notes that this time when he decided to assume he only made an ass out of 'me'
[18:41] <infinity> SpamapS: And that particular class of error (assuming it's char-signedness, which it looks like at a glance) would affect at least arm, powerpc, sparc, and s390.  While upstream may not care about all of those, I'd wager they care about s390, and possibly still sparc.
[18:42] <SpamapS> my $opt_max_test_fail= env_or_val(MTR_MAX_TEST_FAIL => 10);
[18:42] <infinity> (And they should be taught to care about ARM)
[18:42] <SpamapS> They've been super responsive to the couple of ARM porting bugs we've filed
[18:43] <SpamapS> threatening to remove them from Debian and Ubuntu has, if nothing else, gotten us in their heads a little. :)
[18:45] <infinity> SpamapS: Of course, the other possibility for a 1/255-looking thing is alignment, rather than char-signedness, which is a bit more painful to hunt, but still worth fixing.
[18:46] <infinity> SpamapS: Because fixing alignment issues not only makes unaligned arches not broken, it makes x86 faster, cause the machine doesn't have to waste cycles on alignment fixups.
[18:55] <carif> pitti, can jocky-gtk handle printer drivers also?
=== zyga is now known as zyga-afk
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest69114
=== Guest51618 is now known as Zic
[20:06] <jamespage> infinity, around for a glibc question? (sorry to hound you :-))
=== fenris_ is now known as Guest9382
[20:12] <infinity> jamespage: Sure, what's up?
[20:13] <jamespage> infinity, I'm working on enabling the test suite for google-perftools to support an MIR
[20:13] <jamespage> and I've hit a bug in glibc 2.15 which is causing a deadlock
[20:13] <infinity> jamespage: Is it fixed in 2.16?  (ie: do you know what the bug is, or just assuming it's glibc?)
[20:14] <jamespage> infinity, I patched 2.15 with the one line fix locally and re-tested and the deadlock disappears
[20:14] <jamespage> bug 1028038
[20:14] <ubottu> Launchpad bug 1028038 in eglibc (Ubuntu) "sscanf always calls realloc/causes deadlock in google-perftools" [High,New] https://launchpad.net/bugs/1028038
[20:15] <jamespage> and the upstream bug report - http://code.google.com/p/gperftools/issues/detail?id=423
[20:16] <jamespage> infinity, I really wanted to check to see if a) there where plans to upgrade to 2.16 for quantal
[20:17] <infinity> jamespage: I *might* be doing 2.16 for quantal, that's still in the air, while I work with Debian on that.
[20:17] <jamespage> infinity: or b) if not can we get this patch applied to 2.15 (and as this is fairly core I was a little nervous about just doing it :-))
[20:17] <infinity> jamespage: But is the impact of this such that we should be SRUing?
[20:18] <infinity> jamespage: It sounds like something SRU-worthy to me.
[20:18] <jamespage> infinity, this is the only impact I know of; it basically breaks the heap leak checker in gperftools
=== mbarnett` is now known as mbarnett
[20:18] <jamespage> infinity, I tend to agree.
[20:19] <infinity> jamespage: Can you turn your bug into something SRU-friendly (short test-case, etc)?
[20:19] <infinity> jamespage: I'll assign it to me and open a precise task, etc.
[20:19] <infinity> jamespage: And yeah, we can get the patch into quantal as well, that's no drama.
[20:20] <jamespage> infinity, sure - I can do that
[20:20] <stgraber> infinity: I guess you can bundle that one with bug 979003 then?
[20:20] <ubottu> Launchpad bug 979003 in eglibc (Ubuntu Precise) "libc incorrectly detects AVX support" [High,In progress] https://launchpad.net/bugs/979003
[20:21] <infinity> stgraber: Yeahp, and one other too.
[20:21] <infinity> https://bugs.launchpad.net/eglibc/+bug/1016349
[20:21] <ubottu> Launchpad bug 1016349 in eglibc (Ubuntu) "htons() returns wrong type on non-{i386,amd64} platforms" [Undecided,Confirmed]
[20:21] <infinity> Drat, I don't have a precise task for that one.
[20:22] <infinity> I had another one lying around here, too...
[20:22]  * infinity looks.
[20:22] <jamespage> infinity, thanks for picking this up - much appreciated!
[20:23] <seb128> does anyone here know how often is the SRU report updated?
=== Quintasan_ is now known as Quintasan
[20:25] <infinity> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1010069
[20:25] <ubottu> Launchpad bug 1010069 in eglibc (Ubuntu) "bits/fcntl.h does not define AT_EMPTY_PATH" [Medium,Triaged]
[20:25] <infinity> stgraber: ^-- That one's on my radar too.  I need to take a glibc day and tackle all of these.
[20:26] <infinity> seb128: Twice an hour.
[20:26] <seb128> infinity, "Generated: 07/24/12 16:48:31 UTC by sru-report"
[20:26] <seb128> infinity, it didn't get updated for over 3 hours
[20:26] <seb128> infinity, who has access to look at why?
[20:27] <stgraber> seb128: ubuntu-archive on lillypilly IIRC
[20:27] <infinity> ubuntu-archive.
[20:27] <infinity> I'll check.
[20:27] <seb128> thanks
[20:27] <stgraber> seb128: which according to getent includes you :)
[20:28] <seb128> stgraber, it does, I just don't know where to check ;-)
[20:28] <infinity> Hrm, nothing helpful from cron about it being broken.
[20:29] <infinity> It appears to be exiting non-zero.
[20:29] <infinity> Special.
[20:29] <infinity> ubuntu-archive-tools/sru-report > ~/public_html/pending-sru.html.new && mv ~/public_html/pending-sru.html.new ~/public_html/pending-sru.html
[20:29] <infinity> -rw-r--r-- 1 ubuntu-archive ubuntu_archive 126376 Jul 24 16:49 public_html/pending-sru.html
[20:29] <infinity> -rw-r--r-- 1 ubuntu-archive ubuntu_archive 120997 Jul 24 20:20 public_html/pending-sru.html.new
[20:29] <infinity> So, the "&& mv" isn't triggering.
[20:29] <infinity> I'll have to do a manual run and see what's up with that.
[20:29] <seb128> doing that atm
[20:30] <infinity> Or, you can.  Cool.  Go nuts.
[20:30] <infinity> I wash my hands of it. ;)
[20:30] <seb128> not sure that was a smart idea I had there
[20:30] <seb128> note: pretend you are dumb and can't help next time
[20:30] <jerm1080> Hello, I was wondering if there was anyone here who could help me with packaging and distributing a program through apt
[20:44] <seb128> hum
[20:44] <seb128>   File "./sru-report", line 230, in print_report
[20:44] <seb128>     bug = lp.bugs[b]
[20:44] <seb128>   File "/usr/lib/python2.7/dist-packages/lazr/restfulclient/resource.py", line 950, in __getitem__
[20:44] <seb128>     raise KeyError(key)
[20:44] <seb128> KeyError: '900119'
[20:44] <seb128> *
[20:44] <seb128> does anyone has access to that bug?
[20:45] <mdeslaur> seb128: not me
[20:45] <stgraber> nope
[20:46] <micahg> hrm, shouldn't the report exclude private bugs?
[20:46] <stgraber> micahg: or rather, shouldn't SRU always list public bugs? :)
[20:46] <micahg> yeah, that too
[20:46] <stgraber> what's the point of listing a bug in the changelog if people can't read it
[20:46] <seb128> ogasawara, ^
[20:46] <seb128> or somebody else from the kernel team (seems a kernel bug from google)
[20:50] <seb128> infinity, ^ in any case that's the issue with the SRU report
[20:53] <stgraber> seb128: I guess it'd make sense to fix the report not to crash in such case and instead "<strike>#bugnumber</strike>" or similar to make it visible
[20:53] <seb128> stgraber, right, if somebody feels like to do that
[20:59] <stgraber> seb128: I'm doing a test run of a patched sru-report to at least deal with the KeyError. The two other calls to lp.bugs were guarded by a try/except, but not that last one, so at least going for some consistency there :)
[20:59] <micahg> strike is deprecated in HTML 4.0 I believe :)
[21:00] <stgraber> I'll probably try to replace the debug logging by instead showing a list of error at the end of the report, that should be a lot more useful than having cron send the output by e-mail to some local account on lillypilly
[21:00] <stgraber> micahg: yeah, I guess it's font-decoration:strike or something similar in css nowadays
[21:00] <micahg> yeah
[21:01]  * micahg was a web developer in a former life
[21:01]  * stgraber too
[21:01] <stgraber> well, kind of still am I guess... (working on qatracker)
[21:01] <ajmitch> text-decoration: line-through iirc :)
[21:02] <stgraber> ajmitch: yep, that's the one
[21:09] <carif> mterry, i'm experimenting with sbuild too, any pointers you can share?
[21:17] <infinity> seb128: Thanks for the debugging.
[21:17] <infinity> stgraber: If you commit a fix for it, let me know and I'll pull it.
[21:21] <stgraber> infinity: yep, waiting on the result of a test run here.
[21:21] <stgraber> (that thing is horribly slow...)
[21:22] <infinity> stgraber: Yeah, it really is.  I've only hacked on it once or twice, but the turnaround for testing wasn't pleasant.
[21:23] <stgraber> infinity: ok, test run done and it passed. Just adding a bit of code to list all the broken bugs at the end of the report, so should have a branch ready for merging in ~30min (one more test run ...)
[21:24] <infinity> Why list them, when we can just strike them, as suggested?
[21:24] <infinity> We already have CSS for bug tags at the top of the file, it's just one more class. :P
=== cpg|away is now known as cpg
[21:27] <stgraber> it was initially tricky to do that as there are 3 different places where the parsing can fail, but now that I have a list of broken bug numbers, I might actually be able to do it, let me check
[21:39] <arges> infinity, hello. was looking through my list o' bugs... any updates on pad.lv/979003  ?  This is the eglibc FM4/AVX issue. And anything I can do to help with this? thanks
=== dendrobates is now known as dendro-afk
[21:46] <infinity> arges: I'm working on it today (and until it's done).
[21:47] <infinity> arges: Just got off a phone call where I mentioned that very thing (well, among other glibc SRU bugs, but that's the nastiest one).
[21:47] <arges> infinity, awesome. thanks!
=== salem_ is now known as _salem
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk