[00:00] apw: i think it's also turned off for 3.18.9, i'm not sure if the name has changed (it might have, but i think start from 3.16) [01:20] pitti: Heh, well if it matters it popped up the volume again, either right after unpacking systemd or libpam-systemd. :P === Elimin8r is now known as Elimin8er === rmk` is now known as rmk === inaddy is now known as tinoco === beisner- is now known as beisner === mchro- is now known as mchro === not_phunyguy is now known as phunyguy [06:02] kirkland: right, fix-invalid-cryptswap.sh is what needs to go into postinst, protected with the usual "run this on upgrades to this version" dpkg --compare-version [06:03] smoser: yes, the init= on cloud images is hopefully temporary; I don't know exactly where this is done, but someone (Odd_Bloke or utlemming, don't remember) told me it's going away now [06:04] rbasak: yes, of course; it needs the release team to add a permanent "I know the test of this version is broken" exception, but I can wave through this particular one [06:04] Unit193: oh, can you reproduce this with apt-get install --reinstall systemd? If so, can you reproduce it with "sudo systemctl daemon-reload"? [06:04] ... and Good morning! [06:08] hey pitti [06:08] Howdy. [06:08] hey darkxst! [06:08] so that retracer failure was from nettle changing nettle-dbg from a folder to a symlink [06:09] I guess dpkg has no idea about those changes [06:09] do you purge your sandboxes regularly? [06:09] darkxst: ah, you have a permanent sandbox! [06:09] pitti: Yes, yes. [06:09] darkxst: no, I use temporary sandboxes on the Launchpad retracers [06:10] darkxst: errors.u.c. uses permanent ones, though [06:10] I haven't gotten a report about that yet [06:10] but yes, symlinked directories are handled specially by dpkg [06:10] and packages need to be super careful when doing this change [06:11] pitti, mainscript was added in Jan [06:11] +dir_to_symlink /usr/share/doc/nettle-dbg libnettle4 2.7.1-5~ nettle-dbg [06:12] but I have only seen the error a handful of times [06:12] right, but dpkg-deb -x obviously doesn't run them [06:12] yes clearly [06:17] pitti, I suppose you have the sandboxes in tmpfs? [06:18] (on the launchpad retracer) [06:18] darkxst: no, I don't, as I don't have any root privs on the retracer box so I can't set that up [06:18] it's a plain fs [06:19] does it make much difference to speed? [06:19] it has never been a measurable bottleneck TBH [06:20] tmpfs would certainly be a lot faster [06:26] ok, may try it with temporary sandboxes for a bit see how it goes [06:27] btw sent through a patch to make apport-retracer look in the sandbox for python scripts (pretty printers etc) [06:28] s/for gdb to look in the sandbox/ [06:32] darkxst: I saw, thanks! [06:37] pitti: Any specific reason why it'd do that? [06:38] Unit193: I don't know, that's what I'm trying to find out :) but daemon-reload restarts generators and also does a few things, we need to zero in what causes it [06:43] OK, sure. No problem. [06:43] I just found out I have to turn the music off before certain upgrades, or I'm in for a jump. :D [06:45] haha [06:45] Unit193: if you can reproduce it with reinstall/daemon-reload, can you please file a bug, so that we have a place for logs and tracking? [06:55] Alright.. [07:19] Meh, looked at the journel, started to suspect something. It was in alsa-restore/alsa-store. [07:19] Seems to be only triggering the former. [07:33] Unit193: right, that makes sense, I suspected the ALSA script; but I wonder why it's being re-run [07:33] At least stored it at a lower volume. [07:34] Unit193: ok, please file a bug, this shouldn't be too hard to at least track down and understand why it happens [07:37] pitti: Sure. Not really sure what else to add, so 1431200. [07:38] err, daemon-reload surely? [07:41] Right, that. 4am brings typos to bugs. Sorry. [07:42] Unit193: no worries, it most likely happens with daemon-reexec too [07:42] (that kind of implies reloading) [07:42] thanks! [07:43] Sure. [07:46] Odd_Bloke: do you know why the current link on http://cloud-images.ubuntu.com/vivid/ is so far behind? [07:47] it actually seems it went backwards, it now points to a rather old version which doesn't have systemd at all, not even the init= bit === kickinz1|afk is now known as kickinz1 === dbarth__ is now known as dbarth [08:30] good morning === Riddelll is now known as Riddell [08:53] tyhicks, kirkland, there are several reports from users having issues with ecryptfs mounts recently in vivid, not sure if that's due to systemd or coincidence [08:53] things like bug #1430557 or bug #1420236 [08:53] bug 1430557 in schroot (Ubuntu) "sbuild / schroot unmounted encrypted home directory" [Undecided,New] https://launchpad.net/bugs/1430557 [08:53] bug 1420236 in ecryptfs-utils (Ubuntu) "Encrypted home directory randomly unmounts" [Undecided,New] https://launchpad.net/bugs/1420236 [08:53] sil2100 just hit a case where his userdir was not mounted after logging [08:54] qtcreator unmounts it when setting up the click schroots for me [08:54] Yeah, first time that happened, trying to browse my syslog for some info but so far nothing interesting [08:54] sil2100, ^ that channel is probably better for ecryptfs issues [09:01] I've had random cases like that for a fair while, but this sudden increase in report frequency sounds significant [09:03] pitti, well, I've filed bug #1427264 [09:03] bug 1427264 in click (Ubuntu) "using ecryptfs, creating frameworks fail to bind mount issues" [High,New] https://launchpad.net/bugs/1427264 [09:03] pitti, for sure trying to use our sdk leads to issue, so maybe the sdk leads more people to use schroot [09:04] pitti, qtcreator force unmount the schroot which unmounts your userdir in session [09:04] *fun* [09:04] you wonder why everything start acting [09:04] yeah, I'm always quite confused as well [09:04] until you open a command line or a filebrowser and see that your userdir is a README and a script [09:05] until I do an "ls" and see the the unmounted README [09:05] indeed [09:05] pitti: thank you! [09:05] I use schroot dozens of times every day, but it only happens sometimes (not even sure it happens after schroot, or if somethign else triggers it, but it's a likely candidate) [09:06] pitti, what fstab config do you have in your schroot? [09:06] pitti, for me in fails 100% of the time to unmount with the default config [09:07] /home/martin /home/martin none rw,bind 0 0 [09:07] k [09:07] same as me [09:07] err, WTH [09:07] you hacked it locally [09:07] oh, leading / :) [09:07] /home /home none rw,bind 0 0 [09:07] /home/martin /home/martin none rw,bind 0 0 [09:08] yeah, I added /home/martin as otherwise in a schroot I would only get the encrypted one; I also need the unencrypted /home/martin mount [09:08] but I want my $HOME in schroots [09:08] weird [09:08] seb128: weird what? [09:08] with the default config I do get the unencrypted userdir [09:08] pitti: We only update the current link once we've published to EC2, and we're currently tracking down a wrinkle in EC2 publishing. [09:09] but that's maybe because I run those from under my session [09:09] where the dir is unencrypted already [09:09] Odd_Bloke: ah, ok, thanks; I was just surprised that the image I built today seemed older than yesterday's [09:09] in any case without the /home/ entry I hit the issue that the bind mount can't be unmounted [09:17] pitti: Having read through more of the backlog, we have a cpc branch of livecd-rootfs which we build in to a PPA that we point the buildds at; we just copied the 03-boot_with_systemd.chroot hook from ubuntu-core. [09:19] (As you said you didn't know how we were doing it at some point) [09:20] Odd_Bloke: ah, ok; apparently that was taken out again, /current image boots with upstart again [09:20] as its ubuntu-meta is 6 uploads behind [09:20] err 5; it has 1.227 but 1.332 is current [09:21] Odd_Bloke: anyway, it'll sort itself out, thanks for the heads-up! === cking_ is now known as cking [10:00] Odd_Bloke: argh -- I was booting my utopic VM, sorry about the noise! [10:01] pitti: No worries; I was assuming it was all broken because we hadn't updated current in a while anyway. ;) [10:40] darkxst: question in bug https://code.launchpad.net/~darkxst/apport/sandbox-autoload/+merge/252686 [10:43] pitti: So, was your assertion about weird version numbers on update_excuses that adt was returning the right data, and it's a britney bug? [10:44] cjwatson: Could this perhaps relate to you enabling britney for multiple suites? It's pretty suspicious that vivid's excuses is showing utopic's linux version, for instance. [10:45] Err. Wait. I wonder if this relates to: [10:45] ubuntu-archive@snakefruit:~/proposed-migration/data$ ls -l testing unstable [10:45] lrwxrwxrwx 1 ubuntu-archive ubuntu-archive 6 Jun 6 2014 testing -> utopic [10:45] lrwxrwxrwx 1 ubuntu-archive ubuntu-archive 15 Jun 6 2014 unstable -> utopic-proposed [10:45] That seems not right. [10:46] That probably just means it ran most recently. I don't think those symlinks are actually used though [10:47] We should probably stop creating those symlinks (in britney1) and remove them, to make sure there are no stealth dependencies [10:47] cjwatson: The dates on the symlinks suggest they've not changed since after we opened utopic. Maybe we forgot to move them. [10:47] cjwatson: Or delete them entirely and see what breaks, sure. [10:47] cjwatson: But the excuses version oddities are confusing the crap out of me. [10:47] Probably. Yeah, just drop them. [10:48] Doesn't look like anything still creates them. [10:48] Deleted. [10:49] The quoted versions there come almost directly from the results file. [10:51] Hmm. Looking. [10:51] cjwatson: Well, data/adt/vivid-proposed/amd64/vivid-proposed_amd64_linux shows 3.19.0-9.9 running. [10:51] They're actually the causes. At least sometimes. Dubious variable use there. [10:52] I: [Thu Mar 12 10:47:11 2015] - Collected autopkgtest status for linux_3.16.0-23.31/slang2_2.3.0-2ubuntu1: PASS [10:52] possibly related? [10:52] cjwatson@snakefruit:/home/ubuntu-archive/proposed-migration/autopkgtest/work$ fgrep 3.16.0-23.31 *vivid* [10:52] adt.result.vivid:linux 3.16.0-23.31 PASS slang2 2.3.0-2ubuntu1 [10:53] doko_: boost1.57 is in experimental new queue... and in https://launchpad.net/~xnox/+archive/ubuntu/scratch/+packages [10:53] http://paste.ubuntu.com/10584838/ [10:53] doko_: it's "unsplit", however 1.58 rc was posted this morning. =( [10:53] infinity: Could you try http://paste.ubuntu.com/10584839/ ? [10:54] cjwatson: lver being lastversion or something? [10:54] as in coming from pkglist rather than pkgcauses [10:55] pick a better name if you like, the important bit was to be different from ver in the outer loop [10:55] Ahh, didn't noticed the outer loop had the same var. [10:56] Looks like a very plausible cause for version confusion to me. [10:56] Anyway, apply that live, run, see if you get more sensible output [10:57] (or wait for the next run) [10:58] cjwatson: cowboyed, waiting for next run. [11:00] And ubuntu-archive's INBOX is being spammed with: [11:00] W: Unknown Multi-Arch type 'no' for package 'compiz-core' [11:00] W: Unknown Multi-Arch type 'no' for package 'compiz-gnome' [11:01] lolz. [11:01] from chdist apt-get update I guess? [11:01] cjwatson: Yeah. [11:01] cjwatson: It's not wrong about the bug, just an entertaining place for me to find out. :P [11:01] Will be fixed when snakefruit has a newer apt. [11:02] Hrm? Newer apt actually likes that value? [11:02] http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=8f617600aeb931574baf0b53617e7759baa3f370 [11:02] Oh, the spec defines it. I've never seen it used. [11:04] Maybe it's worth SRUing that apt change to shut things up, otherwise we have to put up with cron spam for the next several years until those chdists run on trusty+4 [11:05] (But if we're SRUing anything to trusty's apt, I should include the source caching change ...) [11:06] cjwatson: Well, there's an SRU in progress right now for an AutoRemove bug. [11:06] cjwatson: But tossing this commit in with the source caching thing as an "archive support SRU" seems reasonable. [11:07] infinity: The source caching stuff is in ppa:~launchpad/ubuntu/ppa if you feel like chasing it up [11:07] cjwatson: Output from the cowboy seems more reasonable, if you'd like to commit that. [11:07] infinity: can't [11:07] cjwatson: Oh. Hahaha. [11:07] cjwatson: I'll commit, then. :) [11:07] Thanks :) [11:07] Good, that's been a long-running itch [11:12] Do we know why monitoring-plugins didn't autosync? I don't see it in http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt [11:12] rbasak: autosync is off. [11:12] infinity: I mean back when it was on. [11:13] There may be some conflict with nagios-plugins that needs resolving [11:13] BUt I'd expect to deal with that in vivid-proposed? [11:13] Probably too late for Vivid now, but I'm wondering why it hadn't come up before. [11:13] cjwatson: Reminds me, you might want to train someone else in the joys of autosync (or, the manual bits). [11:14] rbasak: There's some manual stuff involved when autosyncing NEW sources, I believe. Nothing stopping you from just syncing it now. [11:14] infinity: not any more [11:14] rbasak: http://people.canonical.com/~ubuntu-archive/auto-sync/current.log is enlightening [11:14] Yeah, I was about to link to that [11:14] We auto-sync NEW packages unless there are problems preventing it [11:14] Ahh. [11:15] So, yeah, it's the overwrite of modified nagios-plugins [11:15] Ah, OK. [11:15] Unmodified stuff would get autosynced [11:15] I was aware of it but assumed it would be automatic and was too busy with other things to pay attention. [11:15] But in this case you need to check the Ubuntu delta and see if it needs to be ported [11:15] Automation here would risk losing Ubuntu changes [11:15] I see [11:16] Until about three months ago the only way to know about this was to run auto-sync manually or have access to my inbox [11:16] That makes sense. I hadn't considered the interaction of the delta with the autosync before. Thanks [11:16] So at least now there is a log *somewhere*, even if it's slightly under a rock [11:29] meh.. [11:31] do I get outb on qxl? [11:32] does arm64 have outb? [11:41] mlankhorst: Given the total lack of sys/io.h, I'm going to go with no. === kickinz1 is now known as kickinz1|afk [11:53] meh.. [11:53] https://launchpadlibrarian.net/200012400/buildlog_ubuntu-vivid-arm64.xserver-xorg-video-qxl_0.1.1-0ubuntu4build1_BUILDING.txt.gz [11:54] seems outb is no longer defined for arm64.. === kickinz1|afk is now known as kickinz1 [11:56] maybe convert to libpciaccess? [11:56] it won't work either, but at least it will build.. [11:58] mlankhorst: "no longer" implies that it was, at one point, defined. [11:58] mlankhorst: I assure you that I didn't drop io.h between glibc 2.19 and glibc 2.19. :P [12:00] probably xorg-server changes.. === MacSlow is now known as MacSlow|lunch [12:22] didrocks: nice, I just fixed pgbouncer, that was my last "Jenkins Failure" email in my inbox [12:23] our > 1000 package tests were rather helpful for this transition [12:24] anyway all packages build in the ppa now.. [12:31] can someone sponsor http://paste.debian.net/plain/160914 ? [12:36] and http://paste.debian.net/160915/ please, looks like freedreno's not part of the xorg packageset yet [13:03] i can do those [13:03] seb128: I've been prioritizing a (minor) apparmor feature over the eCryptfs schroot/unmounting issue(s) [13:03] seb128: but I'll bump it up and focus on it before everything else today [13:04] mlankhorst: hum, aren't the debs copied from the ppa? so no need to sponsor these [13:04] oh the rest got uploaded already [13:06] hmm, my laptop has been sat doing a dist-upgrade "Setting up systemd (219-4ubuntu5) ..." for some time. [13:07] [Thu Mar 12 13:02:42 2015] Watchdog[1507]: segfault at 0 ip 00007f64e92f083e sp 00007f64d9fbd250 error 6 in libcef.so[7f64e89e5000+46b8000] [13:07] related? [13:09] hah, now it carries on... [13:09] blimey, that took a loooong time. [13:09] Google suggests that libcef.so is related to Spotify === MasterPiece`` is now known as MasterPiece === MacSlow|lunch is now known as MacSlow [13:16] good morning! [13:17] tyhicks, thanks [13:23] Laney: can pull-lp-source pull from PPAs ? [13:24] caribou: Nope [13:24] Laney: thanks :) [13:24] caribou: It's perhaps poorly named, and should be pull-ubuntu-source [13:24] I could imagine it getting a parameter to change the archive it uses though [13:24] But yes, adding a --archive feature would make it work. [13:25] Laney: infinity: I'll look into that if I have a minute [13:26] caribou: Cargo-cult the archive parameter from 'copy-package {--from,--to}' [13:26] infinity: k [13:27] Except that IIRC ubuntu-dev-tools has its own caching LP abstraction layers for everything, so you may have to argue with those. [13:27] I usually find the .dsc and then use dget. It'd be nice to have it integrated though. Together with pull-debian-source. How about "pull-source" that just DTRT? [13:30] rbasak: Well, "pull-source" would still need a --debian switch, so having the other name also works. [13:30] rbasak: On the off chance that we accidentally have the same version but different contents. [13:30] It'd be nice to be able to do "pull-source debian:hello" [13:30] Or "pull-source ppa:racb/mystuff/hello", or "pull-source hello" to default to ubuntu: or something. [13:31] rbasak: Not sure how that's much different from pull-debian-source hello. And the latter tab-completes more easily with less typing. :) [13:31] We should use LP's archive reference syntax rather than inventing a new slash-separated thing, for consistency among tools. [13:31] We should. [13:31] Of course, I still need to train my fingers to use it. [13:32] I was thinking of add-apt-repository. Does that do its own thing already though? [13:32] It does sort of, it predates archive references. [13:32] Also predates derived distributions, so it had to be changed. [13:32] But it's close. [13:32] add-apt-repo and old-style dput are just missing the distro bit, aren't they? [13:32] infinity: don't start to train yet, not sure I can dive into it that easily [13:32] In the archive reference syntax, "debian" means the Debian primary archive, so it shouldn't be that hard to use. [13:32] ie: user/ubuntu/archive instead of user/archive [13:33] infinity: Yes, and they have an extra leading ppa: [13:33] Oh and the ~ stripped off [13:33] Right. [13:33] ppa: == ~ more or less. [13:33] That's the bit my fingers are retraining for. [13:33] Yeah, there's an argument for keeping that as syntactic sugar because it saves on escaping ~ [13:34] I wonder if we should change ArchiveSet.getByReference to accept that. [13:35] Or maybe it should just be at the command-line tools level. [13:35] Wouldn't hurt my feelings if it Just Worked at the API level. [13:36] Given that most people who've done archive reference at the CLI level are used to ppa:foo/bar, why force a pointless syntax change when they go to abuse it at the API level? [13:36] wgrant: ^- WDYT? [13:37] I'd really prefer not... [13:37] I figured that would be his answer. ;) [13:37] ppa:user/archive is an abomination. It's ambiguous. [13:37] Oh, we should keep the distribution. [13:37] add-apt-repository already accepts that. [13:37] wgrant: ppa:user/distro/archive [13:37] But I mean ppa:user/distro/archive as an alias for ~user/distro/archive that doesn't require protection from shells, so is easier to use on command lines. [13:38] wgrant: Colin was talking specifically about making ppa: and ~ synonymous, not about using the old form with one missing component. [13:38] Oh, if you require ppa:, sure. [13:38] I thought you were saying that an archive reference 'wgrant/ubuntu/ppa' would work, which is insane. [13:38] I clearly didn't read back far enough. [13:38] (but to avoid escaping I usually just use --from=~wgrant/ubuntu/ppa) [13:39] Yeah, me too, but it's a slightly annoying gotcha. [13:40] Is that a fragile and scary bash feature, or POSIX? [13:40] (base)adconrad@cthulhu:~$ echo --foo=~adconrad/foo/bar/whee [13:40] --foo=~adconrad/foo/bar/whee [13:40] (base)adconrad@cthulhu:~$ echo foo=~adconrad/foo/bar/whee [13:40] foo=/home/adconrad/foo/bar/whee [13:40] That kinda freaks me out. [13:40] I think that's POSIX. [13:41] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01 [13:41] Though I'm not sure, that shouldn't count as the beginning of a word and isn't an assignment. [13:42] I was just going to say - using ~ in a CLI to mean something else might mean some escaping pain. I didn't realise it was that...surprising. [13:43] And of course it only applies if it gets a hit from NSS. [13:43] $ echo foo=~robie/bar [13:43] foo=/home/robie/bar [13:43] $ echo foo=~rbasak/bar [13:43] foo=~rbasak/bar [13:43] It's odd in this case because it's part of a URL, except everything up to the first slash in the path is implied. [13:43] This disagrees with bash's documentation, AFAICS. [13:44] eg. the branch lp:~foo/bar/baz syntax isn't a problem, because it has another token before it. [13:44] I wonder if it's misfiring and considering it an assignment. [13:44] But infinity's behaviour is very surprising. [13:44] And dash doesn't do this. [13:44] I hadn't realised it did that. [13:45] tjaalton: nah the ppa was for testing, after that was done I uploaded the same _source.changes to the archive [13:45] http://wiki.bash-hackers.org/syntax/expansion/tilde notes this as questionable [13:45] Isn't it more of a POSIX violation than a questionable feature? :) [13:45] Probably, yeah [13:45] mlankhorst: guess I'm living in the past, where packages were copied from the ppa [13:46] yeah [13:46] How very odd. [13:46] cjwatson: It might be for post-assignment in make. [13:46] cjwatson: ie: make foo=~person/stuff [13:47] And the lazy approach was just to evaluate everything that looks like an assignment rather than special-case ever name for "make". [13:47] s/ever/every/ [13:47] Well, if that's true it should at minimum be documented [13:47] Yeah, just a shot in the dark. It really just looks like a bug. [13:48] Hopefully it won't start magically interpreting it as code this time. [13:48] $ echo foo=~adconrad/foo [13:48] foo=~adconrad/foo [13:48] $ echo --foo=~adconrad/foo [13:48] --foo=~adconrad/foo [13:48] $ [13:48] dash appears to do what POSIX says. [13:49] Oh, you noted that. === doko_ is now known as doko [14:05] https://code.launchpad.net/~cjwatson/launchpad/ppa-archive-reference-alias/+merge/252753 [14:51] oops siliconmotion fails without outb too, meh [14:57] mlankhorst: Curious. Did something change in a macro or header exposed by xorg? [14:57] mlankhorst: Cause glibc hasn't changed in any meaningful way since trusty. [14:58] mlankhorst: did you check upstream git? [14:58] doko_, hi, regarding "gcc-5 - 5-20150311-1ubuntu12", now lib32mpx0 is missing [14:59] tjaalton: no I doubt upstream has outb support [15:00] infinity: the headers for xorg-server changed, that probably unmasked those build errors.. [15:00] what's the approperiate way to enable partner repository by default? (Ubuntu Kylin wants it) I'm seeing apt-setup of ubiquity, is it? [15:00] oh fedora got rid of it already [15:00] why can't we? :) [15:01] ooh reading the driver reminds me of the vga days [15:01] ton of vga programming in there [15:02] tjaalton: unfortunately pstream still puts in bild fixes to siliconmotion :/ [15:02] ajax, who dropped the drivers from fedora [15:03] let's just drop all the non-kms drivers in v+1 :) [15:03] last codechurn commit appears to be in 2010 [15:03] minus blobs.. [15:04] Fix lack of precision in video resizing. #26443 [15:06] doko_: do you think you could provide transitional packages for http://launchpadlibrarian.net/199658027/juju-core_1.20.14-0ubuntu2_1.20.14-0ubuntu3.diff.gz ? Then Juju upstream wouldn't need to maintain separate branches with different build-depends lines for their backports. [15:06] I don't know if that is sensible or not, but I thought I'd ask. [15:06] rbasak, what do you mean? [15:07] doko_: have the new source package provide libgo5 and gccgo-go binaries [15:07] That are empty and just depend on gccgo. [15:07] meh, I'll just replace outb and inb with some macros [15:08] mlankhorst: on a Build-Depends? Is that possible? [15:08] does this channel have logs? [15:08] rbasak, no, the libgo5 b-d is crap. feel free to upload an empty gccgo-go binary, depending on gccgo [15:08] my buffer only goes back so far.. [15:08] Pwnna: http://irclogs.ubuntu.com/ [15:09] doko_: so the libgo5 b-d was never needed? Then we might be able to drop that for all releases so that wouldn't be a problem. [15:09] rbasak, well, you build-depend on gccgo anyway, do you? [15:10] doko_: in Vivid we can. But in older releases that doesn't exist so is no good for backports. [15:10] And currently we don't have backport branches - they all share the same packaging, which is convenient. [15:10] But we do depend on gccgo-go everywhere, so if that pulls in libgo5 we don't need it explicitly, so could drop it. [15:11] 15:08 rbasak, no, the libgo5 b-d is crap. feel free to upload an empty gccgo-go binary, depending on gccgo [15:11] Would you be OK with having this package until Trusty EOLs? [15:12] I guess that's a bit unusual for a transitional package maybe, but unless we keep it that long there's no point in doing it, so I thought I'd check. [15:12] An empty gccgo-go binary I mean. === doko_ is now known as doko [15:14] mlankhorst: oh, sorry, you were talking about something else :) [15:15] yeah [15:17] rbasak, an empty gccgo-go binary package should be good enough, depending on gccgo. no need to build-depend on libgo5 [15:17] doko: ack. Thanks. I'll check it does what we need and upload. [15:23] well looks like the outb are easy to convert [15:26] meh.. [15:32] rbasak, jamespage: fyi, I verified that docker.io builds with golang 1.4.2 (in the doko/toolchain PPA) [15:33] Thanks! kickinz1: ^^ [15:33] doko, ok - so I think we're also planning to bump docker version to the one in experimental (1.5.0) but that needs to go via the release team as yet [15:33] 1.3.3 + 1.4.x of go has some problems with sqlite stuff [15:34] which is already impacting on the ppc64el version but not the x86 [15:34] having the golang version aligned makes alotta sense imho [15:34] jamespage, like https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1431032 [15:34] Launchpad bug 1431032 in gccgo-5 (Ubuntu) "powerpc: cgo appears disabled somehow" [Undecided,New] [15:35] doko, not that one [15:35] does anyone even have a siliconmotion device here? [15:35] jamespage, I would prefer 1.4.2, and backport this fix to GCC 5 too [15:42] mvo_: hey, stupid question about conffile prompt. So, I removed from whoopsie the "enabled" line (as we are going to handle it via override/systemctl). However, there is another value report_metrics which isn't in /etc/default/whoopsie by default, but that people may enable via a gnome-control-center capplet. I think we don't want them to be prompted by a conffile change (the change being removing the [15:42] "enable") line and my sedding in preinst won't prevent that, how do you handle that generally? [15:42] mvo_: as there is only a second value, I can of course cache it in preinst, do the changes I need in the conffile (which is empty it), and reset the value of report_metrics then, but it sounds hackish [15:43] didrocks: in a meeting, easiest is probably to have ".d" directory [15:43] didrocks: If it's a dpkg conffile, and it's being edited by gnome-control-center, that's your bug. [15:43] didrocks: That's a massive policy violation. [15:43] infinity: well, I guess it's ev's one in that case, but I doubt he will work on it (anyone in fundation working on whoopsie?) [15:44] ok fixed up siliconmotion [15:44] policy smolishy [15:44] I don't plan to work on whoopsie for the record, was just here to help on the migration [15:44] didrocks: bdmurray is your guy [15:44] i probably broke it in the process on supported platforms, but at least that might show if someone's using it.. [15:44] ev: ok, giving the hot potato to him then! thanks ;) [15:44] sure thing [15:45] bdmurray: I guess we can have a debconf prompt on upgrade due to whoopsie, I'm happy to discuss it with you [15:45] (to give you details) [15:46] infinity: oh can xserver-xorg-video-modesetting be deleted? [15:46] moved to xorg-server [15:46] mlankhorst: The source package, you mean? Or both source and binary? [15:46] bdmurray: as infinity told, whoopsie shouldn't edit those values using the conffile, I think we should get the report_metrics value migrated [15:46] infinity: source and binary [15:47] all the packages recommending modesetting have been fixed [15:47] mlankhorst: Does the new xorg-server P/C/R xserver-xorg-video-modesetting in an attempt to smoothly transition? [15:47] yes, except p [15:47] C/R is fine for forced removal, yeah, as long as nothing depdends on it anymore. [15:47] mvo_: maybe you would have some opinions once your metting is done ^ (and no .d directory, it's already existing code) [15:47] meeting* [15:48] only some of the ddx packages were recommending it, but I fixed those in the transition [15:48] mlankhorst: Which package has the conflict/replace? [15:49] xserver-xorg-core [15:49]