[01:21] <Lirodon> Just wondering, is that "OEM mode" still there?
[01:26] <slangasek> Lirodon: yes
[02:41] <bryceh> jcastro, mind adding https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-xorg to the schedule?  Sorry, I should have registered it earlier but it slipped my mind.
[03:08] <slangasek> bryceh: linked to the sprint; that should let it get scheduled by the autoscheduler
[03:08] <slangasek> (if you "propose for sprint", it goes in the queue fwiw)
[04:05] <pitti> Good morning
[04:07] <ajmitch> morning pitti
[04:14] <pitti> mdke: replied to your langpack mail; TL;DR there is still time to do an ubuntu-docs upload
[04:33] <Laibsch> tumbleweed: you asked me if things about getting patches applied regress.  Well, I just stumbled across bug 697788 again.  And I think that no reaction after three months is pretty bad.  Almost as bad as during the worst times.  I had already forgotten about this one.
[04:33] <Laibsch> I don't think I'm the only one with this problem, am I?
[04:36] <broder> Laibsch: why isn't ubuntu-sponsors subbed to that bug?
[04:37] <ajmitch> broder: even if they were, would it show on a list, since the main bug task is fix released & the nominations aren't marked as accepted yet?
[04:37] <broder> oh ugh. yeah, you're right
[04:38] <Laibsch> broder: dunno.  to be honest, processes change about every 6 months, so I have a hard time keeping up. Let me ask the other way round, what's the purpose of ubuntu-sru?
[04:38] <Laibsch> I know everyone is doing their best, I'm not necessary complaining.  But things can be pretty frustrating.
[04:38] <broder> Laibsch: for at least the last year, it's the list of people who approve SRUs after they've been uploaded by a sponsor
[04:38] <Laibsch> s/necessary/necessarily/
[04:39] <ajmitch> one major problem I see is a LP timeout when trying to review nominations - no wonder it got missed
[04:39] <Laibsch> so, I subscribe the sponsors team and they in turn subscribe the sru team? I don't even need to worry about ubuntu-sru?
[04:39] <broder> Laibsch: that's right
[04:40] <Laibsch> OK
[04:40] <Laibsch> I'll try to remember that (until the next time it's changed) ;)
[04:40] <broder> Laibsch: that's also the process that's documented on !sru (and has been, since we made this change)
[04:40] <broder> ahem
[04:40] <broder> !sru
[04:41] <Laibsch> I can't reread wiki pages every time I want to get a patch accepted ;-)
[04:41] <Laibsch> seriously, this changed so frequently, it's hard to keep up unless you hang around in IRC every day
[04:41] <Laibsch> maybe I'm too old and too long with Ubuntu ;-)
[04:42] <ajmitch> possibly, this changed ~15 months ago from what I can see
[04:42] <broder> most of the time, we change processes because we're trying to make it easier, and for people who don't already know the old way, i think the new approach is a definite improvement
[04:42] <Laibsch> yes
[04:43] <Laibsch> and I agree that many processes were improced recently
[04:43] <Laibsch> most notably the sponsorship process
[04:43] <Laibsch> that's why I noticed that recently things were taking their time again, maybe just bad luck.
[04:43] <broder> i'm fairly confident there was mail to...a mailing list at the time we made the change, but i can't remember which one it would have been
[04:47] <Laibsch> broder: you are overestimating the time I can spend with reading mailing lists, wiki, etc.  One can spend half the day doing that and then I'm sure one is up to date on most of the processes ;-)  I simply can't.
[04:47] <broder> yeah, i was hoping i'd find an e-mail to ubuntu-devel-announce, but it looks like it was just discussed on ubuntu-devel
[04:48] <Laibsch> I wouldn't have read either </sheepish admittance>
[04:48] <broder> (https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/030999.html was the post, for reference)
[04:49] <Laibsch> thx
[04:51] <Laibsch> broder: that actually concerns only the second part of the process (the one that I don't deal with due to lack of privs)
[04:52] <broder> hmm...that's true. i think i was familiar enough with what jdong was proposing that i could read into the sponsorship process changes, but re-reading the e-mail, that's not obvious
[04:52] <Laibsch> it's not always clear to me what is and what isn't in the queue and at what position.  There was http://reports.qa.ubuntu.com/reports/sponsoring/ posted here, yet I'm not fully sure how to read that list.
[04:53] <broder> ah, sure. "queue" is referring to two different things
[04:53] <broder> there's the sponsorship queue - which is your link
[04:53] <broder> but for srus (and new packages and near-release freezes and such), LP puts the upload into a queue to be accepted by an archive admin
[04:53] <broder> (that's http://launchpad.net/ubuntu/precise/+queue or similar)
[04:54] <Laibsch> I guess what I'm saying that the process (and thus the content of the queue) are a bit opaque to people who don't do this stuff at least daily (I'm doing a fair bit)
[04:59] <Laibsch> I see. I don't think I'm concerned at all by the second queue you mentioned.
[05:00] <Laibsch> what priv is necessary to be able to approve series nominations?
[05:00] <micahg> Laibsch: upload rights or series driver
[05:01] <Laibsch> which one is more straightforward to get?
[05:01] <Laibsch> I'm an SRU type of guy, I fiddle too much with my computer already.  Can't have it break every 6 months on top of that ;-)
[05:01] <micahg> Laibsch: upload rights I think, you can ask for tasks here or in #ubuntu-motu as appropriate and someone can usually accept for you
[05:02] <Laibsch> would be nice to be able to do that on my own ;-)  I think I have pretty far-reaching privs in bug-control
[05:08] <ajmitch> micahg: so MOTU can approve nominations for universe packages?
[05:09] <micahg> ajmitch: indeed, and PPU for theirs as well
[05:25] <Laibsch> ah, the dreaded ubuntu-membership comes first
[05:26] <RAOF> Not necessarily.
[05:37] <Laibsch> Well, it seems that me working mostly behind the scenes has so far not helped me ever become anybody in terms of ubuntu-devel membership.  Becoming a DM OTOH was painless and a breeze.
[05:38] <Laibsch> ubuntu-devel as in "dev in ubuntu" not core-dev, but anything upload-related.  and as opposed to -bugs where I hardly ever run into something I cannot fix on my own.
[05:41] <pitti> @pilot in
[05:42] <RAOF> Laibsch: Have you applied for MOTU, or for upload rights to a packageset you work in?
[05:43] <Laibsch> I tried to apply for normal membership once and that was such a terrible experience that it put me off ever trying again.  It was a total insult (and I stayed up until 5 in the morning on top of it!)
[05:44] <Laibsch> Essentially, I was told the equivalent of "you are overqualified for simple membership, application rejected"
[05:44] <Laibsch> wtf
[05:44] <Laibsch> :-O
[05:45] <RAOF> The ubuntu-membership thing appears to be not well advertised.
[05:45] <Laibsch> maybe that's agood thing ;-)
[05:45] <RAOF> No, I mean that it's not something you (generally) apply for; it's something that is a bonus part of something more interesting.
[05:45] <Laibsch> may I ask that somebody accept the lucid task for bug 697788 to get the ball rolling?
[05:46] <RAOF> Or, at least, it's not something developers should ever need/want to apply for; it grants no development privilegdes.
[05:46] <RAOF> Hm, already been done?
[05:47] <Laibsch> ah nice, must have been done in the last 2 minutes or so
[05:48] <Laibsch> RAOF: even if there was no need for a dev to apply for membership only, it should not be rejected based on that ground. It pissed me off to NO end.
[05:49] <Laibsch> how am I to know whether I am already a dev or mere mortal member?
[05:49] <RAOF> Yeah, that seems a bit unnecessary.
[06:33] <mdke> pitti: thanks for the reply. The discussion in #ubuntu-translators appears to have been completely wrong...
[06:33] <mdke> pitti: I will try and do the upload today, and ping you to approve it (if you don't mind)
[06:33] <pitti> mdke: please
[06:33] <pitti> mdke: I have the langpack export, but I'll wait a bit for this to land
[06:34] <pitti> it's enough to have the package built
[06:46] <dholbach> good morning
[06:53] <pitti> hey dholbach
[06:53] <dholbach> hey pitti
[06:53] <mdke> no one happens to know off the top of their head what this build error means?
[06:53] <mdke> make[3]: execvp: /bin/bash: Argument list too long
[06:54] <mdke> I get it quite a lot and can work around it but if there is an easy fix...
[06:57] <geser> IIRC you get this when bash expansion of "*" (and similar) generates too many arguments (like "ls *" in a directory with many, many files)
[06:58] <mdke> yes, it is trying to install too many files
[07:01] <mdke> geser: so I take it from your answer that there is no easy work around?
[07:02] <geser> you'll need to split the calll into several somehow, either calling it first on "a*", then "b*", ... or with find and xargs
[07:02]  * mdke nods
[07:02] <mdke> that's comfortably beyond my skills :)
[07:02] <mdke> ok, thanks for the pointers
[07:03] <mdke> pitti: uploaded version 11.10.5
[07:05] <pitti> mdke: yay, thanks
[07:06] <mdke> pitti: I won't be able to test the -proposed built package until this evening after work, but the one I built worked fine. Anyway it should be enough to get the translations I guess. If there is anything please send me an email as I'll be out of irc contact
[07:06] <pitti> mdke: ok, will do
[07:06] <pitti> mdke: just waiting for the diff to appear on LP, then I'll review this
[07:07] <mdke> pitti: fine, I'll be around for about 30 mins. Please ignore the changes to the html/ directory, I have rebuilt the theme for the website and this isn't used in the package build process, but we keep it in the bzr branch
[07:08] <mdke> pitti: the diff will be huge anyhow because of all the new translations
[07:08] <mdke> when I added them to the bzr branch there was a diff of 120755 lines
[07:47] <pitti> mdke: accepted
[07:47] <TLE> pitti, mdke: Hey guys, sorry about the bumpy start :|
[07:48] <pitti> TLE: no harm done :) package is building now, once that's done I can prepare the langpacks
[07:48] <pitti> the LP export is ready
[07:49] <mdke> pitti: fantastic, thanks. TLE: no worries
[07:54] <TLE> pitti: so by all indications it looks like there will be new language packs ready by thursday I gather, in that case I will give the translators a heads up
[08:01] <pitti> ev: can you please do bug 606134? I can't push to the branch
[08:08] <ev> pitti: sure thing
[08:16] <jamespage> please could the NEW jenkins-htmlunit + osgi-* binary packages be accepted into precise - ta
[08:19] <micahg> dholbach: I thought we were waiting for libraries to mirgate to testing before ACKing syncs? (bug 881822)
[08:23] <dholbach> micahg, I'll bear that in mind for the next syncs I look at, but in this case I checked the upstream changelog and they consisted of almost only fixes and one of them was requested by the debian maintainer
[08:27] <ricotz> dholbach, micahg, hi, these are stable release updates for gnome 3.2 which eventually should get into oneiric-proposed too
[08:27] <micahg> dholbach: ok, but it's less about the package itself than its rdepends when it comes to libraries (AIUI)
[08:28] <micahg> ricotz: indeed, but oneiric-proposed also has a waiting period before migration :)
[08:29] <ricotz> micahg, right, but it seems better to have them in precise first :) to avoid diversions
[08:31] <dholbach> I understand the reasoning and agree that waiting in some cases might bring up problems in rdepends testing new code paths, etc - and as I said: I'll bear that in mind next time
[08:32] <micahg> ricotz: indeed, I appreciate you trying to do things properly, it wasn't so much about this case as in general
[08:32] <micahg> dholbach: thanks, I trust your judgment here :)
[08:33] <dholbach> still I checked the diff, no soname changes, there were memleak fixes in there, it came with a recommendation from the debian maintainer, so I felt sufficiently convinced that it was a good idea to sync - if we want to wait for things in testing no matter what, I must have misread the memo about it :)
[08:34] <ricotz> micahg, no problem, but isnt it reasonable to have libraries transitioned asap to avoid rebuilds of rdepends later
[08:35] <micahg> ricotz: yes, if there's a soname bump it makes sense to get it in early, but there's a tradeoff of making sure that the new version is adequately tested w/the rdepends, in this case there's no soname bump, so as dholbach said, it's less important
[08:36] <ricotz> micahg, alright, i will keep that in mind
[08:47] <micahg> ricotz: then again, syncing from Debian is usually better than a -0ubuntu1 upload as long as the changes are sane, so YMMV
[09:21] <pitti> Riddell: do you know which branch https://launchpad.net/ubuntu/+source/kubuntu-docs/+changelog was committed to?
[09:22] <pitti> Riddell: I checked lp:kubuntu-docs, ~ubuntu-core-doc/kubuntu-docs/natty (which is what Vcs-Bzr says), ~ubuntu-core-doc/kubuntu-docs/oneiric, ~ubuntu-core-doc/kubuntu-docs/precise, but they all stop at natty
[10:33] <Daviey> doko: Does a sync of libpam-krb5 from sid make sense?  Seems to include your multiarch changes, and other goodies.
[10:47] <doko> Daviey, sure
[10:49] <\sh> moins
[10:49] <\sh> micahg, you are sure that with latest dpkg -Werror=format-security was disabled?
[10:50] <cjwatson> sure or aware?
[10:50] <cjwatson> I'd talked to the security team previously, their main desire was to get it into dpkg-buildflags output, they weren't pushing for it to be in the environment by default
[10:50] <cjwatson> "disabled" is misleading
[10:51] <\sh> cjwatson, well...then I wonder why I get all those errors
[10:51] <\sh> xap_UnixDialogHelper.cpp:833:18: error: format not a string literal and no format arguments [-Werror=format-security]
[10:51] <\sh> cc1plus: some warnings being treated as errors
[10:51] <\sh> abiword as an example
[10:52] <\sh> using cdbs
[10:53] <cjwatson> \sh: cdbs fetches dpkg-buildflags output directly - that one would fail in unstable too
[10:53] <cjwatson> I'm only concerned about the ones that were failing just in Ubuntu
[10:54] <cjwatson> cdbs users have to fix their problems more quickly
[10:55] <\sh> cjwatson, looks like
[10:55] <cjwatson> fail in unstable> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643344
[10:57] <pitti> TLE, mdke: new langpacks look good, have the latest ubuntu-docs translations, and also the missing deja-dup/games/etc. mallard help
[10:57]  * pitti sends builder-wards
[10:57] <\sh> cjwatson, that's it...and 2.9.1 is fixing that upstream, but this is development release and {x,l}ubuntu don't want a development version (which I can understand)
[10:57] <\sh> bah..I'll get back to my patch for fixing those buggers.
[10:59] <cjwatson> they're trivial to fix
[10:59] <cjwatson> the main reason I disabled the export-to-environment part in dpkg for that flag was that it was causing silent configure test failures, and I was worried about misbuilds if we were doing that differently from Debian
[11:00] <cjwatson> well, silent configure test failure anyway; I only noticed one, which happened to result in a build failure later - but I was more worried about the ones I wasn't noticing
[11:00] <cjwatson> now, the same may be happening for cdbs packages, but at least we're in sync with Debian on that part
[11:07] <cjwatson> All distro buildds appear to be dead.  I've raised it on #launchpad-dev.
[11:07] <ogra_> tkamppeter_, ping
[11:08] <tkamppeter> ogra, hi
[11:08] <tkamppeter> ogra_, hi
[11:08] <ogra_> tkamppeter, hey, i'm trying to get my hp laserjet 1018 wortking on my arm netbook
[11:09] <ogra_> tkamppeter, in natty it just worked to run hp-plugin or hp-plugin-ubuntu ... seems in oneiric i get a gpg erros for the file it downloads
[11:10] <tkamppeter> ogra_, this printer needs a firmware file and due to the Linux Foundation desaster the Official download from HP is not back working yet.
[11:10] <ogra_> tkamppeter, is there any way i could copy what it downloads from the natty install ? 8where does the .run file unpack its content)
[11:10] <ogra_> i have a working driver on another machine, but i dont know which files to copy
[11:11] <tkamppeter> ogra_, you can use an alternative download, run "sudo getweb 1018" on the command line.
[11:11]  * ogra_ tries
[11:11] <TLE> pitti: awesome
[11:11] <pitti> cjwatson: really? they look ok from here
[11:11] <ogra_> tkamppeter, that prints sihp1018.img, anything i need to do additionally now ?
[11:12] <pitti> cjwatson: a minute ago all five i386 builders built different packages than now
[11:12] <tomreyn> hi. is there a process to request removal of a package because it is not sufficiently maintained?
[11:12] <pitti> cjwatson: oh, you mean they fail to build everything?
[11:12] <pitti> tomreyn: yes; please file a bug against it with a rationale, and subscribe ubutnu-archive
[11:13] <cjwatson> pitti: all the builds just flip back to needs-building after a couple of minutes, failing to leave a log
[11:13] <tkamppeter> ogra_, it should have dropped the firmware file in /lib/firmware/hp, check whether it landed there.
[11:13] <cjwatson> pitti: I've been watching it for a while now
[11:13] <\sh> tomreyn, which package? :)
[11:13] <pitti> cjwatson: ah, right
[11:13] <ogra_> tkamppeter, yes, it did
[11:15] <tomreyn> \sh: https://bugs.launchpad.net/ubuntu/+source/indicator-weather
[11:15] <tomreyn> pitti: thanks
[11:15] <tkamppeter> ogra_, if you unplug and replug your printer or turn it off and on again, the firmware should get loaded into the printer (letting the printer make its startup noise twice).
[11:15] <ogra_> tkamppeter, oh, i forgot to mention, its a network (ipp) printer
[11:16] <TLE> pitti: if they are all good to copy to proposed, let me know when they land there
[11:16] <pitti> TLE: just followed up to the mail
[11:16] <pitti> TLE: I'm uploading to -proposed
[11:16] <tkamppeter> ogra_, the alternative mechanism only works with the printer connected via USB.
[11:16] <pitti> we just need the buildds back, cf. what cjwatson said a few monents ago
[11:16] <pitti> TLE: ^
[11:16] <ogra_> tkamppeter, ah, thats bad
[11:17] <ogra_> tkamppeter, and there is no way to get the driver from the other machine through just copying it ?
[11:17] <tkamppeter> ogra_, the printer itself has only an USB connector, did you connect it to a router? Does HP's software support this configuration?
[11:17] <cjwatson> pitti: wgrant appears to be looking into it
[11:17] <TLE> pitti: ok
[11:17] <pitti> wgrant: thanks muchly
[11:17] <\sh> tomreyn, did you encounter d0od@freenode and ask him about the bugs?
[11:17] <wgrant> Only because nobody else is :)
[11:17] <cjwatson> well, yes ...
[11:17] <ogra_> tkamppeter, it works fine from all other machines, it is a small printserver running cups it is attached to
[11:18] <tkamppeter> ogra_, so than it probably has its firmware, supplied by the CUPS server to which it is connected. Your ARM box does not need to supply firmware to the printer then.
[11:18] <ogra_> tkamppeter, ipp://printsrv.local:631/ipp is what i use on the other machines, the machine i have the issue with is just a new install that does not have the binary bits
[11:19] <ogra_> oh
[11:19] <ogra_> i needed it in the past
[11:21] <tkamppeter> ogra_, the server should also provide the driver for the printer. You can print through a raw queue from the client. If the server's queue is intentionally set up raw, you need a free-software-only (as there is no closed-source plug-in from HP for ARM) driver. This driver is foo2zjs. You have to switch the driver of the queue from hpcups or hpijs to foo2zjs.
[11:21] <ogra_> ok, i will try
[11:21] <tomreyn> \sh: no, can you explain how s/he relates to this package?
[11:22] <tomreyn> \sh: i looked at their mailing list archive and found this, though: https://lists.launchpad.net/weather-indicator-team/msg00096.html
[11:23] <\sh> tomreyn, https://launchpad.net/indicator-weather <- this is the main project page of indicator-weather and d0od is the maintainer ... so eventually he's not aware of the bugs reported on the package in ubuntu
[11:23] <tomreyn> \sh: nickserv tells me d0od: Last seen  : Sep 27 08:49:28 2011 (4 weeks, 1 day, 02:33:00 ago)
[11:25] <tomreyn> I assume he will be one of the "developers [who] either have lost the will to continue contributing or have lack of time".
[11:27] <\sh> tomreyn, yeah looks like...
[11:27] <\sh> tomreyn, just file the removal of this package
[11:32] <tomreyn> \sh: I still can't spot the reference to d0od on https://launchpad.net/indicator-weather - can you help me? I see "Vadim Rutkovsky" listed as "driver", whose IRC nickname would be roignac.
[11:36] <\sh> tomreyn, when you click on the maintainer on the project page
[11:36] <\sh> d0od
[11:36] <\sh> Driver:
[11:36] <\sh> libohso-maintainers
[11:38] <\sh> tomreyn, see privmsg
[11:47] <ogra_> tkamppeter, i got it working now, thanks for the help !
[12:05] <ogra_> GRRR
[12:06] <ogra_> so i spent 2h to get my printer working on my netbook for printing my eticket ... just to find out that us-airways does the checking through a flash based page !
[12:06] <ogra_> *checkin
[12:06] <ogra_> grmbl, silly world
[12:08] <ogra_> (which is indeed not helpful on arm where no flash plugin exists)
[12:09] <OdyX> .oO(lightspark ?)
[12:09] <ogra_> OdyX, doesnt help at all there is no accel for it for arm
[12:10] <ogra_> it runs but with 0.5fps or less
[12:10] <OdyX> ogra_: compiled against libgles though
[12:11] <ogra_> yes, its still 100% SW rendering
[12:22] <cjwatson> LP builders are gradually coming back online now
[13:17] <ogra_> oh, sweet, dexconf is finally dead !
[13:19] <highvoltage> that must be from before my time, I don't even know what dexconf is.
[13:20] <hyperair> debconf X frontend?
[13:20] <highvoltage> ah
[13:21] <hyperair> at least, i think.
[13:22] <hyperair> http://manpages.ubuntu.com/manpages/hardy/man1/dexconf.1.html
[13:22] <hyperair> highvoltage: generate Xorg.conf, apparently.
[13:22] <ogra_> right
[13:22] <ogra_> it used to be the connecting bit between xorg and debconf
[13:22] <Laney> it's been removed a few months
[13:22] <ogra_> one of the worst hacks debian ever had
[13:22] <Laney> but yeah, yay
[13:22] <pitti> @pilot out
[13:23] <ogra_> Laney, i only saw tjaalton's bug right now, i used to follow xorg, but not anymore
[13:23] <Laney> at least in debian it was ~february ish
[13:24]  * dholbach hugs pitti
[13:24]  * pitti hugs back dholbach
[14:37] <Daviey> mterry: heya, would you be able to look at bug 875818, please?
[14:37] <Daviey> it's dep-waiting dnsmasq
[14:37] <mterry> Daviey, sure!
[14:39] <Daviey> mterry: thanks!
[15:01] <slangasek> RoAkSoAx: you have redhat-cluster's merge marked as 'please do not touch', and people have been complying and not touched it since 2009... :)  Is that something that should get merged this cycle?
[15:04] <RoAkSoAx> slangasek: yes, we have a newer version in Ubuntu  3.0.12-2ubuntu5 and merges.u.c shows 3.0.2-5
[15:05] <RoAkSoAx> slangasek: so it might be a bug from merges.u.c?? on the other hand, this cycle we are planning a new upstream release that contains huge changes in comparison to the old rhcs source, and we are wroking with the debian maintainer
[15:09] <slangasek> RoAkSoAx: oh, interesting
[15:09] <slangasek> cjwatson: ^^ for some reason merges.u.c doesn't know we have a new upstream version of redhat-cluster in precise?
[15:09] <cjwatson> RoAkSoAx: yes, can you file that on bugs.launchpad.net/merge-o-matic?
[15:10] <RoAkSoAx> slangasek: that;'s not only bveen in precise but since oneiric
[15:10] <RoAkSoAx> cjwatson: sure
[15:10] <cjwatson> since maverick
[16:06] <jdstrand> it would be ideal to get ruby1.8 demoted
[16:06] <jdstrand> wrong window
[16:36] <apw> ev, just doing and install and tried the > next to teh current operation which opened a text panel, very small and 100% empty for then and forward; i presume that is not expected
[16:43] <slangasek> apw: hey, do you know if aufs implements inotify on the backend?
[16:43] <apw> slangasek, unsure why ?
[16:43] <slangasek> apw: because upstart doesn't manage to automatically reread /etc/init from a LiveCD
[16:43] <apw> slangasek, lets say "probabally" is most likely the answer
[16:44] <apw> slangasek, ahh well we know that overlayfs is not doing inotify quite right
[16:44] <apw> slangasek, and that is what is in use on the livecds
[16:44] <slangasek> this causes install failures if you want to configure a package in the livefs that adds an upstart job
[16:44] <slangasek> apw: oh, we're using overlayfs now, not aufs?  alrighty
[16:44] <slangasek> is that inotifilessness tracked anywhere?
[16:44] <apw> slangasek, awsome, so glad that we test things before release
[16:45] <slangasek> it's not a common scenario
[16:45] <apw> slangasek, ahhh probabally not actually, i was going to file a bug at release sprint and then went ill
[16:45] <Daviey> mterry: bug 875818, should i just removed the versioned shlibs?  That version predates Lucid.
[16:45] <slangasek> why are you installing a server into memory on a liveCD
[16:45] <slangasek> etc
[16:46] <apw> slangasek, will get the bug filed and let you know the number
[16:46] <slangasek> apw: ok.  I have a couple of prospective dupes once available :)
[16:46] <apw> slangasek, deep joy :/
[16:47] <mterry> Daviey, that could work.  Ideally whichever path is more palatable to the Debian maintainer so we can sync in future.  I'd suggest a .symbols file, but just having plain -V is quicker if you want to get something in now
[16:50] <apw> slangasek, that reminds me, if the disk is not persistant you can use a commandline override to select aufs for a CD boot
[16:51]  * apw forgets the exact incantation but its something like UNIONMOUNT=aufs
[16:51] <apw> perhaps UNION=
[16:51] <cjwatson> union=aufs
[16:52] <slangasek> apw: filing that for future reference... I'm not sure the people hitting this bug are even meaning to do this
[16:52] <slangasek> the bug reports are mostly pretty vague
[16:53] <slangasek> I just happen to have one follow-up from someone who self-diagnosed correctly, and it matched what I had seen when doing ubiquity debugging
[16:53] <apw> bug #882147
[16:56] <stgraber> that one kept us busy for a while at the release sprint ;)
[16:56] <slangasek> oh, did it?
[16:58] <slangasek> bdmurray: so there are bugs in launchpad that should be duped to bug #882147
[16:59] <stgraber> slangasek: yeah, we noticed it when trying to debug ubiquity with a "tail -f /var/log/installer/debug" and didn't get anything :)
[16:59] <slangasek> bdmurray: any "start: Unknown job:" error message received while running on the livefs
[16:59] <bdmurray> slangasek: including persistent usb?
[16:59] <slangasek> bug #857406 is an example of this... unfortunately there's no dpkg log, but the error message is in the bug description, and CasperVersion is set
[16:59] <slangasek> bdmurray: yes
[17:00] <stgraber> slangasek: then noticed "watch -n1 tail /var/log/installer/debug" worked fine, inode numbers were identical too and eventually tracked it down to a overlayfs issue, then the kernel guys noticed it was the missing inotify support in overlayfs (or broken inotify support, can't remember the details)
[17:00] <stgraber> slangasek: anyway, wasn't considered critical back then, just very annoying for debugers :)
[17:00] <slangasek> bdmurray: is it practical to find the matching bugs?
[17:01] <broder> ...huh, tail -f uses inotify now? i thought you had to pull inotail out to get that
[17:02] <slangasek> stgraber: what broder said - kinda weird that tail needs inotify
[17:02] <slangasek> but yeah
[17:02] <bdmurray> slangasek: would they generally be package install failures? those get tagged but livemediabuilds don't so that would be a bit more challenging
[17:03] <slangasek> bdmurray: I don't really know i they're package install failures; the one I know about was apparently filed by hand
[17:03] <stgraber> stgraber@castiana:~/Desktop$ strace tail -f /var/log/syslog 2>&1 | grep -i notify
[17:03] <stgraber> inotify_init()                          = 4
[17:03] <cjwatson> tail -f inotify> changed in coreutils 7.5
[17:03] <stgraber> inotify_add_watch(4, "/var/log/syslog", IN_MODIFY|IN_ATTRIB|IN_DELETE_SELF|IN_MOVE_SELF) = 1
[17:03] <stgraber> broder, slangasek: ^ :)
[17:03] <cjwatson>   tail --follow now uses inotify when possible, to be more responsive
[17:03] <cjwatson>   to file changes and more efficient when monitoring many files.
[17:03] <bdmurray> slangasek: well I'll see what I can do
[17:04] <broder> fancy
[17:04] <slangasek> bdmurray: thanks
[17:04] <cjwatson> if inotify_init returns <= 0 it falls back to polling
[17:04] <cjwatson> I'm guessing that in this case support is present but brokene?
[17:04] <cjwatson> *broken
[17:04] <slangasek> cjwatson, stgraber: how future
[17:05] <apw> cjwatson, right present but not working as one might expect
[17:05] <slangasek> present because the kernel supports it, broken because the fs doesn't
[17:05] <stgraber> apw: do you remember if inotify_add_watch actually fails on overlayfs?
[17:05] <apw> stgraber, no i don't think so, the issue is that things get attached to the wrong versions i think
[17:06] <apw> stgraber, anyhow its on my list to investigate with upstream
[17:06] <cjwatson> slangasek: inotify_init only tells you if the kernel supports it; but it also calls inotify_add_watch and falls back to polling if *that* fails, and that should be able to tell whether the fs supports it
[17:06] <slangasek> cjwatson: ah, sure
[17:07] <stgraber> cjwatson: except that on this specific case, inotify_add_watch actually added a watch on the read-only branch instead of the copy-on-write one, so didn't fail, just wasn't doing anything useful :)
[17:07] <cjwatson> right, indeed
[17:07] <bdmurray> slangasek: so bug 8733358 seems like a likely duplicate - correct?
[17:07] <bdmurray> bug 873358
[17:25] <stokachu> vanhoof, yo s0n
[17:27] <slangasek> bdmurray: 873358> yep!
[17:28] <Sarvatt> stokachu: he's in st lucia for his honeymoon :)
[17:28] <stokachu> Sarvatt, ahh finally tied the knot
[17:31] <stokachu> is it normal for the builds in ppa to take anywhere from 1-2days to start?
[17:33] <slangasek> not "normal", but there was a dispatcher problem earlier today which I think explains the current backlog
[17:33] <stokachu> slangasek, ok thanks
[18:04] <bdmurray> slangasek: well, I only found a couple
[18:05] <slangasek> bdmurray: ah, alright
[18:05] <slangasek> duping them?
[18:05] <bdmurray> done
[18:05] <slangasek> is this representable as a bug pattern?
[18:06] <bdmurray> yes
[18:06] <slangasek> cool... will you take care of that as well?
[18:07] <slangasek> probably will only ever catch a small smattering of bugs... but they'll be among the more confusing for anyone to try to triage correctly :)
[18:10] <bdmurray> slangasek: what package would 'start: Unknown job' be translated in?
[18:11] <slangasek> translated?  I don't think we have any l10n for upstart messages
[18:11]  * slangasek checks
[18:11] <bdmurray> ah great
[18:12] <slangasek> well, there are upstart.mo files in the archive.. so I guess that bears checking...
[18:12] <Daviey> Can an AA promote libnetfilter-conntrack src and bin, based on bug 875818, please?  (-dbg package doesn't have anything holding it in main tho.)
[18:17] <barry> so, here's a packaging question i'm not sure how to handle.  i'm working on a new claws-mail-extra-plugins that re-enables gdata_plugin from upstream cvs.  the source branch itself has directories for each of the individual plugins (21 of them).  i `bzr rm` the old directory, `bzr add` the new cvs snapshot directory.  none of the d/* files really need to be changed.  the problem is getting a new orig.tar.gz with the new
[18:17] <barry> subdirectory. this will be a 2ubuntu2 package so the previous upload already got c-m-e-p_3.7.10.orig.tar.gz.  what's the right way to build the source package for this scenario?
[18:19] <Laibsch> Can somebody please confirm the lucid task for bug 881806 so it doesn't fall through the crack again?
[18:19] <slangasek> bdmurray: there are a few translations, it seems. http://paste.ubuntu.com/719918/
[18:19] <tumbleweed> Laibsch: approved
[18:19] <Laibsch> thanks
[18:20] <slangasek> Daviey: done
[18:21] <Daviey> slangasek: thanks!
[18:22] <slangasek> barry: why the 'bzr rm && bzr add'?
[18:22] <barry> slangasek: udd ;)
[18:22] <slangasek> barry: that sounds like a wrong turn to me, but maybe I don't understand what you're doing
[18:23] <barry> slangasek: but i'm not particularly wedded to using udd for this task, if `apt-get source` is a better route
[18:23] <slangasek> so you've bzr rm'ed the upstream directory, and bzr add'ed another one with the same name?
[18:23] <barry> slangasek: bzr rm gdata_plugin-0.2; bzr add gdata_plugin-20111026cvs
[18:23] <slangasek> to your root question, there are two ways to do this
[18:24] <slangasek> 1) use the -2ubuntu2 package version you already mentioned, and carry the cvs snapshot bits entirely in the .diff.gz
[18:25] <slangasek> 2) concoct a new upstream version number (following the rules embodied in dpkg --compare-versions, to avoid it interfering with future upstream releases), generate a "release" tarball for this version by whatever means you find appropriate, and import it with bzr merge-upstream
[18:25] <slangasek> and then use -0ubuntu2 as the revision number
[18:25] <slangasek> personally, given that it's CVS, I would go with option 1)
[18:25] <tumbleweed> as a variation on 1: it's a 3.0 (quilt) package, one can include the directory in debian and move them around in debian/rules
[18:26] <slangasek> tumbleweed: that's only a variation in that it's technically no longer a diff.gz :)
[18:26] <tumbleweed> slangasek: well, the question is, are the changes to that directory representable as a patch
[18:26] <barry> i think the one complication is that i can't have both directories when the build starts (the current rules don't support that, not that i couldn't change them)
[18:27] <barry> tumbleweed's suggestion sounds rather appealing actually :)
[18:27] <tumbleweed> yes, if you are going with 1, either you want to use the old version in the directory name rather than the new one, or you want modifications to rules
[18:27] <slangasek> oh, so the directory name changes and you can't have them both present? yuck
[18:27] <slangasek> barry: what happens if you just push the cvs snapshot into the directory named gdata_plugin-0.2?
[18:27] <barry> slangasek: right
[18:28] <barry> slangasek: hmm, that might work too actually.  it'd be a little white lie, but i can make that clear in d/changelog or in a readme
[18:28] <barry> and i think those changes *would* be representable as a diff
[18:29] <tumbleweed> think of it as bugfixes to 0.2 :)
[18:29] <barry> tumbleweed: yeah :)
[18:29] <barry> tumbleweed, slangasek thanks.  i'll try that and see how it goes
[18:29] <slangasek> barry: cool
[19:27] <GTRsdk> Where is the Ubuntu Unity Dash icon stored on the hard drive?
[19:44] <Ursinha> GTRsdk, maybe you can find that out by dpkg -L package
[19:48] <GTRsdk> It appears that the icon is not in the package
[19:48] <GTRsdk> I am guessing it is the distributor logo (Ubuntu logo) that is what is being used
[20:00] <stokachu> is /etc/default the equivalent to /etc/sysconfing on fedora/rhel?
[22:04] <slangasek> SpamapS: are you continuing to chase bug #859075?