[06:15] <pitti> Good morning
[06:16] <pitti> jtaylor: it failed due to "python-tables : Depends: python-tables-lib (>= 3.1.1-0ubuntu1) but 3.1.0-2ubuntu1 is to be installed", it was uninstallable at that time; I'll retry it
[06:43] <pitti> doko: thanks for the apport speedup patch! I reuploaded with the missing extra import, see bug report
[06:49] <dholbach> good morning
[07:08] <pitti> slangasek, stgraber: sorry for missing the meeting last night, I felt quite bad; FTR, I thought I +1'ed https://wiki.ubuntu.com/Ubuntu%20Kylin/Ubuntu%20Kylin%20Archive on the ML already
[07:44] <Laibsch> Is a pbuilder chroot with build-essential installed but missing the initscripts package considered complete or not (AKA broken)?
[07:50] <infinity> Laibsch: How would you have created such a chroot?  debootstrap wouldn't let you, and apt would yell at you when you start removing required packages.
[07:52] <Laibsch> aptitude didn't yell at me, it seems
[07:54] <infinity> Oh, actually, apt won't either.
[07:55] <infinity> Laibsch: So, no, that wouldn't be "broken" from a policy perspective, FWIW.  "build-essential" consists of "essential" + "build-essential", not required.
[07:55] <infinity> Laibsch: From a "will Ubuntu consider that a sane and supportable system" perspective, though, it's totally broken. :)
[07:55] <infinity> So, it depends on your context.
[07:55] <Laibsch> so, if a package required the mountall command which is in initscripts but didn't specify that build-dependency is the package broken?
[07:56] <infinity> But thanks for pointing out, in a roundabout way, that upstart is no longer transitively essential.  I can knock that out of the LP chroots for 14.10  \o/
[07:56] <infinity> Laibsch: Yes.
[07:56] <Laibsch> OK
[07:56] <infinity> Laibsch: Though, I assume you mean in the mountall package...
[07:56] <Laibsch> reopening bug 1307883, then
[07:57] <FourDollars> pitti: Hi. Could you help me check https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 on precise?
[07:57] <Laibsch> openjdk-7-jre calls mountall in postinst but does not declare a dependency (run-time, actually)
[07:58] <infinity> Laibsch: Hrm, I don't see it calling mountall.
[07:58] <infinity> Laibsch: I just see it wanting /proc mounted.
[07:58] <infinity> Laibsch: And a system without proc mounted is absolutely broken.
[07:58] <Laibsch> sorry
[07:58] <Laibsch> mountall
[07:58] <Laibsch>  /var/lib/dpkg/info/ca-certificates-java.postinst: line 90: mountpoint: command not found
[07:58] <FourDollars> pitti: oops. sorry.  I found it at https://launchpad.net/ubuntu/precise/+queue?queue_state=1.
[07:59] <Laibsch> and now that I look at it the problem might be in ca-certificates-java, not the jre
[07:59] <Laibsch> infinity: proc is mounted
[07:59] <pitti> FourDollars: right, it's waiting for the SRU team to review/accept
[07:59] <infinity> Laibsch: Oh, yeah, I can't read.
[07:59] <Laibsch> infinity: relax, me neither ;-)
[08:00] <infinity> Laibsch: So yes, indeed, that has a runtime dep on initscripts, which isn't Essential, so should be declared.
[08:00] <FourDollars> pitti: I see. Thanks.
[08:00] <Laibsch> infinity: thanks, I reopened the ticket.  against the correct package.
[08:03] <pitti> I never quite understood how "Priority: required" packages are not actually required; it seems odd having to declare a dependency to such a package
[08:04] <Laibsch> infinity: actually, openjdk-7-jre is affected as well verified by the line
[08:04] <Laibsch>   /var/lib/dpkg/info/openjdk-7-jre-headless:i386.postinst: 18: /var/lib/dpkg/info/openjdk-7-jre-headless:i386.postinst: mountpoint: not found
[08:05] <infinity> pitti: "required" is meant to be required for a running Debian system (ie: it's the smallest set you can expect to function meaningfully as a computer), but you still need to depend on them, and they still aren't needed for build-deps.
[08:05] <infinity> Laibsch: So, this is a slight regression in that initscripts used to be transitively Essential due to things depending on upstart in the Essential set.
[08:06] <infinity> That said, it was never Essential:yes, so deps should exist.
[08:07] <infinity> Frankly, I think it's a glorious feature that upstart and udev aren't accidentally in the Essential set anymore.
[08:08] <infinity> And initscripts isn't essential in Debian either, afair.
[08:08] <infinity> Oh, no.  It is.
[08:08]  * infinity ponders how and why.
[08:09] <infinity> Oh, util-linux depends on it directly.
[08:09] <infinity> So, that could solve other buggy packages here.
[08:11] <Laibsch> I've put initscripts into the EXTRAPACKAGES variable in ~/.pbuilderrc for now but somehow it doesn't seem to get installed upon "pbuilder-dist trusty build $blah.dsc" invocation.  Am I misunderstanding "man 5 pbuilderrc"?
[08:11] <infinity> I don't speak pbuilder.
[08:12] <pitti> Laibsch: I don't use pbuilder either, but my suspicion is that this only applies to pbuilder create, and perhaps update, but not build
[08:13] <Laibsch>        EXTRAPACKAGES="ccache lintian XXX"
[08:13] <Laibsch>               Specifies  extra  packages which the system should install in the chroot on pbuilder create.  This is a space-delimited list.  Also this is installed on pbuilder build
[08:13] <Laibsch> from the manpage
[08:13] <Laibsch> "Also ..."
[08:13] <pitti> yes, I know, but it might not actually behave that way
[08:13] <Laibsch> I see
[08:13] <Laibsch> it looks like it
[08:13] <pitti> it's just a suspicion
[08:13] <Laibsch> what are people using these days for building?
[08:13] <pitti> sbuild + apt-cacher-ng + tmpfs = ♥
[08:14] <Laibsch> I've heard a lot of new commands thrown around
[08:14] <Laibsch> I'm already using acng
[08:14] <Laibsch> love, certainly when my download speed drops to less than 10Kbit (yes, bit) out in the jungle ;-)
[08:14] <infinity> cjwatson: Left here for when you get in, an opinion on sanity of approach of comment 3: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1307883
[08:15] <pitti> Laibsch: heh, or when I build packages offline in a train or plane :) but even at home acng is over a magnitude faster than real internet
[08:15] <infinity> acng + tmpfs is the best thing ever.
[08:15] <infinity> Instant build-deps.
[08:16] <Laibsch> how does the tmpfs come into play? I assume it's for speed reasons
[08:16] <pitti> infinity: yeah, that's why I sticked 16 GB into my new laptop (also for LXC/qemu), it just rocks :)
[08:16] <pitti> Laibsch: yes; muchly
[08:16] <Laibsch> how to use?
[08:16] <Laibsch> what do you mount on tmpfs?
[08:16] <pitti> even on a 500 MB/s SSD the difference is significant, mostly due to fsync and friends
[08:16] <infinity> Laibsch: Yeah, doing union (aufs or overlayfs) builds backed in tmpfs, so file ops are instant and cleanup is quick.
[08:17] <pitti> /var/lib/schroot/union/overlay -> /tmp
[08:17] <pitti> /var/lib/schroot/unpack -> /tmp
[08:17] <infinity> pitti: I don't bother with the second one.
[08:17] <pitti> infinity: I use tarballs for most of my schroots, so I need both
[08:17] <geser> Laibsch: mount a tmpfs on /var/cache/pbuilder/build (if you using pbuilder)
[08:17] <infinity> pitti: Oh, right.
[08:18] <infinity> geser: Is that a filesystem overlay, or just the directory where the build happens?
[08:18] <pitti> and of course 'none /tmp tmpfs defaults 0 0' in /etc/fstab, something which we should have done ages ago on systems with >= 2 GB RAM
[08:18] <infinity> Cause I/O matters almost nothing to the build itself, it's the build-dep install that hurts.
[08:19] <geser> infinity: in case of pbuilder: pbuilder extracts there the base.tar.gz, performs the build there (in a chroot) and removes it again when done
[08:19] <infinity> pitti: My /tmp routinely grows a lot more than 2G of cruft between reboots.  That wouldn't be a sane default without a better cleaning cron job.
[08:19] <infinity> geser: Ahh, kay.  So, the whole thing.  That would do, yes.
[08:20] <pitti> and other tweaks are things like "export-dir = /tmp/build-area/" in ~/.gbp.conf
[08:22] <Laibsch> My computer still has only 2G of RAM, frequently well-filled by FF.  Is mounting /var/cache/pbuilder/build on tmpfs still a good idea or is the worst that would happen that overflow would be dropped to swap and thus no gain in speed?  I wouldn't like my machine to crash or crawl to a halt when building a large package.
[08:23]  * Laibsch reminds himself to get more RAM next time when back in civilization
[08:23] <pitti> Laibsch: no, if /tmp is full there is no automatic overflow to swap
[08:23] <pitti> things will just go haywire
[08:24] <Laney> how does changelogs.u.c work?
[08:24] <Laibsch> OK, I'll postpone the speed optimization, then.
[08:24] <Laney> I think something has gone wrong with it updating
[08:24] <seb128> Laney, mvo probably knows
[08:26] <mvo> Laney: there is a lp-changelogs-crawler running on changelogs.u.c
[08:26] <mvo> Laney: it appears I do not have a login anymore, hrm
[08:29] <Laney> mvo: Go abuse IS into giving you it back :P
[08:29] <mvo> Laney: I send a rt and asked for access
[08:29] <Laney> Seems it hasn't updated since last Thursday-ish
[08:29] <Laney> did a little bisect using trusty-changes
[08:43] <jibel> mvo, could you have a look at bug 1307904 ? It's an edge case, only grep:i386 is installed on a 64bit system. The upgrader replaces grep:i386 by grep:amd64 on upgrade but finally refuses the upgrade because grep:i386 is removed
[08:44] <mvo> jibel: sure
[08:57] <bipul> I am looking for networking team, to work with them.
[08:59] <bipul> Any one around? who can help me with my query ?
[09:00] <mvo> jibel: fixed
[09:01] <jibel> mvo, thanks
[09:05] <mvo> jibel: thank you!
[09:10] <zyga> bipul: what do you mean by 'the networking team'
[09:11] <bipul> zyga, any ubuntu projects related to networking.
[09:11] <zyga> bipul: I don't think there is a team of that kind
[09:12] <zyga> bipul: if you can be more precise than networking then you might find what you are looking for
[09:12] <bipul> zyga, or any development team, related to programming.
[09:12] <zyga> bipul: ubuntu is developed by a large number of distributed people
[09:13] <zyga> bipul: perhaps you should just ask your question
[09:14] <bipul> zyga, I am looking for a development team where i can do contribution and also to learn.
[09:15] <zyga> bipul: so hang around, there is no team pe se, there are just people that do stuff, you may be interested in signing up to the mailing list and look at discussions there, if you know programming you should look at upstream projects (the ones that ubuntu and debian package) and contribute your efforts there
[09:16] <bipul> where i can get the upstream projects ?
[09:17] <zyga> bipul: wherever they are hosted, for example you can find out about network-manager using:
[09:17] <zyga> apt-cache show network-manager | grep Homepage
[10:36] <zyga> following sbuild page on the debian wiki (https://wiki.debian.org/sbuild) I got to the part with piuparts, I used the sid chroot (as in the example) but for some reason piuparts wants to setup a saucy chroot (?!), does anyone here use piuparts along with sbuild?
[10:45] <zyga> looking at the source I see this is hardcoded
[10:47] <zyga> pitti: is this worth fixing for trusty?
[10:47] <pitti> zyga: sounds easy enough, and it's certainly not on any image
[10:47] <zyga> pitti: I have a debdiff, what should I do with it?
[10:48] <pitti> zyga: subscribe sponsors for now; I'll try to have a look in the next hours
[10:48] <zyga> http://paste.ubuntu.com/7254566/
[10:48] <zyga> ko
[10:48] <zyga> pitti: so open a bug on the trusty package, attach the debdiff and subscribe sponsors, anything else?
[10:49] <pitti> that sounds like the usual approach
[10:49] <zyga> ok, thanks
[10:49] <pitti> zyga: if the release team is happy for it to go in without a bug, I can also just upload the debdiff
[10:50] <pitti> zyga: but at least this warrants a Debian bug -- this certainly shoudln't hardcode "saucy" but use /etc/os-release
[10:50] <zyga> pitti: it's more "smart" than that, it has several profiles
[10:51] <pitti> meh, and it even calls lsb_release already
[10:51] <geser> perhaps it should use python-distro-info instead to get the devel release
[10:51] <pitti> zyga: anyway, uploaded; please do the above if the release team wants bug reports at this point
[10:54] <zyga> pitti: https://bugs.launchpad.net/ubuntu/+source/piuparts/+bug/1307995
[10:54] <zyga> pitti: uploaded as in you've fixed this in the archive?
[10:55] <pitti> zyga: as in I uploaded your debdiff
[10:55] <pitti> zyga: I'll reupload with that bug ref
[10:55] <zyga> pitti: ah, thanks
[10:55] <pitti> zyga: oh, it was auto-accepted: https://launchpad.net/ubuntu/+source/piuparts/0.56ubuntu1
[10:55] <pitti> seems universe still isn't deep-frozen
[10:56] <zyga> pitti: cool, thanks :-)
[10:56] <zyga> pitti: so should I do anything else at this time or is this enough?
[10:58] <pitti> zyga: seems fine; a Debian bug about this would be nice though
[10:58] <zyga> pitti: ok, I'll try to do that
[10:58]  * zyga keeps forgetting how to use reportbug on ubuntu to target debian
[10:59] <Laney> pitti / jibel: Would it be a good idea to add -o IdentitiesOnly=yes to etc/config in lp:auto-package-testing?
[10:59] <Laney> I was just getting the old 'too many authenticaiton failures'
[11:02] <pitti> Laney: I don't know what that does, I'm afraid
[11:03] <Laney> pitti: Basically makes it ignore the agent provided identities and just use the one given on the commandline
[11:05] <pitti> Laney: seems to work alright here
[11:05] <Laney> It happens if you have a lot of identities in the agent
[11:06] <pitti> Laney: http://paste.ubuntu.com/7254656/ ?
[11:06] <Laney> lgtm
[11:06] <pitti> Laney: pushed
[11:06] <Laney> cheers
[11:07] <Laney> I ought to figure out if all of these keys are really necessary
[11:07]  * Laney gives that problem to future Laney to solve
[11:07] <pitti> in your agent, you mean?
[11:07] <Laney> yep
[11:15] <dpm> hi cjwatson, I've got a website that reports the status of translations for the packages included in a default distro installation (as opposed to LP reporting everything in main). A while ago you explained me how I could find out this list of packages for a desktop installation through the seeds. So the list of seeds to expand that you gave me for the desktop (http://bazaar.launchpad.net/~dpm/ubuntu-translations-stats/trunk/view/head:/stats/management/c
[11:15] <dpm> ommands/utils/distropackages.py#L42) has worked very well so far. I'm now trying to report translation status for the phone. Can I also do this using the same method? I.e. is there a list of seeds that I can use to determine all packages from a default phone installation?
[11:18] <LocutusOfBorg1> dholbach, you there?
[11:19] <LocutusOfBorg1> I saw your comment on the sync request
[11:19] <LocutusOfBorg1> maybe is faster to discuss here
[11:19] <LocutusOfBorg1> :)
[11:36] <dholbach> LocutusOfBorg1, I just wanted to generally provide some links to how to get an upload considered for backports/SRUs
[11:36] <dholbach> LocutusOfBorg1, but sure... how can I help?
[11:36] <LocutusOfBorg1> I would like to have it for trusty
[11:36] <LocutusOfBorg1> :)
[11:36] <LocutusOfBorg1> sorry leaving
[11:37] <dholbach> ... ok
[11:38] <dholbach> for whoever is wondering what this was about, here's the link: bug https://bugs.launchpad.net/ubuntu/+source/flex/+bug/1307604
[11:43] <shadeslayer> dpm: ping
[11:43] <shadeslayer> dpm: https://bugs.launchpad.net/langpack-o-matic/+bug/1267763 < needs adding to langpack-o-matic
[11:43] <dpm> hey shadeslayer
[11:44] <dpm> shadeslayer, you'll need to ping pitti for the langpack-o-matic side of things
[11:45] <shadeslayer> pitti: ^^
[11:46] <shadeslayer> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1278142
[11:48] <shadeslayer> dpm: https://translations.launchpad.net/ubuntu/trusty/+source/kde-config-whoopsie/+imports < templates are imported but not approved?
[11:48] <dpm> shadeslayer, if the're imported, they've been approved :)
[11:48] <shadeslayer> ah I see
[11:48] <dpm> the workflow is Needs Review > Approved > Imported
[11:49] <shadeslayer> ah ok
[11:49] <shadeslayer> dpm: https://bugs.launchpad.net/ubuntu/+source/intltool/+bug/953342 < needs intltool release
[11:51] <geser> does somebody have any opinion what do with myspell-st (src:dict-st)? it looks like it fails in post-inst since precise (bug 980130). The package is in main but was never in Debian so is essentially unmaintained.
[11:51] <dpm> shadeslayer, I know. You might want to ping danilo and dobey as intltool maintainers for a new release
[11:52] <shadeslayer> dobey: ^^ could we get a release pretty please :)
[11:55] <shadeslayer> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1267765
[11:55] <shadeslayer> pitti: all 3 need to be added to langpack-o-matic
[11:56] <Laney> geser: The postinst is automatically generated & a no-change rebuild gets rid of it
[11:56] <Laney> I don't know if the package works or does anything useful though
[11:57] <Laney> It does at least ship files in useful locations...
[11:58] <geser> me neither, but I try to get a SRU for it in the next days to fix this error at least
[11:58] <Laney> I think there are other myspell-* packages that do the same
[12:30] <pitti> shadeslayer: hm, why aren't these in kde-l10n-*?
[12:30] <pitti> shadeslayer: I thought the -base packages only contained the kubuntu specific strings?
[12:32] <pitti> shadeslayer: driver-manager added
[13:09] <shadeslayer> pitti: because at the very least whoopsie/driver manager are kubuntu specific things
[13:09] <shadeslayer> and not part of sc
[13:10] <pitti> shadeslayer: yes, I added that
[13:10] <shadeslayer> pitti: whoopsie too?
[13:10] <pitti> shadeslayer: I was wondering about kdesudo
[13:10] <shadeslayer> ah that, I  am unsure, apachelogger ^^
[13:11] <pitti> shadeslayer: whoopsie? I didn't see that bug
[13:11] <apachelogger> space ships, what?
[13:11] <apachelogger> kdesudo is kubuntu specific right now
[13:11] <apachelogger> perhaps we'll get to change that some time not too far in the future
[13:11] <pitti> shadeslayer: ah, doing now
[13:11] <shadeslayer> pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1267763
[13:13] <cjwatson> dpm: For the phone I think it's minimal plus the sdk-libs and touch seeds in the ubuntu-touch seed collection, but sanity-check that against reality
[13:15] <pitti> shadeslayer: all done
[13:16] <pitti> seb128: is bug 1201485 still actually an issue?
[13:17] <seb128> pitti, no, it's launchpad fix released, the other lines are probably invalid
[13:17] <pitti> seb128: ah, so PPA copying copies along the translations.tar.gz now? nice
[13:17] <seb128> pitti, I didn't especially check but I didn't notice outdated templates/missing translations so I think the fix is working as it should
[13:17] <seb128> pitti, I think so
[13:18] <pitti> the MP times out to load
[13:18] <pitti> seb128: ack, thanks
[13:19] <seb128> pitti, yw!
[13:24] <MacSlow> Saviq, hm... the input filterarea doesn't work reliably... it's swallowing input when on the dash, but not in apps... investigating
[13:24] <MacSlow> Saviq, MouseArea I meant
[13:24] <Saviq> MacSlow, yeah, you need to use an InputFilterArea
[13:25] <Saviq> MacSlow, as well, that is
[13:26] <MacSlow> Saviq, but it (the modal-backgrounds MouseArea) swallows input for the Dash... that's confusing me a bit
[13:26] <Saviq> MacSlow, those are separate surfaces
[13:26] <Saviq> MacSlow, all the shell is one, so you can use a MouseArea to prevent input reaching other layers of the shell
[13:27] <Saviq> MacSlow, but the apps are completely separate clients, they don't know about Shell's MouseAreas, nor does Mir
[13:27] <cjwatson> pitti: Yeah, Ursula fixed LP to copy translations along with everything else back in October
[13:27] <Saviq> MacSlow, InputFilterArea is communicating to Mir that input in this area should not be delivered to clients
[13:27] <MacSlow> Saviq, I changed my branch to use an InputFilterArea... cross-compiling now and then testing it
[13:28] <Saviq> MacSlow, you probably need both (MA for dash, IFA for other apps)
[13:28] <MacSlow> hm... ok
[13:28] <Saviq> MacSlow, FWIW that will change with Qt compositor, as apps there will be just as any other object in the QML scene, so MA will be enough
[13:30] <dpm> cjwatson, ok, I'll try, thanks!
[13:46] <dpm> cjwatson, for the core apps click packages that are installed by default: can I find them out via the seeds too? I guess not, so I'm wondering where to find out the default clicks, so that I can also use them to create the phone translation stats
[13:48] <cjwatson> dpm: http://people.canonical.com/~ubuntu-archive/click_packages/click_list
[13:48] <dpm> aha, perfect, thanks cjwatson
[14:36] <kdeuser56> pitti: what steps would have to be taken to enable dbgsym creation for the mainline kernel ppa?
[15:03] <LocutusOfBorg1> hi dholbach
[15:03] <LocutusOfBorg1> still there?
[15:14] <jamespage> bdmurray, if you are around, can you reject the juju-core upload from the saucy SRU queue
[15:15] <jamespage> bdmurray, I need to pull a bit out after some discussion with upstream
[15:15] <bdmurray> jamespage: sure, rejections are easy!
[15:16] <jamespage> bdmurray, the change drops one of the 'features' introduced so it should make life a bit easier
[15:16] <bdmurray> arges: speaking of SRUs could you look at whoopsie in saucy and whoopsie-daisy in precise?
[15:17] <arges> bdmurray: sure
[15:19] <dholbach> LocutusOfBorg1, as I said earlier... I was looking at the request generally - I don't have much of an idea of flex and can't judge it going into trusty - AFAICS trusty is "done" now
[15:19] <arges> bdmurray: so how come whoopsie doesn't have an ubuntu version?
[15:19] <arges> .33->.34
[15:20] <bdmurray> arges: because it is only in ubuntu
[15:21] <arges> bdmurray: but whoopsie has an ubuntu version?
[15:21] <arges> err whoopsie-daisy doesn't but whoopsie does
[15:21] <jamespage> bdmurray, OK - I uploaded a new version minus the 'update-bootstrap' plugin.
[15:22] <jamespage> bdmurray, the only other bit that's a bit hand wavey is bug 1254729
[15:23] <bdmurray> arges: looks like I made a mistake in the versioning back in january
[15:23] <infinity> arges: Eh?  You just mean the 0.2.24.1ubuntu1 in saucy-updates?  That's pretty much just the uploader of that SRU being silly, it should have been 0.2.24.1.1
[15:23] <arges> bdmurray: infinity ack. So just leave the new version as 0.2.24.1ubuntu2 or should that be 0.2.24.2 ?
[15:23] <arges> or even 0.2.24.1ubuntu1.1
[15:23] <jamespage> bdmurray, for which I'm proposing smoke testing to ensure nothing regressed (bearing in mind I've been using 1.16.6 with MAAS and OpenStack since Jan I've not seen any issues)
[15:23] <infinity> arges: 0.2.24.1.2, I would argue.
[15:24] <infinity> arges: Note the .1 in the middle there that you missed.  I assume 0.2.24.2 already existed in history.
[15:24] <LocutusOfBorg1> dholbach, fair enough, I think the same
[15:24] <arges> infinity: yup that's what i meant
[15:24] <infinity> Yeah https://launchpad.net/ubuntu/trusty/+source/whoopsie/0.2.24.2
[15:24] <LocutusOfBorg1> so, do you think is good to sync for "u" and SRU it, right?
[15:25] <infinity> arges: So, yeah, 0.2.24.1.2, and for bonus points, you could rertoactively changes the 1ubuntu1 entry in the changelog to .1.1 and wipe it out of history. ;)
[15:25] <arges> infinity: sure.   bdmurray mind if i handle that for you and you can approve?
[15:26] <bdmurray> arges: I'm mostly done with that change
[15:26] <arges> bdmurray: ok let me know and i'll rereview
[15:27] <dholbach> LocutusOfBorg1, you might want to read the SRU wiki page again
[15:27] <dholbach> LocutusOfBorg1, it explains quite well what SRU material is and what isn't
[15:28] <dholbach> and to me it looks like there's quite a bunch of changes in that release (even if they all / or the majority are bug fixes)
[15:33] <bdmurray> arges: uploaded
[15:34] <arges> bdmurray: ok accepted
[15:35] <LocutusOfBorg1> dholbach, maybe I can ask to the official developer a feedback? I know there is a line between SRU and backports, and it is difficult to choose sometimes
[15:35] <LocutusOfBorg1> they make many releases, but always with small changes
[15:35] <LocutusOfBorg1> and only bug fix
[15:36] <arges> infinity : so the new queue for precise: https://launchpad.net/ubuntu/precise/+queue?queue_state=0 these look like SRU updates, but somehow are here. should they be treated as SRUs, or is there another process these are waiting on.
[15:36] <dholbach> LocutusOfBorg1, if you can explain in the bug report why it's important to have the upload and what kind of testing you've done and what the impact might be, I think that'd help a lot
[15:36] <dholbach> LocutusOfBorg1, then you could get an answer from the release team
[15:37] <LocutusOfBorg1> yes, anyway let's wait for the release, and the sync
[15:37] <LocutusOfBorg1> after I'll try to test it as deeply as I can
[15:37] <LocutusOfBorg1> with maybe some upstream help
[15:37] <dholbach> ok cool
[15:38] <LocutusOfBorg1> BTW do you know why network-manager in precise is still in proposed queue?
[15:38] <LocutusOfBorg1> the tag verification-needed has been changed in verification-done
[15:38] <infinity> arges: They're SRUs, though also new binaries, so worth a cursory NEW review before otherwise SRU processing.
[15:38] <cyphermox> most likely just because nobody noticed.
[15:38] <cjwatson> arges: there's an LP bug that packages added entirely new post-release tend to be mistreated as NEW thereafter
[15:38] <infinity> arges: If you treat them as an SRU of the previous versioned packages (ie: debdiff against nvidia-thing-319 or whatever), you can get a pretty good idea of the state of things.
[15:39] <cjwatson> because four different subtly wrong ancestry calculation implementations
[15:39] <infinity> arges: And then they also need to have overrides applied, though I can do that in the queue right now.
[15:39] <arges> cjwatson: infinity : gotcha. I can review them if that ok.
[15:40] <mvo> jibel: re bug #1308056 - do you have that system available? what do you have in /var/lib/update-notifier/user.d/, could you pastebin or mail this to me please?
[15:41] <arges> infinity: these aren't even diffed against that there is already nvidia-graphics-drivers-331-331.20ubuntu0.0.1, this is just ubuntu0.0.2
[15:41] <infinity> arges: Alright, overrides fixed in the queue, if you want to review them.
[15:41] <arges> infinity: ok thanks
[15:41] <dholbach> LocutusOfBorg1, no idea - sorry
[15:41] <infinity> arges: Oh, those are already in in a previous version?
[15:41] <arges> infinity:  nvidia-graphics-drivers-331 | 331.20-0ubuntu0.0.1 | precise-updates/restricted | source
[15:41] <infinity> arges: In that case, yeah, just a lanuchpad bug that they're in NEW.
[15:41] <infinity> arges: So, treat like any other SRU.
[15:42] <arges> ok cool. just trying to not mess stuff up
[15:42] <infinity> arges: Well, was good to ask just so an AA could fix the overrides anyway.
[16:00] <xnox> GunnarHj: hey, are you around? i have a few regressions w.r.t. to incomplete language support.
[16:00] <xnox> GunnarHj: i believe it's related to previous SRUs you have done, together with the recent ubiquity bug you reported and a few other things that landed in the language-selector and account services.
[16:00] <xnox> specifically bug #1103547
[16:00] <xnox> bug #1134364
[16:24] <ogra_> xnox, your "remove all py2 from touch" hasnt happened yet, has it ?
[16:26] <xnox> ogra_: no, because my fixes are not getting merged and released.
[16:26] <ogra_> ok
[16:26] <xnox> ogra_: do you want a list of my merge proposals?
[16:26] <xnox> ogra_: ditto qt4 removal.
[16:27] <ogra_> just wanted to be sure, since the image scratches the 500M edge
[16:31] <xnox> GunnarHj: i'm thinking of landing http://paste.ubuntu.com/7256183/
[16:34] <GunnarHj> xnox: Thanks for letting me know. I'll comment on it in a few minutes.
[16:34] <Laney> xnox: patching a patch?
[16:34] <Laney> (0009-language-tools.patch)
[16:34] <xnox> GunnarHj: please review it.
[16:35] <xnox> Laney: also see plymouth - i think that patches patches of patches.
[16:35] <Laney> seems unideal
[16:37] <xnox> GunnarHj: please review, basically the problem is that "/usr/share/language-tools/language-options" says that "fr" is not needed to be installed, when it is not installed, but one did $ locale-gen fr_FR.utf8
[16:37] <xnox> GunnarHj: (as in the state one gets into after offline installation, which configured locale, set incomplete locale flag and did not install the langpacks/hunspell/etc)
[16:38] <GunnarHj> xnox: Will check it out indeed. I thought otherwise, but will check.
[16:39] <Laney> Please do merge it into the first patch
[16:39] <xnox> GunnarHj: interrsection is suppose to mean - desired, valid, not fully installed.
[16:39] <xnox> Laney: yeah, i will. In a sec.
[16:39] <Laney> Ta
[16:39] <GunnarHj> xnox: Please give me a few minutes.
[16:40] <xnox> GunnarHj: i'm still testing it, this is not even in the queue for the release team yet. Take as long as you need, it was not trivial for me to hunt down.
[16:41] <xnox> GunnarHj: in fact, we were hoping you would show up to review this =))))
[16:41] <Laney> xnox: well done finding it
[16:41] <GunnarHj> xnox: Ok. ;)
[16:41] <Laney> $translation_dirs{$_} = 1 for readdir $dh;
[16:41] <Laney> oh perl, you so kooky
[16:42] <GunnarHj> Laney: Don't pick on Perl.
[16:44] <xnox> GunnarHj: Laney: updated debdiff http://paste.ubuntu.com/7256240/
[16:46] <GunnarHj> xnox: Ok, thanks. Makes more sense to change the existing patch.
[17:11] <tjaalton> why on earth do ppa builds insist on building indep targets on amd64 too?
[17:12] <cjwatson> They don't ...
[17:12] <tjaalton> do for me
[17:12] <cjwatson> Your debian/rules is broken then
[17:12] <tjaalton> it's krb5
[17:12] <cjwatson> Example?
[17:12] <cjwatson> Like a +build
[17:12] <tjaalton> https://launchpad.net/~sssd/+archive/updates/+build/5911824
[17:13] <tjaalton> vs https://launchpad.net/~sssd/+archive/updates/+build/5911825
[17:14] <xnox> i thought loads of things will fail when doing arch build without indep build-deps.
[17:14] <xnox> cause debian is not doing it.
[17:15] <cjwatson> tjaalton: precise's dpkg-buildpackage didn't have the necessary smartness to honour build-arch yet
[17:15] <cjwatson> Debian #229357
[17:16] <cjwatson> (well, disregard the implied solution in the bug title)
[17:16] <cjwatson> That was added in dpkg 1.16.2, so quantal
[17:16] <tjaalton> ahah, that would explain it then, thanks
[17:21] <GunnarHj> xnox: If I understand it correctly, what you suggest would redefine what constitutes an installed language. You would no longer be able to generate a locale without l-s starting to prompt you about installing everything.
[17:21] <xnox> GunnarHj: in my testing, l-s is only asking me to install missing things.
[17:22] <xnox> GunnarHj: as it's limited by "locale -a" in the first place, e.g. one typically on has en and enabled locale.
[17:22] <xnox> GunnarHj: if someone will go and actually generate all locales, indeed all language packs will be requested to be installed.
[17:22] <xnox> GunnarHj: at the moment, however, the bug is that _no_ language packs are ever installed at all, but "en".
[17:23] <xnox> GunnarHj: this is actually revert to what the code was before one of the SRUs into precise.
[17:23] <GunnarHj> xnox: Yes, but the possibility to generate a locale without installing the language is intentional. I think cjwatson can confirm that.
[17:23] <xnox> GunnarHj: that's what the installer does, to trigger langpack installation....
[17:24] <xnox> (possibly at a later time when network is available)
[17:24] <xnox> GunnarHj: there is a separate flag to actually block the lang-pack installation.
[17:25] <GunnarHj> xnox: When you have tested, did you check if the language appeared in "Installed languages" in l-s?
[17:25] <xnox> I'm trying to fix bugs "System not localized after an OEM installation" and "language packs not installed after a non-network installation in a non-english language " as in no language packs installed automatically post-install.
[17:26] <xnox> GunnarHj: "When you have tested, did you check if the language appeared in "Installed languages" in l-s?" at which stage? patch applied, locale generated, and no packages for that locale installed?
[17:26] <xnox> GunnarHj: I can test that in a second.
[17:26] <GunnarHj> xnox: Yes.
[17:27] <cjwatson> it's certainly intentional that you can generate a bare locale, but I don't see a reason not to flag it as incomplete support ...
[17:27] <cjwatson> can't you dismiss it and tell it to shut up?
[17:27] <GunnarHj> cjwatson: No, there is no way to tell it to shut up. ;)
[17:28] <GunnarHj> cjwatson: I mean, you'll be prompted whenever you start l-s if you don't install.
[17:28] <xnox> GunnarHj: it shuts up after the first time.
[17:29] <cjwatson> do we need another flag to check-language-support for use by the installer?
[17:29] <cjwatson> GunnarHj: oh, well, sure, but I never start l-s so who cares ;-)
[17:29] <cjwatson> I would care about notification spam
[17:29] <xnox> yeah the auto popup goes away.
[17:29] <GunnarHj> xnox: Does it?
[17:29] <cjwatson> I think it would be reasonable enough for l-s to bug people with extra bare locales
[17:29] <cjwatson> if started manually, which is rare
[17:29] <xnox> GunnarHj: yeah, it has a separate flag which is cleared.
[17:30] <xnox> GunnarHj: but i will test it again here.
[17:31] <GunnarHj> xnox: I'd like to do some testing and think more about it. Can we talk more about it tomorrow?
[17:32] <xnox> GunnarHj: we kind of have a release to make on thursday, and no language packs installed after OEM configuration is very bad for all our OEMs.
[17:33] <xnox> GunnarHj: oem-config does not configure network and pull language packs, the way normal ubiquity installation does.
[17:33] <GunnarHj> xnox: So this is going into the release??
[17:33] <xnox> GunnarHj: i want this to go into release yes.
[17:33] <xnox> otherwise i wouldn't be patching this now & extensively testing.
[17:34] <GunnarHj> xnox: I see.
[17:34] <GunnarHj> xnox: How long will you be there today?
[17:35] <xnox> GunnarHj: if my testing doesn't show any regression on past fixed bugs w.r.t. this we will respin for it probably in a few hours.
[17:35] <xnox> GunnarHj: if we need to further fix this post-release, we will be able to do zero-day SRU etc.
[17:36] <xnox> GunnarHj: this will also will need fixing for 12.04.5
[17:37] <GunnarHj> xnox: Ok, I see. Actually I have a feeling that it will lead to undesired effects that we'll need to take care of as SRUs.
[17:41] <xnox> GunnarHj: hm, yeah, i don't see it do the right thing yet.
[17:41] <GunnarHj> xnox: One thought I have right now is that the installer might be changed to create empty /usr/share/locale-langpack/[lang] directories when installing without the net.
[17:41] <xnox> GunnarHj: it did not install anything for me now.
[17:41] <GunnarHj> xnox: Ok..
[17:41] <cjwatson> Would empty directories help?
[17:42] <GunnarHj> cjwatson: I'm not sure. Just a thought so far...
[17:42] <xnox> cjwatson: we'd need a subdir for the locale, yeah.
[17:42] <cjwatson> It would certainly be possible
[17:42] <xnox> cjwatson: let me test.
[17:42] <cjwatson> If that fixes it it would be less invasive
[17:48] <xnox> ogra_: gtk2 is back on touch image
[17:48] <xnox> ogra_: and i've explicitely removed it
[17:48] <xnox> ogra_: also for the same reason appmenu will get a reject now.
[17:51] <seb128> hum
[17:51] <seb128> would be handy to have ddeb sources on the porter boxes
[17:55] <jtaylor> did something change with the python gdb extensions?
[17:55] <jtaylor> they aren't loading for me anymore, they used to a week ago
[17:56] <GunnarHj> xnox, cjwatson: I made a quick-n-dirty test on 13.10 where I am right now, and it looks promising.
[17:56] <xnox> GunnarHj: creating directories?
[17:56] <GunnarHj> xnox, cjwatson: I added the "fi" directory and did 'sudo locale-gen fi_FI.UTF-8'. It was pulled nicely after that.
[17:57] <xnox> GunnarHj: hm, not doing that here.
[17:57] <xnox> let me try again.
[17:58] <xnox> GunnarHj: nevermind, had dirs in the wrong place.
[17:59] <xnox> GunnarHj: looks good now.
[17:59] <GunnarHj> xnox: That solution would make me feel better. :)
[18:00] <jtaylor> doko: since the last or before last python3 update the gdb debug extensions aren't loading anymore
[18:00] <jtaylor> doko: its expecing them as python3.4-dbg.py now instead of python3.4m-dbg.py
[18:22] <doko> jtaylor, hmm, can't see what should have changed ...
[18:33] <jtaylor> qives the changelog gives no clue
[18:33] <jtaylor> I also have no idea how gdb actually tries to load it
[18:36] <GunnarHj> xnox: Do you think it's doable to make the installer create such empty dirs?
[18:37] <xnox> GunnarHj: yes, we are now moving bug 1307983 to d-i.
[18:37] <xnox> GunnarHj: well localechooser.
[18:38] <GunnarHj> xnox: Ok, sounds good. Thanks for letting me know.
[20:41] <smoser> xnox, around ?
[20:42] <smoser> http://paste.ubuntu.com/7257532/
[20:43] <smoser> how much can i trus tthe order of that output.
[20:45] <smoser> i ask because 'Clean /tmp/directory' (line 373) I think is /etc/init/mounted-tmp.conf which is
[20:45] <smoser>   start on (mounted MOUNTPOINT=/tmp) or (mounted MOUNTPOINT=/usr)
[20:45] <smoser> i woudl have thought that was guaranteed to happen after (and be blocked by) cloud-init-local (line381)
[20:45] <smoser> which is
[20:45] <smoser>  start on mounted MOUNTPOINT=/
[20:47] <smoser> oh yeah, and thank you!. that output looks so much better now.
[21:08] <jtaylor> doko: was bin/python3.4 a symlink before?
[21:08] <jtaylor> it seems gdb just loads <filename>-gdb.py
[21:09] <jtaylor> this might have worked if python3.4 was a link to python3.4m before
[21:10] <jtaylor> or I' was always just using python3-dbg which is a symlink to the right named file, hmmm
[21:35] <doko> jtaylor, so maybe we need two -gdb.py files
[21:35] <jtaylor> or a symlink yes
[21:35] <jtaylor> I added a copy with the right filename and it works
[21:37] <jtaylor> out of curiousity why are there two identical python binaries installed?
[21:37] <doko> these are hard links
[21:37] <doko> done upstream.
[21:37] <jtaylor> oh
[21:38] <doko> jtaylor, does it work when you make python3.4 a symlink to python3.4m?
[21:38] <jtaylor> let me try
[21:38] <doko> /usr/lib/debug/usr/bin/python3.4dm-gdb.py
[21:38] <doko> /usr/lib/debug/usr/bin/python3.4-dbg-gdb.py
[21:39] <doko> these are there, so that's why the -dbg works
[21:39] <jtaylor> no symlink of python3.4 does not work
[21:40] <jtaylor> oh wait it does I linked it to 3.3 ...
[21:41] <doko> ok, then I'll add the python3.4m-gdb.py symlink
[21:42] <doko> I mean, python3.4-gdb.py
[21:44] <jtaylor> btw the test is just: gdb python3; py-list
[21:44] <jtaylor> if it gives you unknown command it doesn't work
[21:45] <jtaylor> or if it gives you "add to save-load blabla" it which means it worked but you need to edit your ~/.gdbinit
[21:45] <jtaylor> add-auto-load-safe-path