[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


[15:53] <primes2h> jibel: ping
[15:54] <jibel> primes2h, pong
[15:54] <primes2h> Hey jibel. How are you?
[15:54] <jibel> primes2h, good. You ?
[15:55] <primes2h> jibel: Nice, thanks. :-)
[15:55] <jibel> Great :-)
[15:57] <primes2h> jibel: sorry for boring you about this, but when are you planning to update the tracker?  natty has been released :-)
[15:58] <jibel> primes2h, I requested a publication, so hopefully within 48 hours
[15:58] <jibel> well less than 48 now
[15:59] <primes2h> jibel: nice! just for curiosity, who is in charge to do this?
[16:00] <primes2h> jibel: usually I mean.
[16:01] <jibel> primes2h, the IS does the updates, I don't have the privileges to modify the files on the server
[16:04] <primes2h> jibel: in this case IS stands for...?
[16:09] <jibel> primes2h, information system
[16:09] <jibel> :)
[16:11] <primes2h> jibel: D'ho! :-!
[16:12] <primes2h> :p


[00:57] <sandprickle> I setup postfix+dovecot starting with mail-stack-delivery, and virtual users are not working. Bounces all mail but that addressed to the mail username that matches my local username. The %d in mail_home and mail_location doesn't seem to be expanding.
[02:15] <mgw> Logos01: thanks, changing bootdev to the dev path (/dev/sdb) worked.
[02:53] <hfaust> hi guys, how are you?
[04:23] <iDealz> anyone have any experience with rebuilding broken RAID arrays?  I had a drive fail completely in an mdadm array 5 and now when I boot my server it boots into initramfs prompt. I believe I need to boot from a CD to get into root, but dont know where to go from there
[04:49] <rostam> HI I am using ubuntu 14.04. I have used debootstrap --downloadonly to download required packages for debootstrap. It works fine, but I see some of the packages have naming convention I do not understand: For example:  zlib1g_1%3a1.2.8.dfsg-1ubuntu1_amd64.deb, But not all the packages have this issue, could someone please help me? thx
[05:20] <sarnold> rostam: I assume it is a : from epoch versioning, 1:1.2.8.dfsg-1ubuntu1
[06:29] <lordievader> Good morning.
[06:34] <Aison> hi
[06:35] <Aison> is it possible, that ufw is just for simple settings?
[06:35] <lordievader> Aison: Imo, yes.
[06:36] <lordievader> You can do simple things, like allow/drop/reject connections but anything more complex... well then you have to write iptables rules.
[06:36] <Aison> yes, I know how to write iptables rules, but my problem is also, that ufw is not removing my custom rules after "ufw disable"
[06:38] <Aison> maybe it's best to use ufw just for filtering of incoming connections
[06:39] <lordievader> What custom rules are you talking about? Those created with ufw?
[06:39] <Aison> eg. things like that:
[06:39] <Aison> -A POSTROUTING -o bond0.2 -s <IP_ADDRESS>/16 -j SNAT --to-source <IP_ADDRESS>
[06:39] <Aison> many of those
[06:40] <lordievader> Aison: I take that you created those outside of UFW, ofcourse it won't remove those.
[06:40] <Aison> yes, when I take them outside, then it is my responsibility :)
[07:47] <hxm> how to know if i am vulnerable to shellshock?
[07:48] <ikonia> there are various tests on the web
[07:49] <lordievader> hxm: If you regularly update your machine you should no longer be vunerable, given you run a supported version.
[07:49] <cynicallemon> hxm: making sure your run updates is a good way
[07:49] <hxm> i am updated, i just wanted to know
[07:49] <hxm> you know, panic attack
[07:51] <cynicallemon> hxm: https://www.digitalocean.com/community/tutorials/how-to-protect-your-server-against-the-shellshock-bash-vulnerability
[07:59] <Aison> argh, wie liest man ipv6 netzmasken?!? muss ich verschiedene subnetze so schreiben 2a02:168:200f:0001::/56, 2a02:168:200f:0002::/56, 2a02:168:200f:0003::/56
[07:59] <Aison> oder so 2a02:168:200f:0100::/56, 2a02:168:200f:0200::/56, 2a02:168:200f:0300::/56
[08:01] <Aison> damn, sorry, wrong channel
[08:01] <Aison> lol
[08:02] <henkjan> Aison: sipcalc is a nice utility for ipv6 addresses/netmasks
[08:02] <hxm> i run the bash version GNU bash, versión 4.2.45(1)-release (x86_64-pc-linux-gnu)
[08:02] <hxm> is that the lastest one?
[08:02] <hxm> i try to upgrade bash and it says is the latest
[08:02] <henkjan> Aison: see output https://p.6core.net/p/Yk3YdNzzdosBDVWhW1WYbtE2
[08:03] <Aison> :D
[08:04] <hxm> np fixed
[08:35] <jamespage> adam_g, comments on mp - missing patch?
[10:00] <jamespage> zul, coreycb: hmm the ironic driver landed in nova for c1
[10:00] <jamespage> rc1 rather
[10:07] <jamespage> adam_g, ironicclient sync from debian (1.2.x)
[10:07] <jamespage> sorry 0.2.x
[10:56] <rostam> HI I see some of the ubuntu packages have extra field: "1%3a" for example  zlib1g_1%3a1.2.8.dfsg-1ubuntu1_amd64.deb. Is this epoch version?  in any case does it have any difference with the package which does not have that extra characthers?  The problem I have I can not use those packages in my http server to download them, the extra packages break the download process.  Thanks
[11:15] <rbasak> rostam: yes, it's for the epoch. The ':' character is in the filename but gets escaped due to HTTP requirements.
[11:21] <rostam> rbasak, if I rename the package (removing extra 1%3a) would cause any issue, or is there a better way doing this? thanks
[11:22] <rbasak> rostam: a better way of doing what?
[11:23] <rostam> rbasak,  I want to remove the "1%3a" from package name?
[11:24] <jamespage> zul, stevedore internal versioning was causing issues so I uploaded 1.0.0 and <IP_ADDRESS> so that I can actually test glance properly
[11:25] <zul> bah
[11:27] <Odd_Bloke> rostam: '1:' is part of the version, not part of the package name.
[11:32] <rostam> Odd_Bloke, ok, so when package is downloaded through http, the  "1:" changes to "1%3a"  ??
[11:32] <Odd_Bloke> rostam: ':' is not a legal character in URL paths so it's encoded to %3a.
[11:34] <rostam> Odd_Bloke, thanks, now I got it.
[11:35] <Odd_Bloke> rostam: :)
[11:37] <jamespage> coreycb, look at you on your IPv6 address :-)
[11:37]  * jamespage stops poking coreycb
[11:40] <jdstrand> lordievader: ufw by default does not flush the primary chains since it by default does not manage the primary change. you should be able to adjust /etc/default/ufw to have MANAGE_BUILTINS=yes, but this may have other side-effects. see /etc/default/ufw for details
[11:41] <jdstrand> s/primary change/primary chains/
[11:43] <lordievader> jdstrand: I don't use UFW ;)
[11:43] <jdstrand> oh whoops
[11:44] <jdstrand> Aison: ^
[12:07] <jamespage> zul, coreycb: almost have nova and glance done
[12:54] <coreycb> jamespage, heh :)
[12:54] <jamespage> coreycb, hello
[12:54] <coreycb> jamespage, hey
[12:58] <coreycb> jamespage, would you mind taking a look at this to see if it looks good so far?  https://code.launchpad.net/~corey.bryant/ceilometer/2014.2-rc1/+merge/236610
[12:58] <coreycb> jamespage, I think I need to pip install to verify some things
[12:59] <coreycb> jamespage, oh and I can take ironic
[12:59] <jamespage> coreycb, adam_g already did
[12:59] <coreycb> jamespage, oh sweet, thanks adam_g !
[13:00] <jamespage> coreycb, interesting - http://specs.openstack.org/openstack/ceilometer-specs/specs/juno/ipmi.html
[13:02] <coreycb> jamespage, yeah pretty cool
[13:03] <jamespage> zul, sigh
[13:03] <jamespage> VersionConflict: (oslo.config <IP_ADDRESS>-a5 (/usr/lib/python2.7/dist-packages), Requirement.parse('oslo.config>=1.4.0'))
[13:03] <jamespage> dealing with it now
[13:03] <zul> nova?
[13:08] <jamespage> zul, no glance
[13:10] <jamespage> zul, I've uploaded new versions of stevedore, oslo.config and oslo.rootwrap with additional .0's to deal with final release/pre-release versioning stuff
[13:10] <zul> ack
[13:19] <jamespage> bug 1373714
[13:36] <jamespage> zul, gah - boto and eventlet are also causing problems...
[13:36]  * jamespage sighs
[13:36]  * zul shakes his head
[13:36] <zul> as in how?
[13:41] <jamespage> zul, for some reason bits of glance use pbr for stuff, and boto and eventlet don't match from a version perspective
[13:42] <zul> jamespage:  gah...you should be able to get around that by patching the requirements.txt
[13:42] <jamespage> zul, yeah - but the eventlet problem is in oslo.vmware as well
[13:42] <jamespage> I can fix that
[13:42] <zul> ok
[13:42] <jamespage> but its a pita
[13:42] <zul> jamespage:  i feel your pain
[13:43] <jamespage> zul, bumping eventlet to 0.15.2 is a 25k diff
[13:43] <jamespage> lots of py3 compat work
[13:43] <jamespage> makes me nervous
[13:43] <jamespage> boto might not be so bad
[13:44] <jamespage> zul, boto - 22k diff
[13:44] <jamespage> again lots of py3 compat
[13:59] <rbasak> utlemming: bug 1375252 interests me. Is cloud-init resetting the hostname as I'd expect here, based on what Azure says, or is walinuxagent supposed to be doing something extra-clever here?
[14:05] <jcastro> jamespage, sorry those openstack charm bugs I filed were not descriptive, I was filing them on the spot. Now that I am back I'll get you more info.
[14:06] <jamespage> jcastro, awesome
[14:06] <jcastro> jamespage, you don't have an orange box do you?
[14:06] <jamespage> jcastro, nope
[14:10] <jamespage> zul, coreycb: We are scheduled to publish 2014.1.3 on Thurs Oct. 2nd for
[14:10] <jamespage> wowser
[14:10] <jamespage> ^^ gaughen :-)
[14:11] <coreycb> jamespage, ok yep
[14:11] <coreycb> jamespage, busy week!~
[14:11] <jamespage> coreycb, yes indeed
[14:14] <coreycb> jamespage, so if something is in universe it can't be a dep in debian/control?
[14:15] <jamespage> coreycb, well it can but will need a MIR
[14:15] <jamespage> coreycb, which one?
[14:16] <coreycb> tox is required to generate ceilometer.conf
[14:16] <coreycb> jamespage, ^
[14:16] <jamespage> great...
[14:17] <coreycb> jamespage, and tests get fubar if I don't include python-pysnmp4 in build-depends
[14:17] <coreycb> but maybe that's just a rules file change, not sure
[14:17] <jamespage> coreycb, pysnmp4 is already under MIR - waiting for security team review
[14:17] <coreycb> jamespage, ah, cool
[14:18] <coreycb> jamespage, guess I should have remembered that, my name is in the bug
[14:18] <coreycb> :)
[14:23] <jamespage> coreycb, hmm tox
[14:25] <coreycb> jamespage, hmm.. tox..
[14:26] <coreycb> jamespage, can we try to MIR?
[14:27] <jamespage> coreycb, use "bash tools/config/generate_sample.sh -b . -p ceilometer -o etc/ceilometer"
[14:27] <jamespage> and bypass tox
[14:31] <coreycb> jamespage, nice, that works
[15:24] <coreycb> jamespage, ceilometer is ready for review - https://code.launchpad.net/~corey.bryant/ceilometer/2014.2-rc1/+merge/236610
[15:51] <queeq> http://pastebin.com/H9LALpSP
[15:51] <queeq> Last lines are actually on different lines, just got malformed when pasted
[15:53] <queeq> Packets are marked:
[15:53] <queeq>   194 15982 MARK       icmp --  *      br0     <IP_ADDRESS>/0            <IP_ADDRESS>/0            MARK set 0x15
[15:59] <queeq> Anyone?
[16:51] <Aison> I guess isc-dhcp-server-ldap is not supporting DHCPv6?
[16:52] <Aison> at least in the schema file there is no dhcpSubnet6
[17:00] <|\n> what should i check first of all, if i see "dhclient.c:2277: Failed to send 300 byte long packet over fallback interface."
[17:05] <jamespage> coreycb, zul: can you guys handle the remaining rc1's please
[17:05] <jamespage> I have a load of charm review/work to finish for eod tomorrow and need to switch focus
[17:05] <coreycb> jamespage, sure
[17:05] <zul> jamespage:  sure
[17:15] <smoser> rbasak, http://blog.oddbit.com/2013/10/04/automatic-dns-entries-for-libvirt-domains/
[17:15] <smoser> stubled across that . and thought of uvt
[17:15] <smoser> does parsing of leases file.
[17:19] <smoser> that is actually really nice. and combined with 'incron' as suggeted. really neat
[17:30] <rbasak> smoser: I hate things that involve modifying /etc/hosts
[17:30] <rbasak> smoser: but an nss module would be nice!
[17:31] <smoser> rbasak, it doesn't require modiying /etc/hosts
[17:31] <smoser> well, the whole solution does.
[17:32] <smoser> but you could just use the parsing libvirt for domain->ip
[17:33] <Logos01> smoser: My apologies, what are you trying to do? (Catch me up)
[17:34] <smoser> well, determine an ip address for a libvirt domain.
[17:35] <Logos01> You could nuke the need for network manager by just sticking w/ dnsmasq and using pkill -SIGHUP dnsmasq whenever there's an inotify event.
[17:35] <smoser> i have no need of network manager.
[17:35] <Logos01> I'm reading the oddbit.com blog page.
[17:36] <smoser> mostly i was just interested in parsing of libvirt xml and dnsmasq.
[17:37] <Logos01> dnsmasq is pretty straightforward in these things.
[17:37] <smoser> ?
[17:37] <smoser> the problem is
[17:38] <smoser>  a.) you start a domain in libvirt named 'smfoo'. it dhcp's and gets an ip address.
[17:38] <Logos01> If I understand it you want to be able to obtain the ip address of an arbitrary libvirt domain/guest.
[17:38] <smoser>  b.) you want to ssh to 'smfoo'
[17:38] <Logos01> Right.
[17:38] <smoser> but smfoo is not resolvable dnswise.
[17:38] <smoser> so you have to do that.
[17:38] <Logos01> And there are ways to make that viable.
[17:38] <smoser> which do not require guest modification?
[17:39] <Logos01> Nope.
[17:40] <Logos01> I am in the habit of using dnsmasq as a local DNS cache on my boxes.
[17:40] <Logos01> So my resolv.conf points to <IP_ADDRESS>
[17:40] <Logos01> This allows me to have whatever upstreams I like -- I could for example have my local dnsmasq instance reference the libvirt dnsmasq as an upstream.
[17:41] <patdk-wk> only issue with that is, no dnssec support
[17:41] <Logos01> The libvirt upstream one will provide responses for its dhcp clients (or at least their leases)
[17:41] <smoser> Logos01, no it wont.
[17:41] <Logos01> patdk-wk: dnsmasq can do dnssec.
[17:42] <smoser> it will provide dns for those that provided it with a hostname on dhcp request.
[17:42] <smoser> and if you launch 10 instances of a disk image that have 'foo' in /etc/hostname it fails.
[17:43] <smoser> avahi is the other guest modification way to publish your name.
[17:43] <smoser> which is what uvtool uses now. but i dont want the guest modification.
[17:43] <Logos01> I'm not in the habit of reusing hostnames during provisioning.
[17:44] <rbasak> smoser: I'm basically doing the same parsing inside uvtool.
[17:44] <smoser> oh. i didn't know that.
[17:44] <smoser> :)
[17:44] <rbasak> smoser: writing /etc/hosts dynamically just feels bad to me.
[17:44] <Logos01> So you want systems to have a shared local hostname, not have that be modified during dhclient lease acquisition, and still have the ability to address a system by hostname upon startup ?
[17:44] <rbasak> smoser: for example, have fun with guests inserting interesting hostnames :)
[17:44] <smoser> Logos01, "provisioning".
[17:44] <smoser> i want no "provisioning".
[17:44] <Logos01> smoser: Then you want no systems.
[17:45] <rbasak> Zeroconf solves the problem.
[17:45] <smoser> i have cloud-init and ubuntu cloud images.
[17:45] <Logos01> Manual provisioning is still provisioning.
[17:45] <smoser> i download them and run them.
[17:45] <smoser> i dont modify them.
[17:45] <rbasak> But avahi-daemon+libnss-mdns didn't seem reliable enough.
[17:45] <Logos01> That's a form of provisioning.
[17:45] <smoser> thats what i want to avoid.
[17:45] <smoser> "guest modification"
[17:45] <Logos01> Then let dhclient assign the hostname.
[17:46] <rbasak> I want sensibly named hosts.
[17:46] <rbasak> THat I specified at the commandline
[17:46] <Logos01> Yeah, there's a meaningful part of the conversation missing here.
[17:50] <smoser> rbasak, actually, the dhclient being run with the hostname
[17:50] <smoser> is more doable now.
[17:50] <smoser> and in the future the nocloud data source would be able to set that.
[17:50] <smoser> the change is that now in utopic, the neworking will not come up until after cloud-init has searched local datasources
[17:51] <patdk-wk> oh? when did dnsmasq get dnssec
[17:52] <Logos01> Not sure when, but: http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
[17:52] <Logos01> "It can be configured to do DNSSEC validation."
[17:53] <Logos01> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2014q1/008086.html <-- looks like it was Q1 2014.
[17:54] <Logos01> Made it into 14.04 w/ dnssec support.
[17:58] <smoser> Logos01, what did you mean by "let dhclient assign the hostname" ?
[17:59] <tafa2> eh
[17:59] <Logos01> smoser: I mean you have your dhcp server assign hostnames for the guests.
[18:00] <smoser> i dont know that i follow.
[18:00] <tafa2> whathttp://askubuntu.com/questions/104918/how-to-get-hostname-from-dhcp-server
[18:00] <tafa2> 2 seconds in google
[18:00] <tafa2> i didnt read it
[18:01] <smoser> guest modification, tafa2.
[18:01] <tafa2> smoser I came late... but you want to give dhcp clients hostnames server by your dhcp server?
[18:02] <tafa2> *served
[18:03] <smoser> never mind.
[18:14] <smoser> it seems this could be fairly well solved with a dnsmasq '--script' or '--luascript'.
[18:15] <smoser> libvirt runs dnsmsasq with dhcp-hostsfile and addn-hosts . the script could then read libvirt, and populate the dnsmasq specific hosts with the new entry.
[18:15] <smoser> you'd still have to query the dnsmasq nameserver to get the response, but youcoudl do it ther.e
[18:15] <Logos01> smoser: That is not guest modification.
[18:15] <Logos01> Guest modification is something done by an automatic provisioning process.
[18:16] <Logos01> Allowing dhcp server to assign hostnames when dhclient is run is a different story.
[18:16] <smoser> but you ahve to modify the guest.
[18:16] <smoser> to make it set its hostname.
[18:16] <smoser> i dont know. maybe i'm missing something.
[18:47] <Logos01> smoser: dhclient *should*, if 'instructed' to do so by the dhcp server, assign the hostname for the dhclient guest.
[18:48] <Logos01> You have to configure your dhcp server to instruct the dhclient binary to set the hostname.
[18:49] <smoser> really ? i dont think that generally sounds like good advice.
[18:50] <smoser> what if i have 2 NICS both dhcp on different networks with different lease times.
[18:50] <smoser> seems unpredictable.
[19:20] <jrwren> i prefer cloud-init setting my hostname :p
[20:51] <[F_F]> Ubuntu = Linux + Cancer + Aids
[20:51] <[F_F]> specially AIDS
[20:54] <bastidrazor> haha, all curable and revolutionary
[21:08] <hxm> hi
[21:08] <hxm> i have apache2 running, the 80 port is busy, now i have a process with webinterface that i want to run in port 80 too
[21:09] <hxm> i changed the listening host but it still says is in use
[21:09] <hxm> how can i do that?
[21:21] <genii> hxm: You changed the port for apache to something else?
[21:21] <hxm> no, i found a solution using proxy_mod and proxypass
[21:23] <genii> Ah, good.
[21:48] <Aison> how can I run a dhcpv6 server and dhcpv4 server at the same time?!?
[21:50] <Aison> the strange thing is, i've got a isc-dhcp-server in /etc/init.d/
[21:50] <Aison> and a isc-dhcp-server.conf and isc-dhcp-server6.conf in /etc/init
[21:50] <Aison> ...-
[21:52] <[F_F]> I guess you need both static IP's first
[21:52] <[F_F]> IPv4 static and IPv6 static
[21:54] <Aison> yes, i've got both, but somehow isc-dhcp-server have got no ipv6 version
[21:55] <[F_F]> hmmm
[21:55] <[F_F]> that's odd
[21:55] <[F_F]> http://knowledgelayer.softlayer.com/learning/adding-ipv6-ubuntu-systems
[21:56] <[F_F]> https://secure.evorack.com/portal/knowledgebase.php?action=displayarticle&id=17
[21:56] <[F_F]> hope that helps
[21:57] <Aison> when I try to start, I get subnet6 statement is only supported in DHCPv6 mode.
[21:59] <Aison> works now :)
[22:00] <[F_F]> Where does 2 links helpful?
[22:00] <[F_F]> or not?
[22:00] <Aison> not directly, the addresses were correctly set
[22:01] <Aison> but the config file had the wrong name ^^
[22:01] <[F_F]> awwww :(
[22:08] <hallyn> jdstrand: any complaints to /sys/firmware/devicetree/** r, in the libvirt-qemu template?
[22:08] <hallyn> (this is for bug 1374554)
[22:11] <jdstrand> hallyn: none
[22:11] <hallyn> thanks, pushing
[22:17] <qman__> Bug 1358925 still being an annoyance :/


[01:19] <Unit193> But...isit?
[08:16] <valorie> !isitout
[08:16] <valorie> lol
[08:16] <valorie> nope
[08:25] <ogra_> could someone update the channel topic in #ubuntu-release-party ?
[09:15] <Unit193> ogra_: Erm, that is you have ops.
[09:23] <ogra_> Unit193, yeah, i noticed the DIY token 🙂
[09:23] <ogra_> ubottu is missing the the channel too (i dont think i can easily add it back)
[09:32] <Unit193> ubottu: join #ubuntu-release-party
[09:32] <Unit193> ogra_: I figured you'd see, but it occured to me much later you might well not since your focus could well be elsewhere.
[15:34] <el> ogra_: if you identify to your account you'll be able to do more things :P
[15:34] <ogra_> el, yeah, i'm lazy ...
[15:50] <tomreyn> i updated #ubuntu's /topic about 24.04 already because we have https://lists.ubuntu.com/archives/ubuntu-announce/2024-April/000301.html
[17:15] <krytarik> tomreyn: I don't see the topic updated yet though.
[17:17] <tomreyn> omg, i posted it to the channel instead of updating it
[17:19] <krytarik> Oh, haha. XD
[17:20] <tomreyn> better don't ask me to hold your beverage today.


[09:23] <czajkowski> Aloha folks
[09:23] <czajkowski> how are we all todya
[09:25] <tdr112> hey czajkowski
[09:26] <czajkowski> tdr112: hows you? back in ireland?
[09:29] <tdr112> yep got back late on Sunday , great time
[09:34] <czajkowski> good stuff,
[09:34] <czajkowski> does it happen once a year?
[09:35] <tdr112> yep that was the 3rd one , there is talk of a smaller one in the uk again in june , near london i think
[09:40] <czajkowski> cool
[09:40] <czajkowski> might see if they are interested in coming along to the next oggcamp that is being planned
[09:41] <tdr112> ebel: would you know how to get a big map of ireland like an svg or some thing a0 size with just the county lines
[09:55] <davem> tdr112: open streetmap?
[09:55] <czajkowski> davem: hey hey
[09:55] <czajkowski> hows you
[09:56] <davem> tired
[09:57] <davem> in work etc ;)
[09:57] <czajkowski> diddums
[09:57] <czajkowski> Keith is coming over here for the weekend
[09:57] <davem> rawr
[09:57] <davem> :p
[09:58] <czajkowski> and sorcha
[09:58] <czajkowski> he came on the ber in Brussels also
[09:58] <davem> yeah was chatting to Niall about it
[09:58] <czajkowski> great way for my bf to meet people , bring the irish piss heads
[09:58] <czajkowski> poor guy and his mates were well thrown with the accents, there were a few of us from ireland
[09:58] <ebel> tdr112: you /can/ export an OSM view from the webpage into an image
[09:59] <ebel> but that's everything
[10:00] <tdr112> ebel: could i get just ireland ?
[10:01] <ebel> then you can get just the counties here http://maps.openstreetmap.ie/?zoom=7&lat=53.55822&lon=-7.84204&layers=0B00FFFFFFFTFFFF
[10:01] <ebel> (but dunno if you can export)
[10:01] <ebel> I think there are county SVG files on wikipedia or something
[10:02] <ebel> The OSM export includes all features incl roads, and works on a box, so you'll probably get a bit of scotland in order to get all of donegal & down in
[10:02] <czajkowski> tdr112: what are you up to
[10:03] <ebel> Of course it is possible to export the data from OSM (using XAPI) then import it into a desktop GIS (geographical information system) application like QGIS and then you can control exactly what to do
[10:03] <ebel> But that's very hard and complex and would take me a few hours :P
[10:03] <tdr112> thinking of making a poster/sign of all the hackerspaces in Ireland printing it to A1 puting an led where each one is and 2d bar codes with links to their web sites , its for an event coming up in a few weeks
[10:04] <tdr112> ebel: na no need for that
[10:06] <ebel> tdr112: http://commons.wikimedia.org/wiki/File:Island_of_Ireland_location_map.svg ?
[10:06] <ebel> or http://commons.wikimedia.org/wiki/File:Ireland_location_map.svg
[10:06] <czajkowski> tdr112: sweet
[10:08] <tdr112> ebel: thanks they will do nicely
[10:11] <tdr112> anyone know a good site for doing qr/2d barcodes
[13:36] <czajkowski> ebel: slashtom ye safe to travel to Oz soon  with Japan being the way it is ?
[13:39] <slashtom> aye, aparently we will be exposed to a lot of radiation as part of regular air travel
[13:39] <slashtom> which happens for every flight everywhere
[13:40] <czajkowski> but surely more so at this time considering the current climate
[13:40] <slashtom> why?
[13:40] <czajkowski> Japan
[13:40] <ebel> earthquakes have nothing to do with climate
[13:40] <slashtom> hopefully the japanese won't plant any nuclear bombs on our plane
[13:40] <slashtom> that would be very mean
[13:41] <czajkowski> I thought with the nuclear power plant issues
[13:42] <slashtom> i think the plane uses jet fuel
[13:42] <slashtom> derived from oil, iirc
[13:42] <czajkowski> fair enough
[13:43] <slashtom> at that altitude, you would be harmed far more by the sun light
[13:43] <ebel> czajkowski: you get 100 uSv of radiation from a long flight like that
[13:43] <ebel> czajkowski: those radiation plants are putting out about 1,000 -> 100,000 uSv of radiation if you stand next to them.
[13:43] <slashtom> however, ebel is wanting to ride through chernobyl
[13:44] <ebel> and remember radiation disperses with distance. so you double the distance between you and the thing, and you get 4 times less radiation (inverse square law)
[13:45] <slashtom> we'll be grand :)
[13:45] <czajkowski> grand so
[13:46] <ebel> 100 uSv of radiation is about as dangerous as smoking 1.4 cigarettes
[13:46] <ebel> eating 10 bananas gives you 1 uSv.
[13:46] <ebel> This is all being blown MASSIVELY out of proportion.
[13:48] <ebel> and remember the nuclear reactor has been shut off.
[13:49] <ebel> nuclear reactors turn uranium into other radioactive stuff which turns into non radioactive stuff.
[13:49] <ebel> the uranium part was turned off seconds after the earthquake. It's the intermediate stuff that's left
[13:49] <ebel> and that'll all turn into non-radioactive stuff naturally over time.
[13:51] <ebel> this is not another chernobyl, it's massivelly different,.
[14:27] <f3d> Event coming up on April 16 that should be of interestEvent coming up on April 16 that should be of interest. http://www.engineersireland.ie/cpd/cpd-training/courses/it-crowd-seminar/ Trying to organise a good prize for a competition on the day.. http://www.engineersireland.ie/cpd/cpd-training/courses/it-crowd-seminar/ Trying to organise a good prize for a competition on the day.
[14:54] <tdr112> hey frank
[14:56] <ebel> yo yo
[15:01] <f3d> Hi Jeffrey, sorry, was away on another window
[15:03] <tdr112> what sort of competition  is it going to be
[15:10] <czajkowski> whoo  I get to go to ireland on Monday for the day
[15:11] <slashtom> in and out on the same day?
[15:11] <tdr112> just dublin ?
[15:16] <czajkowski> yup
[15:16] <czajkowski> in and out for presentations and gone again
[15:16] <tdr112> ah no tie to meet up
[15:16] <czajkowski> I dont think so
[15:16] <czajkowski> meeting finishes @ 4 and ferry at 9
[15:17] <slashtom> ferry!
[15:17] <slashtom> you're taking no chances?
[15:18] <czajkowski> nope
[15:18] <czajkowski> but also easiest and fastest way for us to get there
[15:18] <slashtom> you travelling alone?
[15:18] <czajkowski> nope myself and CEO
[15:18] <slashtom> ferry at 9... holyhead at midnight
[15:18] <slashtom> then a 5 hour drive
[15:19] <tdr112> czajkowski: did you get a car over there
[15:19] <czajkowski> nope
[15:19] <czajkowski> boss lives down near Bristol
[15:19] <czajkowski> so bristol to Holyhead is not far
[15:20] <slashtom> lol
[15:20] <slashtom> it's a 4-5 hour drive
[15:21] <slashtom> i took that 9pm ferry before, i got to cheltenham (an hour before bristol) at about 4am
[15:21] <slashtom> there are no motorways through wales, you have to go toward manchester then via birmingham
[15:22] <czajkowski> 1.5hrs on the ferry
[15:23] <slashtom> http://maps.cloudmade.com/?lat=51.727028&lng=-3.054199&zoom=7&directions=53.30903170363969,-4.628591537475586,51.45732284495817,-2.5932884216308594&travel=car&styleId=1&opened_tab=1
[15:23] <slashtom> but that's no accurate, it is routing you down the A5 - through snowdonia and loaded with speed cameras
[15:23] <slashtom> not accurate*
[15:24] <czajkowski> nods
[15:24] <czajkowski> so a better route??
[15:25] <slashtom> i would go along the A55 and get off near crewe, head down to nantwich and join the M6
[15:25] <slashtom> then hope on the M5, and you're there
[15:25] <slashtom> longer, but much faster roads
[15:26] <delcoyote> put your foot down! :-)
[15:26] <slashtom> but i presume your guy there knows the area
[15:27] <czajkowski> aye
[15:28] <slashtom> http://maps.cloudmade.com/?lat=52.492815&lng=-2.861938&zoom=9&directions=53.293130787340516,-4.61151123046875,53.156858919018774,-2.8973007202148438,53.064944749645356,-2.3315048217773438,52.53371480958668,-1.9702434539794922,51.44373668041616,-2.57904052734375&travel=car&styleId=1&opened_tab=1 - that's more like it, much faster
[15:30] <slashtom> at that time of night, you can comfortably cruise along the M6 and M5 at 150 (or at least that's what i would do)
[15:30] <slashtom> :P
[15:30] <czajkowski> nods
[15:30] <slashtom> enjoy
[15:30] <slashtom> i'm surprised you're not coming here for saturday ;)
[15:31] <czajkowski> nope
[15:31] <czajkowski> have organised a massive meet up
[15:39] <ebel> we used to fly bristol/dublin all the time
[15:39] <ebel> looks like you'll be driving the length and breath of wales
[15:39] <czajkowski> in an audi I dont mind
[15:42] <slashtom> ebel: fsck wales, it's better to head straight for england
[15:42] <slashtom> better roads :P
[15:42] <slashtom> there's even a Bristol/Shannon route ;)
[15:44] <ebel> also remember slashtom can drive relatively fast.
[15:44] <ebel> :P
[15:46] <slashtom> ebel: my last car only had a top speed of 190
[15:46] <slashtom> i just tended to drive quickly in it
[15:46] <slashtom> and agressively...
[15:46] <slashtom> much like an audi driver :P
[17:30] <tdr112> anyone run tomcat
[20:40] <airurando> Hi all
[20:40] <airurando> czajowski is currently on the live uupc show
[20:40] <airurando> link:
[20:41] <airurando> http://podcast.ubuntu-uk.org:8000/uupc.mp3