[00:51] <slangasek> robert_ancell: right and thanks :)
[00:55] <infinity> robert_ancell: (And accepted, BTW)
[03:48] <pitti> Good morning
[03:48] <ion> hi
[03:48] <pitti> infinity: lpia> that's what I did, thanks
[03:49] <pitti> dpb___: postgresql> no, not known to me; I saw you mailed me, will answer via email
[03:49] <pitti> zyga: udisks> yay you!
[04:26] <pitti> hm, quantal is still frozen?
[04:27] <micahg> pitti: yep, until release, so saith the release manager :)
[04:27] <pitti> but we did release
[04:27] <micahg> until final release
[04:28] <micahg> pitti: https://lists.ubuntu.com/archives/ubuntu-release/2012-September/001981.html
[04:28] <pitti> uh?
[04:28] <pitti> *shrug* okaya
[04:29] <micahg> a little backscroll in -release about it as well
[04:29] <pitti> micahg: ah, it's the third-next email in my "to read" list; thanks for pointing out!
[04:30] <micahg> sure, I miss working at this hour :)
[05:57] <dpb___> pitti: thx for the follow up.   I'll file a bug tomorrow.
[06:34] <joeljacobson> pitti: your 9.1.6 packages works great in my 12.04 LTS production environment
[07:01] <dholbach> good morning
[07:04] <pitti> joeljacobson: thanks for the additional testing!
[07:14] <didrocks> speaking of which…
[07:14] <didrocks> @pilot in
[07:14] <dholbach> EVERYBODY: PLEASE HELP OUT SPONSORING!
[07:14]  * dholbach hugs didrocks
[07:15]  * didrocks hugs dholbach back :) (told you I couldn't last week and that I'll do my shift in a quieter time)
[07:15] <didrocks> Mirv: hey, around?
[07:16] <dholbach> didrocks, sure, that's totally fine
[07:16] <dholbach> it's just that some folks seem to have moved their piloting sessions to "somewhere in the next five years", which seems to have become a problem
[07:17] <didrocks> dholbach: maybe there is a bug in the FHS symlinking to /dev/null :)
[07:17] <dholbach> something like that :)
[07:28] <pitti> dholbach: many missing patch pilot shifts?
[07:28] <dholbach> unfortunately yes
[07:29] <dholbach> and what's most depressing is that there are lots of requests in there which are very easy to deal with, so somebody putting in an hour could clear out many of them
[07:30] <micahg> dholbach: some of us are still slowed by merge proposals
[07:30] <dholbach> micahg, can you explain?
[07:31] <micahg> dholbach: any simple thing that has a merge proposal vs debdiff for me multiplies the time needed to handle it
[07:31] <dholbach> really?
[07:31] <micahg> yeah
[07:31] <dholbach> bzr branch A; cd A; bzr merge B; bzr bd -- -S
[07:32] <dholbach> in a lot of cases that's all you need to do
[07:32] <micahg> yeah, and then push back up (and possibly a commit or 2 for fixing stuff up)
[07:33] <dholbach> ah, I often don't push it but let the importer do it :)
[07:33] <Pelam> I'm at a loss for the best way to offer a patch to mod_auth_mysql package in Ubuntu. Suggestions?
[07:34] <micahg> dholbach: that kinda defeats the whole purpose of using a VCS IMHO
[07:34] <dholbach> in any case it gets the patch into Ubuntu - if I do the commit or the importer does it - I'm not sure where the difference is
[07:34] <dholbach> for me it's a step less
[07:35] <Pelam> Is this the correct channel for my question?
[07:35] <Mirv> didrocks: hey
[07:35] <didrocks> Mirv: hey, look at my question on the font MR
[07:35] <sladen> Pelam: https://bugs.launchpad.net/ubuntu/+source/libapache-mod-auth-mysql/+filebug
[07:35] <sladen> Pelam: https://bugs.launchpad.net/ubuntu/+source/libapache-mod-auth-mysql/+filebug-advanced
[07:35] <dholbach> Pelam, yes - either here or #ubuntu-motu
[07:36] <dholbach> Pelam, you can file a bug, as sladen suggested, then attach your patch and subscribe the 'ubuntu-sponsors' team which will get somebody to take a look at it
[07:36] <dholbach> alright, I need to rush off to the doctor - see you in a bit
[07:37] <Pelam> Thanks guys! It's more like a feature so I was hesitant to submit it as a bug :)
[07:37] <Pelam> Here is a small writeup about the thing: http://stackoverflow.com/questions/12543883/apache-mod-auth-mysql-with-phpass-encrypted-password-wordpress/12543884#12543884
[07:37] <Pelam> If you are interested ;)
[07:43] <Pelam> sladen: Sorry, what did dholbach mean with "subscribe the 'ubuntu-sponsors' team"?
[07:48] <Pelam> Hum... launchpad gave timeout error :(
[07:48] <didrocks> same here
[07:48] <didrocks> fixed now
[07:48] <Pelam> col
[07:48] <Pelam> cool
[07:49] <obounaim> Hello everybody
[07:50] <Pelam> Ah. Now I see, A "subscribe someone else" feature :)
[07:53] <Pelam> My first patch submitted to Ubuntu project, suggestions welcome: https://bugs.launchpad.net/ubuntu/+source/libapache-mod-auth-mysql/+bug/1057946
[07:59] <didrocks> pitti: hey, would you mind rejecting https://code.launchpad.net/~thor-peter/ubuntu/quantal/ftpcopy/bug-305831/+merge/126112 please?
[07:59] <pitti> done
[07:59] <didrocks> thanks :)
[08:00] <Pelam> Hello. Thanks for feedback! I was just in fact looking at submitting the patch to Debian.
[08:05] <Pelam> Ignore my last message... thought someone was talking about my bug (my name happens to be Peter)
[08:12] <smb> SpamapS, Not in solving it yet. Seems something with the route cache. But it is slightly complicated.
[08:12] <didrocks> Mirv: please don't remove the merge proposal :/
[08:13] <didrocks> Mirv: I had a followup on it
[08:13] <didrocks> Mirv: you need the Qt version from -proposed
[08:13] <didrocks> Mirv: can you please repropose it and get the changelog targetting -proposed?
[08:21] <Mirv> didrocks: ah, sorry, the proposal was not very useful since the libreoffice bug filed is only a part of the larger, old bug
[08:21] <Mirv> didrocks: and I don't think it's very sensible to change the font without editing the sources, and the sources cannot be edited with free tools alas
[08:22] <didrocks> Mirv: ok, keep me posted if anything changed in that front
[08:22] <Mirv> I will, there is some recent action at least now on the old bug
[08:23] <Laney> is LO still broken with just the qt4-x11 patch?
[08:24] <didrocks> Mirv: ^ as you tested it (only tested your patched font with qt4-x11 patch and was looking fine in LO)
[08:26] <Mirv> I didn't test the qt patch at all, only LO with a modified font
[08:36] <bkerensa> Laney: Sorry about all my trivial MP's
[08:36] <bkerensa> ;p
[08:36] <bkerensa> all 22 of them
[08:43] <didrocks> Laney: you are sponsoring some work from bkerensa? we should maybe coordinate to not overlap :)
[08:43] <Laney> didrocks: nah, he's responding to my mail on -devel
[08:43]  * Laney hugs bkerensa :P
[08:44] <didrocks> ah ok :)
[08:44] <Laney> will do some sponsoring in a bit though
[08:51] <Laney> dholbach: cz<tab> tells me you can edit the fridge calendar. Can you update it to reflect our temporary DMB meeting changes please? (8th → 15th and 22nd → 29th, and delete 5th Nov)
[08:51] <Laney> tumbleweed: ^ is that right?
[08:51] <dholbach> errrrr
[08:51] <dholbach> fridge calendar
[08:51] <dholbach> fridge, yes
[08:51] <dholbach> but calendar
[08:51] <dholbach> let me see
[08:52] <Laney> 28/09 09:46:28 <Laney> who can?
[08:52] <Laney> 28/09 09:46:46 <czajkowski> dholbach
[08:52] <Laney> Blame Laura™
[08:53] <dholbach> Laney, I'm afraid I can't
[08:53] <dholbach> I added it to my calendar (j5q85mmi6ujvjtii5s1n3li5io@group.calendar.google.com), but can't edit it
[08:54] <Laney> ok
[08:54] <dholbach> you could try asking in #ubuntu-news
[08:54] <Laney> will do
[08:54] <dholbach> somebody in there should have the necessary powers, I can only edit the fridge blog
[08:55] <didrocks> pitti: https://code.launchpad.net/~bkerensa/ubuntu/quantal/app-install-data-ubuntu/fix-for-control/+merge/125938 <- reject please :)
[08:56] <pitti> didrocks: aye sir!
[08:56] <didrocks> thanks :)
[08:57] <bkerensa> didrocks: ahh on that one its marked as need brace removed
[08:58] <bkerensa> my understand if braces are supposed to be removed?
[08:59] <didrocks> bkerensa: you meant, on https://code.launchpad.net/~bkerensa/ubuntu/quantal/app-install-data-partner/fix-for-brace-lists/+merge/125946 ?
[09:00] <bkerensa> didrocks: correct its on the todo to remove shell braces since they are not supported
[09:00] <bkerensa> http://lintian.ubuntuwire.org/quantal/tags/brace-expansion-in-debhelper-config-file.html
[09:00] <bkerensa> ^
[09:01] <didrocks> bkerensa: oh interesting, i didn't know about this lintian tag :)
[09:03] <didrocks> bkerensa: ok, so the only issue is that you didn't target the right Vcs-Bzr, please submit on the correct branch :)
[09:03] <bkerensa> didrocks: it is now re-targeted
[09:04] <didrocks> bkerensa: hum, I doubt the branch has the same base, did you check?
[09:07] <bkerensa> didrocks: it will not allow me to MP to the other branch
[09:07] <didrocks> bkerensa: that happens when the base of the branch isn't the same AFAIK
[09:07] <didrocks> bkerensa: so you need to branch from the real target branch
[09:08] <didrocks> put your change in
[09:08] <bkerensa> >.<
[09:08] <didrocks> commit
[09:08] <bkerensa> kk
[09:08] <didrocks> bkerensa: well, makes sense, it's not a patched file :)
[09:08] <didrocks> bkerensa: look at Vcs-Bzr always (there are other MR in the same case) ;)
[09:08] <bkerensa> kk
[09:13] <bkerensa> didrocks: upstream does not have the issue
[09:14] <didrocks> bkerensa: Vcs-Bzr is not targetting upstream, it's where the packaging lives officially
[09:14] <didrocks> if it doesn't have the issue, it means that it's either been fixed recently or that the next upload will fix it :)
[09:16] <didrocks> (if you are speaking about that above MR ^)
[09:17] <bkerensa> didrocks: yeah it appears to be fixed recently
[09:17] <didrocks> excellent! :)
[09:18] <cousteau> aptitude 0.6.8.1 seems to fix the multiarch bug (I think).  Would it be possible to merge it to quantal and backport it to precise and other versions?
[09:19] <didrocks> cousteau: if it's a bug fix only release, should be possible for quantal. Care to work on that? :)
[09:20] <didrocks> cousteau: I don't know the diff between 0.6.6 (precise) and 0.6.8, I think the safest for precise would be to cherry-pick the commit
[09:21] <Laney> so it turned out the reason the yubikey didn't work with my PC is that I was inserting it the wrong way around ...
[09:21] <cousteau> bug #831768
[09:22] <cousteau> I'm not actually sure 0.6.8.1 does fix the multiarch problem, but it seems so for what I read
[09:24] <didrocks> cousteau: please try to get the patch in shape and follow https://wiki.ubuntu.com/SponsorshipProcess to get it sponsored
[09:24] <cousteau> http://packages.debian.org/changelogs/pool/main/a/aptitude/aptitude_0.6.8.1-2/changelog   aptitude (0.6.8.1-1) unstable; urgency=low   * Multi-arch update for the problem resolver:   - handle conflicts without removing all foreign-arch packages (Closes: #672340) (LP: #831768)
[09:24] <didrocks> (in shape == tested ;)
[09:25] <tumbleweed> Laney: can we not find who added the event to the calendar? They can edit it
[09:25] <cousteau> (p.s. I'm not a developer, but I'll see what I can do)
[09:25] <Laney> tumbleweed: dunno
[09:25] <Laney> delegated now
[09:25] <didrocks> cousteau: thanks :)
[09:25] <tumbleweed> Laney: :)
[09:26] <cjwatson> aptitude sponsorship> sponsoring a merge for that package will be way more effort than doing it
[09:26] <cjwatson> IME
[09:26] <Laney> apparently it was Cody though
[09:26] <cousteau> didrocks, anyway I don't think patching/testing is needed since that has already done in debian
[09:27] <cjwatson> cousteau: I'll have a look at it
[09:27] <mvo> cjwatson: hi, someone told me about issues with the upgrade and https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1053896/comments/2 is the root cause. any thoughts what we should do ? push the update for ubuntu-keyring into -update real quick? or fix the update-manager in precise to be robust about missing keys (as long as there is a single valid sig)?
[09:27] <cousteau> (0.6.8.1 is already in debian testing)
[09:27] <hrw> one day I will grep to hunt and kill "Rather than invoking init scripts through /etc/init.d, use the service(8)" message
[09:27] <cjwatson> mvo: Oh seriously?  Argh
[09:28] <cousteau> and since aptitude in oneiric/precise is in "Don't use it" state, I think backporting would be a good idea
[09:28] <cjwatson> cousteau: unfortunately the patch will probably be unSRUably huge
[09:28] <cjwatson> from previous experience
[09:28] <cjwatson> so leave that 'til later 'cos thinking about it is just going to slow me down getting it into quantal
[09:29] <cjwatson> pitti: ^- would you be happy to rubber-stamp a waiver of the usual waiting period for ubuntu-keyring/precise, to unbreak upgrades?
[09:29] <cjwatson> mvo: and once we do that, will do-release-upgrade force the ubuntu-keyring upgrade first, or do we need some kind of special measures?
[09:29] <cousteau> ok, I've got to go now, see you
[09:30] <pitti> cjwatson: I don't have any formal authority about this any more, but this looks fine to me to release now
[09:30] <pitti> well, TB hat I guess
[09:30] <pitti> even on a Friday
[09:31] <cjwatson> TB hat was what I was aiming for :)
[09:31] <cjwatson> right, it's a serious enough issue that I'm going to do it and apologise later if it bothers somebody, then
[09:32] <cjwatson> mvo: copied
[09:32] <pitti> risk/benefit is sufficiently small here IMHO
[09:32] <cjwatson> we may end up having to revert to a single-signed Release if the problem is still gnarly, although I'd hope not to
[09:32] <mvo> cjwatson: we should probably add a dependency and do a SRU for update-manager, but there is no trivial way to enforce this I think because it happens before the release upgrader itself is run
[09:32] <mvo> (or update-manager-core)
[09:32] <mvo> but let me think a little bit about it
[09:33] <cjwatson> Wait, this is just for the signature on the upgrade tool itself, right, not the signature on Release?
[09:33] <mvo> cjwatson: just on the upgrade tool itself
[09:33] <cjwatson> I could easily change ubuntu-archive-publishing to single-sign the upgrade tool
[09:33] <mvo> cjwatson: would be a reasonable short term I think
[09:34] <mvo> cjwatson: what do you think long(er) term? make the release upgrader accept a single sig if another one is missing?
[09:34] <cjwatson> Yeah, I think it should behave like apt
[09:35] <mvo> cjwatson: ok, I will work on a fix
[09:39] <didrocks> cjwatson: python-defaults was uploaded as a native package it seems, was it wanted?
[09:39] <cjwatson> didrocks: I just matched the previous version
[09:40] <didrocks> cjwatson: sorry, not sure to get you, you mean that the previous version was also treated as a native package, right?
[09:40] <cjwatson> yes
[09:40] <cjwatson> didrocks: looking at http://archive.ubuntu.com/ubuntu/pool/main/p/python-defaults/, it seems to have been consistently native for a long time
[09:41] <didrocks> cjwatson: ok, continuing that path then until next upstream version I guess :) just checking, thanks!
[09:45] <didrocks> pitti: https://code.launchpad.net/~bkerensa/ubuntu/quantal/app-install-data-ubuntu/fix-for-control/+merge/126892 -> rejected please as it's the branch without the same base we discussed above.
[09:55] <chrisccoulson> can anyone think why gcc-4.6 in precise would silently ignore the "section" attribute on a global variable, when it works fine with gcc-4.7 in quantal?
[10:07] <chrisccoulson> oh, never mind, i figured it out
[10:07] <pitti> didrocks: that URL doesn't exist; I suppose someone already deleted the MP?
[10:08] <didrocks> seems so
[10:09] <Laney> tseliot: you might like dh_fixperms for fglrx-installer-*
[10:10] <tseliot> Laney: nice, thanks, I didn't know it
[10:29] <doko> zul: test failures in the nova build
[10:46] <didrocks> dholbach: http://reports.qa.ubuntu.com/reports/sponsoring/ < 100 now (95) ;)
[10:46] <didrocks> @pilot out
[10:50] <tkamppeter> mlankhorst, hi
[10:50] <mlankhorst> heya
[10:52] <tkamppeter> mlankhorst, can you have a look at bug 1029865? You told in comment #6 that the bug is temporary, but it is still there. Is there any chance for a fix?
[10:52] <ogra_> didrocks, ergh, patching a conffile from casper and not reverting the patch will cause issues
[10:53] <mlankhorst> tkamppeter: daniel said it was a hardware quirk and nothing can be done about it
[10:53] <mlankhorst> if it was a pure sw bug it would have been easy
[10:53] <cjwatson> ogra_: Why?
[10:54] <ogra_> cjwatson, it will cause questions on upgrades, no ?
[10:54] <dholbach> didrocks, YES :)
[10:54] <cjwatson> ogra_: What upgrades?
[10:54] <ogra_> +if [ -d /root/etc/gdm ]; then
[10:54] <ogra_> +    sed -i '/^[UG]ID_MIN/s/\<1000$/ 999/' /root/etc/login.defs
[10:54] <ogra_> +fi
[10:54] <cjwatson> ogra_: What upgrades?
[10:54] <ogra_> cjwatson, release upgrades
[10:54] <cjwatson> ogra_: In a live session?
[10:54] <ogra_> erm
[10:54] <cjwatson> ogra_: Remember that ubiquity copies the squashfs
[10:54]  * ogra_ blushes and hides somewhere
[10:55] <cjwatson> ogra_: It doesn't copy the results of casper patching stuff
[10:55] <cjwatson> Quite deliberately :-)
[10:55] <ogra_> yeah
[10:55] <mlankhorst> tkamppeter: there was a different bug that also affected that hardware rthat owuld have been fixable, but in this case it just reports that some connector on vga-1 is found without edid
[10:55] <tkamppeter> mlankhorst, I have also another new X problem, which appeared after an update some days ago. Sometimes, when I stay away from my PC for longer time and the screen power saving kicks in, I cannot return to my desktop, I get a black screen with only the mouse cursor.
[10:55] <mlankhorst> which is, sadly, valid
[10:55] <mlankhorst> tkamppeter: sigh, I'll run a valgrind over it again..
[10:55] <didrocks> ogra_: you put me in doubt for a sec :-)
[10:55] <ogra_> sorry
[10:56] <didrocks> no worry :)
[10:56] <mlankhorst> tkamppeter: do you know if X is still alive at that point?
[10:56] <tkamppeter> mlankhorst, you mean the valgrind for the black screen problem?
[10:57] <mlankhorst> tkamppeter: maybe, do you know if X still runs at that point or not?
[10:58] <tkamppeter> mlankhorst, is there a way to "blacklist" VGA1? The GPU is part of the CPU and probably there arte motherboards with different plug configurations. Perhaps mine has some kind of "dead circuit" telling to the on-CPU GPU that there is a VGA screen.
[10:59] <tkamppeter> mlankhorst, unfortunately, I do not have another i5 board here.
[10:59] <mlankhorst> you had a workaround for blacklisting it..
[10:59] <mlankhorst> but unfortunately there are a lot of broken displays out there that may not have a valid edid
[11:00] <tkamppeter> mlankhorst, I tried a workaround, adding video=VGA1:d to the kernel command line, but this did not change anything.
[11:01] <tkamppeter> For the black screen, X was probably still running, as the mouse cursor was there and I could move it with the mouse.
[11:01] <mlankhorst> can you file a bug after that happens so all the relevant logs are attached?
[11:02] <tkamppeter> mlankhorst, according to the display part of GNOME settings my monitor is discovered with its correct product name and native resolution.
[11:02] <mlankhorst> yeah but if it's mirrored to VGA-1 that would explain it
[11:03] <tkamppeter> mlankhorst, I get no crash pop-up after restarting the system afterwards. How do I report a bug which automatically attaches the correct files?
[11:03] <ogra_> stgraber, i was just pointed at bug 50093 (yeah, 6 years old) ... shouldnt bridge-utils just call sysctl from an if-up.d script ?
[11:04] <mlankhorst> tkamppeter: apport-bug in command line
[11:04] <tkamppeter> mlankhorst, can that mirroring be suppressed?
[11:04] <tkamppeter> mlankhorst, apport-bug with which package name?
[11:05] <mlankhorst> if you want a fix in Xorg, xrandr --output VGA1 --off; xrandr --output whatever --mode 1920x1080
[11:05] <mlankhorst> tkamppeter: just xorg
[11:08] <ev> mpt: http://poppy-dev.local/ - how does the legend look to you?
[11:08] <ev> hm, not sure why Firefox puts such a massive gap between the groups in the legend
[11:13] <mpt> ev, "all collected", not "all selected" :-)
[11:13] <mpt> ev, other than that it looks good
[11:13] <ev> hah, that's what I get for looking at the d3 api for too long
[11:13] <ev> thanks
[11:17]  * pitti hugs didrocks after his piloting shift
[11:18] <tkamppeter> mlankhorst, and where do I put this command line so that it is used by lightdm?
[11:18]  * didrocks hugs pitti back
[11:18] <mlankhorst> erm I tend to override it
[11:19] <tkamppeter> mlankhorst, what do you mean with that?
[11:19] <mlankhorst> make /etc/X11/X2, executable
[11:19] <mlankhorst> put this in:
[11:19] <mlankhorst> #!/bin/bash
[11:19] <mlankhorst> exec /usr/bin/valgrind --freelist-vol=500000000 --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg "$@" -verbose 10 &>> /home/mlankhorst/nfs/vg.$(hostname)
[11:19] <mlankhorst> then do a symlink from /etc/X11/X to X2
[11:19] <mlankhorst> the usr/bin/X wrapper hates if /etc/X11/X is not a symlink, or if it's a symlink to a symlink
[11:20] <mlankhorst> change path and it should be good to go :-)
[11:20] <mlankhorst> install the -dbg packages too for synaptics, evdev, i915, xserver-xorg-core
[11:21] <mlankhorst> but it's probably unneeded at this point
[11:21] <mlankhorst> just something I should do now
[11:21] <mlankhorst> as verification there are no random crashing bugs in quantal
[11:28] <tkamppeter> mlankhorst, there are no -dbg packages of synaptics, evdev, i915.
[11:34] <tkamppeter> mlankhorst, I have followed your instructions. X is now running under valgrind.
[11:35] <tkamppeter> till@till:~$ ps auxwww | grep valg
[11:35] <tkamppeter> root      5426 40.3 10.7 998192 870236 tty7    Ss+  13:31   1:07 /usr/bin/valgrind.bin --freelist-vol=500000000 --track-origins=yes --leak-resolution=high --malloc-fill=ef --free-fill=df /usr/bin/Xorg :0 -core -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch -verbose 10
[11:42] <mlankhorst> tkamppeter: you should have -dbg for those
[11:43] <mlankhorst> at least on quantal
[11:43] <mlankhorst> I added them to the most common quantal xorg server packages to make debugging a lot easier :-)
[12:10] <tkamppeter> mlankhorst, I found the dpg packages now.
[12:11] <tkamppeter> mlankhorst, but there are no packages with i915 in their name in Quantal, probably replaced by xserver-xorg-video-intel.
[12:12] <mlankhorst> oh right
[12:13] <tkamppeter> mlankhorst, now I have everything installed, I will do a system update now and then restart the session.
[12:15] <doko> pitti, ubuntu-drivers-common ping
[12:16] <pitti> doko: what's up?
[12:17] <doko> pitti, ftbfs
[12:17] <pitti> just retry it; slow armel builders FTL
[12:17] <doko> ScottK, Riddell: https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3807395
[12:21] <pitti> ogra_: oh, so you guys are having fun with the current arm builders as well?
[12:21] <pitti> ogra_: (just reading platform release report)
[12:21] <pitti> err, "Foundations"
[12:22] <ogra_> pitti, you mean webkit ?
[12:22] <pitti> ogra_: no, qt
[12:23] <ogra_> pitti, ah, that one, yeah, thats from doko
[12:24] <doko> pitti, webkit and qt4-x11 are upstream made issues, but yes, there are otheres too.
[12:24] <doko> e.g. abiword on armhf
[12:25] <doko> bryceh, https://launchpad.net/ubuntu/+archive/test-rebuild-20120922/+build/3844164 could you have a look? it's a package set
[12:27] <tkamppeter> mlankhorst, now I have everything together, all -dbg packages and valgrinding X.
[12:28] <mlankhorst> tkamppeter: might be a bit slower but as long as you don't use sw fallbacks you shouldn't notice it much :-)
[12:35] <tkamppeter> mlankhorst, so now I only need to wait for the black screen appearing again and then attach the log to a bug report?
[12:36] <mlankhorst> tkamppeter: if something suspicious shows up :-)
[12:37] <mlankhorst> I need to run valgrind once too, there were a lot of bugs in quantal that could have been caught with it
[12:37] <mlankhorst> precise*
[12:38] <doko> pitti, re-opening ubuntu-drivers-common. needs to be addressed for the release, in one way or another
[12:40] <tkamppeter> mlankhorst, I can see in the log already that my monitor reports a correct EDID, but VGA1 is without EDID at all (no pseudo EDIDE from mobo), perhaps one should dropm interfaces without EDID.
[12:42] <mlankhorst> tkamppeter: and that is valid too, only windows 7 certified monitors require a valid edid
[12:42] <mlankhorst> :p
[12:42] <mlankhorst> iirc
[12:42] <tkamppeter> mlankhorst, all of display discovery/selection is here: http://paste.ubuntu.com/1247443/
[12:44] <mlankhorst> tkamppeter: I know but upstream marked it resolved/wontfix so not much i can do about it :(
[12:44] <ScottK> doko: re avogadro - tons of direct GL calls that aren't going to work on our armhf (it last built on arm* in natty), so that's not happening.
[12:45] <mlankhorst> unless you can convince upstream it's not a problem on windows i think nothing will happen :\
[12:45] <doko> ScottK, looked like a float/double/q_float thing again
[12:47] <ScottK> No, it's GL.
[12:47] <ScottK> Even if it weren't, fixing whatever it is wouldn't help since the GL issues are still there.
[12:52] <pitti> doko: well, *shrug*, if that proves anything, it's that our arm builders have a problem
[12:52] <pitti> doko: I really don't want to disable tests for umpteen packages just because they occasionally fail
[12:52] <pitti> can't we just retry the build?
[12:53] <doko> pitti, I can understand it. had retried now three times. let's keep it open until we can address it in some form
[12:54] <pitti> hm, I guess at last upload we still had the armel builders running on natty's kernel
[12:54] <ogra_> that must have been long ago then
[12:54] <ogra_> buildds switched to hf quite a while ago i think
[12:54] <pitti> well, if "long ago" means "two weeks", then sure
[12:55] <pitti> 1:0.2.69 was uploaded on September 6
[12:55] <ogra_> (one or two releases)
[12:55] <pitti> ogra_: but until recently they were running natty kernels; now they are running precise's and are swapping themselves to death
[12:55] <ogra_> the kernel should be the same for hf and el
[12:55] <cjwatson> not that long
[12:55] <cjwatson> https://rt.admin.canonical.com/Ticket/Display.html?id=51115
[12:55] <ogra_> it should just use different chroots
[12:55] <pitti> ogra_: yes, it is
[12:56] <pitti> ogra_: and armel and -hf also have the same problems in e. g. glib
[12:56] <ogra_> hmm
[12:56] <pitti> it's pure luck that u-d-common failed on one and succeeded on the other
[12:56] <cjwatson> in fact that indicates nihal is still on a natty kernel (as of that last update anyway)
[12:56] <cjwatson> though the referenced ticket number is wrong
[12:57] <ogra_> i know ppisati's last merge fixed a ton of issues with power management (or rather cpufreq), i wonder if we could switch to a quantal kernel for them
[13:00] <ogra_> pitti, did you do a testbuild on a quantal panda locally by chance ?
[13:00] <pitti> ogra_: no, but I can try one
[13:01]  * pitti powers up his board
[13:02] <Daviey> pitti: you know you have access to porter boxes? Are they no good?
[13:03] <pitti> oh, scheat is back?
[13:03] <pitti> indeed
[13:04] <ogra_> Daviey, they will very likely use the same kernel as the buildds
[13:04] <pitti> still, time to update my panda board
[13:04] <ogra_> wont help much for checking if its a kernel issue :)
[13:04] <pitti> scheat is running 2.6.38
[13:04] <pitti> i. e. natty kernel
[13:04] <ogra_> ugh !
[13:04] <pitti> so I'll test build on my panda with the quantal one
[13:05]  * pitti dist-upgrades first, that'll take a bit
[13:09] <stgraber> ogra_: I think we need to get sysctl to run whenever we get network-device-added, though it's something we need to think about carefully and not rush into a release...
[13:09] <stgraber> jodh might have an opinion on that as IIRC he's touched-it-last on procps :)
[13:10] <ogra_> stgraber, yeah, i didnt mean to rush or anything it just made me feel bad that such a bug is open since 2006
[13:10] <ogra_> and it would be easy to work around it from bridge-utils until a proper fix is in upstart/procps
[13:11] <ogra_> for a proper fix upstart shoudl just emit a bridged-network-up event or some such that could be added to porcps.conf
[13:11]  * ogra_ glares at his fingers
[13:13] <stgraber> ogra_: udev will send a network-device-added even, so "start on ... or network-device-added" and have it run in "instance" mode would do the trick
[13:14] <ogra_> ah, procps already has network device event code, but restricts that to static i think
[13:14] <stgraber> well, procps start condition would work with bridges if it wasn't for the "or virtual-filesystems" part
[13:15] <ogra_> yeah
[13:15] <stgraber> as virtual-filesystems is usually emitted before static-network-up
[13:15] <stgraber> if it was just "start on static-network-up", it'd most likely work fine with bridges, though it may break other things as it'd likely be starting much later on most systems
[13:16] <stgraber> one of those things is the ipv6 privext key that we usually like to have set as early as possible (before bringing up the network)
[13:17] <stgraber> so I think the way forward is going to be to apply sysctl once very early (start on virtual-filesystems), then once per interface (using instance + start on network-device-added) and possibly also once per kernel module load (if we can get an event for that somehow)
[13:17] <stgraber> that should cover all the cases I can think of
[13:18] <cjwatson> Daviey,jamespage: so, update on bug 1050595: I've successfully done a 128M install by forcing lowmem mode; but I also had to delete vga=788 from the command line, otherwise lowmem mode just booted to a blank screen.  I've uploaded a tweak to lowmem to avoid that problem by leaving the framebuffer enabled with vga=*, but an enabled framebuffer uses more memory, so I'm going to have to wait until I get that fix landed and in ...
[13:18] <ogra_> having 2 upstart jobs ?
[13:18] <cjwatson> ... images before I can get true memory measurements
[13:19] <stgraber> ogra_: that or a single job using the "instance" feature of upstart (like we do in network-interface.conf)
[13:19] <ogra_> ah
[13:21] <stgraber> @pilot in
[13:23] <jodh> stgraber/ogra_: kernel modules + network interface should cover it. That said, potentially running sysctl every time a module gets loaded seems pretty extreme. Ideally, we'd have a way to calculate the optimal number of invocations and the point at which we need to make the calls. See https://bugs.launchpad.net/ubuntu/+source/procps/+bug/771372/comments/4 suggestion point (4) for some thoughts.
[13:24] <ogra_> jodh, how about making bug 50093 a dup of that one ? ;)
[13:25] <ogra_> its confirmed since 2006
[13:29] <stgraber> tkamppeter: hey there. I'm reviewing http://launchpadlibrarian.net/117644201/brother-lpr-drivers-common_1.0.0-4-0ubuntu2_1.0.0-4-0ubuntu3.diff.gz in the queue for quantal. That one isn't linked to a bug and I don't know the uploader so I'd just like to check with you that this change should indeed work and won't somehow break the resulting binaries.
[13:31] <tkamppeter> stgraber, there was nothing done on these Brother driver packages for years as the volunteer who originally made them went away/
[13:31] <jodh> ogra_: done.
[13:32] <doko> jamespage, is there still something to do about the java byte code format in main?
[13:32] <ogra_> jodh, i bet you have made a bunch of waiting people happy now :)
[13:32] <jamespage> doko, one thing I think - apport
[13:33] <tkamppeter> stgraber, the debdiff is harmless, only assuring to build under Quantal, you can let it pass. By the way, the author of the patch is not the original author of these packages.
[13:33] <doko> pitti, ^^^ apport & java byte code format
[13:34] <pitti> doko: sorry, what?
[13:35] <stgraber> tkamppeter: ok, thanks
[13:35] <doko> pitti: when compiling java files, use -source 1.5 explicitly
[13:36] <pitti> oh, can do; just add that as an option?
[13:36] <pitti>         subprocess.check_call(['javac'] + glob('com/ubuntu/apport/*.java'))
[13:36] <pitti> i. e. ['javac', '-source', '1.5'] ?
[13:36] <doko> yes, should work
[13:38] <pitti> doko: ok, builds and java tests succeed; committing to trunk, thanks
[13:38] <pitti> doko: OOI, does something break right now?
[13:39] <pitti> I wasn't even aware that anyone used those
[13:39] <doko> pitti: only if somebody tries to run these files using openjdk-6
[13:40] <doko> pitti: ubuntu-drivers-common fails for me locally too in the testsuite, but in other places
[13:41] <pitti> doko: dist-upgrade still running for me, I'll try on my panda after that
[13:41] <pitti> doko: are you running on precise or quantal?
[13:41] <doko> pitti, precise kernel, quantal chroot
[13:43] <doko> pitti: http://paste.ubuntu.com/1247527/
[13:44] <ogra_> that looks like missing b-deps
[13:44] <ogra_> at least the first two
[13:45] <pitti> right, missing aptdaemon and m-i-t?
[13:45] <ogra_> yeah
[13:46] <doko> m-i-t?
[13:46] <ogra_> module-init-tools
[13:46] <pitti> apt-get build-dep ubuntu-drivers-common should help?
[13:46] <ogra_> (modinfo)
[13:46] <doko> hmm, both are installed ...
[13:48] <hallyn> can anyone tell me why https://code.launchpad.net/~kampka/ubuntu/quantal/lxc/upstart-instance/+merge/123995 shows up in sponsor report?  id ont' see ubuntu-sponsor subscribed...
[13:48] <doko> urgh, /usr/sbin not in the path in the chroot
[13:49] <ogra_> lovely
[13:50] <stgraber> hallyn: all branches proposed for merging show up on it
[13:53] <doko> pitti: ok, builds here locally
[13:55] <hallyn> stgraber: so how does one take it off that report?
[13:56] <stgraber> hallyn: its status needs to be changed
[13:56] <jamespage> pitti, needs a "-target 1.5" as well - sorry was OTP
[13:56] <pitti> jamespage: oh, why do we need both?
[13:56] <stgraber> hallyn: though in this case I think its status is still fine as it hasn't been uploaded yet
[13:56] <jamespage> pitti, technically for apport you only need -target
[13:57] <doko> jamespage, wasn't -source implying -target?
[13:57] <jamespage> doko, nope - the other way around
[13:57] <pitti> jamespage: right, I was just going to ask -- the source is compatible with earlier releases anyway
[13:57] <doko> ahh, my bad
[13:57] <jamespage> at least I think so
[13:57] <pitti> so, changing to -target
[13:57] <pitti> yeah, -target implying -source makes more sense
[13:57] <jamespage> pitti, there is an experiemtnal lintian check which detects bad bytecode versions
[13:58] <pitti> jamespage, doko: pushed to trunk
[13:58] <doko> jamespage, can we make this check the default for quantal?
[13:59] <jamespage> doko, I guess we probably can - lintian is not a package that we normally delta
[13:59] <jamespage> but this is a key difference between ubuntu and debian
[13:59] <doko> I'll have a look
[13:59] <tumbleweed> then it can go into the ubuntu profile?
[14:00] <doko> ?
[14:01] <tumbleweed> lintian knows about distro-specific checks these days
[14:04] <jamespage> tumbleweed, that would be great
[14:04] <doko> tumbleweed, how do I disable the experimental tag there?
[14:13] <SpamapS> smb: thanks for the response. If you need any help reproducing or testing a fix, I'm happy to help
[14:15] <smb> SpamapS, np. Oh reproduction is not really the issue with Stephane's little program. Just understanding around which of the many corners of the network stack things might be wrong.
[14:18] <SpamapS> smb: I wonder if precise's kernel works on quantal...
[14:19] <smb> SpamapS, To a certain degree, yes. Though you can end up in a bad state when a driver needs firmware from the firmware package which has been dropped in Q
[14:23] <mpt> ev, pitti: apport is using ~98% CPU on my machine, and has been for several minutes, though it didn't present me any errors. Anything I can do to report the problem usefully?
[14:24] <ev> mpt: be right over
[14:31] <Laney> doko: qt4-x11 configures with -no-webkit
[14:32] <Laney> does it still somehow use it or?
[14:32] <doko> looking at the build log ...
[14:34] <Laney> seems not from what I can see
[14:40] <doko> at least I see -I../include/QtWebKit all over the place
[14:40] <doko> but there is long running link step in the build. wondering which one this is
[14:43] <doko> the biggest shared lib is libQtGui
[14:44] <tumbleweed> doko: no idea. It may be possible to override Experimental: no in the profile
[14:45] <doko> tumbleweed, well, I'll let this for others, just uploading what works for me, and maybe can be reverted later
[14:45] <tumbleweed> :)
[14:48] <mpt> ev, reported bug 1058158 and bug 1058160
[14:48] <Laney> doko: well, I can do an upload with -gstabs on armel armhf to canonical-arm-dev PPA and we can see, if you like?
[14:48] <mpt> please correct my mistakes
[14:49] <doko> Laney, sure. are there other packages in the PPA, which would prevent copying the binaries to the main archive?
[14:49] <Laney> no idea
[14:49] <Laney> if you have some other devirt ppa we can put it there instead
[14:50] <doko> I could use the ubuntu-toolchain-r ppa. could you prepare the upload?
[14:50] <Laney> actually it looks OK
[14:51] <Laney> there's only been 4 Quantal uploads and they're all superseded by the main archive
[14:53] <micahg> doko: is a 5hr timeout enough on arm*?  it used to be 12+
[14:54] <ogra_> 12h ?
[14:54] <ogra_> when
[14:54] <ogra_> iirc it was always something like 150min (2.5h)
[14:55] <doko> micahg, I ran the webkit link step, and it was 2.5h. however larger timeouts apparently hurt the virtualized buildds, so launchpad-ops don't want to increase it even more
[14:55] <ogra_> well, lookin at Laney'S issue the virtualized buildds are not really reliable anyway
[14:55] <micahg> ogra_: it was 2.5hr on x86, 800 min (12hr+) on arm*
[14:56] <ogra_> oh, wow, when was that set so high ? i definitely remember giving back packages in precise that failed with a 150min message
[14:56] <micahg> before the pandas I guess
[14:56] <ogra_> nah
[14:56] <micahg> yeah :)
[14:57]  * ogra_ would like to hear lamont for that ... i'm 100 positive we had several 150min issues in precise
[14:57] <ogra_> *100%
[14:59] <seb128> it's crazy how you get 300 updates the day after beta2
[14:59]  * seb128 upgrade 
[15:03] <smoser> is there some more correct way to copy something from quantal to a ppa for precise other than building source package?
[15:04] <smoser> ideally i'd like to copy binaries from quantal to my ppa
[15:04] <micahg> smoser: I would think it depends if the binary dependencies are met in precise or not (usually stuff is copied forward though)
[15:05] <cjwatson> You can use copy-package to do that
[15:05] <cjwatson> lp:ubuntu-archive-tools
[15:06] <smoser> micahg, well launchpad in ui for ppa copy alows you to copy binaries. i'm just asking to do the same thing ,but from official-archive -> ppa rather than ppa -> ppa
[15:06] <cjwatson> copy-package -s quantal --to-ppa=smoser --to-ppa-name=blah --to-suite=precise <package name>
[15:06] <smoser> cjwatson, thanks. that is exactly what i wanted.
[15:06] <cjwatson> (source package name, that is)
[15:06] <micahg> smoser: right, but what I'm saying is it might not work (the binaries that is):)
[15:06] <cjwatson> smoser: oh
[15:06] <cjwatson> smoser: add -b
[15:06] <smoser> micahg, well of course.
[15:06] <cjwatson> otherwise it will rebuild the binaries in your PPA
[15:06] <smoser> but copying forward doesn't necessarily work either
[15:07] <smoser> (i cna't have it rebuild because i need arm binaries)
[15:07] <smoser> so, yeah, thanks.
[15:07] <cjwatson> I don't know whether it will copy binaries for an architecture not enabled in your PPA ...
[15:07]  * Laney blinks at qt4-x11
[15:07] <smoser> hm..
[15:07] <Laney> *how* long to build a source package?
[15:07] <smoser> well, i'll see.
[15:13] <smoser> cjwatson, that did coyp binaries.
[15:13] <smoser> thanks. that is wonderful.
[15:17] <doko> didrocks, any bogofilter news?
[15:18] <cjwatson> smoser: Good stuff.
[15:18] <didrocks> doko: cyphermox is looking at it AFAIK, was waiting for his feedback
[15:18] <cyphermox> oh, oops
[15:19] <cjwatson> smoser: FWIW, if you do find yourself using the web UI, it'll be improved by joining launchpad-beta-testers.  See https://blog.launchpad.net/general/beta-test-asynchronous-ppa-package-copies
[15:19] <cyphermox> doko: didrocks: I have no opinion really on which is better, but if the issue is that we'd like to avoid having two filters in main I can just flip the alternate  Recommends to have spamassassin first
[15:20] <cyphermox> I'm going to have to do an upload of evo again soon for some fixes
[15:21] <doko> ok, then demoting bogofilter
[15:23] <stgraber> fabo: ping
[15:23] <stgraber> fabo: I'm trying to understand bug 1030588 and the matching merge proposals. My understanding is that quantal got a new qemu-linaro which includes that bugfix and it simply wasn't closed, is that correct?
[15:24]  * fabo looks
[15:25] <ogra_> looks like its highbank only
[15:27] <fabo> stgraber: that's correct, 1.2.0-2012.09-0ubuntu1 has been uploaded. it closes 1030588 and 1030594
[15:27] <cyphermox> doko: ok; I'll upload evo with the change in a few hours at most, just finishing up and cleaning up a patch
[15:27] <stgraber> fabo: ok, I'll clean them up then. thanks for checking
[15:28] <fabo> stgraber: thanks
[15:39] <dholbach> can somebody please reject https://code.launchpad.net/~obounaim/ubuntu/quantal/z3c.form/adding-homepage/+merge/125318?
[15:39] <mvo> stgraber: heh, was just looking at that too :)
[15:40] <mvo> fabo: should this go to precise-proposed as well?
[15:40] <bdmurray> doko: apport will now gather pythonhome and pythonpath
[15:40] <doko> Laney, so this make fix looks fine for me, even if the solution is not the preferred one by upstream. we can assume that we use compliant shells (dash, bash, zsh) in main at least
[15:40] <stgraber> dholbach: done
[15:40] <dholbach> thanks
[15:40] <doko> bdmurray, in quantal?
[15:40] <Laney> doko: OK then
[15:40] <Laney> I'll see if I get armel building locally then we can upload them both at once
[15:40] <bdmurray> doko: yes, it'd be easy to SRU if you think its a good idea
[15:42] <doko> bdmurray, maybe not yet. so it is now used to collect the duplicates? there was one more comment I did see, that even after replacing the lsb_release implementation, this kind of error was still seen with the vmware installers
[15:43] <fabo> mvo: it will be nice, yes.
[15:44] <mvo> fabo: ok, uploaded
[15:46] <bdmurray> doko: no its not used in duplicate detection, just gathered in the bug details
[15:47] <lamont> ogra_: the extreme timeout for armel was bbg3 timeframe
[15:47] <lamont> ogra_: it should be set to something more sane these days, IMO
[15:47] <ogra_> lamont, weird
[15:57] <fabo> mvo: thanks!
[15:58] <cjwatson> dholbach: I think it would be a good time to stop encouraging people to upload trivial changes to quantal, FWIW, if you haven't already
[15:58] <cjwatson> dholbach: We're now frozen until release, and release team bandwidth for reviews is limited
[15:58] <dholbach> gotcha
[15:59] <dpb___> I have a package this is being removed by dist-upgrade.  Is there a way to have it tell me *why* it wants to remove it?
[16:00] <cjwatson> -o Debug::pkgProblemResolver=1 may help
[16:00] <cjwatson> the output can be ... novel to read
[16:01] <dpb___> cjwatson: excellent, now to translate into human
[16:01] <dpb___> cjwatson: thx!
[16:10] <doko> mterry, I had already done the review for pam-xdg. just wanted to have the ack from the security team
[16:10] <mterry> doko, oh missed that in the comments.  Awesome
[16:10] <doko> mterry, yeah sorry, just in the release meeting
[16:14] <micahg> Laney: re webkit, if 1.10 doesn't work out, 1.8.3 builds fine on quantal :)
[16:14]  * micahg will even help with rebuilds...
[16:14] <Laney> heh
[16:15] <Laney> el panda is installing the BDs now
[16:15] <Laney> I suspect this will be a full weekend build, or close enough
[16:15] <micahg> oh, is it just the pandas now, hrm, haven't tested that yet
[16:15] <Laney> we have all builds except armel
[16:15] <Laney> but the suspicion there is that it was busted because virt
[16:16] <stgraber> xnox: any progress on: https://code.launchpad.net/~abone/ubuntu/precise/console-setup/fix-433897/+merge/118886 ?
[16:16] <cjwatson> bug 1057485 - "QString is latin-1 by default" - seriously?  what decade is it again?
[16:16] <cjwatson> stgraber,xnox: I'd like to review that, please
[16:16] <cjwatson> I haven't had time to think about it yet
[16:16] <stgraber> cjwatson: ok, added you as reviewer
[16:17] <cjwatson> right, I commented too
[16:19] <stgraber> infinity: any chance you can look at bug 1000498 for quantal?
[16:19] <xnox> stgraber: I did initial review of the branch, but cjwatson has the bug assigned and voice disagreement with the proposed solution.
[16:20] <cjwatson> Not so much disagreement as wariness born of past pain
[16:20] <cjwatson> It took me at least a week to work out all the constraints on that code
[16:22] <doko> afk now, back later tonight
[16:24] <infinity> stgraber: Looking.
[16:25] <infinity> stgraber: Grr, I wish I'd noticed that when I did the last eglibc SRU.  Oh well.
[16:26] <stgraber> infinity: it's been on the sponsoring report for quite a long time apparently (I'm trying to clear as many "red" entries as possible)
[16:27] <infinity> stgraber: Yeah, I might just be blind. :P
[16:28] <infinity> stgraber: I'll cross-reference with upstream commits (I remember carlos bitching about something related to this, so there may be more fixes), and upload something backporty.
[16:29] <stgraber> infinity: cool, thanks
[16:41] <toabctl> pitti, one memleak I recognized with the d-feet port is documented here: https://bugs.launchpad.net/ubuntu/+source/overlay-scrollbar/+bug/1058205
[17:17] <roaksoax> Howdy! I was wondering how can we avoid asking user input to replace a config file, when dist-upgrading a package?
[17:30] <infinity> roaksoax: By not changing conffiles.
[17:30] <infinity> roaksoax: If a user changed a conffile, you *want* the prompt, overwriting their changes is bad.
[17:31] <infinity> roaksoax: If a package/script changed a conffile, that's a bug.
[17:31] <sarnold> infinity: .. the other option is leaving their conf in place without a prompt..
[17:31] <infinity> sarnold: If the user wants that behaviour, they can set that up.
[17:31] <cjwatson> sarnold: That can easily create bugs if the package side of the change to the conffile is necessary.
[17:32] <cjwatson> Never-overwrite is just as wrong as always-overwrite - it just fails in different situations.
[17:32] <sarnold> cjwatson: indeed ;) but most developers try to provide some modicum of backwards-compat most of the time
[17:32] <cjwatson> This is why Debian policy is painfully explicit that packages must never edit conffiles.
[17:32] <roaksoax> infinity: right, in this particular case we need to change the conffile (in packaging, I know, it is not pretty), so on every upgrade, if upstream conffile has changed, we need to not ask the question and do as required
[17:32] <cjwatson> (I mean, other than by changing the shipped version.)
[17:32] <cjwatson> roaksoax: There isn't a workaround for this other than having it not be a conffile.
[17:33] <sarnold> roaksoax: see 'confold' in dpkg(1)
[17:33] <infinity> roaksoax: Erm, either you're wildly violating policy, or I'm misunderestanding what you're doing.
[17:33] <cjwatson> This is a bit of Debian policy that is there for a very very very good reason.
[17:33] <roaksoax> sarnold: thanks.
[17:34] <cjwatson> sarnold: There's no way for a package to set that just for itself.  You can only control it for the entire upgrade.
[17:34] <cjwatson> Which may be fine in some special cases, but you can't mandate its use.
[17:34] <sarnold> cjwatson: that's perfectly fine :)
[17:34] <infinity> ...?
[17:34] <infinity> Fine in what sense?
[17:35] <cjwatson> If this is a cloud image or something where you control the upgrade process, you may be able to get away with it.
[17:35] <roaksoax> cjwatson: uhmm right, I think that treating those those files as conffig files for packaging would be a better idea then
[17:35] <cjwatson> But otherwise it definitey isn't fine, indeed.
[17:35] <cjwatson> *definitely
[17:35] <sarnold> infinity: I mean 'fine' in the sense that if a user is tired of being prompted, they can tell the upgrade process to leave them alone and clean up the breakage later, if they please.
[17:35] <roaksoax> infinity: again, this is a very special case
[17:35] <roaksoax> Daviey: ^^
[17:35] <cjwatson> sarnold: Debian regards mishandling of conffiles in this way as a release-critical bug, and we should too.
[17:35] <infinity> roaksoax: What's exactly happening here?  Are you shipping conffiles that change from time to time (common thing to do), and users are also constantly changing them?
[17:36] <infinity> sarnold: Yes, true, but not something one should recommend to a user either, and roaksoax was looking for a solution for his package, not a solution as a user.
[17:36] <roaksoax> infinity: the particular case is that on installation, MAAS needs to atomatically do things (such as create passwords) and modify config files in order for this to work out of the box
[17:37] <cjwatson> You need to fight really very hard for it not to need to change conffiles.
[17:37] <roaksoax> infinity: so whenever upstream changes the config file in some way, it prompts for user action in upgrade (becuase the config file has been modified by the .postinst file)
[17:37] <cjwatson> Otherwise it will absolutely bite you later and you will regret it.
[17:37] <infinity> roaksoax: Right, okay.  So the scripts themselves are mangling the files.  Then yes, those should NOT be conffiles, or you need non-conffile conf.d mechanisms or something for the bits that change.
[17:38] <sarnold> infinity: "looking for a solution for his package" is an important piece of the puzzle :)
[17:38] <infinity> roaksoax: It's a blatant policy violation to have non-users editing conffiles, which is where your problem lies.
[17:38] <roaksoax> infinity: right, so given the lack of conf.d/ I guess that the best approach is not treat them as conffiles.
[17:38] <cjwatson> Or add .d support to the relevant packages.
[17:38] <roaksoax> infinity: I agree, but in this particular case was a must do to make things "just" work as required
[17:38] <cjwatson> That's not likely to be harder than treating them as non-conffiles.  It will depend on the situation.
[17:38] <roaksoax> cjwatson: i'll raise that upstream!
[17:38] <cjwatson> roaksoax: Not mishandling conffiles is a "must do".
[17:39] <cjwatson> I realise this is frequently misunderstood, probably because it only bites people six months later.  But it is a false economy to skimp on this.
[17:39] <infinity> roaksoax: Treating them as non-conffiles ends up with a whole new set of issues, such that you need to either employ fancy things like ucf, or be VERY CAREFUL about how you update the files to not overwrite user changes.
[17:39] <infinity> roaksoax: So, yes, conf.d type stuff tends to be a cleaner and easier way to do things like "include 3 small config snippets".
[17:40] <roaksoax> i agree
[17:40] <stgraber> slangasek: you have a few changes in ubuntu:nfs-utils that haven't been uploaded yet. Are you planning an upload? I'm looking at bug 794112 and wondering if I should upload or just stack add it to what you have in the branch and let you upload
[17:40] <cjwatson> .d support is usually easy to patch in even if upstream is uninterested
[17:40] <cjwatson> Depending on the exact configuration semantics I suppose
[17:40] <roaksoax> cjwatson: the problme is that some of those "conffiles" are .py as they are django config files
[17:41] <cjwatson> That should be pretty easy to support, then, given the long tradition of monkey-patching in Python.
[17:41] <infinity> Even doing something sketchy like 'run-parts --list | xargs cat' can give you a ghetto .d implementation, if you're not up for doing it in a shiny way.
[17:41] <Daviey> we can do .d for that... I have a specific example that should help.
[17:41] <infinity> Oh, and while I said that, you mentioned python, so yeah, better ways to do that. :P
[17:42] <roaksoax> awesome then
[17:42] <roaksoax> can anyone please link me to examples?
[17:42] <infinity> roaksoax: It's also entirely possible that some of them shouldn't be conffiles (or config files) at all, don't belong in /etc, and should be in /usr/share, with a simple fopen() to /etc/package/passwordfile.
[17:42] <infinity> (I don't know this to be true, but it may well be)
[17:43] <xnox> roaksoax: Daviey: wasn't there even package created `dotdee` that does this conffile handling despite upstream not supporting .d dirs. And as far as remember juju doesn't something along the lines like that for e.g. hadoop charm.
[17:43] <Daviey> roaksoax: I didn't actually ever upload this.. but i created a .d named settings_override. https://launchpad.net/~davewalker/+archive/cobbler-testing/+packages
[17:44] <Daviey> roaksoax: The deal was, that if you had an extra package installed, it added to the settings_override, and it was picked up at run time.
[17:44] <xnox> and the situation is not dissimilar. juju tries to make hadoop to work out of the box, by modifying conffiles yet managing the whole process to make it automatic on upgrades.
[17:44] <roaksoax> infinity: yeah that's other approach I considered (sourcing /etc/package/passwordfile)
[17:44] <roaksoax> Daviey: cool I'll take a look
[17:45] <Daviey> roaksoax: anything in the .d is considering a django settings file to append... via __init__.py loading.
[17:47] <roaksoax> Daviey: cool
[17:50] <roaksoax> infinity: cjwatson sarnold thank you for the enlightment :)
[17:53] <slangasek> stgraber: those nfs-utils changes were dependent on mountall 2.41, which just went in post-beta; they should all be ok to upload now
[17:54] <stgraber> slangasek: ok, I'll apply the fix from bug 794112, test build and upload it to the archive then
[18:04] <barry> tumbleweed: do you have any other information on bug 1031882?  i need to get a vm up and running to test upgrades in en_ZA, but i thought i'd take a look at that today
[18:08]  * cjwatson discovers that, if you generate a new locale, you can't load it from any process that has previously called setlocale
[18:08] <cjwatson> I wonder how inconvenient that's going to be here ...
[18:12] <barry> cjwatson: do you mean wrt bug 1031882?
[18:15] <cjwatson> No, wrt bug 644736
[18:15] <cjwatson> It should work OK if you don't try to put them in the locale-archive
[18:15] <cjwatson> So I think I'll have to do some fiddling to arrange for that
[18:30] <hallyn> @pilot in
[18:31] <stgraber> hallyn: looks like you'll be called "h" today, not enough characters for you :)
[18:33] <hallyn> yoyoyo, i be down wit dat
[18:43] <smoser> any python smarties want to help
[18:43] <smoser> http://paste.ubuntu.com/1248087/ , when run results in http://paste.ubuntu.com/1248086/
[18:43] <mitya57> we can remove one more character
[18:43] <smoser> basically, yaml.safe_load() wont let me load python_unicode types , but i kind of need to.
[18:46] <hallyn> oh - mvo are you working on the SRU for bug 1030594 ?
[18:46] <hallyn> (i notice you changed the status for precise, but didn't take ownership)
[18:46] <hallyn> hm.
[18:47] <stgraber> hallyn: yeah, it's been uploaded. I thought I remove -sponsors from it, maybe not...
[18:47] <stgraber> fixed
[18:47] <hallyn> stgraber: that was for q though?  or p?
[18:47] <hallyn> hm ok.  cool  :)  thx
[18:48] <stgraber> it was pushed to Q a few weeks ago and mvo uploaded to P 2 hours ago
[18:49] <trism> smoser: http://stackoverflow.com/questions/9169025/how-can-i-add-a-python-tuple-to-a-yaml-file-using-pyyaml (first answer looks about right)
[18:52] <smoser> trism, awesome.
[18:52] <smoser> thank you.
[19:02] <ppetraki> hi all, I'm prepping a submission for per package uploaders rights for multipath-tools and was wondering if it made sense to also propose a delegated team for low level storage packages that have  dependencies?
[19:04] <micahg> ppetraki: hrm, well, I would guess that most of those packages are in core, depending on how sufficiently different the packaging between them are, it might just warrant being core-dev
[19:05] <hallyn> micahg: core-dev brings to mind all the x packaging and such too, though.
[19:06] <hallyn> nothig really wrong with getting PPU to each of the packages ppetraki listed, but a package set does seem to make sense  <shrug>
[19:06] <slangasek> what are "each of the packages"?
[19:06] <ppetraki> yeah, they're all in main now, mp used to be in universe
[19:06] <micahg> hallyn: yeah, well, the idea with core-dev is you know what you do and don't know and are sufficently trusted to ask when you're not in your comfort zone
[19:06] <ppetraki> once you start touching device mapper, the skills start to cross-over quick
[19:07] <hallyn> ppetraki: can you spell out thep ackage list?
[19:07] <micahg> aside from select individuals most core-devs have an area of specialty
[19:07] <hallyn> makes sense,
[19:08] <hallyn> still i for one have been afraid to ask for core-dev, it's still intimidating...
[19:08] <ppetraki> hallyn, multipath-tools, lvm2, dmsetup at a minimum, kpartx can effect them
[19:08] <hallyn> ppetraki: that *is* smaller than the first set of packages i asked for PPU for.  (but still a package set seems to make sense)
[19:09] <ppetraki> hallyn, which is why I bring up the delegated team concept, akin to the Debian LVM team
[19:09] <micahg> ppetraki: I also only see one round of uploads for you with multipath-tools which didn't include any interaction with the package from Debian
[19:10] <slangasek> lvm2 gets deep into udev, initramfs, has a massive delta to manage from Debian; I would hope the DMB would not grant PPU/packageset upload rights to lvm2 to someone that they weren't also comfortable making a core-dev
[19:10] <ppetraki> micahg, there's at least one for mp, some of my initial work went through hallyn iirc
[19:10] <micahg> right, hence my previous comment :)
[19:11] <slangasek> (oh, touches the installer too)
[19:12] <ppetraki> I could stay out of lvm2 then, simply would need to stay in touch
[19:12] <micahg> ppetraki: you're free to contribute to anything through sponsors :)
[19:13] <ppetraki> micahg, that's thing, I've taxed hallyn alot for that for multipath-tools and would like to pull my own weight there
[19:15] <hallyn> tjaalton: bug 1054095, just curious, you marked it fix committed - where is it committed?
[19:16] <ppetraki> I suppose just multipath-tools rights is fine "Per-package Uploaders"
[19:16] <micahg> ppetraki: well, I don't see anything aside from 3 changelog entries, not sure why hallyn didn't credit you in some way in the changelog (even if not having a signature)
[19:16] <ppetraki> micahg, I really don't focus on credit :)
[19:16] <micahg> ppetraki: of course, but we need some type of trail to evaluate your work :)
[19:16] <hallyn> jinkeys, big apologies if i did that
[19:16] <ppetraki> I'm essentially the defaco expert on SAN and low level kernel storage
[19:17] <ppetraki> micahg, I have character witnesses :)
[19:17] <micahg> ppetraki: have you ever merged the package from Debian?
[19:17] <ppetraki> micahg, no
[19:17] <hallyn> ppetraki: i think a PPU for multiptah-tools would be a nobrainer for you.
[19:17] <hallyn> maybe when r opens you do the sponsored merge , and then apply for PPU?
[19:18] <ppetraki> micahg, we actually moved away from even trying to stay synced with them as it was so far out of date that it just did more harm than good, thats why we migrated from 0.4.8 to 0.4.9
[19:18] <micahg> hallyn: ppetraki: well, if you two can construct a paper trail, the next meeting with available slots for applications is at UDS
[19:18] <ppetraki> micahg, I can take that action
[19:19] <micahg> ppetraki: Debian is on 0.4.9 now as well
[19:19] <hallyn> ppetraki: if there are specific commits you need to get sponsored in the meantime, it's good to discuss them here and get some varied sponsors so they can also +1 you at the PPU discussion
[19:19] <micahg> hallyn: +1 :)
[19:20] <ppetraki> micahg, iirc at the time we leap forward they were still on 0.4.8
[19:20] <ppetraki> micahg, I agree though, we could do better in working together for sure
[19:21] <micahg> ppetraki: it happens
[19:22] <micahg> ppetraki: well, from the community side of things, we prefer work to be done in Debian as that means less duplicated efforts which allows all parties involved to accomplish more
[19:22] <ppetraki> micahg, agreed
[19:27] <tjaalton> hallyn: i synced it, still on the queue i think
[19:27] <hallyn> tjaalton: ok, thanks.
[19:30] <micahg> hallyn: zul: 0.10.0-1fakesync1ubuntu1 would've been fine as 0.10.0-1ubuntu1 :)
[19:31] <stgraber> micahg: oh indeed, well too late, I accepted it already :)
[19:31] <hallyn> micahg: oh, i see.  that makes sense, since it's no longer a sync
[19:31] <hallyn> thanks
[19:31]  * hallyn feels silly
[19:32] <stgraber> hallyn: that's fine, the changelog entry will disappear with the next sync anyway ;)
[19:33] <hallyn> stgraber: so if there is another one, should i call it 0.10.0-1ubuntu2?  or ubuntu1?
[19:34] <stgraber> good question ;) I think you should go with ubuntu2 to make it clearer that it's the second ubuntu change
[19:34] <stgraber> technically ubuntu1 would be fine (as it's higher than the current version) but it'd look confusing
[19:35] <hallyn> (would have been my guess :)  thanks
[19:43] <stgraber> @pilot out
[20:03] <BenC> Is there some problem I'm unaware of with blueprints? When I try to create one it keeps telling me that the "Information Type" is required when I clearly have it set as Public
[20:03] <BenC> Nevermind, I had to select as private and then back to public and it let it go
[20:52] <stgraber> SpamapS: speaking of juju and lxc, any change you can get bug 996358 on the roadmap?
[21:05] <hallyn> stgraber: smb: so the netns refcoutn bug, ...  outlook not so good?
[21:30] <hallyn> Could someone who is motu consider sponsoring the debdiff on bug 1054274 ?  it fixes systemtap in quantal.
[21:30] <hallyn> kees: ^ you <3 systemtap right? :)
[21:36] <micahg> hallyn: that's a little more than I want to parse on 2.5 hours of sleep
[21:39] <micahg> hrm, if there were no reverse dependencies, I'd suggest an FFe for 1.8...
[21:40] <nfirvine> Hi all, I'm packaging MATLAB for internal distribution for my organization.  Is this a good channel for help?
[21:43] <xnox> slangasek: you have rdeps =) bug 1058211
[21:44] <slangasek> xnox: well, preferably not; this should be seeded as part of ubuntu-desktop, and weston itself should fall back to $something_sensible if te path isn't set.
[21:45] <hallyn> micahg: though debian doesn't have 1.8 :(
[21:45] <xnox> slangasek: that's my though as well. Can you please comment on the bug and/or reject merge proposal?
[21:45] <kees> hallyn: I love it, yes, but don't use it much.
[21:45] <slangasek> xnox: sure
[21:45] <xnox> slangasek: will libpam-xdg-support be seeded in quantal?
[21:45] <hallyn> kees: drat - ok, thx
[21:45] <slangasek> xnox: that's the intent, but there's a licensing tweak to be sorted first
[21:46] <kees> hallyn: reading the bug, it looks like it's a kernel change that is needed?
[21:46] <xnox> slangasek: licensing? /me thought this has nothing to do with secure boot signatures....
[21:46] <kees> hallyn: if so, did you ask a kernel team person to pull that patch in?
[21:47]  * xnox *giggles*
[21:47] <slangasek> xnox: it's currently licensed GPLv3 per company default; that's fine for a PAM module as long as we're not turning it on by default. :)
[21:47] <xnox> slangasek: ok.
[21:52] <hallyn> kees: no, it's a kernel change that changed symbol naming, and systemtap is updated to handle that
[21:56] <kees> hallyn: ah, is https://launchpadlibrarian.net/116856894/systemtap_lp1054274_quantal_fix2.debdiff the right fix?
[22:02] <hallyn> kees: yup that's what i was looking at
[22:02] <kees> hallyn: we're frozen, yes? I think you need a freeze exception for it first, then it should be trivial to fix.
[22:06] <stgraber> kees, hallyn: looks like a bugfix to me, so shouldn't need a FFe
[22:06] <SpamapS> stgraber: re juju using lxcbr0, its under review now actually :)
[22:07] <kees> stgraber: oh, right, durr
[22:07] <hallyn> kees: it's listed in http://pad.ubuntu.com/ubuntu-release as an 'opportunity target'
[22:07] <kees> hallyn: you want me to upload it?
[22:07] <stgraber> SpamapS: yay! I'm looking forward to being able to run it inside an lxc container! I'll actually need that feature for edubuntu-server in 13.04 :)
[22:07] <hallyn> SpamapS: let us nkow if there's anything you'd like us to look over for that!
[22:07] <SpamapS> stgraber: cool. I'm looking forward to being able to actually use lxc in quantal ;)
[22:08] <stgraber> hallyn: information on that pad tends to be out of date when not in a milestone week
[22:08] <SpamapS> have had to resort to testing in a 12.04 VM
[22:08] <hallyn> kees: that'd be great, thanks.  (The one comment in teh bug asked about mentioning the kernel version where it changed in changelog;  that seems overkill to me but i listed the commit id in the bug at any rate)
[22:08] <hallyn> stgraber: ah :)
[22:08] <hallyn> @pilot out
[22:09] <stgraber> SpamapS: yeah, I hear you, I'd also like to be able to run containers on my laptop instead of running them on a 12.04 server...
[22:09] <kees> hallyn: okay, I'll add it.
[22:13] <hallyn> kees: thanks!
[22:15] <kees> hallyn: np, thanks for pointing it out :)
[22:59] <Xgates> hi guys
[23:01] <Xgates> Besides Ubuntu I run some other distros that I compile apps from source and I noticed that in Ubuntu it has libreoffice broken up into packages, like; libreoffice-writer, libreoffice-calc... and I wanted to find out if anyone knows how this was done, like it seems you can just compile this with only the writer if that's all you want?
[23:02] <xnox> Xgates: we compile once with everything enabled, and just split the installed tree into bits.
[23:02] <xnox> Xgates: you can't actually compile debian package with "just writer" enabled. Plus there is little point, as most of the libreoffice core bits are common across major components.
[23:02] <Xgates> ok, so if someone only installed libreoffice-writer on Ubuntu do you know what other pkgs are going to get pulled in with it?
[23:03] <xnox> Xgates: yes. see the debian/control file in the source package.
[23:03] <xnox> Xgates: a single source package (first paragraph) can build one or more binary packages (all other paragraphs)
[23:04] <sarnold> Xgates: apt-cache show libreoffice-writer will show you a "Depends: " line that has packages that will also be installed (those packages may also pull in dependencies..)
[23:04] <Xgates> yep deps on deps on deps hehe
[23:05] <Xgates> I wish they'd make it so you can build only what you wanted and not the whole thing...
[23:06] <xnox> Xgates: libreoffice is special. on buildd's it takes 4.5 hours to build =(
[23:07] <xnox> Xgates: and by building just -writer, you will end up building most of libreoffice anyway
[23:07] <xnox> Xgates: on armhf - 21 hours.
[23:07] <Xgates> only took me 2 hours to build it
[23:08] <sarnold> Xgates: do you also build all the translations? :)
[23:09] <xnox> Xgates: depends how much of it you build, and whether you do languages stripping for language packs, compressions and debug symbols packages.... like launchpad does
[23:09] <Xgates> I don't think you can just build only certain parts like just writer
[23:09] <Xgates> I built the languages as well all only 2 hours
[23:09] <sarnold> Xgates: nice build box :)
[23:10] <xnox> well somone build libreoffice in 40minutes all in 32 GB RAM and 16 cores.
[23:10] <infinity> I need a new laptop.  My 16G of RAM isn't cool anymore.
[23:10] <sarnold> infinity: ooh, what make/model? :)
[23:11] <Xgates> I just built it on a Sony Vaio lap i3 core 4gb ram is all nothing fancy
[23:11] <infinity> sarnold: Just an old T420s.
[23:11] <sarnold> xnox: do the buildds build the tests as well?
[23:12] <xnox> sarnold: check for yourself. https://launchpad.net/ubuntu/+source/libreoffice/1:3.6.1~rc2-1ubuntu5
[23:12]  * penguin42 hopes the libreoffice guys efforts to remove cruft from the LO code base will keep removing stuff
[23:12] <sarnold> hehe, "add $1060..."
[23:12] <xnox> sarnold: click on the arch under the build section
[23:12] <sarnold> xnox: ooh, thanks :)
[23:12] <Xgates> what an idiot this guy is in the Lbo-dev channel;
[23:12] <infinity> sarnold: No one buys RAM from Lenovo, that's madness. :P
 Xgates: if you plan to help implementing it we may give you some code pointers, otherwise you're in the wrong channel
[23:12] <Xgates> oh gee may give me some pointers LOL
[23:13] <infinity> sarnold: You spec the system with as little RAM as possible, and then go to the local computer parts store. :P
[23:14] <sarnold> infinity: that's been my approach in the past, but of course now they're taking to the solder gun for ram :/
[23:14] <xnox> what do you do when people email you for support, simply because you commented on a bug report
[23:14] <xnox> ????
[23:14] <infinity> sarnold: If by "they", you mean "Apple", that's one of the many reasons I don't buy their stuff.
[23:15] <sarnold> xnox: you can aim users at http://www.ubuntu.com/support/community
[23:15] <infinity> sarnold: I've not noticed Thinkpads suffering this problem.
[23:15] <sarnold> infinity: I think the new lenovo x1 has soldered memory :(
[23:15] <infinity> Oh, the X1 is junk anyway.
[23:15] <sarnold> oh :)
[23:15] <infinity> The T420s was lighter, thinner, faster, and cheaper.
[23:16] <infinity> The X1 really didn't live up to the "X" series name. :P
[23:16] <sarnold> infinity: thanks :) (I'm in the market for a laptop in the next week or so, good advice.)
[23:16] <tumbleweed> barry: I was vaguely intending to look at it this weekend. But basically, running update-manager in the en_ZA.UTF-8 locale should fail fairly before it does any upgrading
[23:17] <barry> tumbleweed: i only got so far as installing a precise vm and i *think* switching it over to en_ZA.  post anything you find out to bug issue and i can pick it up again on monday.  if you don't solve it of course :)
[23:17] <tumbleweed> barry: because the locale was modified in precise to use a non-breaking space as a thousands separator, and we are treating it as ascii
[23:17] <infinity> sarnold: Generally, if you feel the pricepoints are reasonable, you should just still with the X200 series and T400 series, IMO.
[23:17] <xnox> tumbleweed: use proper english. -> wontfix.
[23:17]  * xnox hides =)
[23:18] <tumbleweed> xnox: we use proper english. Not that en_US nonsense
[23:18]  * xnox meh
[23:18] <infinity> sarnold: Some of the cheaper Thinkpads are decent machines, but the X2xx and T4xx tend to never disappoint, and it then just comes down to size/screen/battery tradeoffs between the two.
[23:18] <barry> tumbleweed, xnox what colour is your authorisation?
[23:18] <tumbleweed> :)
[23:19] <sarnold> infinity: thanks! I'd been looking only in the T* range, but felt way out of my league; last time around (eight years ago?) it felt simpler than this. :)
[23:19] <tumbleweed> barry: it's pretty much solved - need to write a patch for python-apt and the release upgrader
[23:34] <barry> tumbleweed: cool
[23:43] <soniah> I'm looking for sponsorship of lp:~sonia/ubuntu/quantal/vim-scripts/fix-for-31204
[23:44] <xnox> soniah: it's in the queue http://reports.qa.ubuntu.com/reports/sponsoring/
[23:45] <xnox> soniah: i'm sure vim lovers will sponsor that quickly though.
[23:45]  * xnox is emacs user =)
[23:47] <soniah> thanks xnox. I use both; I thought I'd start with something small :-)
[23:57] <ScottK> soniah: For changes inside the debian dir, you don't use a patch.  Just make the change directly.  Also you added exuberant-ctags, aspell, and ispell to Suggests, but don't mention it in debian/changelog (which should be a record of all changes and particularly why).