[01:32] <smoser> slangasek, still around ?
[01:32] <smoser> i'm asking about e2fsprogs again.
[03:25] <slangasek> smoser: heya
[03:25] <smoser> hey.
[03:25] <smoser> i was about to go to bed.
[03:25] <smoser> whats up?
[03:26] <slangasek> smoser: you had a question :)
[03:26] <smoser> e2fsprogs
[03:26] <smoser> bug 978912
[03:26] <smoser> oops
[03:26] <smoser> bug 978012
[03:27] <smoser> theres a merge conflict in code that you added (i think) otherwise i'd have a mp for you... but basically i think we should take that.  the upstream seems to know a thing or two about ext[234]
[03:28] <infinity> Doesn't every changelog entry of Ted's urge people to upgrade as soon as possible?
[03:29] <smoser> well, generally, people do care about their data
[03:29] <infinity> Oh, I didn't scroll down and see his rationale. ;)
[03:29] <smoser> :)
[03:50] <slangasek> smoser: sure, he knows a few things about ext*, but that doesn't mean the new upstream versions are automatically low risk
[03:50] <slangasek> as for the mp, which code is conflicted?
[03:50] <smoser> i agree.
[03:51] <smoser> slangasek, yeah. i didn't go looking for udpates, but was looking for something unrelated and checked to see if it was in latest upstream and saw the update.
[03:52] <smoser> thats about all i know about e2fsprogs. so i opened bug and asked hopefully people who have more experience there.
[03:52] <smoser> conflict is http://paste.ubuntu.com/924295/
[03:53] <slangasek> that's odd, neither of those lines looks like mine :)
[03:53] <slangasek> I changed the Build-Depends, but those aren't reflected in that paste
[03:58] <infinity> That may be the first time I've seen a control file in m4.
[03:58] <infinity> I hope it's the last.
[03:58] <slangasek> what a sheltered life you've led
[03:58] <infinity> And I'm happy for it.
[03:58] <infinity> Don't tell me about none of them moving pictures neither.
[03:59] <slangasek> dear firefox, when I asked you to die in a fire, I did not mean to suggest you should use my cpu as fuel for your pyre.
[04:00] <infinity> killall -w firefox && firefox <-- Run every hour when you take a coffee break.
[04:20] <RAOF> cjwatson: Hey, is there anything special needed to upload grub-gfxpayload-lists?  Bug #971204 would be good to fix, and the lists should be safe to update at this stage, right?
[04:58] <FourDollars> Setting up whoopsie (0.1.27) ...
[04:58] <FourDollars> dpkg: error processing whoopsie (--configure): subprocess installed post-installation script returned error exit status 1
[04:59] <FourDollars> But whoopsie is not listed on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
[05:01] <slangasek> that's not the sort of problem tracked by that page
[05:07] <FourDollars> What is precise_probs.html used for?
[05:07] <slangasek> showing whether the dependencies of packages are satisfiable in the archive
[05:10] <FourDollars> I see. Thx.
[05:10] <slangasek> the failure you're seeing at install time is probably bug #978502
[05:12] <FourDollars> Yes, thx a lot. :)
[05:17]  * FourDollars is blocked by this bug now. :(
[05:20] <StevenK> FourDollars: You can edit the postinst directly to unblock yourself.
[05:20] <FourDollars> StevenK: Yes, that is a good idea. :D
[06:12] <pitti> Good morning
[06:28] <mvo> @pilot out
[06:46] <dholbach> good morning
[08:07] <cjwatson> RAOF: nothing special
[08:08] <RAOF> cjwatson: Good.  I'll get the reporter to check that I've got the pciid match right, and post the debdiff if you'd like.
[08:11] <cjwatson> RAOF: as far as I'm concerned, that package is handed over to graphics people who have a clue what's supposed to be in the lists
[08:12] <cjwatson> I split it off from grub2 partly so I wouldn't have to be a bottleneck on it - so please just go ahead :)
[08:12] <RAOF> Ok, cool.
[08:28] <cjwatson> ev: when you're around, bug 978502 needs urgent attention, since it caused more image build failures overnight
[08:28] <ev> on it now
[08:29] <cjwatson> thanks
[08:53] <doko> seb128, could you have a look at bug 949823? what needs to be done to register .jnlp files with javaws?
[08:57] <ev> cjwatson: uploaded as 0.1.28
[08:59] <cjwatson> ev: ta
[09:06] <jibel> doko, do you think bug 925218 could be SRUed to Oneiric ? It's causing problems in the lab when jenkins and kvm runs on the same server.
[09:06] <doko> jibel, sure
[09:21] <jibel> doko, thanks. I'll do the nomination than
[09:24] <seb128> doko, can you pastebin a "gvfs-info somefile.jnlp" where somefile.jnlp is a real file in that format?
[09:36] <doko> seb128, http://paste.ubuntu.com/924600/
[09:37] <seb128> doko, gvfs-mime --query "application/x-java-jnlp-file"
[09:37] <doko> $ gvfs-mime --query "application/x-java-jnlp-file"
[09:37] <doko> Default application for 'application/x-java-jnlp-file': firefox.desktop
[09:37] <doko> Registered applications:
[09:37] <doko> 	firefox.desktop
[09:37] <doko> 	icedtea-netx-javaws.desktop
[09:37] <doko> 	thunderbird.desktop
[09:37] <doko> 	chromium-browser.desktop
[09:37] <doko> 	gedit.desktop
[09:38] <doko> 	emacs23.desktop
[09:38] <doko> Recommended applications:
[09:38] <doko> 	icedtea-netx-javaws.desktop
[09:38] <seb128> doko, the recommended one is icedtea-netx-javaws.desktop weird that default is firefox
[09:39] <seb128> doko, grep "application/x-java-jnlp-file" ~/.local/share/applications/*
[09:40] <seb128> oh, tjaalton reported that bug :p
[09:40] <seb128> tjaalton, ^ same questions for you
[09:41] <doko> seb128, no output
[09:41] <seb128> I guess I will install icedtea-netx to have a look
[09:47] <tjaalton> seb128: http://paste.ubuntu.com/924606/ rest is the same as for doko
[09:47] <seb128> tjaalton, doko: can one of you add a jnlp to the bug?
[09:47] <seb128> or an url to download one?
[09:47] <tjaalton> I can do that
[09:48] <seb128> tjaalton, thanks
[09:49] <tjaalton> seb128: done
[09:50] <seb128> tjaalton, thanks
[10:26] <seb128> tjaalton, doko: I don't understand the bug, seems an issue on the xdgmime,glib,gvfs side, I'm trying to check with upstream
[10:27] <seb128> tjaalton, doko: not sure why it doesn't pick the recommended application to be default
[10:37] <jibel> mvo, there are many users reporting that synaptic lost its translation in Precise
[10:38] <seb128> jibel, wasn't that fixed yesterday?
[10:38] <seb128> synaptic (0.75.9) unstable; urgency=low
[10:38] <seb128>   * generate synaptic.pot during the package build to really enable
[10:38] <seb128>     langpack support
[10:39] <seb128> jibel, I guess it will need another langpack export to pick the translations back though
[10:40] <jibel> seb128, I don't know in bug 978738 the reporter says it occurred with the latest update (0.75.9)
[10:40] <seb128> jibel, right, you need a langpack export
[10:43] <Riddell> Daviey: when I get user support questions in #kubuntu that are server questions, where do I send them?
[10:43] <Daviey> Riddell: #ubuntu-server
[10:45] <Riddell> Daviey: that's user support and development?
[10:46] <Daviey> Riddell: yah.. shared space currently
[10:47] <Riddell> thanks
[10:50] <mvo> pitti: can you help me with https://bugs.launchpad.net/ubuntu/+source/synaptic/+bug/978738 ? is that just transitional until the next langpack update?
[10:51] <pitti> mvo: was that marked with X-Ubuntu-Langpack: ?
[10:52] <pitti> mvo: indeed; I followed up in the bug
[10:52] <pitti> mvo: YAFIYGI :)
[10:59] <mvo> pitti: thanks, when is the next export scheduled?
[10:59] <pitti> mvo: we got one yesterday (automatic update)
[10:59] <pitti> mvo: usually twice a week
[10:59] <mvo> ok
[10:59] <mvo> thanks!
[11:00] <pitti> mvo: we'll build the final packs on Apr 18
[11:54] <mdeslaur> @pilot in
[12:00]  * dholbach hugs mdeslaur
[12:03]  * mdeslaur hugs dholbach
[12:03] <dholbach> :)
[13:11] <herton> @pilot in
[13:24] <hallyn> slangasek: (haven't tested it yet but) thanks for fixing the vt7 handover bug :)
[13:36] <smoser> cjwatson, i am not looking for a real solution, but wondered if you might have thoguhts on how i could hack it.
[13:37] <smoser> during an install of server from mini-iso, we often get squid proxy errors . we know the root cause of those and are looking to fix them.
[13:38] <pitti> ev: thanks for the updated permanent sandbox branch! merged nwo
[13:38] <smoser> but one work around would be to get apt and wget to send the header " Cache-Control: max-age=0"
[13:38] <ev> pitti: yay, thanks!
[13:38] <smoser> in early command we could convince apt to do that, but at that point, debootstrap has already downloaded and got inconsistent data.
[13:38] <smoser> (and failed)
[13:39] <pitti> ev: I'll add support for that to crash-digger, too
[13:39] <ev> awesome
[13:39] <pitti> ev: I take it you don't use crash-digger in the whoopsie env?
[13:40] <smoser> i'm wondering if there would be a dirty way to hook into the installer early enough to affect debootstrap. (i'm realizing now that maybe debootstrap doesnt run in installer, but i thought it did.) or, if its not debootstrap,then whatever it is that does the initial apt metadata download.
[13:41] <cjwatson> debootstrap does run in the installer.
[13:41] <ev> pitti: nope, as what we need there is mostly Cassandra code: http://bazaar.launchpad.net/~ev/whoopsie-daisy/trunk/view/head:/backend/process_core.py
[13:41] <ev> well, that and AMQP
[13:41] <cjwatson> There aren't really any particularly relevant hooks.  I guess you could hack it with sed -i in a partman/early_command hook.
[13:41] <cjwatson> Sounds like we ought to add an option to debootstrap to do this, though.
[13:42] <cjwatson> The neatest hack might actually be, in partman/early_command, move wget to wget.real and replace wget with a script that runs wget.real with the right options.
[13:43] <smoser> cjwatson, that was my thought.
[13:43] <smoser> but i was not aware of partman/early_command.
[13:43] <smoser> and yes, instlaler option would be nice.
[13:43] <smoser> but i did not consider that an option at this point.
[13:43] <cjwatson> Hmm.  I don't think our busybox wget configuration supports adding extra headers right now.  You might have to 'anna-install wget-udeb'.
[13:44] <cjwatson> no, agreed
[13:44] <smoser> right.
[13:44] <smoser> still hackable.
[13:44] <smoser> thanks, cjwatson .
[13:44] <cjwatson> partman/early_command runs at the start of the partitioner; its main virtue for this is that it runs after all installer components have been retrieved, so you can run sed over stuff in the knowledge that it actually exists.
[13:44] <smoser> we're chasing the real for this particular issue in RT 52121.
[13:46] <smoser> cjwatson, wow. 'busybox wget' shows '--header' flag on precise
[13:47] <cjwatson> oh ok
[13:48] <cjwatson> smoser: the udeb configuration is different
[13:48] <cjwatson> $ grep WGET_LONG_OPTIONS debian/config/pkg/{deb,udeb}
[13:48] <cjwatson> debian/config/pkg/deb:CONFIG_FEATURE_WGET_LONG_OPTIONS=y
[13:48] <cjwatson> debian/config/pkg/udeb:# CONFIG_FEATURE_WGET_LONG_OPTIONS is not set
[13:48] <cjwatson> so 'busybox wget' in a real system isn't an accurate guide
[13:49] <smoser> booo!
[13:50] <smoser> but thanks. i just assumed it would =. thanks.
[14:18] <nemo> So, my mom uses Ubuntu One a lot
[14:19] <nemo> has relied on it for quite a while for note taking, and has built up an extensive number of notes. Hundreds?
[14:19] <nemo> Just wanted to say I'm a little disappointed w/ you guys for pulling a Google and just killing off a service that people had become dependent on.  You'd think you could at least just hide it for people who aren't using the notes sync :(
[14:19] <nemo> you know.  do it a bit more slowly
[14:20] <nemo> or. Maybe, and Google at least does this, give like a 6 month warning period so people can try to find an alternate service without something they rely on vanishing
[14:20] <nemo> and, yeah, I know that Ubuntu One tomboy sync still works, but without the ability to access notes from work, she's crippled.
[14:20] <nemo> So now I'm reading the API trying to figure out how hard it would be to reimplement a subset of the functionality you removed :(
[14:22] <dholbach> nemo, you could try to ask in #ubuntuone
[14:23] <nemo> ah. figured all the ubuntu devs worked as one hive mind :-p
[14:26] <apw> cjwatson, so the lts-backport-maverick kernel will be dropping off support with the EOL of maverick proper; this leaves people with that kernel in a bit of a hole.  we'd like to offer them the to either stay where they are, or upgrade to the natty or oneiric lts backports.  is there a clean way to do such things?
[14:27] <nuclearbob> can anybody help with with a complicated packaging question?
[14:28] <apw> nuclearbob, i am sure there is someone, but the right someone won't know they are unless you ask
[14:29] <nuclearbob> apw, I'd like to build two architecture independent binary packages from one source package, and embed one package inside the other
[14:29] <nuclearbob> I've got a client/server sort of thing, and I'd like to be able to easily install the client from the server
[14:30] <directhex> "embed one package inside the other" ?
[14:30] <apw> so you want to include the client.deb as a file inside the server.deb?
[14:30] <nuclearbob> yes
[14:30] <dholbach> could the server depend on the client package? :)
[14:31] <nuclearbob> yes, if necessary
[14:31] <apw> dholbach, i think he wants the package as a .deb and not installed
[14:31] <nuclearbob> ideally
[14:31] <nuclearbob> but if the best way to do it is a dependency, I can try that
[14:31] <dholbach> apw, I just mentioned it because that's quite straight-forward to do :)
[14:31] <roaksoax> jdstrand: ping
[14:31] <nuclearbob> right now the server Provides the client, since the server is a superset of the client functionality
[14:32] <jdstrand> roaksoax: ?
[14:32] <apw> dholbach, heh indeed indeed ...
[14:32] <slangasek> hallyn: you're welcome :)
[14:32] <roaksoax> jdstrand: i'm working on bug #975436 and I was wondering if you have a good example of how user/group should be created
[14:33] <roaksoax> jdstrand: i.e. following http://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html#s-bpp-lower-privs or, as I have seen in many packages, just creating it in postinst without too much code
[14:34] <jdstrand> roaksoax: otoh libvirt
[14:35] <roaksoax> jdstrand: cool, will look at it. Thanks
[14:36] <jdstrand> np
[14:36] <cjwatson> apw: I'm not sure, really; you could turn it into a dependency-only transitional package, but that doesn't really give people a choice
[14:36] <cjwatson> apw: perhaps a NEWS.Debian entry for those people who read such things via apt-listchanges
[14:42] <apw> cjwatson, could we add like a new 'ticky' like you get with exim 'stay with this final kernel/natty/oneiric'
[14:43] <cjwatson> apw: you're talking a lot of packaging complexity there
[14:43] <apw> cjwatson, yeah ... i thought you'd be saying that
[14:44] <cjwatson> I'm wary of that kind of thing when it's *only* going to be tested by a subset of LTS users
[14:44] <cjwatson> we don't get to try it out in precise first
[14:44] <apw> no indeed true
[14:48] <apw> cjwatson, tricky -security would like us to just upgrade them to the natty or later lts, we're rather wary of that as it s a big jump without some kind of warning
[14:48] <tjaalton> any ideas about a user having "iconv: error while loading shared libraries: libiconv.so.2: cannot open shared object file: No such file or directory" fail during package updates?
[14:50] <jdstrand> it is hard to predict what is riskier
[14:50] <jdstrand> there is risk associated with upgrading, but in my mind, they signed up for it when going with an 18 month lts kernel
[14:51] <jdstrand> and while most kernel CVEs of late may not be mind-blowing horrible, that doesn't mean that next week/month/year there won't be one
[14:51] <jdstrand> s/18 month lts kernel/18 month lts backport kernel/
[14:51] <jdstrand> in fact, it was my understanding that they would have an upgrade path. I may have just been assuming though...
[14:51] <jdstrand> apw: ^
[14:52] <jdstrand> and, they opted into it
[14:52] <jdstrand> if they opted into it, they can probably adjust grub and look at the changelog
[14:53] <apw> jdstrand, all true
[14:53] <jdstrand> and if it is on a server, a responsible admin should be looking at the changelog
[14:53] <jdstrand> before blindly upgrading
[14:53] <apw> i suspect its those ones where its actually on desktop installs which will wail.  but that also is not necessarily a problem
[14:53] <jdstrand> it is also not supported
[14:54] <jdstrand> (for lucid)
[14:54] <apw> indeed
[14:54] <jdstrand> so we get to test what happens here before infliciting... err.. applying these updates to precise users
[14:55] <jdstrand> (not supported for lucid desktop, just to be clear)
[14:57] <cjwatson> so in that case I guess make the maverick metapackages start depending on the natty ones?
[15:39] <rbasak> cyphermox: I have a fix for the amd64 ical ftbfs. How's arm coming along?
[15:40] <cyphermox> not really much further yet, but I'm testing something I'll be able to tell you in 53%.
[15:41] <rbasak> cyphermox: ok, I've attached a debdiff to bug 978862
[15:41] <cyphermox> rbasak: ok, thanks
[15:58] <mdeslaur> @pilot out
[16:06] <infinity> @pilot in
[16:08]  * dholbach hugs infinity :)
[16:18] <arges> infinity, hello. trying to get a package into lucid-backports, haven't seen any activity on it, and not sure what needs to be done.
[16:19] <infinity> arges: Bug number?
[16:19] <arges> infinity, ah sure. lp#968612
[16:21] <infinity> arges: Ahh, I'm not entirely sure what the process is for backports-with-changes, but I'll look this up after coffee and we'll make this work. ;)
[16:22] <arges> infinity, thanks!
[16:22] <infinity> (My guess is that the process is me just uploading to backports, but I generally never deal with backports, to educational fun for all)
[16:22] <ScottK> infinity: The process (loosely) is ubuntu-backporter approves, ubuntu-dev uploads, someone with powerz accepts.
[16:22] <micahg> arges: sorry, meant to look at that last night, do you need a backport package to do the runtime tests?
[16:23] <infinity> ScottK: Well, I'm two out of three of that pipeline, I guess I need the first. ;)
[16:23]  * ScottK looks over at micahg.
[16:23] <infinity> And micahg's the first.
[16:23] <infinity> Yes.
[16:24] <infinity> micahg: If you're on top of this, I'll go pilot other things after my coffee. ;)
[16:24] <micahg> infinity: yeah, it's not an easy backport though :)
[16:24] <infinity> micahg: It's not?  The diff looks trivial.
[16:25] <arges> micahg, yea, when I ran the backportpackage tool it had quite a bit of tests to run
[16:26] <arges> which i wasn't sure how to run those
[16:26] <infinity> micahg: Although, if there's a valid reason for the db4.8 versioned build-dep, it might be less scary to backport that too...
[16:30] <infinity> micahg: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588969 FWIW.
[16:30] <doko> zul, swift ftbfs
[16:31] <zul> doko: 1.4.8-0ubuntu1?
[16:31] <micahg> infinity: thanks :)
[16:33] <doko> zul: yes, https://launchpad.net/ubuntu/+source/swift/1.4.8-0ubuntu1/+build/3396611
[16:34] <infinity> doko: A new versionw as already uploaded.
[16:35] <infinity> zul: Although, really?  Just disabling the test suite? :/
[16:35] <infinity> zul: Also, what's "temporamental"?  Is the test suite travelling through time? ;)
[16:35]  * ogra_ wipes the coffee off the kbd
[16:37] <zul> infinity:  swift testsuite assumes that you have like /dev/log /dev/sda, not building in a chroot
[16:37] <infinity> Every test assumes that?
[16:38] <zul> a large chunk of them
[16:38] <infinity> Erm.
[16:38] <infinity> Ran 1027 tests in 20.421s
[16:38] <infinity> FAILED (failures=4, errors=48, skipped=191)
[16:38] <infinity> I'd say the larger chunk of them work just fine.
[16:39] <infinity> And disabling the 4 that throw the 48 errors wouldn't be hard?
[16:39] <infinity> Some old adage about babies and bathwater.
[16:39] <infinity> We like babies.
[16:40] <zul> infinity:  a large chunk has already been disabled/skipped because of issues with building it in the buildds
[16:40] <zul> er...running the tests in the buildds
[16:40] <infinity> Yes, that would be the 191.
[16:40] <infinity> With 1027 still remaining.
[16:40] <infinity> And only a few of those failing.
[16:40] <infinity> I'm not sure why you'd give up now and declare the suite not worth running.
[16:41] <zul> because i already spent alot of time getting it to run in 1.4.7
[16:41] <infinity> ...
[16:41] <infinity> "I made it work in the past, so never again"?
[16:42] <ogra_> tests are for whimps anyway
[16:42] <zul> ok im fine with you rejecting it then
[16:43] <infinity> I'm just saying.  Downalod a build log, grep for 'ERROR:', obtain list of broken tests, double-check in log that they're breaking due to doing Stupid Things, disable.
[16:43] <infinity> You could even skip the middle part, and it would still be better than disabling the whole suite.
[16:43] <infinity> (Though, please don't skip the middle part, one or more of the tests could be failing legitimately?)
[16:43] <infinity> (Which is kinda the point of running a test suite...)
[16:46] <zul> infinity: right but having it worked before in 1.4.7 and and spending x number of hours on my day off,  testing the build before getting a FFE uploading and having the testsuite fail on some random place in the buildds is a bit frustrating
[16:48] <infinity> zul: You could make it fail exactly the same place at home.  The buildds aren't special.
[16:48] <zul> infinity: but it didnt fail there
[16:48] <infinity> zul: If you're bindmounting /dev in your build chroots, don't.  Environment reproduced.
[16:48] <zul> infinity: k ill do that next time at least
[17:40] <doko> ev, do you understand https://launchpadlibrarian.net/101340308/buildlog_ubuntu-precise-armhf.whoopsie-daisy_0.1.28_FAILEDTOBUILD.txt.gz ?
[17:41] <ev> doko: nothing jumps out. I'll have a look tomorrow.
[17:43] <infinity> doko: Looks like something went goofy with the build.
[17:43] <infinity> doko: debian/changelog disappeared...
[17:43] <doko> infinity, did give it back. it's repeatable
[17:44] <infinity> Okay, debian/changelog was never created? :)
[17:44] <infinity> There's a new one in the queue.
[17:45] <slangasek> bdmurray: I wonder if we should have a bug pattern to treat all package install failures of flashplugin-installer (<< 11.2.202.228ubuntu2) and ttf-mscorefonts-installer (<< 3.4ubuntu3) as dupes of 876298
[17:47] <bdmurray> slangasek: I'll have a look into how many there are etc...
[17:48] <slangasek> bdmurray: at least 3 more came in after the upload to precise due to the new version pushed to all releases
[17:49] <slangasek> bdmurray: oh, though that does mean a version check is insufficient... since the upstream version number is bumped as well for previous releases
[17:49] <slangasek> so probably has to check the distrorelease
[17:51] <cody-somerville> lmao
[17:51] <cody-somerville> I find it funny that 'whoopsie' broke all PES's image builds last night, lol.
[17:53] <ev> cody-somerville: you're welcome
[17:53] <ev> :-P
[17:53] <adam_g> how does one go about getting the ubuntu recommender updated after a binary has moved to another package?
[17:55] <bdmurray> do you mean command not found?
[17:56] <adam_g> bdmurray: no, i mean an executable has been moved from one binary package to another in the same source package, but reco[Dmmender still reports the original as the suggested package to install
[17:57] <bdmurray> right command-not-found is the thing that recommends you install a package if you type a command in a terminal
[17:57] <adam_g> bdmurray: oh, i see
[17:59] <bdmurray> there is an update-from-web script in the package that I'm pretty sure updates the data
[18:07] <trijntje> Do different flavours of ubuntu use different installers? I was testing the localisation of different flavors, and not all flavors were equally translated
[18:32] <doko> slangasek, see who did approve the hardcoding of the path in opensc.conf? ;p
[18:32] <slangasek> doko: no, who?
[18:32] <doko> -- Steve Langasek <steve.langasek@ubuntu.com> Thu, 18 Feb 2010 02:52:33 -0800
[18:32] <slangasek> isn't that just me hard-coding a different path than the one that was there before? :)
[18:33] <doko> currently looking
[18:33] <doko> debian doesn't have a hardcoded path
[18:38] <doko> at least dlopen now finds the library. uploaded
[18:39] <ahasenack> hi, is someone from the sru team here? Could I interest you in reviewing #978884 ?
[19:15] <bdmurray> slangasek: so for precise you'd like the pattern to match a version less than
[19:15] <bdmurray> 11.2.202.228ubuntu2 - correct?
[19:43] <slangasek> bdmurray: for flashplugin-installer, yes
[19:44] <bdmurray> slangasek: right and apport uses re for the patterns
[19:45] <ahasenack> hi, is someone from the sru team here? Could I interest you in reviewing #978884 ?
[19:46] <slangasek> bdmurray: right; so in that case, we can probably omit precise entirely from the bug battern
[19:46] <slangasek> pattern
[19:47] <slangasek> since there shouldn't be too many more reports coming in against old versions
[19:47] <bdmurray> okay, works for me
[20:08] <seb128> infinity, can you kill https://launchpad.net/ubuntu/+source/gnome-keyring/3.2.2-2ubuntu3/+build/3393735 ?
[20:08] <seb128> it's hanging in the testsuit again :-(
[20:09] <bdmurray> seb128: what are the chances of bug 942539 getting fixed for precise?
[20:09] <seb128> bdmurray, correctly fixed in nautilus? 1%
[20:10] <bdmurray> seb128: okay, I was trying to determine if we should hack around it
[20:10] <seb128> you probably want to workaround it by changing the name adding a return char or something
[20:15] <infinity> seb128: Yeah, I think our brilliant plan was to try to find a unicode replacement for '.' that looked passably okay but didn't cause a line break. :P
[20:16] <seb128> infinity, what about the build I pinged you about just before? ;-)
[20:16] <infinity> seb128: Relayed to webops.
[20:16] <seb128> infinity, thanks
[20:17] <seb128> infinity, I though you could do that sort of stuff, dunno why
[20:17] <seb128> infinity, I'm disappointed
[20:17] <infinity> seb128: That was the old me, this is the new me.
[20:17] <seb128> infinity, your new you is boring
[20:17] <infinity> Ouch.
[20:18] <seb128> ;-)
[20:18] <infinity> I think the next eglibc upload might involve some special casing if euid=seb128 ...
[20:18] <seb128> hum, my turn to say "ouch"?
[20:19] <seb128> infinity, in some way you still have too much power :p
[20:19] <infinity> ;)
[20:27] <ScottK> doko: Would you please fix your strigi upload (it FTBFS)?
[20:28] <doko> ScottK, it did ftbfs before as well. so if you can tell me what's wrong, then yes
[20:29] <ScottK> So you uploaded it knowing it FTBFS?
[20:29] <ScottK> Sigh.
[20:33] <janimo> ScottK, not sure about strigi but I definitely uploaded more than once knowing it is a FTBFS, in case I had a patch that made the build progress to the next FTBFS spot and fixed the original one
[20:33] <ScottK> There are certainly cases where this is necessary.
[20:43] <herton> @pilot out
[20:50] <doko> ScottK, bullshit. I did see the build failure, tested the fix on armhf, and then did the merge
[21:14] <ScottK> It wasn't a hard fix.
[21:23] <jtaylor> doko: why do we have 2 argparse providers again?
[21:23] <jtaylor> that breaks my builds again ..
[21:31] <doko> jtaylor, which ones?
[21:32] <jtaylor> doko: python2.7 2.7.3-0ubuntu1 python 2.7.2-9ubuntu6
[23:28] <bdmurray> slangasek: so bug 942539 appears fixed but I see no clear indication why