[05:17] <ari-tczew> please some main sponsors review bug, whether it can by synced or merged, thanks
[05:17] <ari-tczew> bug 604802
[05:42] <mantiena-baltix> morning all
[05:42] <mantiena-baltix> Ubuntu 10.04.1 images from http://cdimage.ubuntu.com/lucid/daily-live/current/ contains packages from lucid-proposed repository, is this ok?
[05:43] <mantiena-baltix> AFAIK it's a bug, but I don't know where I should report this bug :(
[07:58] <Riddell> maxwellian: yes debuild -nc will still recompile whatever needs to be recompiled, it just doesn't run make clean
[08:13] <twb> slangasek: ping
[08:14] <Damascene> hi,
[08:14] <twb> slangasek: in /usr/share/pam-config/foo on lucid, I can say "Session-Final:\nfoo", but not "Session-Final: foo".  That's a little annoying/unexpected.
[08:15] <Damascene> asac, Bug #603022
[08:15] <Damascene> would you like to talk about the bug?
[09:28] <asac> Damascene: no thats fine from what i understand
[09:35] <pitti> Good morning
[09:35] <asac> hi pitti
[09:38] <\sh> hoi pitti, asac
[09:39] <pitti> hey \sh
[09:39] <pitti> hello asac
[09:40] <asac> moin \sh ;)
[10:02] <bdrung> crimsun_: can you unsubscribe ubuntu-sponsors when you sponsor a bug? bug #581786 seems to be sponsored.
[10:05] <bdrung> crimsun_: i can't see your upload to -proposed. so it's up to you to unsubscribe ubuntu-sponsors.
[10:07] <smoser> Keybuk, could you look at upstart script branch in bug 43574 (not urgent at all)
[10:08] <smoser> and also, sometime this week i'd like to get your thoughts on bug 606373
[10:11] <LucidFox> seb128, does Murrine even have an upstream bugtracker?
[10:11] <LucidFox> I couldn't find one
[10:11] <seb128> LucidFox, gnome.org
[10:11] <seb128> bugzilla.gnome.org
[10:12] <LucidFox> Ah, found it
[10:20] <LucidFox> seb128> Forwarded, https://bugzilla.gnome.org/show_bug.cgi?id=624805
[10:21] <seb128> LucidFox, thanks
[10:28] <agutierr> Hello: Someone knows how to disable Halt/Reboot entries from indicator-applet-session in gnome? (editing gconf keys doesnt works)
[10:29] <twb> agutierr: if you work it out, let me know.
[10:29] <twb> agutierr: same goes for disabling "user switching"
[10:30] <agutierr> arggg twb
[10:30] <agutierr> I need this!!! :-(((
[10:30] <twb> I "fixed" user switching by replacing gdm with xdm, which conveniently also sidestepped some gdm information disclosure fuckups (at least in the default theme).  The button still shows up, but clicking it does nothing.
[10:31] <agutierr> twb, there is some shorcut for make it work?
[10:31] <agutierr> user switch i dont care
[10:31] <agutierr> but halt and reboot... :-s
[10:31] <twb> You might want to try looking for dbus .service files and diverting/deleting them.  I haven't investigated that approach yet; it's just a hunch.
[10:31] <LucidFox> seb128, should I CC you to that upstream bug?
[10:32] <seb128> LucidFox, no, that's ok, just add the url to the launchpad bug
[10:32] <twb> One of the other engineers here said that not being able to lock it via gconf mandatory settings was a bug introduced in 8.10 and still not fixed :-/
[10:32] <agutierr> twb, removing permissions to /sbin/halt and reboot may be an option
[10:32] <twb> agutierr: I bet polkit will fuck you there, since it'll setuid
[10:32] <twb> *it'll *effectively* setuid
[10:33] <agutierr> I know
[10:33] <LucidFox> I wonder why this issue only occurs with those drivers, though
[10:33] <agutierr> Argggg Bugubuntu
[10:33] <LucidFox> and not, say, Nouveau 3D
[10:33] <LucidFox> Does Maverick's version of Cairo use the cairo-gl backend?
[10:36] <agutierr> twb, I think it takes less than recompiling the gdm & indicator-applet-session...
[10:36] <twb> agutierr: I wasn't suggesting recompiling anything
[10:37] <twb> IMO once you're rolling PPAs, you've lost
[10:37] <agutierr> twb, yep, but now for me it the fastest option
[10:37] <agutierr> recompiling and cp the binary
[10:39] <twb> I wish GUIs would just die in a fire
[10:39] <agutierr> ^_^
[10:40] <LucidFox> seb128> Any ideas why this bug is only reproducible with the NVIDIA drivers? Could this be related to the cairo-gl backend?
[10:41] <ricotz> chrisccoulson, hi, i am currently uploading a thunderbird 3.1.1build2 package to my ppa (it is not nobinonly), but maybe it is worth a look, it will be in ricotz/staging in a few minutes
[10:41] <LucidFox> assuming it's even enabled in maverick...
[10:41] <chrisccoulson> ricotz, carrying the ubuntu patches?
[10:41] <LucidFox> ricotz, I've always wondered, what's nobinonly?
[10:41] <chrisccoulson> LucidFox, it has the binary only files removed?
[10:41] <ricotz> chrisccoulson, yes
[10:41] <LucidFox> ah, makes sense
[10:42] <chrisccoulson> ricotz, have you switched off the official branding?
[10:42] <ricotz> chrisccoulson, i just used the orig.tar.bz2 and the packaging from maverick
[10:43] <ricotz> chrisccoulson, using debsrc 3
[10:43] <chrisccoulson> hmmm, we don't have 3.1.1 in maverick yet do we? unless i missed something ;)
[10:44] <chrisccoulson> in any case, you probably need to build with the unofficial branding
[10:45] <ricotz> chrisccoulson, no there is no 3.1.1 package yet, ok so my package does fit the ubuntu branding then
[10:46] <chrisccoulson> ricotz, micahg is going to be packaging tb3.1 quite soon, and we're going to be shipping it in lucid too
[10:47] <ricotz> chrisccoulson, ok, i know i talked to him earlier
[10:48] <chrisccoulson> you say you downloaded the tarball, or did you create it with the packaging?
[10:49] <ricotz> chrisccoulson, i used the official mozilla tarball + ubuntu packaging, without nesting it in the tar.gz
[10:49] <chrisccoulson> ah, we create our own tarballs (by running debian/rules get-orig-source DEBIAN_TAG=THUNDERBIRD_3_1_1_BUILD2)
[10:50] <ricotz> chrisccoulson, i think with moving to debsrc3 it isnt needed
[10:51] <chrisccoulson> but you probably need to build it with the unofficial branding if you are uploading it to a PPA with the ubuntu patches (trademark restrictions)
[10:52] <chrisccoulson> ricotz, we can't transition to debsrc3 yet (the packaging still has to support hardy)
[10:52] <ricotz> chrisccoulson, hmm, ok
[10:52] <chrisccoulson> we can only do that once hardy and jaunty have both gone EOL
[10:53] <chrisccoulson> which is why we've not done it already ;)
[10:53] <ogra> Keybuk, i have a hung screen in front of me saying: "udevd[85] failed to create queue file: No space left on devce"
[10:53] <ricotz> chrisccoulson, alright
[10:53] <ogra> Keybuk, any idea how that could happen ?
[10:53] <chrisccoulson> but we will still probably use a debian/rules target to roll our own tarballs anyway (so we have a single process for creating snapshots and milestoned releases)
[10:54] <ogra> Keybuk, oh, i'll take that back, it wasnt hung hard, just very slow (it just moved on)
[11:00] <bilalakhtar> Someone, please sponsor bugfix #550955
[11:00] <bilalakhtar> I mean, bug #550955
[11:20] <maxwellian> Riddell: Thanks for the info!
[11:29] <ogra> doko, does http://paste.ubuntu.com/466402/ look ok ?
[11:43] <skillet> hi all
[11:43] <skillet> is there a reason why ubuntu is on openssl 0.9.8k?
[11:44] <skillet> 1.0 is out
[11:44] <skillet> i see, probably due to freeze
[11:44] <skillet> ok
[11:44] <twb> skillet: lucid is stable, so it basically only gets security patches
[11:45] <skillet> yes i am aware of this
[11:45] <skillet> i just saw the release date of 1.0
[11:45] <skillet> anyway
[11:45] <twb> Unless you mean maverick is frozen -- I don't pay much attention to non-LTS releases
[11:46] <skillet> im trying to work out why all the ec ciphers arent showing in the list, when they are in the .so
[11:46] <cjwatson> we mostly follow Debian for openssl; http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578376
[11:47] <skillet> pff
[11:47] <skillet> you trust those guys to handle openssl? :P
[11:47] <cjwatson> yes
[11:47] <cjwatson> (note that many people here are Debian developers; insulting Debian is not generally a way to win friends and influence people)
[11:48] <skillet> sorry i am a security guy
[11:49] <skillet> i was referring to the great debian ssl fail of '08
[11:49] <cjwatson> lessons have been learned from the debacle a couple of years ago, and it's in the past
[11:49] <cjwatson> I am deeply, deeply familiar with that
[11:49] <skillet> ok then
[11:49] <cjwatson> I was part of the response team in Ubuntu
[11:49] <cjwatson> that doesn't mean we have to hold it against the Debian openssl package forevermore amen
[11:49] <skillet> here's the problem
[11:50] <twb> A large contributing factor to that fuckup was upstream 1) doing something weird/dumb without an explanatory comment; and 2) failing to respond to queries about (1) on their own mailing list
[11:50] <twb> It's not like the Debian maintainer just decided one day to deliberately destroy the entropy.
[11:50] <cjwatson> I don't think it's necessary to go over it in depth again - it's been analysed in considerable detail
[11:50] <twb> Sorry, you're right.
[11:50] <skillet> $ strings /usr/lib/libssl.so.0.9.8 |grep ECDHE-RSA-AES256-SHA
[11:50] <skillet> ECDHE-RSA-AES256-SHA
[11:51] <doko> ogra: well, this fix will make openjdk-6 fail to build (which is good). I really do not want openjdk-6 built on armel in maverick before the arm assembler interpreter is enabled again, because the interpreter will run 4-5 times slower and wasn't tested for a year
[11:51] <skillet> $ openssl ciphers |grep ECDHE-RSA-AES256-SHA
[11:51] <skillet> $
[11:52] <skillet> none of the ec* ciphers are enabled
[11:52]  * cjwatson prods a security team member across the table
[11:52] <mdeslaur> skillet: let me take a look, one sec
[11:52] <skillet> (on debian as well)
[11:52] <ogra> doko, so i should upload it and wait until you uploaded the toolchain to give it back then ?
[11:52] <ogra> doko, as i understood you yesterday thats the change we need
[11:53] <doko> ogra: no, please don't upload openjdk until the arm assembler interpreter is re-enabled
[11:53] <ogra> doko, k, does that hapen in the linaro toolchain ?
[11:54] <ogra> *happen
[11:54] <ogra> i.e. in a forseeable time
[11:54] <doko> ogra: it has to happen in openjdk. rob is working on this
[11:54] <ogra> ok
[11:54] <ogra> i'll leave it to him completely then
[12:03] <mdeslaur> skillet: try openssl ciphers -v ECDHE-RSA-AES256-SHA
[12:03] <mdeslaur> skillet: it would appear "openssl ciphers" doesn't show it, even though it's supported
[12:04] <skillet> mdeslaur: ahh ok, thanks
[12:04] <skillet> i still cant use it though
[12:04] <skillet> hmm ill do a test
[12:05] <mdeslaur> skillet: feel free to open a bug if it doesn't actually work, and subscribe me to it.
[12:08] <skillet> 21718:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1006:
[12:09] <mdeslaur> skillet: ok, please file a bug with a test case in it, and I'll take a look
[12:09] <mdeslaur> skillet: thanks
[12:09] <skillet> mdeslaur: okay
[12:09] <skillet> ill do some more tests first
[12:09] <skillet> dont want to raise a false positive
[12:09] <mdeslaur> skillet: sure, np
[12:10] <slangasek> twb: heh, I don't think we'll change that; the syntax of those fields is that they declare /blocks/ of lines to insert in the config file, it would be confusing to /read/ to have these on the same line as the field name
[12:10] <mdeslaur> skillet: don't forget to subscribe me to the bug, or ping me when it's open. Lunch now, bbl.
[12:11] <twb> slangasek: I was expecting it to behave in an 822-y manner
[12:11] <twb> (It was also confusing that I didn't need to indent the "body" of a field with whitespace)
[12:12] <twb> For the typical case where I'm only ever adding a single line to each file, I don't find it confusing to have that line after the Foo:, but I don't care enough to argue about it
[12:24] <\sh> hmm...when was the last day to upload new packages to universe for maverick?
[12:25] <tumbleweed> \sh: there is no such day, it just gets harder. However before feature freeze you should have little difficulty
[12:25] <\sh> tumbleweed: I thought so....good
[12:27] <MattJ> http://packages.ubuntu.com/maverick/ is broken for me at least :/
[12:34] <geser> MattJ: known problem, it's being worked on
[12:34] <twb> slangasek: another bug for you: it doen't ignore backup~ files in pam-configs/
[12:35] <twb> (Generally with .d/'s I try to follow run-parts(8) approach of only looking at a whitelist of sane file names, rather than trying to keep a blacklist of the most popular backup file formats.)
[12:35] <MattJ> geser: Thanks, good to know
[13:27] <ricotz> chrisccoulson, i remade the tb3.1.1 package using get-orig-source
[13:29] <ricotz> chrisccoulson, will take quite some time to upload, i am back later
[13:54] <Riddell> siretart: libx264-98 is in binary new, do you know who asked for that sync and are they going to do the transition for the rdepends?
[13:58] <pitti> cjwatson: do you have a minute to review my gparted SRU?
[14:13] <LucidFox> http://paste.ubuntu.com/466462/ <-- any ideas?
[14:15] <coolbhavi> hello I ve a doubt (as asked in #ubuntu-motu), I m maintaining mobile-broadband-provider-info in debian and ubuntu .. How to request SRU in case of an exception? https://wiki.ubuntu.com/StableReleaseUpdates#mobile-broadband-provider-info
[14:16] <Riddell> coolbhavi: an exception?  you mean a crash?
[14:16] <smoser> cjwatson, what module do i need to provide to grub-mkimage to get 'if' support
[14:17] <Riddell> coolbhavi: oh I see, it has exceptional SRU allowances
[14:17] <Riddell> coolbhavi: make a new package, file a bug and find someone to upload it
[14:17] <Riddell> coolbhavi: and subscribe the bug to ~ubuntu-sru
[14:18] <coolbhavi> Riddell, yep The Readme file says "...The Package contains only informational files so it's safe for distributions to grab updates even during feature freeze and maintenance stages."
[14:18] <coolbhavi> The update could also solve some of these bugs through regular check: https://bugs.launchpad.net/ubuntu/+source/mobile-broadband-provider-info
[14:19] <coolbhavi> Riddell, so just adding a exception tag in the bug report is enough?
[14:20] <smoser> cjwatson, never mind.
[14:21] <smoser> (sh)
[14:22] <DktrKranz> LucidFox: it's probably because of --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg, while trying to create a Debian chroot
[14:23] <LucidFox> Well yes, but I had no such problem when using it on my work machine, which runs lucid
[14:24] <LucidFox> I wonder if something broke in maverick
[14:25] <kees> cjwatson: are we doing a techboard meeting?
[14:26] <geser> kees: isn't the TB meeting next week? today is a DMB meeting
[14:31] <kees> geser: I think my calendar is lying to me
[14:32] <kees> geser: yup, you're totally right.
[14:32] <kees> cjwatson: ignore me please :)
[14:36] <siretart> Riddell: that is no sync, I prepared that package myself
[14:38] <siretart> Riddell: and yes, that is a library transition like many others. rdepends need to be checked and fixed
[14:41] <seb128> cjwatson, pitti: the ubuntuone-client 8 bugs are verification-done
[14:41] <seb128> cjwatson, pitti: I think it would be worth getting for .1, it has been uploaded almost a month ago, the first upload failed to build though and they didn't use -v for the second one
[14:41] <seb128> which is why the sru page lists none of the bugs
[14:42] <pitti> seb128: aah, that explains it, thanks
[14:46] <pitti> doing
[14:46] <seb128> pitti, thanks
[14:48] <pitti> hm, now I have to manually close them all
[14:53] <seb128> pitti, get dobey to do it ;-)
[14:53] <Riddell> siretart: shouldn't it have a -XubuntuY version number if it's not a sync?
[14:55] <Riddell> siretart: accepted out of New
[14:56]  * Riddell does the empty new queue dance
[14:57] <JontheEchidna> \o/
[14:58] <siretart> Riddell: err, do we really require that? udev is a prominent example that does not as well
[15:00] <Riddell> siretart: no we don't, it just seems sensible if it's likely to be synced from debian ever (but since you'd be incharge of that most likely, you could coordinate it easily enough)
[15:02] <siretart> Riddell: the package does not exist in debian
[15:03] <siretart> but yes, in case it gets accepted somewhen in the future, I'll of course make sure that it can be easily synced
[15:09] <cjwatson> pitti: looking
[15:11] <cjwatson> pitti: Riddell asked for a test case in the bug
[15:11] <cjwatson> pitti: do we need to handle both udisks and hal-lock being there?
[15:11] <maxb> As the armel build queue is currently empty, may I please have a give-back of https://edge.launchpad.net/ubuntu/+source/subversion/1.6.12dfsg-1ubuntu1/+build/1853956 to establish whether it is a transient or systematic failure?
[15:22] <cjwatson> maxb: given-back
[15:22] <maxb> thanks
[15:33] <pitti> cjwatson: yes, in case hal is running
[15:33] <pitti> cjwatson: test case> can do, it's trivial; I'm in a meeting now, will do after that
[15:34] <tgall_foo> anyone around that somewhat groks live-helper configs ?
[15:48] <cjwatson> pitti: the current fix only calls udisks, and doesn't have the udisks && hal-lock case to match devkit-disks && hal-lock below
[16:03] <pitti> cjwatson: so, hal isn't actually an issue on our live systems or Ubuntu, but I guess we'd need it if you run gparted on kubuntu
[16:03] <pitti> cjwatson: then again, kubuntu doesn't have udisks
[16:04] <pitti> but we could just add this, too, and then send it upstream again
[16:05] <cjwatson> pitti: up to you, I can disregard it if you really don't think it matters
[16:06] <pitti> cjwatson: I won't have time today to fix it harder; I think it's "good enough" for our purposes, but not 100% correct
[16:08] <Riddell> pitti: if you're into SRUs bug 578215 could do with being copied over to -updates
[16:09] <pitti> Riddell: it's not marked verified
[16:09] <pitti> Riddell: if it is, please do so and run sru-release lucid <pkgname>
[16:10] <pitti> (fancy way of doing copy-package)
[16:11] <Riddell> pitti: it has the verification-done tag, how else should it be marked?
[16:12] <pitti> Riddell: oh, I looked at virtuoso-opensource
[16:12] <pitti> Riddell: ah, that had a broken changelog, and thus didn't appear on http://people.canonical.com/~ubuntu-archive/pending-sru.html
[16:13] <pitti> Riddell: if you release it, you need to close the bug manually
[16:17] <Riddell> pitti: where is sru-release ?
[16:17] <pitti> Riddell: script on cocoplum
[16:17] <Riddell> oh right, was looking in ubuntu-archive-tools
[16:22] <NCommander> pitti: ping, can you refix the mobile trendlines again :-)?
[16:23] <nigelb> cjwatson: would it make sense if I brought the issue of sending mail at the end of the meeting?
[16:24] <cjwatson> sure
[16:24] <nigelb> okay :)
[16:30] <pitti> NCommander: which? to what?
[16:30] <pitti> NCommander: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile-maverick-alpha-3.html looks quite fine to me
[16:30] <NCommander> pitti: mobile burndown charts trendline
[16:30] <pitti> NCommander: http://people.canonical.com/~pitti/workitems/maverick/canonical-mobile.html looks broken, I'll fix that
[16:31] <ogra> pitti, A3 is completely off
[16:31] <NCommander> pitti: er, that doesn't look right to me. We had an issue with a spec not being properly targetted even thought work was happening on it from the beginning
[16:31] <pitti> NCommander: ah, so it was mis-planning, rather than additional work coming in mid-cycle?
[16:31] <ogra> should be at 22
[16:31] <NCommander> pitti: mis-clicking :-)
[16:32] <pitti> done
[16:32]  * ogra hugs pitti 
[16:50] <Riddell> Laney: you're not core-dev but you self confirmed a sync for main?  bug 607641
[16:50] <cjwatson> f-spot's in the cli-mono package set
[16:51] <cjwatson> ./edit_acl.py -p laney query; ./edit_acl.py -P cli-mono -S maverick query
[16:52] <Riddell> ah hah, thanks cjwatson
[17:13] <maxb> Hmm. Is there anywhere I can ask "Is armel known to be broken right now?" ?
[17:14] <maxb> In respect of messages like "sh: gcc: not found" and kdelibs5-dev being uninstallable,
[17:14] <maxb> Oh, armel builders on Manual. /me assume Something Is Happening
[17:18] <geser> maxb: "sh: gcc: not found" appears in every log, you can ignore that one
[17:22] <Riddell> maxb: qt hasn't built on arm in a while so KDE bits are unlikely to work
[20:23] <johanbr> is there anyone around who feels particular responsibility for texlive?
[20:24] <johanbr> the current maverick version of texlive-publishers has some serious issues, it'd be nice to get it updated some time before release
[20:28] <tantiv> Is there a reason partimage is only available on x86?  I checked the partimage server and all amd64 bugs were closed for the version currently built for i386.  I successfully built it from deb-src and it seems to work perfectly.
[20:41] <bryceh> jcastro, you about?