=== charles_ is now known as charles
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== neunon_ is now known as neunon
[05:37] <pitti> Good morning
=== Malsasa_ is now known as Malsasa
=== FourDollars_ is now known as FourDollars
=== kickinz1|afk is now known as kickinz1
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
[08:01] <dholbach> good morning
=== milli` is now known as milli
=== sil2100_ is now known as sil2100
=== doko_ is now known as doko
=== Malsasa_ is now known as Malsasa
=== Malsasa is now known as Guest41468
=== Malsasa_ is now known as Malsasa
=== kickinz1 is now known as kickinz1|afk
[11:07] <pitti> jamespage: the neutron regression looks real (ERROR: HYPERV PLUGIN IS NOT RUNNING); maybe some glitch with the new generated init.d/upstart job scripts?
[11:07] <pitti> the other tests succeeded
[11:07] <jamespage> pitti, looking at that now
[11:08] <pitti> jamespage: if you think it's a race, I'm happy to restart, but so far they seemed pretty stable
=== cking_ is now known as cking
[11:16] <jamespage> pitti, interesting
[11:17] <jamespage> pitti, the package in updates also does the same thing; installs and then shutsdown straight away due to missing configuration
[11:17] <jamespage> pitti, I guess we where race lucky before :-(
[11:17] <pitti> jamespage: you mean s/updates/vivid/, I presume? ah, so it didn't wait long enough for the startup to actually finish?
[11:18] <jamespage> pitti, quite possibly
[11:18] <jamespage> pitti, I'll look at test tests again
[11:28] <sladen> I'm out of touch, who holds the keys for developer.ubuntu.com?
[11:28] <sladen> ...there's a broken example that I'd love to just-fix in 30 seconds
[11:29] <sladen> instead of begging other people to do
[11:36] <sil2100> mitya57: hey! So I made qtserialport-opensource-src buildable on amd64, which made qtdoc-opensource-src buildable and made other things buildable as well - waiting for pyqt5 to finish now
[11:37] <sil2100> mitya57: my fix for qtserialport-opensource-src was really really dumb but I confirmed that it was actually working on a chroot
[11:44] <zyga> stgraber: hi, what's the most Ubuntu-portable way of using the freezer subsystem?
[11:45] <zyga> stgraber: I want to run a process in a new cgroup and once it terminates, freeze that cgroup, inspect any children if may have created (and kill them)
[11:45] <LocutusOfBorg1> hi developerz!
[11:45] <zyga> stgraber: I'd like to support Ubuntu 14.04+ but 12.04 (with LTS kernels) would be also nice
[11:45] <zyga> stgraber: is there a intermediate service I should be talking?
[11:45] <zyga> stgraber: systemd / cgroupmgr / something else?
=== _salem is now known as salem_
=== Tribaal_ is now known as Tribaal
[12:49] <mitya57> sil2100: o_O, I can't believe that simply swapping two lines fixed it
[12:50] <mitya57> Is it a bug in debhelper?
[12:52] <mitya57> I thought that file was not generated at all (even reported that as https://bugreports.qt.io/browse/QTBUG-43846)
[12:52] <sil2100> mitya57: now this is something I don't understand - from my various experiments in an chroot this is actually what fixed it
[12:52] <sil2100> mitya57: as after removing it completely from the .install it was mentioning that it's there but not installed
[12:53] <mitya57> Weird
[12:53] <mitya57> Anyway, thanks for finding the solution!
[12:53] <mitya57> Now I need to do something with qtwebsockets failure on powerpc
[12:53] <sil2100> mitya57: and really - in the original order it wasn't generated, but when the -index one is first, is magically gets built - I wonder if that's not some race somewhere, but yeah...
[12:53] <sil2100> Maybe there would be a better solution, but at least this one works ;p
[12:54] <mitya57> In the report I linked upstream also suggested that it's a race condition
=== kickinz1|afk is now known as kickinz1
=== MacSlow is now known as MacSlow|lunch
=== pgraner-afk is now known as pgraner
=== marcusto_ is now known as marcustomlinson
[13:46] <mitya57> sil2100: FYI: https://codereview.qt-project.org/103701
[13:46] <mitya57> Maybe at some point in the future we'll be able to drop appmenu-qt5 completely
[13:47] <sil2100> mitya57: huh, that's something new!
[13:47] <sil2100> mitya57: need to see how they're trying to do that, but yeah, I wouldn't mind this being upstream
[13:52] <alexbligh1> rbasak, I hate to bug you, but have you had a chance to look at LP#1366174 ?
[13:52] <mitya57> sil2100: that is a very early WIP, no real code yet.
[13:53] <rbasak> alexbligh1: sorry. I haven't forgotten. I'm still working on MySQL :-(
[13:53] <alexbligh1> rbasak, my commiserations ...
[13:54] <rbasak> I don't mind you pinging me though. Please do lest I forget. I will get to it eventually.
[13:54] <alexbligh1> rbasak, you may regret saying that ...
[13:54] <rbasak> I'm also spending an hour a day now on mentoring others to remove me as a bottleneck for this stuff.
[14:00] <alexbligh1> Did ubottu die, or does he no longer like decoding bugs in LP#1366174 format?
[14:01] <Unit193> LP #1366174
[14:01] <ubottu> Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged] https://launchpad.net/bugs/1366174
[14:02] <alexbligh1> I could have sworn that worked without the space before.
[14:03] <Unit193> Nope.
[14:04] <alexbligh1> I stand corrected then.
[14:05] <Unit193> There's a couple different formats it likes, but it likes the space.  It'll do links too of course.
[14:06] <LocutusOfBorg1> arges, thanks!
[14:07] <arges> LocutusOfBorg1: no problem
[14:17] <mdeslaur> pitti: "Note that I'm not claiming the merging for this package" - lol, nice try :)
[14:18] <pitti> mdeslaur: which one was that?
[14:18] <mdeslaur> pitti: samba...it made me chuckle, that's all :)
[14:20]  * rbasak ponders adding a disclaimer to every changelog of every upload :-P
[14:20] <pitti> well, I don't think it's unfair; I earn a ton of merges already because people don't merge their's; I don't want to be penalized even further by fixing the archive with no-change uploads :)
=== MacSlow|lunch is now known as MacSlow
=== zyga is now known as zyga-afk
[14:47] <LocutusOfBorg1> pitti, can I merge samba then? the merge is easy, no conflicts
[14:47] <pitti> if you want to, please
[14:49] <LocutusOfBorg1> as soon as I finish testing for bug 1411507
[14:49] <ubottu> bug 1411507 in virtualbox (Ubuntu) "[SRU] virtualbox-guest-dkms 4.3.10-dfsg-1: virtualbox-guest kernel module failed to build [error: 'generic_file_aio_read' undeclared here (not in a function)]" [Undecided,New] https://launchpad.net/bugs/1411507
[15:30] <LocutusOfBorg1> pitti can you sponsor it or should I open a bug?
[15:31] <LocutusOfBorg1> I can send the debdiff by mail
[15:36] <pitti> LocutusOfBorg1: bug probably works better in case some other sponsor gets to it earlier, but mail WFM too
[15:36] <stgraber> zyga-afk: cgmanager is your best bet for that I think
=== Laney changed the topic of #ubuntu-devel to: Archive: open (alpha 2 freeze) | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[15:37] <arges> Laney: hey. mind if I merge virt-manager? it will fix a bug for me.
[15:37] <LocutusOfBorg1> I think I send it, I can open a bug if needed
[15:37] <Laney> arges: no attachment there, go wild
[15:38] <arges> Laney: yay. thanks
[15:47] <hallyn> pitti: hey.  on bug 1411978, others have reported this.  It seems to happen when you switch to systemd and then back again.  maybe dbus ges removed?  i personally don't think cgmanager is to blame but i could be wrong
[15:48] <ubottu> bug 1411978 in cgmanager (Ubuntu) "cgmanager and udev 208-8ubuntu8.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Low,Confirmed] https://launchpad.net/bugs/1411978
[15:48]  * hallyn tries in a container
[15:49] <pitti> hallyn: yeah, I followed up there explaining that booting and upgrading with systemd in utopic is unsupported and known broken, so feel free to just invalidate
[15:50] <hallyn> pitti: you actually said "with upstart", so i got confused
[15:50] <pitti> hallyn: oh, did I? argh
[15:50] <hallyn> :)
[15:51] <pitti> followed up
[15:51] <pitti> hallyn: wah, wah, hate init systems! :-)
[15:51] <hallyn> pitti: see bug 1407954 for a dup
[15:51] <ubottu> bug 1407954 in cgmanager (Ubuntu) "package cgmanager 0.32-4ubuntu1.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1407954
[15:53] <pitti> hallyn: AFAIK cgmanager isn't even using the system d-bus, is it? it implements its own server
[15:54] <hallyn> no, but the upstart init job starting does
[15:54] <hallyn> so i htink it's a pakcaging bug with systemd or more likely upstart
[15:55] <hallyn> though, hm, dbus shouldn't be required
[15:57] <hallyn> worthwhile question might be "how did you switch back to upstart'
[16:01] <seb128> apw, hey, your most recent casper upload doesn't seem to be in the vcs, is that a push omission?
[16:02] <apw> seb128, that'd be me doing it wrong i recon
[16:02] <apw> seb128, shall i repair that ?
[16:02] <seb128> apw, that would be great, thanks :-)
[16:02]  * apw slaps self
=== Malsasa_ is now known as Malsasa
[16:14] <apw> seb128, ok i think that is repaired
[16:15] <seb128> apw, looks so, thanks!
[16:15] <apw> seb128, thanks for catching, and checking
[16:25] <hallyn> stgraber: weren't there autogenerated docs on the lxc api posted somewhere?  (they're no tlinked on https://linuxcontainers.org/lxc/introduction/)
[16:25] <stgraber> hallyn: they're linked from the documentation page
[16:25] <stgraber> hallyn: https://linuxcontainers.org/lxc/apidoc/
[16:26] <hallyn> awesome, thanks
[16:27] <hallyn> stgraber: oh, i see.  ihave to use menus to find the docs page :)
[16:27] <hallyn> iow, my non-javascript browser is sol
=== zyga-afk is now known as zyga
[16:28] <stgraber> hallyn: works in w3m :)
[16:28] <hallyn> course the apidoc page itself requires js so just as well
[16:28] <stgraber> but yeah, I guess a graphical browser which does CSS but no JS would be a problem
[16:28] <zyga> stgraber: can I use cgmanager on 12.04 as well?
[16:28] <zyga> stgraber: or can I just do wild-west manual cgroup poking there and don't look back>?
[16:29] <stgraber> zyga: cgmanager works fine on 12.04 though it's not in the archive so you'll need a backport (like the ones we maintain in ppa:ubuntu-lxc/stable)
[16:31] <zyga> stgraber: that sounds okay
[16:31] <zyga> stgraber: how about on the phone, the codebase I work on supports 12.04+ and the phone
[16:31] <stgraber> cgmanager is on the phone and used by default by upstart and the app launcher
[16:31] <zyga> excellent, thanks
[16:32] <zyga> I'll google for the API and see what we can do with it
[16:32] <zyga> stgraber: just one last question, how does it cooperate with systemd?
[16:32] <stgraber> works fine alongside it, they usually don't touch the same cgroups
[16:32] <zyga> stgraber: ok
[16:33] <zyga> stgraber: my use case is to put a process in a new cgroup and freeze it at some point time later (to reliably kill all children)
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
[17:01] <jamespage> anyone know which bit of systemd populates /etc/machine-id ? and what should happen on a upstart based system?
[17:01] <mitya57> sil2100, returning to appmenu-qt5: can I land it?
[17:01] <jamespage> context: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1413293
[17:01] <ubottu> Launchpad bug 1413293 in nova (Ubuntu) "Unable to start instances, empty /etc/machine-id file." [Undecided,New]
[17:03] <sil2100> mitya57: yeah, it should be fine to do so - I double tested that all works fine even without Qt 5.4
[17:03] <mitya57> sil2100, then I will now land three my branches :)
[17:05] <jamespage> utlemming, smoser: reading http://www.freedesktop.org/software/systemd/man/systemd-machine-id-setup.html is this something we need todo for vivid on first boot for cloud-images?
[17:06] <jamespage> ^^ see above bug for context
[17:06] <utlemming> jamespage: looking
[17:07] <jamespage> utlemming, 14.04 deploys don't get that file, so I'm wondering whether its a bit of cruft from the build process for vivid
[17:07] <jamespage> esp as vivid is still upstart right now
[17:08] <utlemming> jamespage: I think this is an artifact of us switching from cloud image custom live build to using a stock live build
[17:09] <smoser> reading
[17:10] <smoser> it would seem, yes. that we shoudl set that
[17:16] <xnox> jamespage: at the moment /etccc/machine-id is borked up on ubuntu
[17:16] <xnox> jamespage: it should be done by "first boot job" or the "installer", in practice it's done on the livefs builder and thus all ubuntu desktops have the same one.
[17:16] <xnox> dito dbus machine-id
[17:18] <Odd_Bloke> xnox: jamespage: Am I right in thinking that we would (ideally) not have /etc/machine-id on the images at all (so it'll be generated at boot time)?
[17:18] <xnox> jamespage: smoser: ideally, the livefs builder should be fixed to delete/omit those. But then something should be enabled to generate it properly.
[17:18] <jamespage> Odd_Bloke, xnox: on a systemd boot, if its empty it gets populated automatically
[17:18] <xnox> Odd_Bloke: yes.
[17:18] <jamespage> just not under upstart
[17:18] <jamespage> so removal for now might be best
[17:18] <xnox> jamespage: cool. needs an upstart job + removal on the image builder
[17:19] <jamespage> dumb here just thought he'd try a complete openstack deploy with systemd
[17:19] <jamespage> however forgot that juju only installs upstart configs right now :-)
[17:19] <jamespage> bang!
[17:19] <xnox> =)))))
[17:22] <SpamapS> smoser: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1413279 <-- I won't have time to fix until about 3 weeks from now, but it might be a pretty easy fix for you to slam in there... just sayin.
[17:22] <ubottu> Launchpad bug 1413279 in ifupdown (Ubuntu) "upstart event static-network-up emited to early" [High,Triaged]
[17:23] <Odd_Bloke> We intentionally truncate /etc/machine-id at the moment (rather than deleting it).
[17:24] <smoser> SpamapS, well, isn't bug 1413279 a dupe of bug 1379427 ?
[17:24] <ubottu> bug 1413279 in ifupdown (Ubuntu) "upstart event static-network-up emited to early" [High,Triaged] https://launchpad.net/bugs/1413279
[17:24] <ubottu> bug 1379427 in ifupdown (Ubuntu) "/etc/network/if-up.d/upstart emits static-network-up to early" [High,Triaged] https://launchpad.net/bugs/1379427
[17:25] <smoser> second, "family" isn't really enough... as i could quite reasonably have 2 or more ipv6 addresses configured for an nic, couldn't i?
[17:25] <SpamapS> smoser: first: yes. second: yes you can, but ifup won't return until they're all assigned.
[17:26] <smoser> ah. that would seem to make sense then.
[17:27] <SpamapS> man page is somewhat silent on duplicate sections
[17:28] <SpamapS> smoser: unfortunately I think this might mean you have to touch ifquery :-/
[17:28] <SpamapS> smoser: as it makes no distinction on family
[17:38] <LocutusOfBorg1> pitti, sorry, mdeslaur pushed a samba update, should I redo the merge?
[17:38] <mdeslaur> LocutusOfBorg1: sorry about that
[17:39] <LocutusOfBorg1> no need to be sorry, I'm just asking how to proceed :)
[17:39] <LocutusOfBorg1> I think you will override also another upload because of CVEs (virtualbox)
[17:39] <LocutusOfBorg1> I'm preparing the debdiff right now (this week I hope)
[17:46] <Odd_Bloke> jamespage: xnox: So mvo added a patch to (just) truncate /etc/machine-id on 2014-10-29; his comment reads "truncate, do not remove otherwise systemd is unhappy". Has systemd learned to cope with it missing since then?
[17:46] <jamespage> Odd_Bloke, not sure
[17:48] <xnox> Odd_Bloke: no. something should generate it. systemd can cope with it not being there, only when the whole /etc is empty as far as i can tell.
[17:48] <xnox> (well precisely condition first boot is satisfied)
[17:55] <xnox> Odd_Bloke: mvo: actually looking at recent source code from systemd, if /etc/machine-id is not present conditionfirstboot is satisifed and then units that have conditionfirstboot are triggered
[17:55] <xnox> e.g. set presets, generate machine id, etc....
=== SturmFlut|AFK is now known as SturmFlut
[18:15] <pfsmorigo_> cjwatson, hi, some of the fixes in grub2 needs to be added to 14.04 as well. 14.04 seems to be using release 9 and all our fixes are after that...
[18:17] <cjwatson> slangasek,infinity: ^- could one of you help pfsmorigo_ out?
[18:18] <cjwatson> pfsmorigo_: I moved to the Launchpad team at the start of the year - I'm still maintaining grub2 in Debian, but hopefully slangasek can give you a new routine contact for Ubuntu grub2 things
[18:18] <pfsmorigo_> cjwatson, I see
[18:19] <cjwatson> There's an ubuntu/trusty branch in the Debian git repository, which ideally would be kept up to date; infinity has access or I can give it to others
=== pgraner is now known as pgraner-errand
[18:25] <infinity> I do indeed have access, haven't looked at it since the switch to the new patch system.
[18:26] <cjwatson> http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html has some recipes.
[18:26] <infinity> pfsmorigo_: Can you highlight the fixes that need SRUing, file some bugs (or if bugs already existed and were closed, point them out to me), etc?
[18:31] <pfsmorigo_> infinity, LP#: 1334793, 1338471, 1295255...
[18:33] <pfsmorigo_> infinity, do you prefer that I open a new lauchpad with all patches so you can apply it?
[18:33] <pfsmorigo_> infinity, there are two fixes without launchpad
[18:33] <infinity> pfsmorigo_: One bug that points at all the fixes might be helpful.
[18:34] <pfsmorigo_> infinity, ok, will do that
[18:34] <pfsmorigo_> infinity, tks
=== salem_ is now known as _salem
[18:45] <hallyn> say, https://bugs.launchpad.net/bugs/1412671 is telling me i took a wrong turn.  but that's the buglink in the bug email i'm looking at.  is launchpad having trouble?
[18:45] <ubottu> Error: launchpad bug 1412671 not found
[18:46] <hallyn> exactly
=== greyback__ is now known as greyback
=== pgraner-errand is now known as pgraner
=== _salem is now known as salem_
[19:18] <infinity> hallyn: Could be a private bug you're not subscribed to.
[19:21] <hallyn> d'oh, right.  i thought i was logged in, but maybe i'm not
[19:21] <hallyn> hm, i am
[19:22] <sarnold> I can't see it either; it's marked private
[19:22] <hallyn> well that's a shame :)
[19:22] <hallyn> i figured if it ws marked private, package owners would still be able to se eit
[19:22] <hallyn> looks like i misunderstood
[19:22] <sarnold> I always get a giggle when I see someone file a bug report Private Security then beg for help then mark it Private -- and no one else will ever see that bug again...
[19:23] <hallyn> but i often see private bugs tha i can open.  i'm confused.  what is one supposed to do then?  is the bug submitter supposed to add people s/he trusts?
[19:24] <sarnold> good question :/
[19:25] <hallyn> ok completely separate question - libvirt needs libcurl-dev to build --with-esx.  apt is telling me i have to choose between openssl, nss, and gnutls versions.  which do we recommend?  all 3 are in main...
[19:27] <mdeslaur> hallyn: it's a licensing issue
[19:27] <hallyn> oh gah
[19:27] <hallyn> now that you mention it i recall libvirt having to deal with that
[19:32] <teward> any way to achieve distro-specific pages (for default pages in a webserver) without scripting debian/rules to specify the file to copy over?  (maybe in the .install file, or some other method with debhelper or such?)
[19:37] <hallyn> mdeslaur: so do you know offhand whichone to use with lgpl code?
[19:39] <mdeslaur> hallyn: is there an openssl exception in that lgpl code? if not, I think gnutls
[19:40] <mdeslaur> hallyn: this is what, libvirt?
[19:40] <mdeslaur> since libvirt already build-deps on libgnutls-dev, I'm guessing the curl gnutls backend would be appropriate
[19:43] <hallyn> mdeslaur: yeah libvirt, and gnutls is mentione din configure.ac, so i'm going with that - thanks
=== alexisb is now known as alexisb_bbl
=== salem_ is now known as _salem
=== kickinz1 is now known as kickinz1|afk
=== kickinz1|afk is now known as kickinz1
[20:55] <infinity> teward: Doing it in Debian rules based on dpkg-vendor is probably your best option.
=== kickinz1 is now known as kickinz1|afk
=== Laney is now known as Guest54456
[22:11]  * Snow-Man is really anxious for a new kernel which fixes #1404558. :(
[22:26] <infinity> Snow-Man: Test out the kernel in -proposed, pretty please?
[22:27] <infinity> Snow-Man: Enable trusty-proposed, apt-get install linux-image-generic, disable proposed.
[22:27] <Snow-Man> it was tested and confiirmed?
[22:27] <infinity> Snow-Man: Since it seems to be an intermittent issue, more testing would be nice.
[22:27] <infinity> Snow-Man: But stgraber's testing has been good.
[22:28]  * Snow-Man sighs.
[22:29] <Snow-Man> having a bug that completely breaks ipv6 be released is pretty terrible and that it's taking this long to get it fixed is extremely frustrating. :(
[22:31] <infinity> stgraber: It's been 5 more days since you commented, are you still confident that LP: #1404558 is fixed?
[22:31] <ubottu> Launchpad bug 1404558 in linux (Ubuntu Trusty) "IPv6 related kernel panic following upgrade to 3.13.0-43" [Critical,Fix committed] https://launchpad.net/bugs/1404558
[22:32] <infinity> Snow-Man: Our kernel SRU process really doesn't allow for rapid turnaround of every single patch and bugfix (we pull out all the stops and burn a lot of hours to do emergency security updates, but we can't push a new kernel every two days for every bug).
[22:32] <infinity> Snow-Man: So, frustrating, yes, but the alternatives are worse. :/
[22:33] <Snow-Man> infinity: How about a bit more testing w/ ipv6 before releasing it to the masses? :/
[22:34] <infinity> Snow-Man: I'm all for that.  Though, in this case, it seemed to need a 24h burn test w/ IPv6.  Most testsuites are geared to testing specific functionality.
[22:34] <Snow-Man> it definitely didn't take that long to trigger here
[22:34] <infinity> Snow-Man: Not saying testing can't be improved, it always can be, but bugs happen. :(
[22:35] <Snow-Man> it was more about the amount of ipv6 activity.
[22:35] <stgraber> infinity: yep, still no kernel panic
[22:35] <infinity> Snow-Man: Anyhow, based on stgraber's comment, and his lack of followup in 5 days, I'm assuming the -proposed kernel will make your machine happy.
[22:35] <infinity> Snow-Man: Oh, and look, even better. :)
[22:35] <infinity> stgraber: Thanks.
[22:35] <Snow-Man> I'm going through and installing the kernel from proposed on my various VMs, but it'll take me a few hours to get it done.
[22:36] <Snow-Man> I would have preferred to not deal with pulling in -proposed and then having to do another round of upgrades in the relative near-term, but it is what it is.
[22:36] <infinity> Snow-Man: The testing versus reactive thing is a bit of a rock and a hard place.  The reason the kernel in proposed isn't released yet is because we do a bunch of testing, and it's not all done yet.  The reason the bug happened is because we need more testing, always.  Never seems to be enough.
[22:38] <Snow-Man> ugh.  I dunno why, but v6 from the ubuntu mirrors isn't working out too well for me either atm. :/
[22:38] <stgraber> Snow-Man: us.archive ?
[22:39] <Snow-Man> yes
[22:39] <stgraber> Snow-Man: over an HE.net tunnel?
[22:39] <Snow-Man> sixxs, but with an HE pop
[22:40] <stgraber> ok, so yeah, known issue, it's been broken for over a week now
[22:40] <stgraber> the route goes through Internap and they've got some bad config which drops everything on the floor at the moment
[22:40] <Snow-Man> :(
[22:40] <stgraber> there are Canonical, HE.net and Internap tickets open about the issue
[22:42] <JanC> the problem with bugs that only happen "once in a while" is often that they may happen more often for one test environment than for another; they may happen once every minute for the user and once every month for the developer trying to fix it...  :-/
[22:46] <pfsmorigo_> is there a way to access shell directly when I do a ssh into the installation?
[22:46] <pfsmorigo_> ssh installer@ip shows me a menu directly
[22:53] <sarnold> pfsmorigo_: try "ssh installer@ip /bin/bash"  ?
[22:54] <pfsmorigo_> sarnold, nope, it still shows the meny
[22:54] <pfsmorigo_> *menu
[22:55] <pfsmorigo_> sarnold, maybe if I log as root@
=== alexisb_bbl is now known as alexisb