[00:17] <robert_ancell> infinity, gentle nudge.. :)
[00:22] <infinity> robert_ancell: OH MY GOD GET OFF MY BACK.
[00:22] <infinity> robert_ancell: Wait, what was the nudge about? :)
[00:22] <infinity> robert_ancell: Oh, right.  New package.  Let me poke it.
[00:23] <robert_ancell> infinity, thanks!
[00:23] <infinity> robert_ancell: Remind me which one?
[00:23] <robert_ancell> infinity, libpwquality, bug 1011361
[00:24] <infinity> Seriously, someone reinvted this wheel?
[00:24] <infinity> reinvented, too.
[00:24] <robert_ancell> yep
[00:24] <infinity> Is it insanely more awesome than cracklib somehow?
[00:25] <infinity> Anyhow.  My value judgements about people reinventing wheels don't matter for NEW reviews.  Let me look at the actual packaging. :P
[00:26] <infinity> W: libpwquality source: package-needs-versioned-debhelper-build-depends 9
[00:27] <infinity> robert_ancell: The above seems to make some sense, since your debian/compat is 9.
[00:28] <robert_ancell> infinity, oh, I didn't see that warning
[00:29] <infinity> robert_ancell: To be fair, your build-dep (8.1.3~) is when compat 9 was introduced, but it was experimental, and changed every second day.
[00:29] <infinity> Minor nitpick, anyway.
[00:30] <robert_ancell> infinity, I copied it off another package
[00:31] <infinity> ;)
[00:31] <robert_ancell> infinity, I've fixed that in the branch, resubmit or just upload next time?:
[00:31] <infinity> robert_ancell: Next time is fine.
[00:31] <infinity> robert_ancell: I have a minor nit with upstream that their dual license doesn't specify WHICH GPL.
[00:32] <infinity> robert_ancell: And while I'm betting they meant 2+, I could totally dig up a pre-1.0 draft and use it!
[00:32] <robert_ancell> infinity, yes, they are unclear, but I did find somewhere that indicated it was 2+
[00:32] <infinity> Well, they include 2, which is a fair hint that it's either "just 2" or "2+".
[00:33] <infinity> Man, dh7+ rules files are so boring to read. :/
[00:34] <infinity> robert_ancell: Your short descriptions are also ridiculously long.
[00:34] <robert_ancell> infinity, yeah, any recommendations?
[00:35] <infinity> Maybe I'm just an old skooler who likes "package - short_desc" to fit on an 80char terminal.
[00:35] <infinity> s/and generating random passwords/and generation/ would help a bit.
[00:35] <robert_ancell> the "(development files)" suffix is a bit of a killer, but that seems pretty standard
[00:37] <robert_ancell> ok, fixed that for next release
[00:37] <infinity> robert_ancell: It's also perfectly reasonable to not have the word "library" in the short description of every lib* package in the archive. ;)
[00:37] <robert_ancell> it seemed to be the convention
[00:37] <infinity> "password quality checking and generation" would be enough for the lib bits, IMO.
[00:37] <robert_ancell> ok, will do
[00:38] <infinity> But yeah.  None of this matters terribly.  I just like to be able to read things. ;)
[00:39] <infinity> robert_ancell: The million dollar question... Will GNOME be depending on the python module for this?
[00:39] <infinity> robert_ancell: And if so, when will it be py3?
[00:39] <robert_ancell> no
[00:40] <infinity> Alright, I like no.
[00:40] <robert_ancell> I think technically yes, but no python programs access it
[00:40] <infinity> Well, "technically yes" is bad if it's on the CD. :P
[00:41] <infinity> Cause we're trying to ditch python2.
[00:41] <robert_ancell> yeah, so no package in the archive will depend on it, and dont expect that to change
[00:42] <infinity> Kay. If you discover that it supports py3, please do build the module. :)
[00:42] <robert_ancell> ok
[00:42] <infinity> Also, uscan tells me there's a new upstream for you to merge!
[00:42] <infinity> Other than that, I'm happy.  Accepting it.
[00:42] <robert_ancell> yay, cheers!
[00:43] <infinity> robert_ancell: It's entirely possible this needs zero porting to be a happy py3 camper.
[00:43] <robert_ancell> infinity, patches welcome :)
[00:44] <infinity> robert_ancell: I'm the wrong person to ask about python patches. ;)
[00:44] <TheMuso> heh
[00:44] <infinity> barry: Care to have a 5-second look at libpwquality and, in your expert opinion, tell us if it's just a matter of a debian/control stanza and a quick change to rules to make it spit out a useful py3 module?
[00:45] <barry> infinity: sure.  i lied about eod :)
[00:45] <infinity> robert_ancell: Waaaaaitasec.  I just noticed the build-dep.  This is all just a super fancy wrapper around cracklib? :)
[00:46] <infinity> robert_ancell: Somehow, that makes me feel a bit better about it.
[00:46] <robert_ancell> yeah cracklib+a few more functions
[00:46] <infinity> Maybe this can replace pam_cracklib on my machines some day, if it's extra fancier.
[00:47] <TheMuso> Cracklib probably wrapped in GObject.
[00:48]  * TheMuso hasn't looked atht elib so is assuming since its a GNOME lib.
[00:48] <infinity> robert_ancell: If this is going to be a GNOME dep, do you have an MIR for it somewhere too?
[00:48] <ScottK> SpamapS: I don't see this python-qt4 SRU you uploaded for Lucid.  If the branch diff in the bug represents what you uploaded, it's not going to solve the problem.  Where can I find the package?
[00:48] <infinity> TheMuso: It has no external dependencies other than cracklib, so I'm guessing not.
[00:48] <infinity> TheMuso: GObject kinda requires glib, right?
[00:49] <TheMuso> Coudl a C++/gcc 4.7 guru please have a look at this FTBFS, and tell me what I should be looking to fix? http://paste.ubuntu.com/1053528/
[00:50] <TheMuso> infinity: Yet, the glib package contains libgobject.
[00:50] <TheMuso> s/yetyes/
[00:50] <TheMuso> gah my typing sucks this morning.
[00:50] <infinity> TheMuso: Use a c++ compiler?
[00:51] <infinity> TheMuso: (Or reorder your linking arguments)
[00:51] <TheMuso> Hrm why did I think it was C++? heh ok, thanks.
[00:51] <TheMuso> Yay, waf.
[00:51] <infinity> TheMuso: It is C++.  But the package is doing a manual "cc -lstdc++"
[00:52] <infinity> Cause it thinks it's clever.
[00:52] <TheMuso> Ah ok.
[00:52] <infinity> For reasons I can't fathom.
[00:52] <TheMuso> Me neither.
[00:53] <infinity> Anyhow, the real problem is your -l args should all be at the end.
[00:54] <TheMuso> Yep ok, time to learn about the joys of waf.
[00:54] <infinity> Which may require mangling some configure or Makefile to put $LIBS or $LD_LIBS or similar at the end of the line.
[00:59] <infinity> robert_ancell: So, I really should have test-built that before I accepted it.
[00:59] <robert_ancell> infinity, will do the mir next
[01:00] <robert_ancell> hmm, which build dep did i miss
[01:00] <robert_ancell> libpam...
[01:00] <infinity> robert_ancell: At least libpam-dev.  Passing it through sbuild for another go now.
[01:00] <robert_ancell> infinity, no worry, i can update directly now right
[01:00] <infinity> robert_ancell: Yup.
[01:01] <infinity> robert_ancell: Let me let this build finish. :)
[01:01] <robert_ancell> it's cheaper to waste server time than people time
[01:01] <infinity> It's building on a server.
[01:06] <infinity> robert_ancell: Yeah, libpam-dev makes it happy.
[01:07] <infinity> robert_ancell: Plus, I stepped out for a smoke.  So, no wasted time. :P
[01:08] <infinity> robert_ancell: So, this is your big chance to rev to the new upstream, fix debian/control, and then ignore the package forever!
[01:09] <infinity> robert_ancell: (I wouldn't advertsise the last bit in your MIR)
[01:57] <robert_ancell> infinity, hah, we never forget about packages on the cd http://people.canonical.com/~platform/desktop/desktop.html
[01:58] <robert_ancell> infinity, you may also be interested in http://people.canonical.com/~platform/desktop/boot.html and http://people.canonical.com/~platform/desktop/standard.html - that's the boot and standard seeds being tracked
[01:58] <infinity> robert_ancell: What are the mushroom bugs?
[01:59] <robert_ancell> infinity, I think that means it needs to be sponsored by someone with main privileges
[02:00] <robert_ancell> I did it ages ago, and I can't quite remember but the source seems to confirm that
[02:00] <infinity> robert_ancell: Also, I'm going to assume by your "we never forget" statement that there will be an upload soon that builds. :P
[02:00] <robert_ancell> infinity, yep
[02:02] <infinity> robert_ancell: Oh, right.  The mushroom was the logo for the main sponsors group before it was abolished for a generic ubuntu sponsors one.
[02:03] <infinity> robert_ancell: (Or maybe the mushroom was universe and the star was main, I don't remember now)
[03:33] <vibhav> bryceh: ping
[03:44] <twb> Apparently I'm banned from #ubuntu-server.  Anybody know how I'd find out *why*?
[03:49] <ajmitch> I think #ubuntu-irc is the place to ask
[03:50] <vibhav> !ban > twb
[03:59] <twb> Thanks.
[04:31] <pitti> Good morning
[04:34] <pitti> cjwatson: ah, so adt-ubiquity is back green
[04:50] <infinity> ...
[04:50] <infinity> robert_ancell: Dude.  Another libpoppler ABI?  apw is going to hurt you.
[04:51] <infinity> robert_ancell: Does this one introduce more incompatible API changes again that require porting, or can we just rebuild all the stuff Andy ported to lib25?
[04:52] <robert_ancell>  infinity, yeah, they love their abi changes
[04:53] <infinity> robert_ancell: Seriously, we just spent the last two weeks porting the world to the last one, I really hope this one's just an ABI bump but not a massive API break again.
[04:54] <infinity> I guess we'll find out. :P
[04:54] <robert_ancell> infinity, evince built fine with it, haven't checked in too much detail
[04:54] <infinity> robert_ancell: That's somewhat comforting.
[05:00] <robert_ancell> infinity, btw, is there a way to make the rebuilds against the new poppler wait correctly, or do you just wait until it hits the mirrors?
[05:01] <infinity> robert_ancell: I just wait until it's published.
[05:02] <infinity> robert_ancell: Were you going to do all the 25->26 rebuilds for us?
[05:02] <robert_ancell> infinity, yup, working on them now
[05:02] <infinity> robert_ancell: (There were still some 19->25 bits that need porting, if I recall)
[05:03] <infinity> Oh, might just be libreoffice now.
[05:06] <robert_ancell> why is publishing sooo slooow
[05:07] <infinity> robert_ancell: Because you're impatient?
[05:07] <robert_ancell> I sure am
[05:08] <infinity> robert_ancell: You'll be happy to know that the last publisher ran overtime, so it's not going to run until :33 :P
[05:08] <infinity> robert_ancell: Which means your binaries won't land for another hour or so.
[05:09] <robert_ancell> ok, that's not just impatience.  That's ridiculously slow
[05:09] <infinity> I only accepted them just before the hour.
[05:09] <infinity> Just pretend I did it a few minutes later and missed the :03 run. :P
[05:12] <infinity> robert_ancell: Oh, it's also that time of day when we slow down ftpmaster for some other cronjobs.  THat would be why it's sad.  I/O contention.
[05:35] <infinity> robert_ancell: I'm watching publisher log files, I'll let you know when cocoplum's good to go.
[05:35] <infinity> robert_ancell: (Mirrors don't matter, since buildds pull directly from ftpmaster)
[05:36] <robert_ancell> infinity, ta.  I'm finishing up now but I'll drop in later and upload when it's ready.  No problems so far in cups-filters, inkscape, calibre, xpdf, gdal
[05:37] <infinity> robert_ancell: Should be less than 30m, if you're around then.
[05:38] <infinity> robert_ancell: Alternately, you can just queue 'em up, sign them all, and then "sleep 3600 && dput *changes" ;)
[05:38] <robert_ancell> infinity, nice idea - I'm totally going to do that
[05:40] <infinity> Oh dear lord, there was a libreoffice upload in that.
[05:40]  * infinity head->desk.
[05:40] <infinity> Poor publisher.
[05:40] <StevenK> Poor cocoplum
[05:40] <StevenK> Poor buildds
[05:40] <infinity> robert_ancell: Make that 7200. :P
[05:41] <infinity> StevenK: cocoplum, in this case.  Dealing with those translations tarballs seems to make the publisher have a sad.
[05:41] <StevenK> Just one?
[05:41] <infinity> It's been grinding for 8 minutes on libreoffice_3.5.4-0ubuntu1_powerpc_translations.tar.gz
[05:42] <StevenK> Oh, a binary upload. Right.
[05:43] <infinity> Yeah.  I have no idea what, exactly, we're doing there that's so hard, but couldn't that be farmed off to appservers?
[05:43] <StevenK> No idea about translation tarballs, myself.
[05:44] <infinity> Yeah, me neither.  I've never peered into that black box.
[05:44] <infinity> But it's pretty rough.
[05:44] <infinity> When we get a kde langpack upload, it can be followed with a 6 hour publisher run while it imports them all.
[05:44] <infinity> Which is speeeeecial.
[05:52] <TheMuso> About as special as all the kde-l10n packages poluting changes every so often? :p
[05:58] <infinity> robert_ancell: If you're still around, you might want to skip out on the clever delayed upload idea.  ftpmaster is pitching a fit.
[06:03] <infinity> And 28 minutes later, the libreoffice translations are finally done.  Wow.
[06:27] <infinity> robert_ancell: Okay, I retract my warning about delayed uploads, everything's published to ftpmaster, fire when ready.
[06:57] <dholbach> good morning
[07:17] <alkisg> Hello, keyboard layout switching is broken for Greek (us,gr) from 12.04 on except for the first user that did the installation, and I'm trying to pinpoint the problem in order to file a better bug report, may I ask a few questions about it?
[07:17] <alkisg> For the user that everything works OK, in /var/lib/AccountsService/users/alkisg, I have: XKeyboardLayouts=us;gr;
[07:17] <alkisg> For all the other users, I have: XKeyboardLayouts=
[07:17] <alkisg> The result is that there's only (en) in lightdm when I select the other users, and when they login, there's no keyboard switching applet.
[07:17] <alkisg> In /etc/default/keyboard, I have: XKBLAYOUT="us,gr"
[07:17] <alkisg> So my question is, should accountsservice be returning "us,gr" for newly created users, or returning "unset" is fine, and it's lightdm's fault that it doesn't take the system-wide defaults into account?
[07:24] <RAOF> alkisg: I guess that accountsservice should be returning "us,gr"; starting off with the system-wide defaults would seem to be the most appropriate behaviour.
[07:24] <alkisg> RAOF: thank you, so I'll file it against accountservice
[07:37] <AnAnt> Hello, could someone sponsor LP #1014705 ?
[07:42]  * alkisg filed LP bug #1016409, thanks again
[07:58] <melodie_> hello
[08:01] <melodie_> at the moment it is still a bit difficult to find information related to configuring the launcher panel. I need to have several launchers fixed, so that the users can't remove them at all. For this purpose I put a copy of the desktop files which start them into the ~/.local/share/applications directory. I also configured the order for them in the dconf-editor at the laucher line, then I put a "chattr +i" on the ~/.config/dconf
[08:01] <melodie_> but it's not yet perfect:
[08:02] <melodie_> I can still remove icons from the launcher, however when I close/reopen the session the launchers are there again.
[08:02] <melodie_> is there any known way to stick them so that they can't be removed, even during the session ?
[08:02] <melodie_> or any way I could try ?
[08:07] <melodie_> I'll ask again later and will be back
[08:07] <melodie_> have to go for a moment
[09:36] <mpt> How can I check whether -proposed is NotAutomatic like -backports is?
[09:39] <Laney> look in its Release file on a mirror
[09:39] <Laney> but, it isn't :-)
[09:39] <cjwatson> $ wget -q -O- http://archive.ubuntu.com/ubuntu/dists/precise-backports/Release | grep NotAutomatic
[09:39] <cjwatson> $ wget -q -O- http://archive.ubuntu.com/ubuntu/dists/precise-proposed/Release | grep NotAutomatic
[09:40] <cjwatson> NotAutomatic: yes
[09:40] <cjwatson> $
[09:41] <mpt> cjwatson, that's odd, I get the opposite result
[09:41] <mpt> (but thanks)
[09:46] <mpt> cjwatson, according to <https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-backports-ui> they both should be NotAutomatic. Where would I report that bug? <https://launchpad.net/ubuntu-seeds>?
[09:47] <mpt> Hm, no, ubuntu-seeds isn't configured to use LP for bugs
[09:47] <mpt> ah, <https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta>
[09:52] <mpt> reported bug 1016454
[09:55] <tumbleweed> mpt: Laney raised it on ubuntu-release a while back too https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001380.html
[09:55] <Laney> I think he is talking about post-release
[09:55] <tumbleweed> oh
[09:55] <tumbleweed> precise, duh
[09:56] <Laney> that should be discussed with the SRU and archive teams, IMHO
[09:56] <Laney> and should be coupled with a way of notifying users that they might want to get something from there
[09:57] <tumbleweed> yeah, not usually something we'd change post-release
[09:58] <mpt> Laney, yes, I'm sketching out a "Contributor Console" (working title) that would let people turn on -proposed; choose which -proposed updates to install; report a bug on something by clicking on it; get the code for something by clicking on it; etc
[09:59] <Laney> mpt: I was thinking something in whoopsie/apport (or whichever component it is) that can recommend you try a particular SRU. I think this was discussed at UDS.
[09:59] <Laney> anyway I would say that this other work needs to be done first, before we could think about turning this on for proposed
[10:00] <Laney> (and of course bug #888665 [this one, again] would need to be fixed)
[10:00] <mpt> Laney, if you mean the "An update is available to fix the problem you just had", I'm considering that as separate for now
[10:01] <Laney> I do mean that, and it seems quite tied to turning that flag on for proposed to me.
[10:03] <mpt> How?
[10:03] <mpt> It seems to me that would be setting the default expectation that every Ubuntu user is willing to be a beta tester.
[10:03] <Laney> if they turn on proposed, then that is what they are saying
[10:03] <mpt> But the fact that -proposed is off by default in the first place suggests the opposite.
[10:04] <Laney> otherwise they turn it on and nothing happens
[10:04] <Laney> if we had NotAutomatic and this other way of them finding relevant packages then we should turn it on by default, yes.
[10:04] <mpt> Yes, but now the place for turning it on would be the same place where you choose which -proposed update(s) you want to install
[10:04] <cjwatson> mpt: Launchpad itself controls whether a suite is NotAutomatic or not.
[10:05] <cjwatson>         if (pocket == PackagePublishingPocket.BACKPORTS and
[10:05] <cjwatson>             distroseries.backports_not_automatic):
[10:05] <cjwatson>             release_file["NotAutomatic"] = "yes"
[10:05] <cjwatson>             release_file["ButAutomaticUpgrades"] = "yes"
[10:05] <mpt> cjwatson, fixed, thanks
[10:05] <cjwatson> Note the pleasing absence of abject hardcoding there
[10:06] <mpt> yesssssss
[10:06] <cjwatson> (No DB column for pockets, which doesn't help)
[10:06] <cjwatson> Er s/column/table/
[10:53] <AnAnt> Hello, could someone sponsor LP #1014705 ?
[10:54] <Laney> Not sure it works like that for partner.
[10:54] <AnAnt> Laney: who should I ask ?
[10:54] <Laney> mvo may know
[10:55] <Laney> but he isn't here. hum.
[10:55] <cjwatson> You know, it's not actually that often that I notice hardware having got lots faster over the last ten years, because software does kind of tend to keep pace with it.  But I'm sure I remember being pleased with a new laptop on the grounds that it could build groff in 40 minutes or something like that, and my current laptop takes about 4 ...
[11:00] <nuketro0p3r> I recently migrated from windows to ubuntu and I want to contribute to the OS. Where do I begin o.O ?
[11:01] <nuketro0p3r> I want to contribute code .
[11:01] <mpt> nuketro0p3r, https://wiki.ubuntu.com/ContributeToUbuntu has a long list of ways
[11:01] <mpt> nuketro0p3r, if you want to contribute code, one way to start is to find a bug that bothers you, or a particular package where you'd like to fix something small
[11:02] <nuketro0p3r> Like empathy?
[11:02] <mpt> sure
[11:03] <mpt> nuketro0p3r, https://bugs.launchpad.net/ubuntu/+source/empathy is the list of known bugs for empathy
[11:03] <nuketro0p3r> tnx ^_^
[11:03] <mpt> you're welcome
[11:03] <shnatsel> pitti: hello! I'm the apport-tackling guy from elementary :) I'm getting "W:Failed to fetch http://ddebs.ubuntu.com/dists/oneiric/universe/binary-amd64/Packages  404  Not Found" error every time I'm trying to retrace something. My sandbox config is at https://code.launchpad.net/~elementary-os/elementaryos/apport-retrace-sandbox/ Is that a known bug or I just suddenly started doing something terribly wrong?
[11:04] <pitti> hey shnatsel; sure, I haven't forgotten you :)
[11:04] <pitti> shnatsel: we had to drop universe and multiverse for oneiric on ddebs.u.c.
[11:04] <pitti> so please remove those two components from your config
[11:04] <pitti> (running out of space)
[11:07] <shnatsel> pitti: ah, I see. I thought I didn't use Oneiric, but I've grepped now just to be sure and it's there. I'll remove it, thanks!
[11:07] <pitti> yw
[11:15] <mpt> TheMuso (or anyone else): Would it be feasible to have a program where someone can click a button, then use a pointing device to click on a string in any *other* program, and the accessibility layer collects that string? (Assuming that it's in a known toolkit, e.g. GTK, Qt, XUL, Nux.)
[11:16] <mpt> TheMuso, the use case is "I see here a string that's badly translated -- I want to easily find which package it is so that I can fix the translation."
[11:16] <mpt> (And which string in that package.)
[11:18] <xnox> mpt: one caveat is that strings have substituition variables in them, and as far as I know those are computed in the code before displaying. Also plugins can hook into programs leading to false detection of the package.
[11:18] <mpt> true
[11:18] <xnox> many translations come from a lang-pack separate to the software package (all of main / most things on the cd)
[11:19] <xnox> i'm guessing that a fuzzy search in rosseta (launchpad translations) with some hints as to which package this might be and whether it is / isn't in main
[11:20] <xnox> can probably get you to the more correct place, e.g. where the string actually needs to be fixed
[11:20] <shnatsel> mpt: I'd assume that's possible in GTK2 with parasite module. It was not updated for GTK3 AFAIK.
[11:20] <mpt> I often find a Google "site:translations.launchpad.net" search useful in telling which package a string is in
[11:20] <xnox> mpt: what is the reason behind this question: file a bug about the package or correct/propose a translation as a contributor
[11:21] <shnatsel> mpt: local .mo files can be used for determining the package. Process name of the clicked window also can be tracked down to a package easily.
[11:21] <mpt> shnatsel, yes, the missing step from that is reading the text you clicked on
[11:22] <xnox> mpt: note that when my american friend uses my laptop and the locale is set to en_GB.UTF-8 the translations will be 'wrong' to that user due to wrong locale.
[11:22] <dholbach> iulian, great to see the RMB back in action :-D
[11:22] <xnox> similar problems with brazillian portugese, dutch, austrian german, etc...
[11:23] <mpt> xnox, then your friend shouldn't try to correct the text...
[11:23] <xnox> =)
[11:24] <cjwatson> process name> To some extent; however consider text that is generated by some backend process and displayed by a frontend.
[11:24] <mpt> e.g. aptdaemon
[11:24] <cjwatson> For example, ubiquity's package download progress messages are actually generated by apt, but you aren't going to be able to determine that at the toolkit level.
[11:25] <cjwatson> (And they're substituted too; I can't think of a way to automatically track down the source, without inventing a new mechanism for tagging strings with the unsubstituted text or something, and making sure that mechanism is passed through all sorts of layers ...)
[11:25] <cjwatson> But maybe a partial solution would be better than nothing, even so
[11:28] <iulian> dholbach: Yup.
[11:51] <glatzor> mpt, you want hunt strings in libapt er even curl?
[11:51] <glatzor> want to
[11:54] <shnatsel> glatzor: well, from UX designer standpoint the string should be fixed regardless of its origin :)
[12:09] <jibel> on 2 of my systems running Quantal, usb keyboard doesn't work in grub. One system is a Mac mini, the other a generic PC with a BIOS and keyboard works fine before grub starts. Should I file a bug against grub, what info do you need ?
[12:12] <cjwatson> Probably the known bug that it doesn't have EHCI support.
[12:12] <cjwatson> (I don't know the number offhand.  IIRC it's fixed upstream.)
[12:17] <vibhav> xnox: ping
[12:17] <xnox> vibhav: pong
[12:18] <vibhav> xnox: Are you working on https://bugs.launchpad.net/ubuntu/+source/avogadro/+bug/1016433 or should I try a merge?
[12:18] <xnox> vibhav: nope, not working on it. Merging it would be a great help!
[12:19] <vibhav> thanks
[12:19] <xnox> yofel_: are we ok stealing your merge of avogadro ^^^
[12:19] <xnox> ?
[12:19] <vibhav> Cool, the ubuntu delta patches are small too. Can be done easily
[12:21] <xnox> vibhav: any of these: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=boost1.49 would be a great help in debian or ubuntu
[12:21] <xnox> to finish off: http://people.canonical.com/~ubuntu-archive/transitions/boost1.49.html
[13:02] <mpt> glatzor, ideally, but I realize that's probably impractical
[13:39] <highvoltage> the new square radio buttons look like tick boxes :-/
[13:39] <mpt> New square radio buttons?
[13:39]  * highvoltage gets a screenshot
[13:40] <mpt> What do checkboxes look like, then?
[13:41] <vibhav> something other than the new square radio boxes?
[13:41] <mpt> (For screenshot purposes, Time & Date settings includes both)
[13:42] <vibhav> xnox: Most of the changes are in debian, just the architecture is changed to i386, amd64 and powerpc FYI
[13:43] <highvoltage> mpt: http://irc.jonathancarter.org/files/ubuntu/square-radio-buttons.png
[13:43] <xnox> highvoltage: yeah I hate them too
[13:43] <mpt> wtf
[13:43] <highvoltage> that's what she said
[13:43]  * mpt strolls over to chat with Cimi
[13:44] <vibhav> highvoltage: Thats alien :\
[13:45] <xnox> mpt: i think there is a serious bug with the theming engine currently
[13:45] <xnox> mpt: see bug 1015497
[13:46] <LordOfTime> is there a mailing list for the developers?
[13:46] <LordOfTime> (there's a package maintained by "Ubuntu Developers" and I'd like them to take special attention to it)
[13:46] <xnox> mpt: maybe you want to file another one as well, about e.g. other theming weirdness that you have been noticing.
[13:46] <xnox> LordOfTime: all packages are maintained by Ubuntu Developers in the whole archive
[13:46] <LordOfTime> xnox:  any central mailing list?
[13:46] <xnox> LordOfTime: file a bug on launchpad against the correct package.
[13:47] <LordOfTime> xnox: its *about* other bugs filed
[13:47] <LordOfTime> i.e.
[13:47] <highvoltage> LordOfTime: yep, it's the first result when you google 'ubuntu-devel mailing list': https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[13:47] <LordOfTime> there's a TON of crash bugs which refer to the 'cairo' libs
[13:47] <xnox> that will get the attention of the correct people who are responsible for said package.
[13:48] <highvoltage> LordOfTime: but if you want to report bugs then https://help.ubuntu.com/community/ReportingBugs may be of more use
[13:48] <LordOfTime> xnox: if a bug crashes on some 'cairo' lib, then, would you refile *all* those crash bugs against 'cairo'?
[13:48] <xnox> LordOfTime: yes. and we track those in the crash database errors.ubuntu.com those are automatically filed by apport
[13:48] <LordOfTime> highvoltage: as an FYI: I'm on Bug Squad and BugControl
[13:48] <highvoltage> LordOfTime: ok :)
[13:48] <LordOfTime> i'm not *reporting* a bug, i'm trying to get the people who maintain the libs to check their package in each of these use cases
[13:48] <LordOfTime> *because* of the influx of crash bugs relating to the cairo libs
[13:48] <mpt> highvoltage, xnox: So the short answer is, it's Red Hat's fault
[13:49] <xnox> LordOfTime: we don't refile, best mark duplicate of the master cairo bug, or get in touch to write a bug pattern for the launchpad bug bot to do it.
[13:49] <ogra_> LordOfTime, raise the bug proirity and ask on the bug how the status is ... thats way more effective than spamming a mailing list about bugs
[13:49] <mpt> highvoltage, xnox: They have changed GTK to make the radio button radius data private, so that theming engines (like light-themes) can't change it. Supposedly themes should use CSS instead, but there are things CSS can't do yet.
[13:49] <LordOfTime> xnox: assuming there is a master bug (there isnt one)
[13:49] <LordOfTime> i'll check on this one though
[13:50] <ogra_> make one ... you are in bug control :)
[13:50] <LordOfTime> :P
[13:50] <xnox> ogra_: LordOfTime: and add bug-pattern-needed tag?
[13:51] <mpt> highvoltage, xnox: The theme will look like that for a few more weeks at least.
[13:51] <ogra_> sounds right
[13:51] <highvoltage> mpt: aah. interesting. for a moment I was scared you were going to say they moved gtk to systemd or something
[13:51]  * xnox can't remember the tag where bug pattern is needed.
[13:51] <highvoltage> mpt: ok cool. I'm just glad it's not intentional :)
[13:51] <xnox> mpt: is there a bug about the radius?
[13:52] <mpt> xnox, it is a bug.
[13:52] <xnox> mpt: launchpad bug # ?
[13:52] <mpt> no idea, sorry
[13:56] <larsduesing> Hi together
[13:57] <mpt> Debconf question: I'm reading <http://www.fifi.org/doc/debconf-doc/tutorial.html> and it's not clear whether a Debconf prompt can appear at removal/purge time, or just during install/update. Anyone know?
[13:57] <larsduesing> could anybody please nominate LP: #1007408 for precise?
[13:57] <larsduesing> https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408
[13:58] <tumbleweed> larsduesing: nominated
[13:58] <larsduesing> thanks tumbleweed :)
[13:58] <larsduesing> patch is on the way
[14:00] <larsduesing> oh.. btw... https://wiki.ubuntu.com/StableReleaseUpdates says I should make a debdiff for precise - would it not be more simple if I do a bzr-branch?
[14:01] <larsduesing> (as I do not have any upload-rights... )
[14:01] <cjwatson> If you like, sure
[14:01] <mpt> ... I guess it's possible for a Debconf prompt to come up if removal fails <http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails>
[14:02] <larsduesing> cjwatson: ok, thanks.
[14:23] <larsduesing> ahem, cjwatson sorry, question: "Propose branch for merging" should I use the correct "precise-proposed" or "precise"?
[14:23] <larsduesing> (for a SRU)
[14:24] <xnox> larsduesing: if there is precise-proposed branch target that, if not target branch precise
[14:24] <xnox> changelog should say precise-proposed
[14:24] <larsduesing> xnox: changelog is so
[14:24] <xnox> many sponsors prefer debdiffs for SRU
[14:24] <larsduesing> oh
[14:24] <xnox> because precise, precise-updates and precise-proposed can be easily superseeded by a security update
[14:25] <xnox> and it's easier to check debdiff and re-apply debdiff in those cases
[14:25] <larsduesing> ok, doing debdiff...
[14:25] <xnox> and merge proposals generate a lot of .pc changes (if you add a patch) which is very painful to review for an SRU
[14:26] <cjwatson> If you already have a branch you can just attach bzr diff output if you like
[14:26] <cjwatson> Rather than bothering with generating a debdiff as such.  The exact patch-a-like format really doesn't matter much.
[14:26] <xnox> larsduesing: I do $ bzr diff -rtag:1.0.1-1 | filterdiff -x ".pc*"
[14:26] <xnox> where 1.0.1-1 is version in e.g. precise
[14:26] <larsduesing> this was the reason I asked about bzr vs. diff :)
[14:26] <xnox> to get the debdiff
[14:26] <larsduesing> ok
[14:27] <larsduesing> oh, cool... no more creating .dsc and such
[14:27] <xnox> larsduesing: well I presume you did create .dsc and did clean builds and tested the debs, right? =)
[14:28] <larsduesing> xnox: YES... :) for quantal
[14:28] <xnox> it's just that you use vcs tools to create the diff ;-)
[14:28] <xnox> larsduesing: but you should do the same tests for precise, if you are doing an SRU!
[14:28] <xnox> ;-)
[14:28] <larsduesing> xnox: *hiding*
[14:28] <larsduesing> :)
[14:29] <xnox> stuff can FTBFS in precise, yet building fine in quantal and vice versa =)
[14:29] <larsduesing> give me a sec
[14:29] <larsduesing> :)
[14:30] <larsduesing> done
[14:30] <larsduesing> (btw, FTBFS cannot happen, if I only change the upstart-script in debian/ )
[14:31] <larsduesing> but, I know why I should do it
[14:32] <xnox> slangasek: i am suspecting that autofs5 merge is expecting newer nfs-utils, as the mount.nfs -V call prints the version string in debian's 1.2.6 but not in ubuntu's 1.2.5-3ubuntu3. I can disable that call in autofs, until nfs-tools are merged
[14:33] <xnox> this is where the extra forks come in in autofs breaking it's current upstart job
[14:33] <xnox> unless you are still asleep after posting emails all night long =)
[14:34] <vibhav> bryceh: ping
[14:34] <larsduesing> ok... I should now search a sponsor :P
[14:35] <larsduesing> any volunteer?
[14:35] <vibhav> larsduesing: Ask the patch pilots
[14:36] <vibhav> * pilot(s) even
[14:36] <larsduesing> oh, pitti Hallo :) Would you please be so kind and sponsor my sru: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408
[14:37] <larsduesing> thanks vibhav
[14:37] <vibhav> np
[14:37] <larsduesing> (I should get accustomed to all this here... )
[14:37] <vibhav> larsduesing: piiti's busy most of the time, you might want to suscribe ubuntu-sponsors too
[14:38] <larsduesing> I know, did already
[14:39] <slangasek> xnox: so which version of nfs-utils do we need? 1.2.6?
[14:40] <larsduesing> vibhav: oh, should I add SRU- impact, testcase and regression to the description? thanks :)
[14:41] <vibhav> np
[14:42] <pitti> larsduesing: may I refer you to today's patch pilots? (SpamapS and cjwatson are on the calendar)
[14:44]  * pitti waves goodbye, have a nice weekend everyone
[14:45] <larsduesing> oeh
[14:45] <larsduesing> pitti: you too
[14:46] <larsduesing> so topic is wrong, pitti, SpamapS and cjwatson :)
[14:46] <xnox> slangasek: yeap.
[14:47] <xnox> pitti: can you do @pilot out ?
[14:47] <xnox> larsduesing: yes you should all the mandatory sections for an SRU
[14:47] <larsduesing> SpamapS or cjwatson: would you please be so kind and sponsor my sru https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 ? thans
[14:48] <larsduesing> xnox: I did, but not in bug description
[14:48] <larsduesing> but in a comment
[14:50] <xnox> slangasek: I think I will upload new autofs, but with workaround to start daemon in foreground. then nfs-tools can wait & I need to patch autofs to support nfs-tools correctly anyway as that introduces extra forks which confuse upstart.
[14:50] <slangasek> xnox: I can merge nfs-utils today
[14:50]  * mpt wonders whether a debconf string prompt accepts multi-line input, or just single-line
[14:51] <xnox> slangasek: ok. then I will see if I can move that fork later without breaking all of it.
[14:57] <cjwatson> Sorry, I'm going to have to shift my patch piloting for today
[14:57] <xnox> slangasek: actually it only wants 1.1.1 . My new question is, why does `mount.nfs -V` on ubuntu does not print version string?
[14:58] <slangasek> xnox: ah
[14:59] <xnox> yet it does on Debian....
[14:59] <slangasek> xnox: good question
[15:01] <xnox> slangasek: furthermore, I just want to patch that code out of autofs because (a) 1.1.1 is acient and pre-dates hardy (b) 2.6.22 kernel is acient as well and pre-dates hardy
[15:01] <xnox> and I can avoid fork
[15:01] <slangasek> xnox: ok, sounds good to me
[15:02] <vibhav> Is it right to call an ubuntu delta a fork?
[15:02] <vibhav> of the package
[15:02] <vibhav> in Debian
[15:03] <slangasek> vibhav: "fork" implies the divergence is long-term, with no (or minimal) fixes flowing back between the two branches
[15:03]  * xnox used word fork, as in UNIX process fork which is confusing an init system
[15:03] <slangasek> but yes, xnox means fork() :)
[15:03] <SpamapS> larsduesing: I don't know if I'll get to it today, but I'll look at it soon. Sponsorship queue is a bit backed up right now.
[15:04] <vibhav> slangasek: ah, got it. thanks
[15:06] <larsduesing> SpamapS: take your time (it's near week-end after all :-) )
[15:08] <xnox> slangasek: and I will file a bug about `mount.nfs -V` not returning a version string =)
[15:08] <slangasek> xnox: sounds good
[15:10] <slangasek> xnox: note that the usage says 'mount.nfs remotetarget dir [-rvVwfnsih]'... if you do 'mount.nfs foo: /bar -V' you get a version string ;P
[15:10] <xnox> wow! https://launchpad.net/~/+upcomingwork
[15:10] <vibhav> xnox: neat trick
[15:10]  * xnox head -> desk
[15:11] <vibhav> xnox: why?
[15:14] <larsduesing> xnox: all clear... So I do not have anything to do? :-)
[15:15] <xnox> larsduesing: what's the bug # ? =)
[15:15] <larsduesing> (what would occur there?)
[15:15] <larsduesing> which bug # ?
[15:15] <xnox> larsduesing: for the SRU
[15:15] <larsduesing> 1007408
[15:15]  * xnox thought you wanted a sponsor
[15:15] <xnox> larsduesing: bug 1007408 will print me a link =)
[15:15] <xnox> tadah!
[15:15] <larsduesing> oh ok... sorry... was about the "upcomingwork"
[15:16] <larsduesing> ah.. LP: #1007408 doesnt work
[15:16] <larsduesing> but bug 1007408
[15:16] <xnox> larsduesing: oh upcomingwork shows bugs & blueprints which you, the logged in user needs to work on.
[15:16] <larsduesing> won't work too...
[15:16] <larsduesing> bug 1007408 is boring *ubottu doesn't like me*
[15:16] <larsduesing> oh..
[15:17] <tumbleweed> meh, need to milestone my blueprints for them to appear in upcomingwork
[15:17] <larsduesing> sorry for spamming
[15:18] <xnox> tumbleweed: it doesn't show, *cough* overdue work....
[15:19] <xnox> larsduesing: i wondering if I should sponsor this into proposed
[15:19]  * xnox ponders
[15:19] <larsduesing> as far as I read, yes...
[15:20] <slangasek> xnox: nfs-utils mount.c has this at the top, so I don't see how this would work any better in debian... http://paste.ubuntu.com/1054411/
[15:20] <larsduesing> "Upload the fixed package to release-proposed with the patch in the bug report, a detailed and user-readable changelog, and no other unrelated changes. Make sure that:"
[15:20] <larsduesing> https://wiki.ubuntu.com/StableReleaseUpdates
[15:21] <xnox> slangasek: is autofs upstream known to be compatible with anything but it's own hand compiled dependencies?
[15:22] <slangasek> xnox: I have no idea; I haven't used autofs in about a decade
[15:22] <xnox> slangasek: that's about right when they did last stable release, so you are fairly up to date ;-)
[15:23] <slangasek> xnox: is autofs 5 not stable yet? :)
[15:25] <xnox> slangasek: if stokachu is still patching it & I am still patching new upstream.....
[15:25] <slangasek> heh
[15:32] <vibhav> slangasek: you there
[15:32] <slangasek> vibhav: me, here?
[15:33] <vibhav> slangasek: Im merging aalib (you have touched it last in ubuntu) from sid, is that fine
[15:34] <zul> pitti: i think i answered your questions in my last email i sent to the tech-board but it needs to be let though the moderated-queue
[15:36] <slangasek> vibhav: yes, certainly
[15:36] <vibhav> thanks
[15:38] <rtg> kenvandine, shall I just let you fix chromium-browser ? I'll go on to something else.
[15:38] <kenvandine> i'd rather not :)
[15:39] <kenvandine> i'll send the changes i have to micahg
[15:39] <rtg> kenvandine, no problem.
[15:42] <stgraber> zul: I've let them through
[15:42] <zul> stgraber: thanks
[15:48] <infinity> Riddell / ScottK: Can either of you tell me if ktp-contact-applet is obsolete (perhaps replaced by ktp-contact-runner?).  It was the only thing not revision bumped for the ktp-common-internals transition, and I'm wondering if it should just be removed.
[15:48] <ScottK> infinity: That's a Riddell question.
[15:50]  * infinity throws a cat at Riddell.
[15:50] <Riddell> infinity: hmm ktp-contact-applet is part of upstream's 0.4, let me investigate
[15:51] <infinity> Riddell: Kay, then the (really nicely-handled otherwise, BTW) transition was just missing an upload, I suspect.
[15:51] <infinity> Riddell: Please fix and/or advise. ;)
[16:29] <AnAnt> Please sponsor LP #1014705
[16:44] <bdmurray> superm1: do you have an idea of how much space dkms needs in /tmp?
[16:44] <bdmurray> I'm looking at bug 1011662
[16:45]  * xnox 0_0
[16:56] <superm1> bdmurray: i think that should depend upon if DKMS packages are using it at all
[17:00] <SpamapS> hmm...
[17:00] <SpamapS> package-import.ubuntu.com doesn't show a juju error, but juju's package branch is out of date in quantal
[17:01] <ScottK> SpamapS: Did you get my ping about your python-qt4 upload for lucid-proposed?
[17:01] <SpamapS> ScottK: probably not. ??
[17:01] <SpamapS> Did I do it wrong? :-P
[17:02] <ScottK> SpamapS: OK.  In the bug you said you were uploading it, but I don't find it.  Please don't upload that package as I posted the relevant bits of the diff in the bug.
[17:02] <SpamapS> ScottK: yeah something wrong with the version
[17:04] <ScottK> OK. Either you can do a revised upload and I'll review it or the reverse.  I agree it's an important bug to fix.
[17:08] <SpamapS> ScottK: hrm, I missed the two features in my first review. I don't know, is that enough to force a cherry pick?
[17:09] <SpamapS> ScottK: this is where I hate having discretion. ;)
[17:09] <ScottK> SpamapS: It's not just that, it's all the doc regeneration and such.
[17:10] <ScottK> If the actual fix weren't obvious, I'd say go for it, but since it is in this case, I think a patch to fix the actual problem is better.
[17:11] <ScottK> The feature changes are small extensions and low risk, so I wouldn't mind those, but SRU are supposed to be minimal.
[17:11] <SpamapS> ScottK: yeah I agree.
[17:11] <SpamapS> ScottK: and the reason I missed the features was that I was filtering the diff aggressively. Exactly the kind of thing I usually refuse to do in SRU review :)
[17:13] <ScottK> I'd prefer you upload and I review if that's OK.
[17:28] <bdmurray> superm1: could you elaborate?
[17:30] <glatzor_> mpt, hopefully apt will get a better error message handling in the next years
[17:31] <glatzor_> mpt, there is also intrest from upstream, since raised errors are block boxes internally too
[17:31] <glatzor_> black boxes
[17:33] <adam_g> ice
[17:42] <slangasek> xnox: fwiw, the mount.nfs -V looks to be broken in 1.2.5 and fixed in 1.2.6
[17:43] <bdmurray> slangasek: how can find the version of apt for the lucid upgrader?  comment #18 in bug 541595
[17:43] <xnox> slangasek: yeah same conclusion here, but I didn't dwell too much into it.
[17:44] <slangasek> bdmurray: not sure I understand the question... you're not asking for the version numbers from /var/log/dist-upgrade/main.log, I guess?
[17:45] <slangasek> oh, you're referencing my own comment, heh
[17:45]  * slangasek reads
[17:45] <bdmurray> trolling through the dupes I found one or two with 0.8.16~exp12ubuntu6~upgrade1
[17:46] <bdmurray> er upgrader
[17:46] <bdmurray> and I wonder if that is the most recent
[17:46] <slangasek> bdmurray: the source packages in lucid-updates are release-upgrader-apt and release-upgrader-python-apt; release-upgrader-apt is at version 0.8.16~exp12ubuntu6~upgrader1
[17:46] <bdmurray> hmm
[17:47] <slangasek> bdmurray: only one or two, though, out of 8 billion duplicates?
[17:49] <bdmurray> 2 man!
[17:50] <slangasek> bdmurray: might be worth forking those off to a new master bug?
[17:50] <slangasek> since it kinda sounds like the issue is *mostly* fixed in the new version
[17:51] <bdmurray> both are from the same person so I am getting skeptical
[18:00] <bdmurray> slangasek: the first error is:
[18:00] <bdmurray> dpkg: dependency problems prevent configuration of libgcc1:i386:^M
[18:00] <bdmurray>  libgcc1:i386 depends on libc6 (>= 2.2.4); however:^M
[18:00] <bdmurray>   Package libc6:i386 is not configured yet.^M
[18:00] <bdmurray> dpkg: error processing libgcc1:i386 (--configure):^M
[18:00] <bdmurray>  dependency problems - leaving unconfigured^M
[18:06] <slangasek> bdmurray: erm, that's a strange error to be hitting
[18:06] <slangasek> bdmurray: which bug # is this on?
[18:07] <bdmurray> bug 969536
[18:07] <bdmurray> that really wasn't very helpful
[18:16] <melodie_> hi
[18:18] <slangasek> bdmurray: so libc6 and libgcc1 have a circular dependency relationship; that probably has something to do with it
[18:20] <slangasek> bdmurray: and the bit triggering the "already installed and configured" is the hostname package, which has a pre-dependency - I think this is the same symptom but a separate bug
[18:21] <bdmurray> slangasek: okay, I'll pull the two of them out then and think about the pattern for these
[18:54] <SpamapS> slangasek: if we build mysql with debug symbols, (-DWITH_DEBUG=ON) will the binaries be stripped into dbgsym packages properly?
[18:54] <SpamapS> I've never fully grasped how that works exactly
[18:54] <SpamapS> dh_strip -a is called..
[18:54] <slangasek> SpamapS: dh_strip will strip them, yes, and pkgbinarymangler will ensure that when dh_strip is called, the symbols are saved off
[18:54] <SpamapS> but isn't that just for normal symbols, not full "-g" debugging symbols? or does that result in the same thing?
[18:55] <SpamapS> "typing it out loud"
[18:55] <SpamapS> I think I get it
[18:55] <SpamapS> slangasek: ok, so I think we should probably just do that then.
[19:07] <ScottK> SpamapS: I like that diff a lot better.  Thanks.
[19:08] <SpamapS> ScottK: NP, I like it better too. :)
[19:08] <SpamapS> shocking how long that package took to test build
[19:08] <SpamapS> Starting to think I should invest in a local build machine with some ridiculously fast i7 CPU's
[19:10] <xnox> SpamapS: use cloud VM
[19:11] <SpamapS> I do
[19:11] <SpamapS> a lot actually
[19:11] <SpamapS> c1.medium is usually enough
[19:12] <SpamapS> its often a lot slower than my Core2Duo 2.53Ghz cpu's though..
[19:12] <xnox> SpamapS: due to I/O - instance storage?
[19:12] <SpamapS> no, due to the CPU being about half as fast
[19:13]  * xnox has an i5 but not enough RAM =(
[19:13] <SpamapS> I have 4GB .. which is fine
[19:24] <rtg> infinity, what is the difference between 'Section: restricted/metapackages' and just plain 'Section: metapackages' ? Does it have any relevance in Ubuntu?
[19:31] <infinity> rtg: Yes, the bit before the / indicates the component.
[19:31] <infinity> rtg: And, while we have some pretty wildly fun bugs surrounding how we deal with that, our upload queue is meant to respect it, so I don't have to do as many manual overrides. :P
[19:31] <infinity> rtg: (cjwatson is working on fixing those bugs)
[19:35] <rtg> infinity, herton noted that the linux-powerpc, linux-powerpc64-smp and linux-powerpc-smp meta packages are all in the restricted component.
[19:36] <infinity> rtg: In the archive, or in the packaging?
[19:36]  * infinity looks.
[19:36] <rtg> infinity, in the packaging
[19:37] <melodie_> have someone noticed something strange with the completion in gnome-terminal, in Precise ?
[19:37] <melodie_> I was using a gnome/openbox session and I could not get correct completions on the path of the directories...
[19:37] <infinity> rtg: Right, that was correct back in hardy, when those packages depended on LRM (and were, in fact, in the restricted component), it's certainly wrong now, when they're in main.
[19:38] <melodie_> ie : "cat /home/user (here a blank whereas I was hitting tab to get more)
[19:38] <rtg> infinity, ok, I'll get that fixed.
[19:39] <melodie_> I am asking because I can't check again now at home, I was in an enterprise for a sort of "test week", before entering a training next autumn
[19:40] <melodie_> I don't have the same setup here.
[19:50]  * xnox changelogs are alive!!!! =)))) YEAH!
[19:51] <melodie_> :p
[19:52] <melodie_> is there anyone here who likes openbox ? (this type of question can't hurt I suppose)
[19:59] <kees> hallyn: if I make changes to /etc/cgconfig.conf, what do I need to to do get those reflected on the running system?
[20:20] <xnox> is there a bug number on launchpad for fixing changelogs.ubuntu.com?
[20:20]  * xnox has many reports to file as duplicates
[20:20] <xnox> as in mark as duplicates
[20:23] <hallyn> kees: not sure.  it'll be moot soon, libcgroup in debian just disabled all of the initscripts
[20:24] <hallyn> kees: hm, depending on the changes you can try 'restart cgconfig'
[20:24] <hallyn> but some changes in composition of cgroups, the kernel won't allow without a reboot
[20:25] <kees> hallyn: hrm... I'm getting:
[20:25] <kees> Loading configuration file /etc/cgconfig.conf failed
[20:25] <kees> Cgroup mounting failed
[20:25] <kees> I'm so confused :P
[20:25] <kees> I don't feel like this /etc/cgconfig.conf is very complex at all.
[20:25]  * xnox found it.
[20:29] <hallyn> kees: can you pastebin the new cgconfig.conf?
[20:29] <hallyn> kees: check syslog.  my guess is that you're changing the cgroup composition...
[20:30] <kees> http://pastebin.ca/2163955
[20:30] <kees> I've isolated it to the browser ... memory {} section
[20:30] <kees> the failure output from that tool is not great :)
[20:31] <kees> "memory.memsw.limit_in_bytes" seems to be the bad line
[20:31] <kees> which makes no sense to me... I see it there.
[20:32] <hallyn> kees: is 3G valid?
[20:32] <hallyn> you might have to enter it in bytes, for real
[20:32] <kees> it works for memory.limit_in_bytes but not memory.memsw.limit_in_bytes ?
[20:32] <hallyn> (can test on thecmdline)

[20:32] <kees> how do I test on command line?
[20:32] <hallyn> not inconceivable,
[20:33] <hallyn> mkdir /cgroup/ab;  cd /cgroup/ab; echo 3G > memory.memsw.limit_in_bytes
[20:33] <hallyn> yeah fails here
[20:33] <kees> worked fine for me
[20:33] <hallyn> works for me with memory.limit_in_bytes, failed with memsw
[20:34] <kees> oh how odd...
[20:34] <kees> so
[20:34] <kees> 2G worked, 3G didn't
[20:34] <hallyn> oh is memsw swap?  maybe i just don't have enough :)
[20:34] <kees> er, other way around
[20:34] <kees> AH
[20:35] <hallyn> to the kernel code, batman
[20:35] <kees> this is bizarre
[20:35] <kees> I bet memory.memsw.limit_in_bytes must be >= memory.limit_in_bytes
[20:37] <hallyn> kees: yup, comment in code says /* We have to guarantee memcg->res.limit < memcg->memsw.limit.
[20:38] <kees> memory.memsw.limit_in_bytes needs to be set first.
[20:38] <kees> the cgconfig.conf file seems to not be able to handle ordering?
[20:39] <hallyn> uh, no,
[20:39] <hallyn> you mean memory.limit_in_bytes must be set first
[20:40] <hallyn> else it is (unsigned)-1, and memsw.limit_in_bytes can never be > it
[20:41] <hallyn> kees: so reverse the order of your entries, and make sure memsw is >, not >=
[20:41] <hallyn> i'm not guaranteeing that libcg will honor the ordering :)
[20:41] <hallyn> i *am* guaranteeeing that soon it won't matter unless you hand-reenable the initscripts
[20:42] <kees> heh
[20:43] <kees> but 3G works on the command line...
[20:43] <kees> /sys/fs/cgroup/memory/browser# echo 3G > memory.limit_in_bytes
[20:43] <kees> /sys/fs/cgroup/memory/browser# echo 3G > memory.memsw.limit_in_bytes
[20:43] <hallyn> huh, ok :)  i was going based on the comment in the code (not even the code itself), so you win :)
[20:44] <kees> regardless, libcg appears to continue to fail :(
[20:44] <hallyn> yup works for me too
[20:45] <kees> well now /usr/sbin/cgconfigparser doesn't work at all, even with that memory section removed
[20:45] <kees> Cgroup mounting failed
[20:45] <kees> wtf does that mean?
[20:45] <hallyn> kees: i have some work to do to look at it, but jbernard was mentioning incorporating the cgroup-lite startup in cgroup-bin.  It sounds like you need something more flexible.  Perhaps we should talk next week about making cgroup-lite's startup more flexible
[20:45] <kees> sure
[20:46] <hallyn> well do you still have memory cgroup mounted?
[20:46] <hallyn> (apart from cgconfig's mount)?
[20:46] <kees> ah, my shell was messing with it.
[20:47] <hallyn> it works now?
[20:47] <kees> as long as I keep memory.memsw.limit_in_bytes commented out of cgconfig.conf, yes

[20:48] <hallyn> actualy if you want the user/group stuff like you're showing, then you'll always need to re-enable the libcgroup daemon (which is inherently buggy), so no sense talking about cgroup-lite flexibility
[20:49] <kees> I really don't understand what's going on here at all.
[20:49] <kees> I renamed "browser" to "monkey", and it won't load again.
[20:53]  * kees just adds manual mkdir and echo to the pre-start ...
[20:56] <hallyn> kees: are you wanting every task you own to end up in browser group?
[20:56] <hallyn> (i'm not even familiar enough with cgconfig.conf go know if that's what you're doing, but it looks like it to me)
[20:57] <kees> hallyn: no, I'm trying to define the "browser" group, so that my cgrules.conf line works:
[20:57] <kees> kees:chrome memory browser/
[21:03] <dobey> barry: around?
[21:27] <barry> dobey: hi
[21:30] <dobey> barry: https://plus.google.com/103117938079967018309/posts/2CET5s46EXa
[21:32] <barry> dobey: you say that in py2 it's a unicode but in py3 it's a str.  isn't that the same thing? ;)
[21:32] <barry> or did you want it to be a bytes in py3?
[21:32] <barry> in which case, use os.environb.get()
[21:34] <dobey> it's unicode in py2 because i added the unicode_literals future import i guess. so it didn't used to be unicode, but a str in python2 also
[21:34] <dobey> but os.environb doesn't exist in python2
[21:35] <barry> dobey: i guess the question is, what do you want? :)  obviously, consistency b/w 2 and 3, but bytes or unicodes?
[21:36] <dobey> barry: well i need to return something encoded in utf-8. internally i don't really care, as long as it works in both pythons
[21:39] <barry> dobey: so, maybe something like this:
[21:39] <barry> try:
[21:39] <barry>   env = os.environb
[21:39] <barry> except AttributeError:
[21:39] <barry>    env = os.environ
[21:39] <barry> path = env.get(key)
[21:39] <barry> blah blah...
[21:45] <dobey> not sure that works
[21:57] <infinity> Riddell: Thanks for the new ktp-contact-applet .. If only it built. ;)
[21:58] <alkisg> Hi, which component is responsible for showing the user name in the upper panel in gnome-session-fallback? It's not working in LTSP fat clients, and I'd like to look at its source...
[22:13] <infinity> alkisg: It only shows the username if the user switcher sees more than one available account.
[22:14] <infinity> alkisg: On a default Ubuntu install, that's your user, and "guest".
[22:14] <alkisg> infinity: ah, thank you, that explains it
[22:14] <infinity> alkisg: If you disable guest, it goes away (until you add more users)
[22:14] <alkisg> So the only way around it would be to add a fake guest user for ltsp fat clients?
[22:15] <infinity> alkisg: If they're all logging in with the same userid, it wouldn't matter anyway, would it?
[22:15] <infinity> alkisg: And if they're not (but you're using network auth, perhaps?), exporting a user list to the client would suddenly make it populate.
[22:15] <infinity> Riddell: (ktp-contact-applet Fixed, BTW)
[22:15] <alkisg> infinity: we're using ssh for authentication, and we're copying only the user entry from the server passwd
[22:16] <infinity> alkisg: Ah.  Right, then the user switcher just isn't going to be useful in that case, I suspect.  Not without some hacking.
[22:16] <alkisg> Displaying the username is very useful for classrooms, so that the teacher can see the pupil names
[22:16] <alkisg> infinity: which source package is that in?
[22:16] <infinity> alkisg: It's part of indicator-session, I believe.
[22:16] <alkisg> Thank you very very much :)
[22:18] <barry> kenvandine: ping
[22:19] <infinity> barry: Say, did you ever find 20 seconds to see if libpwquality was py3-able with minimal effort?
[22:19] <infinity> barry: Not looking to have it ported, just enabled if it's trivial.
[22:19] <barry> infinity: i did not, sorry
[22:20]  * cjwatson wonders how exactly translations_* (DDTP) uploads manage to get into the archive
[22:20] <cjwatson> They appear to be constructed as more-or-less-sourceless binary uploads
[22:23] <xnox> does live-cd has all the packages installed, or does it contain packages which are not installed but available from the cd?
[22:24] <cjwatson> Oh.  Wow.  Apparently you're allowed to do that if the upload has precisely one custom upload file and nothing else.
[22:24] <cjwatson> Some packages are only conditionally installed and aren't installed in the squashfs.
[22:24] <cjwatson> Language packs are a good example.
[22:26] <infinity> cjwatson: Cute trick.  I suppose we just assume these uploads are their own source?
[22:26] <infinity> cjwatson: Which is true for translations tarballs, of course.
[22:26] <infinity> (more or less)
[22:28] <bdmurray> slangasek: looking at bug 969536 some more I found some corrupt package error messages
[22:28] <cjwatson> infinity: They have no SPPH at all
[22:28] <cjwatson> infinity: I didn't even know that was possible
[22:29] <cjwatson> infinity: I care because this means I can't easily fix bug 827941 (the copier really kind of wants there to be an SPPH), so I think I'll have a word with mvo next time I see him and find out if we can reorganise this
[22:30] <slangasek> bdmurray: oh?
[22:31] <slangasek> ah, so there are
[22:45] <bdmurray> bryceh: do you find the auto tagging of regression-update by your package hook to be accurate?
[22:59]  * xnox may have been not passing -vW.X-YubuntuZ before uploading merges....
[23:01] <infinity> xnox: I forget occasionally too.  We won't kick you out of the club just yet.
[23:02] <xnox> infinity: ok. thank you.
[23:02]  * xnox was getting really worried now
[23:06] <bryceh> bdmurray, it's doing that based on Q&A from the user, so accuracy is subject to pebkac.
[23:06] <bryceh> bdmurray, however I haven't run across any problems so far (knock on wood)
[23:11] <bryceh> bdmurray, the kernel used to ask the user if it was a regression, and presented them with a list of different types of regressions
[23:11] <bryceh> bdmurray, my approach is a bit better in that I can examine the system to see what class the reporter fits in, so don't need to present so many choices.  I think this is a better way of doing it.
[23:12] <bryceh> redundantly, I think I am being redundant
[23:13] <bdmurray> I ask because we are looking at subscribing the ubuntu sru team to bugs tagged regression-update and regression-proposed
[23:13] <bdmurray> and I saw bug 1016771 tagged regression-update
[23:13] <bdmurray> bryceh: ^ and that seemed incorrect to me afaict
[23:15] <bdmurray> I wonder if there is a way to see if the pacakge is from -updates
[23:17] <bryceh> bdmurray, you thinking like parse apt-cache policy?
[23:17] <bryceh> of course in this particular case that would lead us astray; the regression wouldn't be in the 'xorg' package, but rather the kernel (or maybe mesa or -intel)
[23:20] <bdmurray> bryceh: well you have all those packages in the description …
[23:20] <bdmurray> so if none were -updates remove the tag regardless of what they say
[23:22] <bryceh> hmm, maybe
[23:22] <bryceh> bdmurray, I'll give it some thought and rework it to be more sensible
[23:24] <bdmurray> bryceh: well if there isn't a terrible volume of false positives I wouldn't work too hard on it
[23:25] <bryceh> bdmurray, heh, well do you want me to work on it or not?  ;-)
[23:26] <bryceh> actually independent of this it would be helpful for debugging purposes to better identify what packages were updated during the time frame
[23:27] <hallyn> kees: so for what you're doing, would you be happy with a chrome wrapper which sticks itself into the right cgroup?
[23:29] <bryceh> bdmurray, do you happen to know if there are a lot of regression-update X bugs ?  I used to have a report that showed this but seems I'm not running it now.
[23:32] <bdmurray> bryceh: no, not really
[23:32] <bdmurray> what in the world?
[23:32] <bdmurray> bug 1012195
[23:32] <bdmurray> how is that regression-everything
[23:34] <bdmurray> and of course there are dozens of missing plug-ins tagged this way
[23:40] <xnox> stgraber: can you look at https://bugs.launchpad.net/ubuntu/+source/qpid-cpp/+bug/945365/comments/1 it's an IPv6 test failure
[23:42] <kees> hallyn: yeah, but that means messing with packaging. I've got it working fine with mkdir/echo stuff now. *shrug*
[23:43] <kees> hallyn: seems like this is a regression from lucid where that file is valid.
[23:43] <infinity> xnox: Those are, arguably, two bugs (though, I suppose fixing them both at the same time would be nice)
[23:45] <infinity> xnox: Oh, and the ARM alignement bug seems to have been fixed, which makes adding your comment to it even more confusing.
[23:46] <xnox> infinity: right so, i'm gonna rename that bug back and close it, and file a new one
[23:47] <xnox> infinity: and i should be less gready and open bugs instead of piggy-back
[23:47] <infinity> xnox: It's entirely possible the buildds just can't resolve ::1
[23:47] <infinity> xnox: Though, shouldn't that be resolvable at the glibc level without any help from anything else?
[23:47]  * infinity pokes this with a stick.
[23:48] <xnox> infinity: and debian's buildd pass fine
[23:48] <infinity> xnox: Indeed.
[23:50] <xnox> https://bugs.launchpad.net/ubuntu/+source/qpid-cpp/+bug/1016778
[23:54] <hallyn> kees: have you filed a bug?  i'm not a big fan (an dit's in universe) but i'm interested in taking a look at some point
[23:54] <hallyn> (again, it'll be short-term since we're nixing it :)