[00:46] <rbasak> powersj, nacc: grep-dctrl -S may be helpful. Give it stuff in /var/lib/apt/lists.
[00:47] <rbasak> Actually that's backwards (affects input not output).
[00:47] <rbasak> But still, grep-dctrl may be helpful here.
[00:51] <nacc> rbasak: good point
=== JanC is now known as Guest53841
[05:37] <hyperair> kirkland: hey i noticed your github mirror of byobu. do you accept PRs to that, or would you prefer that i push to lp?
=== NCommander is now known as KD2JRT
[08:36] <Unit193> didrocks: Thanks for glib2.0, it should fix some nasty crap.
[08:43] <didrocks> Unit193: heh, hoping so. running it happily for 24h at least :)
[08:43] <Unit193> didrocks: Oh?  Did you get nasty mounts on the desktop?
[08:45] <didrocks> Unit193: no, I didn't in my case. I think jdstrand had some, but I saw it's supposed to fix it in that new release
[08:46] <Unit193> It's still regressed from zesty, but much better. (So says my Debian install, or the packages direct from Debian.)
[11:03] <Unit193> Great, so now when I try to switch to a TTy, lightdm pops back up.  That in itself is bad, but trying to switch to a TTY to remove .xauthority and .iceauthority so I can actually login...
[11:05] <ogra_> you can always add "text" to the kernel cmdline in grub (as a last resort)
[11:06] <ogra_> that will boot to tty and block lighdm fom starting
[11:09] <Unit193> No, it doesn't do that anymore (last I checked), you have to do the new easy to remember 'systemd.unit=multi-user.target'.  That's what I ended up with since I couldn't ssh in (NM not logging me on yet?), just hard when grub doesn't like the USB keyboard. :D
[11:33] <Lowas> #ubuntu-artwork
[11:53] <ogra_> Unit193, oh, i didnt know we improved our userfriendliness so much :P
[11:53]  * ogra_ shakes head
[11:54] <Unit193> Yeeeah...  I poked around with a few services to see if 'text' was pretty effortless to get back.  Would take someone that knows systemd better than I.
[12:00] <Unit193> ogra_: In theory dumping '3' in might work too, easier to remember but not as nice as 'text' :P
[12:02] <ogra_> heh, so the redhat initlevel stuff silently sneaked into debian via systemd
[12:03] <ogra_> s/initlevel/runlevel/
[12:03] <Unit193> Untested!
[12:32] <doko> niedbalski, rbasak: is that the percona issue?
[12:32] <niedbalski> doko, yes, I am awaiting for review on the latest patch from rbasak.
[12:37] <jdstrand> didrocks, Unit193: this is my bug: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1712100
[12:37] <ubottu> Launchpad bug 1712100 in nautilus (Ubuntu) "some disk volumes showing up that should probably be filtered" [Low,New]
[12:43] <Unit193> jdstrand: The linked bugs contained in that were the ones I found.  I had a nice list of "dev, pts, sys, proc", etc, etc.  sshfs mounts too.  It got nasty.
[12:44] <jdstrand> icky
[12:55] <rbasak> niedbalski: "+ # Turn on Werror (warning => error) when using maintainer mode."
[12:56] <rbasak> niedbalski: is it possible that upstream have left that there exactly for us to what we need? Did you try turning off that mode to see if it fixes the build, and if so, is doing that suitable for us?
[12:57] <rbasak> Though actually I see other instances of -Werror too that you've had to address.
[12:57] <rbasak> So perhaps not.
[12:57] <niedbalski> rbasak, yes, tried that, still I saw dependencies being compiled with the flags.
[12:59] <rbasak> doko: do you have an opinion on how to handle this please? I suggested not making the new gcc-7 warnings into errors if they don't appear to reveal actual bugs. Does that seem OK to you?
[13:43] <lag> Hola
[13:43] <lag> When a package is built, are the logs stored/publicly available?
[13:44] <lag> Similar to: https://kojipkgs.fedoraproject.org//packages/mesa/17.2.2/2.fc27/data/logs/aarch64/build.log
[13:46] <Unit193> https://launchpad.net/ubuntu/+source/mesa → https://launchpad.net/ubuntu/+source/mesa/17.2.2-0ubuntu1/+build/13541743 → https://launchpad.net/ubuntu/+source/mesa/17.2.2-0ubuntu1/+build/13541743/+files/buildlog_ubuntu-artful-arm64.mesa_17.2.2-0ubuntu1_BUILDING.txt.gz
[14:01] <lag> Unit193: Ideal, thanks
[14:16] <Stravy> hi there, sorry to bother you if this message is not in the right channel. I posted a bug report concerning Artful but I'm not sure it's in the right place to be seen : https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1719612
[14:16] <ubottu> Launchpad bug 1719612 in initramfs-tools (Ubuntu) "non-us keyboard layout not setup in initramfs" [Undecided,New]
[14:44] <ddstreet> sil2100 my vlan sru has been in proposed for 2 wks, can you push it to updates?  cpaelzer uploaded it but i think he's out
[14:47] <sil2100> ddstreet: sure, I'll get to it in a bit possibly
[14:47] <ddstreet> thanks!
[14:47] <sil2100> I'm slowly running through the pending page
[14:55] <sil2100> ddstreet: hm, there seems to be a nova autopkgtest regression with the new vlan, doesn't look related but still worrying as this test is generally passing for others
[14:56] <ddstreet> sil2100 i saw that, but the failure is 'nova-something isn't running'
[14:56] <sil2100> ddstreet: but I did see some nova issues with this test recently for other SRUs as well, just different architectures
[14:56] <ddstreet> don't see how that could be related, but i'll try running the autopkgtest for it locally without the -proposed vlan pkg
[14:56] <sil2100> slashd: you mentioned that the nova autopkgtest issues are being investigated ^ ?
[15:00] <ddstreet> sil2100 i also have an initramfs pkg in -proposed but only at 6 days, i added a comment to its bug noting that the linux-lts-* test failures are unrelated to the initramfs pkg update
[15:02] <slashd> sil2100, yes but let me double-check with freyes one more time ^^
[15:06] <slashd> sil2100, yes look the regression potential section "The failures are not related to this change, nova autopkgtest failure is being analyzed at https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1713059
[15:06] <slashd> "
[15:06] <ubottu> Launchpad bug 1713059 in nova (Ubuntu Xenial) "drop db sync commands from OpenStack packages" [High,Fix committed]
[15:10] <freyes> slashd, ddstreet, sil2100, a new nova package was uploaded (xenial) to fix the nova autopkgtest failure, probably still waiting to be approved
[15:11] <sil2100> freyes: but do you know if the same could be the case on zesty?
[15:11] <sil2100> freyes: since we're seeing nova test failures on zesty as well
[15:11] <freyes> sil2100, let me take a look, for zesty there were no failures with my patch
[15:12] <sil2100> slashd: ^
[15:12] <slashd> sil2100, freyes there is a magnum (s390x) failure IIRC on zesty
[15:14] <sil2100> For vlan I also see a failure like that for nova
[15:14] <sil2100> e.g. the nova autopkgtest failing
[15:14] <slashd> sil2100, magnum one seem to always fail : http://autopkgtest.ubuntu.com/packages/m/magnum/zesty/s390x
[15:15] <sil2100> I'm trying to figure out if this is related to the issue freyes was mentioning: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/s390x/n/nova/20170921_203340_e5492@/log.gz
[15:15] <slashd> sil2100, ok freyes ^
[15:18] <freyes> sil2100, is /var/log/ from the testbed published somewhere?
=== leitao_ is now known as leitao
=== mhcerri_ is now known as mhcerri
[16:56] <powersj> rbasak: nacc is it possible to create a precise chdist now given that it appears the precise Release file is not signed?
[16:56] <powersj> https://paste.ubuntu.com/25680735/
[16:57] <nacc> powersj: i think you can set allow_insecure (see man apt-secure) for just the precise chdist
[16:57] <nacc> powersj: each chdist has it's own etc/apt/apt.conf.d
[16:58] <cjwatson> it's signed, you just need an older ubuntu-keyring I think
[17:04] <powersj> ok for now I added "[trusted=yes]" to the apt sources.list lines
[17:04] <powersj> thanks
[22:41] <Unit193> sarnold: Unfortunatly I remembered.
[22:41] <sarnold> Unit193: ha! :D what's up?
[22:43] <Unit193> sarnold: Since Ubuntu doesn't have codesearch, do you happen to know of anything else other than (presumably) Ubuntu's geoclue and ubiquity that use http://geoip.ubuntu.com/lookup?
[22:46] <sarnold> Unit193: aha! :) sad to say my own archive mirror of unpacked sources is now woefully out of date since I never automated the unpacking step :( One Of These Days [tm]
[22:47] <sarnold> Unit193: jamie's got some scripts that can do the search "eventually".. it's not real quick, kind of manual..
[22:48] <sarnold> jdstrand: no real rush, is there any chance you could search for users of http://geoip.ubuntu.com/lookup? re 1617535 maybe it'd be nice to be rid of the package entirely?
[22:49] <Unit193> sarnold: Oh fancy!  Didn't know you had such a thing.  I'm not entirely sure it's worth grepping the entire repo for, though. :3
[22:53] <Unit193> sarnold: If the goal is to remove that, searching for other terms might be more useful as that isn't likely used.  I know of some external tool that uses the geoip service but not geoclue.
[22:53] <sarnold> ohhh
[22:55] <Unit193> ...On a related but different note.