[01:30] <wigs> bug #831768
[01:30] <wigs> three months and still no comment from ~ubuntu-sru
[01:31] <wigs> no contact details for that team?
[01:36] <cjwatson> I've commented.
[01:37] <cjwatson> xnox: FWIW I don't generally think the workflow of "wait for SRU team to comment on the bug" is a good one; keeping up with bug mail on ~ubuntu-sru's subscriptions is a horrific firehose and it's better just to have one queue
[01:38] <RAOF> Likewise
[01:42] <wigs> cjwatson: yes, though not pertaining to the sru issue
[01:42] <wigs> it was mterry who decided that workflow, xnox was only attempting to facilitate it
[01:43] <cjwatson> Either way
[01:43] <cjwatson> And mterry's not here :)
[01:43] <xnox> cjwatson: RAOF: ok. I guess I should have pinged people about that bug. To me it's a risky yet useful feature cherry-pick, and I don't want to maintain / fix subsequent bugs in aptitude's multiarch support in precise.
[01:44] <wigs> feature?
[01:44] <wigs> its a bug fix
[01:44] <cjwatson> We could argue about feature vs. bug-fix all day; better to look at the impact
[01:44] <xnox> (I don't want, as in I don't think we should)
[01:45] <wigs> no regressions reported and at least several people are using the patch as supplied on precise
[01:46] <wigs> impact of bug: aptitude more-or-less unusable on precise
[01:46] <cjwatson> The precise patch there is definitely worth a try in -proposed; we can worry about future bugs in the future
[01:46] <cjwatson> And evaluate them based on their impact, not based on some kind of notion of precedent
[01:47] <xnox> ok.
[01:50] <wigs> cjwatson: will you make a similar comment on the report, and I can then take it back to -sponsors?
[01:50] <wigs> oh, n/m :-)
[01:51] <cjwatson> Yeah, as I say, I did that first
[01:55] <wigs> thanks now
[02:03] <cjwatson> tjaalton: commented on bug 1093974 for you
[03:01] <TheMuso> @pilot out
[05:32] <doko> Riddell, qtwebkit-source failed again, maybe add DEFINES+=ENABLE_ASSEMBLER=0 too?
[05:49] <pitti> Good morning
[05:49] <pitti> dobey: tomboy> I left ~ubuntu-sru some 8 months ago, so I can't accept it
[07:19] <doko> jbicha, will you finish the cogl transition?
[07:29] <dholbach> good morning
[07:42] <pitti> wookey: wow, congrats to that great arm64 milestone!
[07:49] <doko> didrocks, pitti (and seb128), I'm tired about https://launchpadlibrarian.net/132463304/buildlog_ubuntu-raring-amd64.network-manager-iodine_0.0.3-1ubuntu1_FAILEDTOBUILD.txt.gz
[07:49] <doko> please can we disable that warning?
[07:50] <didrocks> doko: we shouldn't use -Werror in the projects rather
[07:50] <didrocks> doko: and do the transition upstream
[07:50] <didrocks> or fix every projects, one by one
[07:50] <doko> didrocks, then please do
[07:51] <didrocks> doko: ? rather please report the failure and we'll task the team to fix those
[07:58] <pitti> yeah, -DG_DISABLE_DEPRECATED + -Werror is literally crying for "please break me"
[07:58] <pitti> that's just wrong
[08:34] <tjaalton> cjwatson: ah, thanks. I'll update it for quantal
[08:41] <tjaalton> cjwatson: also, you've merged gnutls26 last, mind if I merge 2.12.23-1 from experimental? the unstable version (.20-4) merges bunch of stuff from the new upstream, thought it would make sense to just merge from exp
[09:16] <tkamppeter> pitti, glatzor, hi
[10:04] <pitti> hello tkamppeter
[10:18] <tkamppeter> pitti, I have a problem with aptdaemons fake PackageKit which prevents unsigned PPD-only packages from being installed.
[10:19] <tkamppeter> pitti, see my Python interactive sessions on http://pastebin.ubuntu.com/5568436/
[10:21] <tuxinator> hi all
[10:23] <tuxinator> on 12.04 is there a convienent way of displaying current boot order of processes? i have a issue when i use multipathing+iscsi i get the message on boot that my partition on multipathd cannot be mounted, if i skip and the system boots i can however mount it, also if i want to reboot the system it does never proceed as it seems to wait for something (i think the same order issue perhaps not...
[10:23] <tuxinator> ...umounting)
[10:23] <pitti> tkamppeter: the last error seems quite clear (package already installed)
[10:24] <pitti> tkamppeter: for the others, do you have the matching GPG key installed in apt?
[10:24] <pitti> tkamppeter: can you try installing an Ubuntu package with the same API,?
[10:40] <darkxst> seb128, chrisccoulson, what would need to be done to land the forthcoming spidermonkey update in raring?
[10:41] <seb128> darkxst, what is it useful/needed for?
[10:41] <darkxst> at this stage mainly gnome-shell
[10:41] <darkxst> it fixes many memory leaks and GC deadlocks
[10:42] <darkxst> unfortunately most of the other rdepends (apart from probably cinnamon) will still require the old version
[10:42] <seb128> darkxst, good that we are not going for GNOME 3.8 this cycle I guess ;-)
[10:43] <darkxst> seb128, oh but I want to land this with gnome-shell 3.6 ;)
[10:43] <seb128> darkxst, anyway, let's way for chrisccoulson to reply, not sure if he has time for that atm
[10:43] <chrisccoulson> i don't ;)
[10:43] <seb128> darkxst, you would probably take over maintaining spidermonkey if you have interest in it...
[10:45] <darkxst> seb128, I guess that would be ok, I basically did all the upstream work to make this release happen
[10:45] <seb128> chrisccoulson, ^
[10:47] <darkxst> and ricotz has initial packages on his ppa btw
[10:48] <seb128> I'm not surprised, ricotz has all the broken crack of the day stuff in his ppa :p
[10:52] <darkxst> anyway RC will be out shortly (i.e. within the next day)
[10:59] <darkxst> seb128, maybe, but in this case (and I have been running it for several months) the new spidermonkey engine is solid and stable
[11:00] <darkxst> basically I would like to get spidermoneky update and gjs 1.36 landed before freeze if possible
[11:01] <seb128> darkxst, yeah, well I've to say I don't really know about the topic and it's not a priority at the moment for us
[11:01] <seb128> if you are wanting to do the work and that it's fully compatible and breaks nothing why not
[11:01] <seb128> there is no api/abi change right?
[11:02] <darkxst> huge api/abi change in spidermonkey (hence why we would need to keep the old version)
[11:03] <seb128> darkxst, so you suggest adding another version rather than upgrading the one we have?
[11:03] <darkxst> seb128, yes
[11:03] <seb128> darkxst, how much work would it take to port everything we have and drop the old one?
[11:03] <seb128> I don't think we want yet another version
[11:03] <seb128> we should either go for the new one and deal with the transition
[11:03] <seb128> or wait next cycle
[11:04] <darkxst> seb128, oh lots of work
[11:04] <darkxst> but the main killer is CouchDB, they are using illegal javascript in their user scripts
[11:04] <seb128> seems like a good topic for ubuntu-devel@ list
[11:05] <darkxst> seb128, the porting itself is relatively straightforward, but results in quite large diffs, so not something would want to carry as distro patches probably
[11:06] <darkxst> its all a catch22 I guess, no (other) upstream is going port to a spidermonkey that doesnt exist in distros
[11:07] <tkamppeter> pitti, all these packages install correctly with "sudo apt-get install ...", the unsigned ones need confirmation.
[11:08] <pitti> tkamppeter: I guess it needs confirmation because it cannot be authenticated?
[11:08] <tkamppeter> pitti, the epson package is signed and this I can install, the error occures only for unsigned PPDF-only packages.
[11:08] <pitti> tkamppeter: that's what's breaking it; please try installing an Ubuntu package, that should work
[11:09] <pitti> tkamppeter: ah, I see; I don't know whether aptdaemo allows you to install unsigned packages somehow, that's a question for glatzor (he's not online ATM)
[11:09] <tkamppeter> pitti, formerly I could install the unsigned packages with this method without problem, is there a way to get this working again?
[11:27] <darkxst> seb128, chrisccoulson, would it be so bad to have a second version of spidermonkey in universe?
[11:27] <darkxst> given the massive improvements to gnome-shell?
[11:29] <seb128> darkxst, better to ask ubuntu-devel@ to collect opinions on the topic, that source is security sensitive and the less copies we have the better
[11:29] <tkamppeter> pitti, all signed packaghes (which are currently not already installed) install perfectly with my Python commands, independent whether they are from Ubuntu (tried "foo2zjs") or from third party (here Epson).
[11:32] <darkxst> seb128, ok will do
[11:32] <seb128> thanks
[11:51] <doko> staring at the libgc ftbfs ...
[11:53] <tkamppeter> pitti, problem is actually that the Python calls do not install unsigned packages any more. Perhaps one needs some special parameters to tell that unsigned packages are OK.
[11:54] <pitti> tkamppeter: yes, that's what I meant "this is a question for glatzor"
[13:08] <tkamppeter> pitti, I have reported bug 1134320 now, thank you for your help.
[13:56] <tkamppeter> mdeslaur, I need some help to create a signature key for OpenPrinting.
[13:56] <mdeslaur> tkamppeter: hi!
[13:56] <mdeslaur> tkamppeter: aren't the binary packages on openprinting signed?
[13:57] <tkamppeter> mdeslaur, on OpenPrinting there are no signed packages at all, the binary packages for the Epson printers are on Epson's servers.
[13:59] <tkamppeter> mdeslaur, for development I have created a signature: gpg --recv-keys DCACEA71CDC01CD4995C34687A4B44C2D2A2203E
[13:59] <mdeslaur> tkamppeter: are the PPD packages in an apt repository, or are they just downloaded directly from the server?
[13:59] <tkamppeter> mdeslaur, I have created it some time ago.
[13:59] <tkamppeter> mdeslaur, they are in an apt repo.
[14:00] <mdeslaur> where is it located?
[14:00] <mdeslaur> (what's the url?)
[14:00] <tuxinator> multipath-tools and iscsi seem to stop before umount of my iscsi partition, is this a known bug of 12.04?
[14:00] <tuxinator> lets explain like that, when multipath runs and open-iscsi i can reboot my server and shutdown
[14:00] <tuxinator> if i do mount the partition additionaly to multipath daemon and open-iscsi daemons running i can't reboot and halt
[14:01] <tkamppeter> mdeslaur, https://www.openprinting.org/download/printdriver/keys/fingerprint-test
[14:01] <tkamppeter> mdeslaur, repo is http://www.openprinting.org/download/printdriver/debian/
[14:02] <tkamppeter> mdeslaur, in http://www.openprinting.org/download/printdriver/debian/dists/lsb3.2/ contains a Release.gpg
[14:04] <mdeslaur> tkamppeter: right, but it's older than the Release file, so presumably it hasn't been signed in a long time
[14:04] <mdeslaur> every time you regenerate the Release file, you need to create the Release.gpg that goes with it
[14:05] <cjwatson> tjaalton: gnutls26> go ahead
[14:06] <mdeslaur> tkamppeter: with something like "gpg -abs -o Release.gpg Release"
[14:06] <seb128> slangasek, hey, we were discussing systemd-helpers on #ubuntu-desktop, there are some issues
[14:06] <seb128> slangasek, desrt said he copied that to you
[14:06] <seb128> slangasek, just as a fyi, we are going to look at doing the needed change so it's not work for you, I just wanted to check you are not working on it already
[14:07] <desrt> slangasek: also give you a chance to tell me that my approach is insane :)
[14:08]  * desrt can never sense these things for himself before his first cup of coffee
[14:08] <matttbe> Hello Ubuntu devs!
[14:08] <matttbe> With a fresh install of Ubuntu 12.04.2 (64bits), if we try to install ia32-libs, it will replace a lot of mesa and x11 packages (which ends with '-lts-quantal' ; full list here: http://paste.ubuntu.com/5570521/) by a previous version (without: -lts-quantal).
[14:09] <matttbe> The big problem is that some drivers are no longer available, e.g. xserver-xorg-input-synaptics (yes... which means no touchpad on a netbook).
[14:09] <matttbe> According to the 'debian/control' file of ia32-libs, ia32-libs-multiarch depends of 'libglapi-mesa' and 'libglu1-mesa'.
[14:09] <matttbe> 'libglapi-mesa' is a virtual package provided by 'libglapi-mesa-lts-quantal' and 'libglu1-mesa' depends of 'libgl1-mesa-glx' or 'libgl1' which are also virtual packages provided by 'libgl1-mesa-glx-lts-quantal'.
[14:09] <matttbe> But why all '*-lts-quantal' are uninstalled?
[14:09] <matttbe> in fact, I don't know where can I report this bug
[14:10] <matttbe> is it due to  ia32-livs? mesa? x11 packages?
[14:10] <matttbe> *libs
[14:10] <doko> ScottK, any update on qscintilla2? anything to help with?
[14:10] <ScottK> Should have it done in the next day or two.
[14:18] <cjwatson> matttbe: Probably bug 1130419.
[14:21] <matttbe> cjwatson, yes it seems it's this bug!
[14:21] <matttbe> thank you, I didn't know that it was a bug in apt
[14:52] <dholbach> slangasek, would you be interested in uploading https://bugs.launchpad.net/ubuntu/+source/sqsh/+bug/1134233 to Debian? :)
[15:04] <tkamppeter> mdeslaur, I have found the problem, on the server the Release.gpg was not up to date. I have updated it and now I am able to use signed packages.
[15:04] <cjwatson> bdmurray: BPPH.changeOverride(new_phased_update_percentage=) will work as of the next LP deployment
[15:04] <mdeslaur> tkamppeter: great!
[15:08] <mdeslaur> tkamppeter: remember, you need to regenerate it every single time you update Releases
[15:08] <mdeslaur> s/Releases/Release/
[15:34] <slangasek> seb128, desrt: hey, so I guess my only concern with implementing org.freedesktop.systemd would be if other things besides timedated use it and it turns out down the line to cause bugs due to incompatible semantics or incompatible namespacing of service names
[15:48] <slangasek> dholbach: hmm, bug not reproducible in Debian unstable; checking to see what's going on here
[15:48] <dholbach> slangasek, gracias!
[15:52] <hallyn> stgraber: so the report on lxc-users about 12.04.1 kernel not decrementing inotify watch counts - does that explain the problem someone was reporting here last week?
[15:54] <stgraber> hallyn: definitely looks like the same thing, though IIRC in jibel/pitti's case it was on 12.10 (3.5 kernel, not 3.2)
[15:54] <hallyn> stgraber: who knows when it actually got fixed...
[15:54] <stgraber> hallyn: if it ever did
[15:55] <hallyn> stgraber: it did, bc my raring box is not affected
[15:55] <stgraber> hallyn: neither was my quantal box when I tried with the python script, so I'm wondering if it's not our testcase that's broken :)
[15:56] <hallyn> well that coudl be :)  or they were running a slightly older quantal kernel.  i never saw a kernel version from them
[15:56] <hallyn> but the guy on lxc-devel says a newer kernel did fix it for him
[16:05] <slangasek> doko: is bug #1134233 a deliberate behavior change in gcc / binutils?
[16:06] <stgraber> hallyn: doing a quick test run on 12.04
[16:08] <cjwatson> slangasek: Pretty sure that's http://wiki.debian.org/ToolChain/DSOLinking#Not_resolving_symbols_in_indirect_dependent_shared_libraries, isn't it?
[16:09] <slangasek> cjwatson: I would think so, but the package doesn't fail to build in sid, only in raring
[16:10] <doko> slangasek, yes, I think so. looks plausible
[16:11] <stgraber> hallyn: can't reproduce on 3.2.0-38
[16:12] <stgraber> hallyn: -37 and -38 contain some inotify/fsnotify fixes though
[16:12] <stgraber> jibel, pitti: can you confirm that your server is running the latest kernel from quantal?
[16:13] <jibel> stgraber, it's running 3.5.0-25-generic #38-Ubuntu
[16:13] <hallyn> stgraber: interesting
[16:15] <jibel> stgraber, wait, it was running 3.5.0.23.29 when the bug occurred
[16:16] <jibel> but I bumped max_user_instances to 4096 so it may take a while before it happens again
[16:20] <stgraber> jibel: .24 included a bunch of notify fixes, including changes in the way the locking is done and the release of the watches
[16:20] <stgraber> jibel: any chance you can restore the sysctls to their initial values and see if the bug occurs again?
[16:24] <pitti> stgraber: thanks for the heads-up! so if it stops overflowing now, the new kernel worked
[16:24] <pitti> stgraber: so we have something to watch out for
[16:26] <jibel> stgraber, sure but not right now
[16:26] <stgraber> jibel: sure, no hurry, would just be nice to confirm so we can tell anyone else reporting a similar issue to just update to the latest kernel and reboot
[16:28] <jibel> stgraber, do you think it's enough to restart the container after setting sysctl to its initial value?
[16:29] <stgraber> jibel: yep
[16:32] <jibel> stgraber, done. we'll see how it goes.
[16:36] <arges> Hello. I was wondering if a patch pilot can look at bug 982961 and see why the precise task was marked 'Fix Committed', but it was never committed to the bzr branch. Thanks
[16:39] <stgraber> jibel: cool, thanks
[16:56] <bdrung> tumbleweed: anything needs to be done before i upload ubuntu-dev-tools 0.146 to experimental?
[16:56] <tumbleweed> bdrung: looking
[16:59] <doko> afk, firefox buildd time anyway
[17:03] <arges> bryce: hi. I noticed you uploaded https://launchpad.net/ubuntu/+source/iptables/1.4.12-2ubuntu2.1 for me in quantal. I was wondering what happened to the same bug/patch for precise. thanks
[17:06] <|Anthony|> I've been watching Session Management & Multiseat blueprints
[17:06] <|Anthony|> https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-session-management
[17:06] <|Anthony|> and have noticed that it seems to be going in the direction of systemd
[17:07] <|Anthony|> is there anyone here that is familiar with this blueprint or topic?
[17:07] <slangasek> yes
[17:07] <|Anthony|> i'm concerned with the use of systemd for multiseat
[17:08] <Sarvatt> arges: bryce isn't around today but it's unapproved still - https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text= , as for why I don't know
[17:08] <|Anthony|> using systemd will exclude nvidia users to some extent
[17:08] <arges> Sarvatt: ok thanks. Yea i'm trying to figure it out too. : )
[17:08] <slangasek> |Anthony|: I don't follow why that would be the case
[17:09] <slangasek> |Anthony|: but in any event, we have no plans to invest in any other solution for multiseat
[17:09] <xnox> |Anthony|: also that blueprint talks about using only logind daemon from the systemd package.
[17:09] <xnox> not all of systemd.
[17:09] <|Anthony|> slangasek, the systemd multiseat solution is incompatible with nvidia binary
[17:10] <slangasek> we can either use systemd-logind to have a multiseat solution for some hardware, or we can not have any real multiseat solution at all (the current situation)
[17:10] <|Anthony|> there is a branch of console kit and gdm that is designed for multiseat
[17:10] <xnox> seems like it was fixed in fedora:
[17:10] <xnox> https://bugzilla.redhat.com/show_bug.cgi?id=878605
[17:11] <|Anthony|> oh?
[17:11]  * |Anthony| opens link
[17:11] <slangasek> well, we don't use gdm and consolekit is dead upstream
[17:12] <|Anthony|> it' been a little while since i updated https://help.ubuntu.com/community/MultiseatX
[17:13] <|Anthony|> thanks for the link xnox
[17:16] <|Anthony|> last i chatted with lenart poettering he said that the nvidia binary didn't expose something required for compatibility... i argued that it should be as simple as a proper udev rule. he assured me i was wrong. lol
[17:16] <|Anthony|> i suppose i gave up in frustration too easily
[17:17] <xnox> i'd be surprise if this was not going to be resolved, it's hard to ignore half of graphics cards in the world.
[17:17] <|Anthony|> right?
[17:17] <xnox> and not surprisingly neither can nvidia ignore a good chunk of the linux market.
[17:18] <|Anthony|> and the open source driver options for nvidia are still not ready (last i checked)
[17:19] <|Anthony|> well this is good news then :) should users expect a seat management UI?
[17:20] <slangasek> we don't have plans for creating one
[17:20] <|Anthony|> pulseaudio, another poettering creation, is quite a chore to configure in multiseat and entirely unstable between reboots.
[17:21] <|Anthony|> but that is largely due to consolekit not being seat aware
[17:21] <|Anthony|> acls and such
[17:29] <vibhav> Does one need a .pbuilderrc for using pbuilder-dist?
[17:30] <tumbleweed> no
[17:31] <vibhav> tumbleweed: A friend says  that pbuilder-dist whines that .pbuilderrc ain't there
[17:32] <vibhav> Probably  a warning
[17:32] <vibhav> tumbleweed: Am I missing something here ^?
[17:34] <tumbleweed> vibhav: yes, concrente information from the friend, such as command + output
[17:37] <vibhav> tumbleweed: never mind, he didn't describe the problem well. Fixed
[17:38] <vibhav> Turns out he was building something and thought it something he not done with pbuilder-dist create
[17:39] <vibhav> Thanks tumbleweed
[17:40] <tumbleweed> np
[18:20] <tumbleweed> Laney: any news on bug 1088423?
[18:27] <tumbleweed> bdrung: can't see any any reason not to
[19:02] <bdrung> tumbleweed: uploaded
[19:58] <zul> mterry:  ping we should be good for rtslib now
[19:59] <mterry> zul, ok, let me relook
[20:06] <mterry> zul, why the version fb27 suffix?  We're sure they won't release a 2.1.x?
[20:07] <zul> mterry:  its the upstream naming version
[20:07] <Laney> tumbleweed: nein
[20:07] <Laney> micahg: ScottK: ^^^
[20:07] <ScottK> ?
[20:07] <zul> mterry:  https://github.com/agrover/rtslib-fb/tags
[20:08] <tumbleweed> ScottK: bug 1088423
[20:08]  * ScottK looks
[20:08] <Laney> s/should/shouldn't/ in the description, evidently
[20:08] <mterry> zul, ah OK.  I hadn't seen those
[20:09] <Laney> I wonder if we can open backport uploading up to general sponsorship now that we're able to review that stuff in queue
[20:09] <ScottK> Laney: Commented.
[20:10] <Laney> ty
[20:10] <ScottK> Not sure if that would really improve things.
[20:10] <ScottK> You'd see a stack of uploads in queue instead of a stack of bugs waiting for upload.
[20:11] <ScottK> Additionally, most sponsors (probably) don't know what to look for.
[20:11] <Laney> I suppose you'd have to do the same checking anyway
[20:11] <Laney> I just know I'm crappy at actually processing the bugs
[20:32] <seb128> is there any buildd admin around?
[20:32] <seb128> can we kick the score of https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/4332170 slightly raised? ;-)
[20:37] <stgraber> seb128: done
[20:38] <seb128> stgraber, thanks!
[20:50] <smoser> psusi, is there some beter way to decide "is 'update' supported" than "is kernel > 3.8.0" ?
[20:52] <psusi> smoser: runtime, or compile time check?
[20:52] <smoser> runtime
[20:52] <psusi> not that I know of, why?
[20:52] <smoser> i'm looking at making growpart just do the right thing if it can
[20:52] <psusi> you can always try the ioctl and if it isn't supported, it just fails
[20:53] <psusi> good idea
[20:53] <psusi> I'd say don't worry about it then... issue the ioctl, if it works, great, if not... you're no worse off than you are now
[21:58] <micahg> Laney: ScottK: re sponsoring backports, AIUI the idea was that uploaders are responsible for backports moreso than regular archive uploads
[22:02] <micahg> I think part of the thinking was that a limited number of people could upload these, so some ownership was required, I guess I'd be fine with sponsored uploads (assuming backportpackage grows support for it), but I think there should still be the same sense of ownership in that failures require push back on the person being sponsored to fix (as should happen in regular archive uploads)
[22:03] <dupondje> damn build queue :(