[00:00] <Pwnna> 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] <Unit193> pitti: Heh, well if it matters it popped up the volume again, either right after unpacking systemd or libpam-systemd. :P
[06:02] <pitti> 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] <pitti> 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] <pitti> 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] <pitti> 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] <pitti> ... and Good morning!
[06:08] <darkxst> hey pitti
[06:08] <Unit193> Howdy.
[06:08] <pitti> hey darkxst!
[06:08] <darkxst> so that retracer failure was from nettle changing nettle-dbg from a folder to a symlink
[06:09] <darkxst> I guess dpkg has no idea about those changes
[06:09] <darkxst> do you purge your sandboxes regularly?
[06:09] <pitti> darkxst: ah, you have a permanent sandbox!
[06:09] <Unit193> pitti: Yes, yes.
[06:09] <pitti> darkxst: no, I use temporary sandboxes on the Launchpad retracers
[06:10] <pitti> darkxst: errors.u.c. uses permanent ones, though
[06:10] <pitti> I haven't gotten a report about that yet
[06:10] <pitti> but yes, symlinked directories are handled specially by dpkg
[06:10] <pitti> and packages need to be super careful when doing this change
[06:11] <darkxst> pitti, mainscript was added in Jan
[06:11] <darkxst> +dir_to_symlink /usr/share/doc/nettle-dbg libnettle4 2.7.1-5~ nettle-dbg
[06:12] <darkxst> but I have only seen the error a handful of times
[06:12] <pitti> right, but dpkg-deb -x obviously doesn't run them
[06:12] <darkxst> yes clearly
[06:17] <darkxst> pitti, I suppose you have the sandboxes in tmpfs?
[06:18] <darkxst> (on the launchpad retracer)
[06:18] <pitti> 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] <pitti> it's a plain fs
[06:19] <darkxst> does it make much difference to speed?
[06:19] <pitti> it has never been a measurable bottleneck TBH
[06:20] <pitti> tmpfs would certainly be a lot faster
[06:26] <darkxst> ok, may try it with temporary sandboxes for a bit see how it goes
[06:27] <darkxst> btw sent through a patch to make apport-retracer look in the sandbox for python scripts (pretty printers etc)
[06:28] <darkxst> s/for gdb to look in the sandbox/
[06:32] <pitti> darkxst: I saw, thanks!
[06:37] <Unit193> pitti: Any specific reason why it'd do that?
[06:38] <pitti> 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] <Unit193> OK, sure.  No problem.
[06:43] <Unit193> I just found out I have to turn the music off before certain upgrades, or I'm in for a jump. :D
[06:45] <pitti> haha
[06:45] <pitti> 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] <Unit193> Alright..
[07:19] <Unit193> Meh, looked at the journel, started to suspect something.  It was in alsa-restore/alsa-store.
[07:19] <Unit193> Seems to be only triggering the former.
[07:33] <pitti> Unit193: right, that makes sense, I suspected the ALSA script; but I wonder why it's being re-run
[07:33] <Unit193> At least stored it at a lower volume.
[07:34] <pitti> Unit193: ok, please file a bug, this shouldn't be too hard to at least track down and understand why it happens
[07:37] <Unit193> pitti: Sure.  Not really sure what else to add, so 1431200.
[07:38] <pitti> err, daemon-reload surely?
[07:41] <Unit193> Right, that.  4am brings typos to bugs.  Sorry.
[07:42] <pitti> Unit193: no worries, it most likely happens with daemon-reexec too
[07:42] <pitti> (that kind of implies reloading)
[07:42] <pitti> thanks!
[07:43] <Unit193> Sure.
[07:46] <pitti> Odd_Bloke: do you know why the current link on http://cloud-images.ubuntu.com/vivid/  is so far behind?
[07:47] <pitti> 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
[08:30] <dholbach> good morning
[08:53] <seb128> 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] <seb128> things like bug #1430557 or bug #1420236
[08:53] <seb128> sil2100 just hit a case where his userdir was not mounted after logging
[08:54] <seb128> qtcreator unmounts it when setting up the click schroots for me
[08:54] <sil2100> Yeah, first time that happened, trying to browse my syslog for some info but so far nothing interesting
[08:54] <seb128> sil2100, ^ that channel is probably better for ecryptfs issues
[09:01] <pitti> I've had random cases like that for a fair while, but this sudden increase in report frequency sounds significant
[09:03] <seb128> pitti, well, I've filed bug #1427264
[09:03] <seb128> pitti, for sure trying to use our sdk leads to issue, so maybe the sdk leads more people to use schroot
[09:04] <seb128> pitti, qtcreator force unmount the schroot which unmounts your userdir in session
[09:04] <seb128> *fun*
[09:04] <seb128> you wonder why everything start acting
[09:04] <pitti> yeah, I'm always quite confused as well
[09:04] <seb128> until you open a command line or a filebrowser and see that your userdir is a README and a script
[09:05] <pitti> until I do an "ls" and see the the unmounted README
[09:05] <seb128> indeed
[09:05] <rbasak> pitti: thank you!
[09:05] <pitti> 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] <seb128> pitti, what fstab config do you have in your schroot?
[09:06] <seb128> pitti, for me in fails 100% of the time to unmount with the default config
[09:07] <pitti> /home/martin    /home/martin    none    rw,bind        0       0
[09:07] <seb128> k
[09:07] <seb128> same as me
[09:07] <pitti> err, WTH
[09:07] <seb128> you hacked it locally
[09:07] <pitti> oh, leading / :)
[09:07] <pitti>  /home           /home           none    rw,bind        0       0
[09:07] <pitti>  /home/martin    /home/martin    none    rw,bind        0       0
[09:08] <pitti> 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] <pitti> but I want my $HOME in schroots
[09:08] <seb128> weird
[09:08] <pitti> seb128: weird what?
[09:08] <seb128> with the default config I do get the unencrypted userdir
[09:08] <Odd_Bloke> 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] <seb128> but that's maybe because I run those from under my session
[09:09] <seb128> where the dir is unencrypted already
[09:09] <pitti> Odd_Bloke: ah, ok, thanks; I was just surprised that the image I built today seemed older than yesterday's
[09:09] <seb128> in any case without the /home/<user> entry I hit the issue that the bind mount can't be unmounted
[09:17] <Odd_Bloke> 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] <Odd_Bloke> (As you said you didn't know how we were doing it at some point)
[09:20] <pitti> Odd_Bloke: ah, ok; apparently that was taken out again, /current image boots with upstart again
[09:20] <pitti> as its ubuntu-meta is 6 uploads behind
[09:20] <pitti> err 5; it has 1.227 but 1.332 is current
[09:21] <pitti> Odd_Bloke: anyway, it'll sort itself out, thanks for the heads-up!
[10:00] <pitti> Odd_Bloke: argh -- I was booting my utopic VM, sorry about the noise!
[10:01] <Odd_Bloke> pitti: No worries; I was assuming it was all broken because we hadn't updated current in a while anyway. ;)
[10:40] <pitti> darkxst: question in bug https://code.launchpad.net/~darkxst/apport/sandbox-autoload/+merge/252686
[10:43] <infinity> 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] <infinity> 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] <infinity> Err.  Wait.  I wonder if this relates to:
[10:45] <infinity> ubuntu-archive@snakefruit:~/proposed-migration/data$ ls -l testing unstable
[10:45] <infinity> lrwxrwxrwx 1 ubuntu-archive ubuntu-archive  6 Jun  6  2014 testing -> utopic
[10:45] <infinity> lrwxrwxrwx 1 ubuntu-archive ubuntu-archive 15 Jun  6  2014 unstable -> utopic-proposed
[10:45] <infinity> That seems not right.
[10:46] <cjwatson> That probably just means it ran most recently.  I don't think those symlinks are actually used though
[10:47] <cjwatson> We should probably stop creating those symlinks (in britney1) and remove them, to make sure there are no stealth dependencies
[10:47] <infinity> cjwatson: The dates on the symlinks suggest they've not changed since after we opened utopic.  Maybe we forgot to move them.
[10:47] <infinity> cjwatson: Or delete them entirely and see what breaks, sure.
[10:47] <infinity> cjwatson: But the excuses version oddities are confusing the crap out of me.
[10:47] <cjwatson> Probably.  Yeah, just drop them.
[10:48] <cjwatson> Doesn't look like anything still creates them.
[10:48] <infinity> Deleted.
[10:49] <cjwatson> The quoted versions there come almost directly from the results file.
[10:51] <cjwatson> Hmm.  Looking.
[10:51] <infinity> cjwatson: Well, data/adt/vivid-proposed/amd64/vivid-proposed_amd64_linux shows 3.19.0-9.9 running.
[10:51] <cjwatson> They're actually the causes.  At least sometimes.  Dubious variable use there.
[10:52] <cjwatson> 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] <cjwatson> possibly related?
[10:52] <cjwatson> cjwatson@snakefruit:/home/ubuntu-archive/proposed-migration/autopkgtest/work$ fgrep 3.16.0-23.31 *vivid*
[10:52] <cjwatson> adt.result.vivid:linux 3.16.0-23.31 PASS slang2 2.3.0-2ubuntu1
[10:53] <xnox> doko_: boost1.57 is in experimental new queue... and in https://launchpad.net/~xnox/+archive/ubuntu/scratch/+packages
[10:53] <infinity> http://paste.ubuntu.com/10584838/
[10:53] <xnox> doko_: it's "unsplit", however 1.58 rc was posted this morning. =(
[10:53] <cjwatson> infinity: Could you try http://paste.ubuntu.com/10584839/ ?
[10:54] <infinity> cjwatson: lver being lastversion or something?
[10:54] <cjwatson> as in coming from pkglist rather than pkgcauses
[10:55] <cjwatson> pick a better name if you like, the important bit was to be different from ver in the outer loop
[10:55] <infinity> Ahh, didn't noticed the outer loop had the same var.
[10:56] <cjwatson> Looks like a very plausible cause for version confusion to me.
[10:56] <cjwatson> Anyway, apply that live, run, see if you get more sensible output
[10:57] <cjwatson> (or wait for the next run)
[10:58] <infinity> cjwatson: cowboyed, waiting for next run.
[11:00] <infinity> And ubuntu-archive's INBOX is being spammed with:
[11:00] <infinity> W: Unknown Multi-Arch type 'no' for package 'compiz-core'
[11:00] <infinity> W: Unknown Multi-Arch type 'no' for package 'compiz-gnome'
[11:01] <infinity> lolz.
[11:01] <cjwatson> from chdist apt-get update I guess?
[11:01] <infinity> cjwatson: Yeah.
[11:01] <infinity> cjwatson: It's not wrong about the bug, just an entertaining place for me to find out. :P
[11:01] <cjwatson> Will be fixed when snakefruit has a newer apt.
[11:02] <infinity> Hrm?  Newer apt actually likes that value?
[11:02] <cjwatson> http://anonscm.debian.org/cgit/apt/apt.git/commit/?id=8f617600aeb931574baf0b53617e7759baa3f370
[11:02] <infinity> Oh, the spec defines it.  I've never seen it used.
[11:04] <cjwatson> 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] <cjwatson> (But if we're SRUing anything to trusty's apt, I should include the source caching change ...)
[11:06] <infinity> cjwatson: Well, there's an SRU in progress right now for an AutoRemove bug.
[11:06] <infinity> cjwatson: But tossing this commit in with the source caching thing as an "archive support SRU" seems reasonable.
[11:07] <cjwatson> infinity: The source caching stuff is in ppa:~launchpad/ubuntu/ppa if you feel like chasing it up
[11:07] <infinity> cjwatson: Output from the cowboy seems more reasonable, if you'd like to commit that.
[11:07] <cjwatson> infinity: can't
[11:07] <infinity> cjwatson: Oh.  Hahaha.
[11:07] <infinity> cjwatson: I'll commit, then. :)
[11:07] <cjwatson> Thanks :)
[11:07] <cjwatson> Good, that's been a long-running itch
[11:12] <rbasak> 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] <infinity> rbasak: autosync is off.
[11:12] <rbasak> infinity: I mean back when it was on.
[11:13] <rbasak> There may be some conflict with nagios-plugins that needs resolving
[11:13] <rbasak> BUt I'd expect to deal with that in vivid-proposed?
[11:13] <rbasak> Probably too late for Vivid now, but I'm wondering why it hadn't come up before.
[11:13] <infinity> cjwatson: Reminds me, you might want to train someone else in the joys of autosync (or, the manual bits).
[11:14] <infinity> rbasak: There's some manual stuff involved when autosyncing NEW sources, I believe.  Nothing stopping you from just syncing it now.
[11:14] <cjwatson> infinity: not any more
[11:14] <Laney> rbasak: http://people.canonical.com/~ubuntu-archive/auto-sync/current.log is enlightening
[11:14] <cjwatson> Yeah, I was about to link to that
[11:14] <cjwatson> We auto-sync NEW packages unless there are problems preventing it
[11:14] <infinity> Ahh.
[11:15] <cjwatson> So, yeah, it's the overwrite of modified nagios-plugins
[11:15] <rbasak> Ah, OK.
[11:15] <cjwatson> Unmodified stuff would get autosynced
[11:15] <rbasak> I was aware of it but assumed it would be automatic and was too busy with other things to pay attention.
[11:15] <cjwatson> But in this case you need to check the Ubuntu delta and see if it needs to be ported
[11:15] <cjwatson> Automation here would risk losing Ubuntu changes
[11:15] <rbasak> I see
[11:16] <cjwatson> 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] <rbasak> That makes sense. I hadn't considered the interaction of the delta with the autosync before. Thanks
[11:16] <cjwatson> So at least now there is a log *somewhere*, even if it's slightly under a rock
[11:29] <mlankhorst> meh..
[11:31] <mlankhorst> do I get outb on qxl?
[11:32] <mlankhorst> does arm64 have outb?
[11:41] <infinity> mlankhorst: Given the total lack of sys/io.h, I'm going to go with no.
[11:53] <mlankhorst> meh..
[11:53] <mlankhorst> https://launchpadlibrarian.net/200012400/buildlog_ubuntu-vivid-arm64.xserver-xorg-video-qxl_0.1.1-0ubuntu4build1_BUILDING.txt.gz
[11:54] <mlankhorst> seems outb is no longer defined for arm64..
[11:56] <mlankhorst> maybe convert to libpciaccess?
[11:56] <mlankhorst> it won't work either, but at least it will build..
[11:58] <infinity> mlankhorst: "no longer" implies that it was, at one point, defined.
[11:58] <infinity> mlankhorst: I assure you that I didn't drop io.h between glibc 2.19 and glibc 2.19. :P
[12:00] <mlankhorst> probably xorg-server changes..
[12:22] <pitti> didrocks: nice, I just fixed pgbouncer, that was my last "Jenkins Failure" email in my inbox
[12:23] <pitti> our > 1000 package tests were rather helpful for this transition
[12:24] <mlankhorst> anyway all packages build in the ppa now..
[12:31] <mlankhorst> can someone sponsor http://paste.debian.net/plain/160914 ?
[12:36] <mlankhorst> and http://paste.debian.net/160915/ please, looks like freedreno's not part of the xorg packageset yet
[13:03] <tjaalton> i can do those
[13:03] <tyhicks> seb128: I've been prioritizing a (minor) apparmor feature over the eCryptfs schroot/unmounting issue(s)
[13:03] <tyhicks> seb128: but I'll bump it up and focus on it before everything else today
[13:04] <tjaalton> mlankhorst: hum, aren't the debs copied from the ppa? so no need to sponsor these
[13:04] <tjaalton> oh the rest got uploaded already
[13:06] <popey> hmm, my laptop has been sat doing a dist-upgrade "Setting up systemd (219-4ubuntu5) ..." for some time.
[13:07] <popey> [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] <popey> related?
[13:09] <popey> hah, now it carries on...
[13:09] <popey> blimey, that took a loooong time.
[13:09] <rbasak> Google suggests that libcef.so is related to Spotify
[13:16] <cyphermox> good morning!
[13:17] <seb128> tyhicks, thanks
[13:23] <caribou> Laney: can pull-lp-source pull from PPAs ?
[13:24] <Laney> caribou: Nope
[13:24] <caribou> Laney: thanks :)
[13:24] <infinity> caribou: It's perhaps poorly named, and should be pull-ubuntu-source
[13:24] <Laney> I could imagine it getting a parameter to change the archive it uses though
[13:24] <infinity> But yes, adding a --archive feature would make it work.
[13:25] <caribou> Laney: infinity: I'll look into that if I have a minute
[13:26] <infinity> caribou: Cargo-cult the archive parameter from 'copy-package {--from,--to}'
[13:26] <caribou> infinity: k
[13:27] <cjwatson> 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] <rbasak> 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] <infinity> rbasak: Well, "pull-source" would still need a --debian switch, so having the other name also works.
[13:30] <infinity> rbasak: On the off chance that we accidentally have the same version but different contents.
[13:30] <rbasak> It'd be nice to be able to do "pull-source debian:hello"
[13:30] <rbasak> Or "pull-source ppa:racb/mystuff/hello", or "pull-source hello" to default to ubuntu: or something.
[13:31] <infinity> 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] <cjwatson> We should use LP's archive reference syntax rather than inventing a new slash-separated thing, for consistency among tools.
[13:31] <infinity> We should.
[13:31] <infinity> Of course, I still need to train my fingers to use it.
[13:32] <rbasak> I was thinking of add-apt-repository. Does that do its own thing already though?
[13:32] <cjwatson> It does sort of, it predates archive references.
[13:32] <cjwatson> Also predates derived distributions, so it had to be changed.
[13:32] <cjwatson> But it's close.
[13:32] <infinity> add-apt-repo and old-style dput are just missing the distro bit, aren't they?
[13:32] <caribou> infinity: don't start to train yet, not sure I can dive into it that easily
[13:32] <cjwatson> In the archive reference syntax, "debian" means the Debian primary archive, so it shouldn't be that hard to use.
[13:32] <infinity> ie: user/ubuntu/archive instead of user/archive
[13:33] <cjwatson> infinity: Yes, and they have an extra leading ppa:
[13:33] <cjwatson> Oh and the ~ stripped off
[13:33] <infinity> Right.
[13:33] <infinity> ppa: == ~ more or less.
[13:33] <infinity> That's the bit my fingers are retraining for.
[13:33] <cjwatson> Yeah, there's an argument for keeping that as syntactic sugar because it saves on escaping ~
[13:34] <cjwatson> I wonder if we should change ArchiveSet.getByReference to accept that.
[13:35] <cjwatson> Or maybe it should just be at the command-line tools level.
[13:35] <infinity> Wouldn't hurt my feelings if it Just Worked at the API level.
[13:36] <infinity> 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] <cjwatson> wgrant: ^- WDYT?
[13:37] <wgrant> I'd really prefer not...
[13:37] <infinity> I figured that would be his answer. ;)
[13:37] <wgrant> ppa:user/archive is an abomination. It's ambiguous.
[13:37] <cjwatson> Oh, we should keep the distribution.
[13:37] <cjwatson> add-apt-repository already accepts that.
[13:37] <infinity> wgrant: ppa:user/distro/archive
[13:37] <cjwatson> 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] <infinity> wgrant: Colin was talking specifically about making ppa: and ~ synonymous, not about using the old form with one missing component.
[13:38] <wgrant> Oh, if you require ppa:, sure.
[13:38] <wgrant> I thought you were saying that an archive reference 'wgrant/ubuntu/ppa' would work, which is insane.
[13:38] <wgrant> I clearly didn't read back far enough.
[13:38] <wgrant> (but to avoid escaping I usually just use --from=~wgrant/ubuntu/ppa)
[13:39] <cjwatson> Yeah, me too, but it's a slightly annoying gotcha.
[13:40] <infinity> Is that a fragile and scary bash feature, or POSIX?
[13:40] <infinity> (base)adconrad@cthulhu:~$ echo --foo=~adconrad/foo/bar/whee
[13:40] <infinity> --foo=~adconrad/foo/bar/whee
[13:40] <infinity> (base)adconrad@cthulhu:~$ echo foo=~adconrad/foo/bar/whee
[13:40] <infinity> foo=/home/adconrad/foo/bar/whee
[13:40] <infinity> That kinda freaks me out.
[13:40] <cjwatson> I think that's POSIX.
[13:41] <cjwatson> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01
[13:41] <cjwatson> Though I'm not sure, that shouldn't count as the beginning of a word and isn't an assignment.
[13:42] <rbasak> 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] <rbasak> And of course it only applies if it gets a hit from NSS.
[13:43] <rbasak> $ echo foo=~robie/bar
[13:43] <rbasak> foo=/home/robie/bar
[13:43] <rbasak> $ echo foo=~rbasak/bar
[13:43] <rbasak> foo=~rbasak/bar
[13:43] <wgrant> 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] <cjwatson> This disagrees with bash's documentation, AFAICS.
[13:44] <wgrant> eg. the branch lp:~foo/bar/baz syntax isn't a problem, because it has another token before it.
[13:44] <cjwatson> I wonder if it's misfiring and considering it an assignment.
[13:44] <wgrant> But infinity's behaviour is very surprising.
[13:44] <cjwatson> And dash doesn't do this.
[13:44] <wgrant> I hadn't realised it did that.
[13:45] <mlankhorst> tjaalton: nah the ppa was for testing, after that was done I uploaded the same _source.changes to the archive
[13:45] <cjwatson> http://wiki.bash-hackers.org/syntax/expansion/tilde notes this as questionable
[13:45] <wgrant> Isn't it more of a POSIX violation than a questionable feature? :)
[13:45] <cjwatson> Probably, yeah
[13:45] <tjaalton> mlankhorst: guess I'm living in the past, where packages were copied from the ppa
[13:46] <mlankhorst> yeah
[13:46] <wgrant> How very odd.
[13:46] <infinity> cjwatson: It might be for post-assignment in make.
[13:46] <infinity> cjwatson: ie: make foo=~person/stuff
[13:47] <infinity> And the lazy approach was just to evaluate everything that looks like an assignment rather than special-case ever name for "make".
[13:47] <infinity> s/ever/every/
[13:47] <cjwatson> Well, if that's true it should at minimum be documented
[13:47] <infinity> Yeah, just a shot in the dark.  It really just looks like a bug.
[13:48] <wgrant> Hopefully it won't start magically interpreting it as code this time.
[13:48] <infinity> $ echo foo=~adconrad/foo
[13:48] <infinity> foo=~adconrad/foo
[13:48] <infinity> $ echo --foo=~adconrad/foo
[13:48] <infinity> --foo=~adconrad/foo
[13:48] <infinity> $
[13:48] <infinity> dash appears to do what POSIX says.
[13:49] <infinity> Oh, you noted that.
[14:05] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/ppa-archive-reference-alias/+merge/252753
[14:51] <mlankhorst> oops siliconmotion fails without outb too, meh
[14:57] <infinity> mlankhorst: Curious.  Did something change in a macro or header exposed by xorg?
[14:57] <infinity> mlankhorst: Cause glibc hasn't changed in any meaningful way since trusty.
[14:58] <tjaalton> mlankhorst: did you check upstream git?
[14:58] <ricotz> doko_, hi, regarding "gcc-5 - 5-20150311-1ubuntu12", now lib32mpx0 is missing
[14:59] <mlankhorst> tjaalton: no I doubt upstream has outb support
[15:00] <mlankhorst> infinity: the headers for xorg-server changed, that probably unmasked those build errors..
[15:00] <happyaron> 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] <tjaalton> oh fedora got rid of it already
[15:00] <tjaalton> why can't we? :)
[15:01] <mlankhorst> ooh reading the driver reminds me of the vga days
[15:01] <mlankhorst> ton of vga programming in there
[15:02] <mlankhorst> tjaalton: unfortunately pstream still puts in bild fixes to siliconmotion :/
[15:02] <tjaalton> ajax, who dropped the drivers from fedora
[15:03] <tjaalton> let's just drop all the non-kms drivers in v+1 :)
[15:03] <mlankhorst> last codechurn commit appears to be in 2010
[15:03] <tjaalton> minus blobs..
[15:04] <mlankhorst>     Fix lack of precision in video resizing. #26443
[15:06] <rbasak> 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] <rbasak> I don't know if that is sensible or not, but I thought I'd ask.
[15:06] <doko_> rbasak, what do you mean?
[15:07] <rbasak> doko_: have the new source package provide libgo5 and gccgo-go binaries
[15:07] <rbasak> That are empty and just depend on gccgo.
[15:07] <mlankhorst> meh, I'll just replace outb and inb with some macros
[15:08] <rbasak> mlankhorst: on a Build-Depends? Is that possible?
[15:08] <Pwnna> does this channel have logs?
[15:08] <doko_> rbasak, no, the libgo5 b-d is crap. feel free to upload an empty gccgo-go binary, depending on gccgo
[15:08] <Pwnna> my buffer only goes back so far..
[15:08] <rbasak> Pwnna: http://irclogs.ubuntu.com/
[15:09] <rbasak> 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] <doko_> rbasak, well, you build-depend on gccgo anyway, do you?
[15:10] <rbasak> doko_: in Vivid we can. But in older releases that doesn't exist so is no good for backports.
[15:10] <rbasak> And currently we don't have backport branches - they all share the same packaging, which is convenient.
[15:10] <rbasak> 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] <rbasak> 15:08 <doko_> rbasak, no, the libgo5 b-d is crap. feel free to upload an empty gccgo-go binary, depending on gccgo
[15:11] <rbasak> Would you be OK with having this package until Trusty EOLs?
[15:12] <rbasak> 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] <rbasak> An empty gccgo-go binary I mean.
[15:14] <rbasak> mlankhorst: oh, sorry, you were talking about something else :)
[15:15] <mlankhorst> yeah
[15:17] <doko> rbasak, an empty gccgo-go binary package should be good enough, depending on gccgo. no need to build-depend on libgo5
[15:17] <rbasak> doko: ack. Thanks. I'll check it does what we need and upload.
[15:23] <mlankhorst> well looks like the outb are easy to convert
[15:26] <mlankhorst> meh..
[15:32] <doko> rbasak, jamespage: fyi, I verified that docker.io builds with golang 1.4.2 (in the doko/toolchain PPA)
[15:33] <rbasak> Thanks! kickinz1: ^^
[15:33] <jamespage> 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] <jamespage> 1.3.3 + 1.4.x of go has some problems with sqlite stuff
[15:34] <jamespage> which is already impacting on the ppc64el version but not the x86
[15:34] <jamespage> having the golang version aligned makes alotta sense imho
[15:34] <doko> jamespage, like https://bugs.launchpad.net/ubuntu/+source/gccgo-5/+bug/1431032
[15:35] <jamespage> doko, not that one
[15:35] <mlankhorst> does anyone even have a siliconmotion device here?
[15:35] <doko> jamespage, I would prefer 1.4.2, and backport this fix to GCC 5 too
[15:42] <didrocks> 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] <didrocks> "enable") line and my sedding in preinst won't prevent that, how do you handle that generally?
[15:42] <didrocks> 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] <mvo_> didrocks: in a meeting, easiest is probably to have ".d" directory
[15:43] <infinity> didrocks: If it's a dpkg conffile, and it's being edited by gnome-control-center, that's your bug.
[15:43] <infinity> didrocks: That's a massive policy violation.
[15:43] <didrocks> 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] <mlankhorst> ok fixed up siliconmotion
[15:44] <ev> policy smolishy
[15:44] <didrocks> I don't plan to work on whoopsie for the record, was just here to help on the migration
[15:44] <ev> didrocks: bdmurray is your guy
[15:44] <mlankhorst> i probably broke it in the process on supported platforms, but at least that might show if someone's using it..
[15:44] <didrocks> ev: ok, giving the hot potato to him then! thanks ;)
[15:44] <ev> sure thing
[15:45] <didrocks> bdmurray: I guess we can have a debconf prompt on upgrade due to whoopsie, I'm happy to discuss it with you
[15:45] <didrocks> (to give you details)
[15:46] <mlankhorst> infinity: oh can xserver-xorg-video-modesetting be deleted?
[15:46] <mlankhorst> moved to xorg-server
[15:46] <infinity> mlankhorst: The source package, you mean?  Or both source and binary?
[15:46] <didrocks> 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] <mlankhorst> infinity: source and binary
[15:47] <mlankhorst> all the packages recommending modesetting have been fixed
[15:47] <infinity> mlankhorst: Does the new xorg-server P/C/R xserver-xorg-video-modesetting in an attempt to smoothly transition?
[15:47] <mlankhorst> yes, except p
[15:47] <infinity> C/R is fine for forced removal, yeah, as long as nothing depdends on it anymore.
[15:47] <didrocks> mvo_: maybe you would have some opinions once your metting is done ^ (and no .d directory, it's already existing code)
[15:47] <didrocks> meeting*
[15:48] <mlankhorst> only some of the ddx packages were recommending it, but I fixed those in the transition
[15:48] <infinity> mlankhorst: Which package has the conflict/replace?
[15:49] <mlankhorst> xserver-xorg-core
[15:49] <infinity> didrocks: The only way to avoid a conffile prompt is to never change the conffile.  But you can fudge it in pre/post by caching values, restoring to pristine, and then reinjecting values in post.
[15:49] <bdmurray> didrocks: does anything really modify report_metrics?
[15:50] <infinity> didrocks: Really, though, that file should not be a conffile at all if it's being edited at runtime.
[15:50] <infinity> mlankhorst: Yeah, no.  It's not. :P
[15:51] <infinity> mlankhorst: That has a versioned Breaks/Replaces on xserver-xorg-video-modesetting, that's not what you want if you want to force the package off.
[15:51] <didrocks> infinity: agreed, I discovered that was the way it worked when doing the systemd transition though :)
[15:51] <infinity> mlankhorst: You want an unversioned Conflicts/Replaces.
[15:51] <didrocks> bdmurray: yeah, gnome-control-center privacy capplet
[15:51] <mlankhorst> infinity: ah, but the version in vivid is only 0.9..
[15:51] <didrocks> bdmurray: part of whoopsie-preferences
[15:52] <mlankhorst> so << 0.10 will kill it
[15:52] <infinity> mlankhorst: Doesn't matter.  Breaks/Replaces is for overwriting files, not packages.
[15:52] <mlankhorst> oke..
[15:52] <infinity> mlankhorst: Trust me, you want C/R, and unversioned.
[15:52] <mlankhorst> oke
[15:52] <mlankhorst> sec then
[15:52] <infinity> mlankhorst: I mean, sure, versioned if the package is going to show up again later and not conflict, but then you wouldn't be asking me to remove it.
[15:53] <mlankhorst> it might, x has split out all its drivers before
[15:53] <didrocks> bdmurray: I suggest that you changes whoopsie-preferences to read/write to another file, and we remove the conffile on whoopsie upgrade + create the other file with the cached value if report_metrics was true
[15:53] <mlankhorst> irony is that they're getting back..
[15:57] <mlankhorst> infinity: ok I've added C/R unversioned
[15:58] <rbasak> doko: does http://paste.ubuntu.com/10586133/ look OK to you please? I had to add the dh_gencontrol line so I tacked it on to the gccgo package build. Also the final deb produces /usr/share/doc/gccgo-go -> cpp - is this correct?
[15:58] <pitti> smoser, infinity: hm, all of wolfe-0X give me "Permission denied (publickey)" on ssh now..
[15:58] <smoser> pitti, looking
[16:00] <smoser> pitti, seems batuan is denying me
[16:00] <smoser> and if i dont hop through there.
[16:00] <pitti> ah, confirmed
[16:01] <pitti> is that IS? or CI?
[16:01] <infinity> IS.
[16:01] <doko> rbasak, urgh, adding it to gcc-defaults?
[16:01] <infinity> Didn't they send a warning that they were cutting everyone off the jumphosts and it was VPN or die?
[16:01] <rbasak> doko: well that's where gccgo is. Where do you want it instead?
[16:02] <pitti> infinity: ooh! it indeed works without the ProxyCommand now, nice!
[16:02] <doko> rbasak, well, then maybe just providing gccgo-go should be good enough
[16:05] <pitti> smoser: so, all good, thanks (and you should probably update your ssh config too :)
[16:05] <cjwatson> Yeah, the batuan VPN has gone bye-bye.
[16:06] <mvo_> didrocks: well, not too much that can be done really, you could do crazy preinst magic or try ucf, do you have some more details or a open bugreport?
[16:06] <cjwatson> And indeed probably the jumphost too.
[16:07] <rbasak> doko: good point. I'll just add the Provides to gcc-defaults then. Thanks.
[16:07] <pitti> die, ProxyCommands, die!
[16:10] <smoser> so.. given that, and the fact that i used ProxyCommand to do shell hostname hack-resolution... as desscribed here:
[16:10] <smoser>  http://bazaar.launchpad.net/~smoser/+junk/ppc64el-kvmhelpers/view/head:/ip4ppc64el
[16:10] <smoser> is there a way other than using:
[16:10] <smoser>  ProxyCommand nc -q0 $(ip4ppc64el %h) %p
[16:11] <smoser> to get the hostname translation done ?
[16:12] <didrocks> mvo_: tried to express that on bug #1431432
[16:14] <caribou> Is there a way to have sbuild take locally built packages into account to fulfill BuildDeps ?
[16:16] <rbasak> caribou: I have a hack that I use, but I'd love to know if there's an easier way
[16:17] <rbasak> I set $external_commands in ~/.sbuildrc to add an extra local repository and apt-get update
[16:19] <caribou> rbasak: that's what I tried first
[16:19] <cjwatson> smoser: I don't think so, unless you switch to generating .ssh/config sshebang-style.
[16:19] <rbasak> It's a bit painful. I have scripted most of it, but it involves adding the key the Releases file is signed with with apt-key add
[16:19] <rbasak> (and of course generating Release and Packages and signing Release)
[16:20] <caribou> rbasak: I was hoping to do "dpkg -i {}.deb" but the chroot is amd64 and it builds armhf
[16:20] <infinity> mlankhorst: That looks better, thanks.
[16:21] <tarpman> caribou, rbasak: sbuild 0.65 has some improvements wrt. that use case: --extra-repository and --extra-package
[16:21] <rbasak> caribou: you should be able to do that in $external_commands I think. In that environment, apt-get has to be able to install build dependencies anyway so presumably it works.
[16:21] <cjwatson> caribou,rbasak: sbuild >= 0.65.0-1 in unstable has --extra-repository and --extra-package options, but that hasn't been ... that
[16:21] <cjwatson> too slow
[16:21] <cjwatson> Oh, in fact, that's in vivid too
[16:21] <rbasak> Oooh, nice!
[16:22] <caribou> cjwatson: tarpman: thanks I'll look into that
[16:22] <tarpman> rbasak: also 'deb [trusted=yes] file:/...' in sources.list lets you skip the signing dance. hat tip to geofft for that one
[16:23] <smoser> cjwatson, thanks. i didn't think so either. i'll just leave the 'nc' proxycommand in place :)
[16:23] <rbasak> Thanks - I think I learned about that later but never put it together with my hack.
[16:23] <rbasak> I usually have a ~/repo/ directory that contains scripts "add" and "rebuild".
[16:23] <rbasak> And ~/repo/key
[16:23] <rbasak> "add" runs apt-key add against key
[16:23] <rbasak> and adds to sources.list
[16:24] <rbasak> And "rebuild" runs apt-ftparchive and gpg appropriately
[16:24] <rbasak> So then my .sbuildrc just needs to run "add"
[16:24] <rbasak> It's handy when testing inside containers and PPAs too.
[16:24] <rbasak> uh, KVM machines. Not PPAs. That makes no sense.
[16:26] <didrocks> infinity: ok, conffile now killed on upgrade, I need to work on the g-c-c capplet side though as nobody seems to own it
[16:28] <infinity> mlankhorst: Remind me about the removal when the world is ready to migrate.  Can't do it now without breaking things.
[16:46] <didrocks> bdmurray: can you make core-dev ables to push to lp:whoopsie (same for whoopsie-preferences if it's not the case), please?
[16:49] <bdmurray> didrocks: do you know which part of LP is the right place to do that?
[16:50] <infinity> bdmurray: Add core-dev to the team that owns the branch.
[16:50] <infinity> Assuming that's the canonical packaging branch.
[16:51] <didrocks> https://launchpad.net/~daisy-pluckers
[16:51] <infinity> If there's a clear upstream/packaging split, tell didrocks to join daisy-pluckers to do upstream work? :P
[16:51] <didrocks> infinity: no split :p
[16:51] <bdmurray> there isn't but I'm not sure of everything daisy-pluckers can do
[16:51] <didrocks> I'm doing that's patch, because I won't let you down, but to be clear, I'm not a whoopsie maintainer :)
[16:52] <infinity> Looking at some of these branches, yeah, I'm not sure you want all of core-dev there.
[16:52] <didrocks> bdmurray: look at all branches it has access: https://code.launchpad.net/~daisy-pluckers
[16:52] <didrocks> bdmurray: I'm fine with pushing packages if you merge the content back
[16:52] <infinity> didrocks: Just send an MP?  Or just upload and make bdmurray commit the debdiff. :P
[16:52] <didrocks> I will go with the second :)
[16:52] <didrocks> btw, bdmurray, seems latest upload isn't in lp:whoopsie
[16:53] <didrocks> from rsalveti
[17:51] <doko> seb128, didrocks: please fix the component-mismatch mess which robert_ancell just introduced by promoting indic-fonts
[17:53] <mlankhorst> hmm
[17:54] <mlankhorst> oh forgot to set a build-depends on qxl
[17:58] <didrocks> doko: want to trade with whoopsie? It's coming from your team afterall :)
[17:58] <mlankhorst> and ati it seems
[17:58] <doko> didrocks, whoopsie ie evil
[17:59] <ev> breaking my heart, doko
[17:59] <doko> ... oops, evand even
[17:59] <doko> heh
[17:59] <ev> :-P
[17:59] <doko> didrocks, so nothing to trade ;-P
[18:00] <ricotz_> doko, did you notice my complaint about the recent gcc-5 build ;P
[18:00] <didrocks> doing things in my priority order then ;)
[18:00] <doko> ricotz_, it's fixed
[18:00] <seb128> doko, didrocks, robert_ancell can fix it
[18:01] <doko> seb128, yeah, can't see him neither here nor on #distro
[18:01] <ricotz_> doko, i mean: regarding "gcc-5 - 5-20150311-1ubuntu12", now lib32mpx0 is missing
[18:01] <seb128> doko, he's living in .nz
[18:01] <seb128> so sleeping
[18:02] <Laney> Pretty sure he's aware and will work on fixing it
[18:05] <mlankhorst> infinity: so new xorg-server built, can you delete modesetting now?
[18:10] <infinity> mlankhorst: That doesn't seem to be the only thing preventing migration.
[18:11] <mlankhorst> infinity: it will be soon, I rebuild bumped the missing bits
[19:10] <mlankhorst> infinity: how about now? radeon seems to be missing from the autohinter, but it's built in -proposed correctly now..
[19:12] <mlankhorst> yeah just modesetting blocking now
[19:12] <infinity> mlankhorst: Yeah, looks good now.
[19:12] <mlankhorst> \o/
[19:12] <infinity> mlankhorst: Removal done.  Should migrate soon.
[19:36] <asac> anyone knows what KERNEL vs KERNELS is in udev land?
[19:37] <asac> like first entry in this has KERNEL== ... the rest has KERNELS== https://pastebin.canonical.com/127488/
[19:37] <asac> opops bad pastebin :)
[19:37] <asac> http://paste.ubuntu.com/10587178/
[19:43] <asac> ok i think i found it kinda here: https://www.kernel.org/pub/linux/utils/kernel/hotplug/udev/udev.html
[20:05] <flexiondotorg_> Are there any sponsors here who could help expedite some Ubuntu MATE stuff?
[20:30] <flexiondotorg_> cyphermox, Are you available for some sponsoring?
[20:56] <cyphermox> flexiondotorg_: maybe later, but you can point things out or subscribe ubuntu-sponsors, so it shows up in the sponsoring overview.
[20:57] <cyphermox> bbl
[21:09] <knome> hey infinity, did you get bluesabre's ping about the ubiquity slideshow earlier? do you have time to upload it, or should we ask somebody else?
[21:12] <infinity> knome: Oh, you might be better off finding another sponsor.  I finished off that xfce4util transition for you, though.
[21:13] <knome> infinity, ok, cheers
[21:13] <knome> ^ all that being said, anybody can sponsor the ubiquity slidehow upload?
[21:13] <Unit193> infinity: Noticed, thanks very much!
[21:15] <seb128> tyhicks, thanks for investigating those mount issues!
[21:15] <tyhicks> seb128: no problem
[21:37] <knome> Riddell, since you've done it before, would you mind doing a release for the ubiquity slideshow again? we've prepped the xubuntu slideshow and updated translation templates in main
[21:38] <Riddell> knome: I'm working on it right now, however did you know?
[21:38] <knome> Riddell, oh, thanks! :D
[21:38] <knome> Riddell, i guess it's some kind of UIF day black magic
[21:39] <Riddell> knome: your stuff is commited and ready to update?
[21:39] <knome> Riddell, yes! :)
[21:39]  * knome bows very deeply
[21:40] <Riddell> knome: groovy, I'll upload when kubuntu stuff is done
[21:40] <knome> cheers!
[23:29] <knome> Riddell, i see the upload - thanks - are the translations templates updated automatically to LP or do we need to take actions?
[23:31] <Riddell> knome: launchpad should extract them out of the .deb I think
[23:31] <knome> ok, we'll wait until tomorrow or sth