=== rww is now known as ubuparty === ubuparty is now known as rww === maclin__ is now known as maclin [06:15] Good morning [06:16] 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] doko: thanks for the apport speedup patch! I reuploaded with the missing extra import, see bug report [06:49] good morning [07:08] 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] Is a pbuilder chroot with build-essential installed but missing the initscripts package considered complete or not (AKA broken)? [07:50] 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] aptitude didn't yell at me, it seems [07:54] Oh, actually, apt won't either. [07:55] Laibsch: So, no, that wouldn't be "broken" from a policy perspective, FWIW. "build-essential" consists of "essential" + "build-essential", not required. [07:55] Laibsch: From a "will Ubuntu consider that a sane and supportable system" perspective, though, it's totally broken. :) [07:55] So, it depends on your context. [07:55] 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] 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] Laibsch: Yes. [07:56] OK [07:56] Laibsch: Though, I assume you mean in the mountall package... [07:56] reopening bug 1307883, then [07:56] bug 1307883 in openjdk-7 (Ubuntu) "openjdk-7-jre fails to install in pbuilder chroot" [Undecided,Invalid] https://launchpad.net/bugs/1307883 [07:57] pitti: Hi. Could you help me check https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1303819 on precise? [07:57] Launchpad bug 1303819 in bluez (Ubuntu Precise) "Bluetooth menu's content disappeared after resume." [Undecided,In progress] [07:57] openjdk-7-jre calls mountall in postinst but does not declare a dependency (run-time, actually) [07:58] Laibsch: Hrm, I don't see it calling mountall. [07:58] Laibsch: I just see it wanting /proc mounted. [07:58] Laibsch: And a system without proc mounted is absolutely broken. [07:58] sorry [07:58] mountall [07:58] /var/lib/dpkg/info/ca-certificates-java.postinst: line 90: mountpoint: command not found [07:58] pitti: oops. sorry. I found it at https://launchpad.net/ubuntu/precise/+queue?queue_state=1. [07:59] and now that I look at it the problem might be in ca-certificates-java, not the jre [07:59] infinity: proc is mounted [07:59] FourDollars: right, it's waiting for the SRU team to review/accept [07:59] Laibsch: Oh, yeah, I can't read. [07:59] infinity: relax, me neither ;-) [08:00] Laibsch: So yes, indeed, that has a runtime dep on initscripts, which isn't Essential, so should be declared. [08:00] pitti: I see. Thanks. [08:00] infinity: thanks, I reopened the ticket. against the correct package. [08:03] 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] infinity: actually, openjdk-7-jre is affected as well verified by the line [08:04] /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] 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] 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] That said, it was never Essential:yes, so deps should exist. [08:07] Frankly, I think it's a glorious feature that upstart and udev aren't accidentally in the Essential set anymore. [08:08] And initscripts isn't essential in Debian either, afair. [08:08] Oh, no. It is. [08:08] * infinity ponders how and why. [08:09] Oh, util-linux depends on it directly. [08:09] So, that could solve other buggy packages here. [08:11] 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] I don't speak pbuilder. [08:12] 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] EXTRAPACKAGES="ccache lintian XXX" [08:13] 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] from the manpage [08:13] "Also ..." [08:13] yes, I know, but it might not actually behave that way [08:13] I see [08:13] it looks like it [08:13] it's just a suspicion [08:13] what are people using these days for building? [08:13] sbuild + apt-cacher-ng + tmpfs = ♥ [08:14] I've heard a lot of new commands thrown around [08:14] I'm already using acng [08:14] love, certainly when my download speed drops to less than 10Kbit (yes, bit) out in the jungle ;-) [08:14] 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:14] Launchpad bug 1307883 in openjdk-7 (Ubuntu) "ca-certificates-java misses runtime dependency on initscripts" [Undecided,New] [08:15] 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] acng + tmpfs is the best thing ever. [08:15] Instant build-deps. [08:16] how does the tmpfs come into play? I assume it's for speed reasons [08:16] infinity: yeah, that's why I sticked 16 GB into my new laptop (also for LXC/qemu), it just rocks :) [08:16] Laibsch: yes; muchly [08:16] how to use? [08:16] what do you mount on tmpfs? [08:16] even on a 500 MB/s SSD the difference is significant, mostly due to fsync and friends [08:16] Laibsch: Yeah, doing union (aufs or overlayfs) builds backed in tmpfs, so file ops are instant and cleanup is quick. [08:17] /var/lib/schroot/union/overlay -> /tmp [08:17] /var/lib/schroot/unpack -> /tmp [08:17] pitti: I don't bother with the second one. [08:17] infinity: I use tarballs for most of my schroots, so I need both [08:17] Laibsch: mount a tmpfs on /var/cache/pbuilder/build (if you using pbuilder) [08:17] pitti: Oh, right. [08:18] geser: Is that a filesystem overlay, or just the directory where the build happens? [08:18] 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] Cause I/O matters almost nothing to the build itself, it's the build-dep install that hurts. [08:19] 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] 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] geser: Ahh, kay. So, the whole thing. That would do, yes. [08:20] and other tweaks are things like "export-dir = /tmp/build-area/" in ~/.gbp.conf [08:22] 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] Laibsch: no, if /tmp is full there is no automatic overflow to swap [08:23] things will just go haywire [08:24] how does changelogs.u.c work? [08:24] OK, I'll postpone the speed optimization, then. [08:24] I think something has gone wrong with it updating [08:24] Laney, mvo probably knows [08:26] Laney: there is a lp-changelogs-crawler running on changelogs.u.c [08:26] Laney: it appears I do not have a login anymore, hrm [08:29] mvo: Go abuse IS into giving you it back :P [08:29] Laney: I send a rt and asked for access [08:29] Seems it hasn't updated since last Thursday-ish [08:29] did a little bisect using trusty-changes === mbiebl_ is now known as mbiebl [08:43] 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:43] bug 1307904 in ubuntu-release-upgrader (Ubuntu) "Cannot upgrade to 14.04" [Undecided,New] https://launchpad.net/bugs/1307904 [08:44] jibel: sure [08:57] I am looking for networking team, to work with them. [08:59] Any one around? who can help me with my query ? [09:00] jibel: fixed [09:01] mvo, thanks [09:05] jibel: thank you! [09:10] bipul: what do you mean by 'the networking team' [09:11] zyga, any ubuntu projects related to networking. [09:11] bipul: I don't think there is a team of that kind [09:12] bipul: if you can be more precise than networking then you might find what you are looking for [09:12] zyga, or any development team, related to programming. [09:12] bipul: ubuntu is developed by a large number of distributed people [09:13] bipul: perhaps you should just ask your question [09:14] zyga, I am looking for a development team where i can do contribution and also to learn. [09:15] 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] where i can get the upstream projects ? [09:17] bipul: wherever they are hosted, for example you can find out about network-manager using: [09:17] apt-cache show network-manager | grep Homepage === tkamppeter_ is now known as tkamppeter === MacSlow is now known as MacSlow|lunch [10:36] 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] looking at the source I see this is hardcoded [10:47] pitti: is this worth fixing for trusty? [10:47] zyga: sounds easy enough, and it's certainly not on any image [10:47] pitti: I have a debdiff, what should I do with it? [10:48] zyga: subscribe sponsors for now; I'll try to have a look in the next hours [10:48] http://paste.ubuntu.com/7254566/ [10:48] ko [10:48] pitti: so open a bug on the trusty package, attach the debdiff and subscribe sponsors, anything else? [10:49] that sounds like the usual approach [10:49] ok, thanks [10:49] zyga: if the release team is happy for it to go in without a bug, I can also just upload the debdiff [10:50] zyga: but at least this warrants a Debian bug -- this certainly shoudln't hardcode "saucy" but use /etc/os-release [10:50] pitti: it's more "smart" than that, it has several profiles [10:51] meh, and it even calls lsb_release already [10:51] perhaps it should use python-distro-info instead to get the devel release [10:51] zyga: anyway, uploaded; please do the above if the release team wants bug reports at this point [10:54] pitti: https://bugs.launchpad.net/ubuntu/+source/piuparts/+bug/1307995 [10:54] Launchpad bug 1307995 in piuparts (Ubuntu) "piuparts hardcodes 'saucy' as the default ubuntu version" [Undecided,New] [10:54] pitti: uploaded as in you've fixed this in the archive? [10:55] zyga: as in I uploaded your debdiff [10:55] zyga: I'll reupload with that bug ref [10:55] pitti: ah, thanks [10:55] zyga: oh, it was auto-accepted: https://launchpad.net/ubuntu/+source/piuparts/0.56ubuntu1 [10:55] seems universe still isn't deep-frozen [10:56] pitti: cool, thanks :-) [10:56] pitti: so should I do anything else at this time or is this enough? [10:58] zyga: seems fine; a Debian bug about this would be nice though [10:58] pitti: ok, I'll try to do that [10:58] * zyga keeps forgetting how to use reportbug on ubuntu to target debian [10:59] pitti / jibel: Would it be a good idea to add -o IdentitiesOnly=yes to etc/config in lp:auto-package-testing? [10:59] I was just getting the old 'too many authenticaiton failures' [11:02] Laney: I don't know what that does, I'm afraid [11:03] pitti: Basically makes it ignore the agent provided identities and just use the one given on the commandline [11:05] Laney: seems to work alright here [11:05] It happens if you have a lot of identities in the agent [11:06] Laney: http://paste.ubuntu.com/7254656/ ? [11:06] lgtm [11:06] Laney: pushed [11:06] cheers [11:07] 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] in your agent, you mean? [11:07] yep === zyga is now known as zyga-afk === _salem is now known as salem_ [11:15] 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] 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] dholbach, you there? [11:19] I saw your comment on the sync request [11:19] maybe is faster to discuss here [11:19] :) === salem_ is now known as _salem [11:36] LocutusOfBorg1, I just wanted to generally provide some links to how to get an upload considered for backports/SRUs [11:36] LocutusOfBorg1, but sure... how can I help? [11:36] I would like to have it for trusty [11:36] :) [11:36] sorry leaving [11:37] ... ok [11:38] for whoever is wondering what this was about, here's the link: bug https://bugs.launchpad.net/ubuntu/+source/flex/+bug/1307604 [11:38] Launchpad bug 1307604 in flex (Ubuntu) "Sync flex 2.5.39-1 (main) from Debian unstable (main)" [Undecided,New] [11:43] dpm: ping [11:43] dpm: https://bugs.launchpad.net/langpack-o-matic/+bug/1267763 < needs adding to langpack-o-matic [11:43] Launchpad bug 1267763 in langpack-o-matic "kde-config-whoopsie not localized" [Undecided,New] [11:43] hey shadeslayer [11:44] shadeslayer, you'll need to ping pitti for the langpack-o-matic side of things [11:45] pitti: ^^ [11:46] pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1278142 [11:46] Launchpad bug 1278142 in langpack-o-matic "kubuntu-driver-manager not localized " [Undecided,New] [11:48] dpm: https://translations.launchpad.net/ubuntu/trusty/+source/kde-config-whoopsie/+imports < templates are imported but not approved? [11:48] shadeslayer, if the're imported, they've been approved :) [11:48] ah I see [11:48] the workflow is Needs Review > Approved > Imported [11:49] ah ok [11:49] dpm: https://bugs.launchpad.net/ubuntu/+source/intltool/+bug/953342 < needs intltool release [11:49] Launchpad bug 953342 in intltool (Ubuntu) "Add support for Qt Designer UI files" [Medium,Triaged] [11:51] 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] bug 980130 in dict-st (Ubuntu) "package myspell-st 20070206-4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/980130 [11:51] shadeslayer, I know. You might want to ping danilo and dobey as intltool maintainers for a new release [11:52] dobey: ^^ could we get a release pretty please :) [11:55] pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1267765 [11:55] Launchpad bug 1267765 in langpack-o-matic "kdesudo not localized" [Undecided,New] [11:55] pitti: all 3 need to be added to langpack-o-matic [11:56] geser: The postinst is automatically generated & a no-change rebuild gets rid of it [11:56] I don't know if the package works or does anything useful though [11:57] It does at least ship files in useful locations... [11:58] me neither, but I try to get a SRU for it in the next days to fix this error at least [11:58] I think there are other myspell-* packages that do the same [12:30] shadeslayer: hm, why aren't these in kde-l10n-*? [12:30] shadeslayer: I thought the -base packages only contained the kubuntu specific strings? [12:32] shadeslayer: driver-manager added === greyback_ is now known as greyback|lunch [13:09] pitti: because at the very least whoopsie/driver manager are kubuntu specific things [13:09] and not part of sc === MacSlow|lunch is now known as MacSlow [13:10] shadeslayer: yes, I added that [13:10] pitti: whoopsie too? [13:10] shadeslayer: I was wondering about kdesudo [13:10] ah that, I am unsure, apachelogger ^^ [13:11] shadeslayer: whoopsie? I didn't see that bug [13:11] space ships, what? [13:11] kdesudo is kubuntu specific right now [13:11] perhaps we'll get to change that some time not too far in the future [13:11] shadeslayer: ah, doing now [13:11] pitti: https://bugs.launchpad.net/langpack-o-matic/+bug/1267763 [13:11] Launchpad bug 1267763 in langpack-o-matic "kde-config-whoopsie not localized" [Undecided,New] [13:13] 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] shadeslayer: all done [13:16] seb128: is bug 1201485 still actually an issue? [13:16] bug 1201485 in Ubuntu Translations "Need to import translations for the unity daily builds" [High,Triaged] https://launchpad.net/bugs/1201485 [13:17] pitti, no, it's launchpad fix released, the other lines are probably invalid [13:17] seb128: ah, so PPA copying copies along the translations.tar.gz now? nice [13:17] 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] pitti, I think so [13:18] the MP times out to load [13:18] seb128: ack, thanks === greyback|lunch is now known as greyback [13:19] pitti, yw! [13:24] Saviq, hm... the input filterarea doesn't work reliably... it's swallowing input when on the dash, but not in apps... investigating [13:24] Saviq, MouseArea I meant [13:24] MacSlow, yeah, you need to use an InputFilterArea [13:25] MacSlow, as well, that is [13:26] Saviq, but it (the modal-backgrounds MouseArea) swallows input for the Dash... that's confusing me a bit [13:26] MacSlow, those are separate surfaces [13:26] MacSlow, all the shell is one, so you can use a MouseArea to prevent input reaching other layers of the shell [13:27] MacSlow, but the apps are completely separate clients, they don't know about Shell's MouseAreas, nor does Mir [13:27] pitti: Yeah, Ursula fixed LP to copy translations along with everything else back in October [13:27] MacSlow, InputFilterArea is communicating to Mir that input in this area should not be delivered to clients [13:27] Saviq, I changed my branch to use an InputFilterArea... cross-compiling now and then testing it [13:28] MacSlow, you probably need both (MA for dash, IFA for other apps) [13:28] hm... ok [13:28] 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] cjwatson, ok, I'll try, thanks! === zyga-afk is now known as zyga === _salem is now known as salem_ [13:46] 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] dpm: http://people.canonical.com/~ubuntu-archive/click_packages/click_list [13:48] aha, perfect, thanks cjwatson === benrodrigue is now known as brod [14:36] pitti: what steps would have to be taken to enable dbgsym creation for the mainline kernel ppa? [15:03] hi dholbach [15:03] still there? [15:14] bdmurray, if you are around, can you reject the juju-core upload from the saucy SRU queue [15:15] bdmurray, I need to pull a bit out after some discussion with upstream [15:15] jamespage: sure, rejections are easy! [15:16] bdmurray, the change drops one of the 'features' introduced so it should make life a bit easier [15:16] arges: speaking of SRUs could you look at whoopsie in saucy and whoopsie-daisy in precise? [15:17] bdmurray: sure [15:19] 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] bdmurray: so how come whoopsie doesn't have an ubuntu version? [15:19] .33->.34 [15:20] arges: because it is only in ubuntu [15:21] bdmurray: but whoopsie has an ubuntu version? [15:21] err whoopsie-daisy doesn't but whoopsie does [15:21] bdmurray, OK - I uploaded a new version minus the 'update-bootstrap' plugin. [15:22] bdmurray, the only other bit that's a bit hand wavey is bug 1254729 [15:22] bug 1254729 in juju-core (Ubuntu Saucy) "Update Juju to make a "safe mode" for the provisioner" [Undecided,New] https://launchpad.net/bugs/1254729 [15:23] arges: looks like I made a mistake in the versioning back in january [15:23] 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] bdmurray: infinity ack. So just leave the new version as 0.2.24.1ubuntu2 or should that be 0.2.24.2 ? [15:23] or even 0.2.24.1ubuntu1.1 [15:23] 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] arges: 0.2.24.1.2, I would argue. [15:24] arges: Note the .1 in the middle there that you missed. I assume 0.2.24.2 already existed in history. [15:24] dholbach, fair enough, I think the same [15:24] infinity: yup that's what i meant [15:24] Yeah https://launchpad.net/ubuntu/trusty/+source/whoopsie/0.2.24.2 [15:24] so, do you think is good to sync for "u" and SRU it, right? [15:25] 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] infinity: sure. bdmurray mind if i handle that for you and you can approve? [15:26] arges: I'm mostly done with that change [15:26] bdmurray: ok let me know and i'll rereview [15:27] LocutusOfBorg1, you might want to read the SRU wiki page again [15:27] LocutusOfBorg1, it explains quite well what SRU material is and what isn't [15:28] 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] arges: uploaded [15:34] bdmurray: ok accepted [15:35] 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] they make many releases, but always with small changes [15:35] and only bug fix [15:36] 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] 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] LocutusOfBorg1, then you could get an answer from the release team [15:37] yes, anyway let's wait for the release, and the sync [15:37] after I'll try to test it as deeply as I can [15:37] with maybe some upstream help [15:37] ok cool [15:38] BTW do you know why network-manager in precise is still in proposed queue? [15:38] the tag verification-needed has been changed in verification-done [15:38] arges: They're SRUs, though also new binaries, so worth a cursory NEW review before otherwise SRU processing. [15:38] most likely just because nobody noticed. [15:38] arges: there's an LP bug that packages added entirely new post-release tend to be mistreated as NEW thereafter [15:38] 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] because four different subtly wrong ancestry calculation implementations [15:39] arges: And then they also need to have overrides applied, though I can do that in the queue right now. [15:39] cjwatson: infinity : gotcha. I can review them if that ok. [15:40] 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:40] bug 1308056 in language-selector (Ubuntu) "language packs not installed after a non-network installation in a non-english language" [High,New] https://launchpad.net/bugs/1308056 [15:41] 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] arges: Alright, overrides fixed in the queue, if you want to review them. [15:41] infinity: ok thanks [15:41] LocutusOfBorg1, no idea - sorry [15:41] arges: Oh, those are already in in a previous version? [15:41] infinity: nvidia-graphics-drivers-331 | 331.20-0ubuntu0.0.1 | precise-updates/restricted | source [15:41] arges: In that case, yeah, just a lanuchpad bug that they're in NEW. [15:41] arges: So, treat like any other SRU. [15:42] ok cool. just trying to not mess stuff up [15:42] arges: Well, was good to ask just so an AA could fix the overrides anyway. [16:00] GunnarHj: hey, are you around? i have a few regressions w.r.t. to incomplete language support. [16:00] 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] specifically bug #1103547 [16:00] bug 1103547 in language-selector (Ubuntu Precise) "drag and drop does not work language support not complete" [Medium,Fix released] https://launchpad.net/bugs/1103547 [16:00] bug #1134364 [16:01] bug 1134364 in language-selector (Ubuntu Precise) "Check for missing language support for all installed languages" [Undecided,Fix released] https://launchpad.net/bugs/1134364 === trijntje_ is now known as trijntje [16:24] xnox, your "remove all py2 from touch" hasnt happened yet, has it ? [16:26] ogra_: no, because my fixes are not getting merged and released. [16:26] ok [16:26] ogra_: do you want a list of my merge proposals? [16:26] ogra_: ditto qt4 removal. [16:27] just wanted to be sure, since the image scratches the 500M edge [16:31] GunnarHj: i'm thinking of landing http://paste.ubuntu.com/7256183/ [16:34] xnox: Thanks for letting me know. I'll comment on it in a few minutes. [16:34] xnox: patching a patch? [16:34] (0009-language-tools.patch) [16:34] GunnarHj: please review it. [16:35] Laney: also see plymouth - i think that patches patches of patches. [16:35] seems unideal [16:37] 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] 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] xnox: Will check it out indeed. I thought otherwise, but will check. [16:39] Please do merge it into the first patch [16:39] GunnarHj: interrsection is suppose to mean - desired, valid, not fully installed. [16:39] Laney: yeah, i will. In a sec. [16:39] Ta [16:39] xnox: Please give me a few minutes. [16:40] 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] GunnarHj: in fact, we were hoping you would show up to review this =)))) [16:41] xnox: well done finding it [16:41] xnox: Ok. ;) [16:41] $translation_dirs{$_} = 1 for readdir $dh; [16:41] oh perl, you so kooky [16:42] Laney: Don't pick on Perl. === superm1_ is now known as superm1 [16:44] GunnarHj: Laney: updated debdiff http://paste.ubuntu.com/7256240/ [16:46] xnox: Ok, thanks. Makes more sense to change the existing patch. === lutostag is now known as lutostag-away === bfiller is now known as bfiller_afk [17:11] why on earth do ppa builds insist on building indep targets on amd64 too? [17:12] They don't ... [17:12] do for me [17:12] Your debian/rules is broken then [17:12] it's krb5 [17:12] Example? [17:12] Like a +build [17:12] https://launchpad.net/~sssd/+archive/updates/+build/5911824 [17:13] vs https://launchpad.net/~sssd/+archive/updates/+build/5911825 [17:14] i thought loads of things will fail when doing arch build without indep build-deps. [17:14] cause debian is not doing it. [17:15] tjaalton: precise's dpkg-buildpackage didn't have the necessary smartness to honour build-arch yet [17:15] Debian #229357 [17:15] Debian bug 229357 in dpkg-dev "dpkg-buildpackage: support for Build-Options: build-arch" [Wishlist,Fixed] http://bugs.debian.org/229357 [17:16] (well, disregard the implied solution in the bug title) [17:16] That was added in dpkg 1.16.2, so quantal [17:16] ahah, that would explain it then, thanks [17:21] 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] GunnarHj: in my testing, l-s is only asking me to install missing things. [17:22] GunnarHj: as it's limited by "locale -a" in the first place, e.g. one typically on has en and enabled locale. [17:22] GunnarHj: if someone will go and actually generate all locales, indeed all language packs will be requested to be installed. [17:22] GunnarHj: at the moment, however, the bug is that _no_ language packs are ever installed at all, but "en". [17:23] GunnarHj: this is actually revert to what the code was before one of the SRUs into precise. [17:23] xnox: Yes, but the possibility to generate a locale without installing the language is intentional. I think cjwatson can confirm that. [17:23] GunnarHj: that's what the installer does, to trigger langpack installation.... [17:24] (possibly at a later time when network is available) [17:24] GunnarHj: there is a separate flag to actually block the lang-pack installation. [17:25] xnox: When you have tested, did you check if the language appeared in "Installed languages" in l-s? [17:25] 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] 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] GunnarHj: I can test that in a second. [17:26] xnox: Yes. [17:27] 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] can't you dismiss it and tell it to shut up? [17:27] cjwatson: No, there is no way to tell it to shut up. ;) [17:28] cjwatson: I mean, you'll be prompted whenever you start l-s if you don't install. [17:28] GunnarHj: it shuts up after the first time. [17:29] do we need another flag to check-language-support for use by the installer? [17:29] GunnarHj: oh, well, sure, but I never start l-s so who cares ;-) [17:29] I would care about notification spam [17:29] yeah the auto popup goes away. [17:29] xnox: Does it? [17:29] I think it would be reasonable enough for l-s to bug people with extra bare locales [17:29] if started manually, which is rare [17:29] GunnarHj: yeah, it has a separate flag which is cleared. [17:30]