[00:09] <rbasak> nacc: I wrote up some notes as they occurred to me. A starting point for tomorrow at least.
[00:11] <nacc> rbasak: thanks
[00:16] <nacc> rbasak: i think i got your active-series-only function in 18 lines of code :)
[00:24] <nacc> rbasak: ok, i'm off for the night, i just merged your changes for queue and pushed out the active-series feature, although it's not working for applied yet, probably something obvious
=== led2 is now known as led1
[09:05] <bdrung_work> pitti, good morning. do you have time to discuss apport-retrace?
[09:08] <pitti> bdrung_work: good morning! a bit
[09:10] <bdrung_work> pitti, point one: i have some commits for you in git. may i wait until you switched to git or should i dig out my rusty bzr knowledge to apply the changes to bzr?
[09:11] <pitti> bdrung_work: I pinged bdmurray yesterday whether he was fine with switching to git; I defer to his judgement, as he is the primary maintainer now
[09:11] <pitti> bdrung_work: alternatively, attach the format-patches to the LP bug, and it's easy enough for me to apply to bzr :)
[09:12] <bdrung_work> i have 9 patches right now.
[09:14] <arune> newbie questions, I have imported 3 patches with quilt, but they are applied in the wrong order when building, how do I change the order?
[09:15] <pitti> arune: in debian/patches/series
[09:15] <bdrung_work> arune, debian/patches/series
[09:15] <pitti> but they get applied in the same order as you created them
[09:15] <arune> I just change the order there? thanks
[09:16] <arune> seems like that list is the reverse of the order I imported them
[09:17] <arune> nice, now they applied clean
=== Orphis_ is now known as Orphis
[09:42] <bdrung_work> pitti, attached the patches to #1684535
[09:42] <bdrung_work> https://bugs.launchpad.net/apport/+bug/1684535
[09:42] <ubottu> Launchpad bug 1684535 in Apport "Please support CoreDumpFile in crash file" [Undecided,New]
[09:45] <bdrung_work> pitti, point two: #1684117 isn't easy to solve. I have 3 local patches that make it work with debian, but this is still not ideal and working correctly.
=== klebers_ is now known as klebers
=== RAOF is now known as Guest94094
[11:47] <bdrung_work> pitti, there are two ways to solve #1684117. option one: install all specified dependencies in the sandbox and only search for files that are missing (i.e. not specified in the dependencies). option 2: restructure apport.packaging.get_file_package to return a list of (package,version)
[12:18] <bdrung_work> pitti, and another issue: https://bugs.launchpad.net/apport/+bug/1684690
[12:18] <ubottu> Launchpad bug 1684690 in Apport "sandbox: __AptDpkgPackageInfo.get_distro_name() returns host distro name" [Undecided,New]
=== _salem is now known as salem_
=== salem_ is now known as _salem
[15:39] <nacc> rbasak: fyi, --active-series-only is fixed now, was a missed namespace change on my part
[15:40] <rbasak> nacc: thanks. OK to start pushing imports as needed again, or is that still on hold? (No problem if it is)
[15:41] <nacc> rbasak: i think it's ok, my bastion is up again i just haven't restarted the cron job yet
[15:42] <rbasak> OK
[15:42] <nacc> rbasak: and merged your reuqest
[15:43] <nacc> rbasak: but yeah, you can run imports you need by hand for now, i'll start the job again after i'm back later today -- i need to verify ssh and stuff
[15:45] <rbasak> OK thanks
[15:46] <nacc> rbasak: np
[15:46] <nacc> rbasak: and sorry for the delay on that, lots of churn lately :) but patches-applied working again is a big-win
[15:46] <rbasak> It's fine. What delay? :-)
[15:46] <rbasak> (really!)
[15:47] <nacc> i think i've had my bastion for > 24 hours :)
[16:14] <sil2100> bdmurray, cyphermox: could any of you include the relevant SRU information for bug LP: #1676547
[16:14] <ubottu> Launchpad bug 1676547 in network-manager (Ubuntu) "No network connectivity after upgrade from 16.04 to 16.10" [Critical,In progress] https://launchpad.net/bugs/1676547
[16:14] <sil2100> ?
[16:14] <sil2100> Wanted to review it
[16:59] <cyphermox> sil2100: ack
[17:07] <sil2100> cyphermox: thanks!
=== lutostag_ is now known as lutostag
[20:49] <drab> hi, trying to test some versions of ubuntu with qemu, but can't get the installer to work in text mode. anybody knows what magical parameter I need to pass on the command line or something?
[20:50] <drab> I'm running qemu in console with -curses so I need things to work in text mode. I tried DEBIAN_FRONTEND=text,but that didn't do it
[21:17] <tomreyn> drab: use the server install iso or mini.iso
[21:17] <drab> tomreyn: I am already, I'm using mini.iso
[21:18] <drab> somehow qemu thinks that's graphical mode, not sure why, but if I don't specify "text" at boot time (and it uses the framebuffer) it also think that's gfx mode
[21:18] <tomreyn> well those don't use X, but output text, then i don't seem to be getting the issue
[21:18] <drab> and shows nothing in curses
[21:18] <drab> fair enough, I thought ti was strange and maybe it's something else I don't get
[21:18] <drab> I see the pxe boot part, the menu, the kernel booting and then bam, it goes black
[21:19] <drab> and all I have is that msgs saying it's in graphical mode 640x480
=== lutostag_ is now known as lutostag
[21:19] <drab> which is the same thing I get with pxe if I use vesamenu.c32
[21:19] <drab> so I was thinking that "text" didn't matter if it was somehow triggering the framebuffer or something
[21:19] <tomreyn> vesa is a graphics mode
[21:19] <drab> it's not a GUI, but it's not pure text either
[21:19] <tomreyn> 640x480 is vga
[21:20] <drab> yeah, understand,which is why I put "text" on the cmdline
[21:20] <tomreyn> you can't output text if you don't have a means of graphical output
[21:20] <tomreyn> (except on a serial console, i guess)
[21:20] <drab> but that seems to be ignored once pxe hand it over to the installer
[21:20] <drab> qemu has a -curses mode, which shows fine everything up to the installer starting
[21:20] <tomreyn> hmm, yes, i'm not sure what this issue is you're running tinot there, haven't experienced it
[21:21] <drab> if I take the same command/img and run it on my desktop but remove the -curses it show the installer at that point, so pretty sure something is going on when things are handed over to it
[21:22] <drab> just can't figure out what
[21:22] <drab> it looks like something is autoloaded because it thinks it's a graphic mode
[21:23] <tomreyn> what is it you're trying to achieve there anyways, why are you running those tests?
[21:24] <tomreyn> http://download.qemu.org/qemu-doc.html lists all qemu options and their meanings in case you don't have that available, yet
[21:27] <drab> tomreyn: just trying to test some stuff with nfs-kernel-server, so I'm spinning up some qemu instances on test server, ie no gui
[21:28] <drab> I'm ssh'ing into the server and using a command that includes -curses
[21:29] <drab> yeah I looked at those options, especially the -display section
[21:29] <tomreyn> you could add a vnc interface and access that from a graphical desktop
[21:29] <tomreyn> you could use the serial console output instead to get a text only output
[21:30] <drab> I tried to look at serial console, but then it seems I have to provide a kernel to qemu on the cmdline, which is kind of backwards
[21:30] <drab> but maybe I misunderstood how to set that up
[21:31] <tomreyn> the default installer doesn't work over serial, i think, if that's what you mean
[21:31] <tomreyn> there's no requirement to use PV instead of HVM to achieve serial output though
[21:32] <drab> right, that too, altho I meant to get qemu to use the serial console to begin with
[21:32] <drab> but really, it sounds like VNC is my best option at this point
[21:32] <drab> and it's all preseeded so it's really for debugging until I figure out why my postinst script is failing
[21:33] <drab> tomreyn: any chance you have a quick hint on setting up vnc?
[21:33] <tomreyn> maybe you should just install virt-manager on your desktop which has ssh access to the virtualization host, and use this to get a better idea of how qemu is meant to work
[21:34] <tomreyn> it helped me to get started
[21:35] <drab> tomreyn: I looked at that too, but it seems like in order for virt-manager to work you need to get the whole libvirtd shebang
[21:35] <drab> and create another bridge, etc etc... and that test host has already its own bridge and some lxc stuff for testing
[21:35] <drab> I was trying not to make disruptive/major changes to that host
[21:37] <tomreyn> hmm right it has a bunch of dependencies
[21:39] <drab> I might be asking too much to, so I'll try VNC and see what I get and if not maybe I'll try to find another host to experiment with
[21:39] <drab> thank you for your help
[21:42] <tomreyn> welcome, you could also ask those questions in #ubuntu-server or #ubuntu, might be more suitable
[22:04] <drab> tomreyn: yeah, I'm in -server, I asked there first and no asnwer and thought some of the devs might have been familiar with the installer frontend question
[22:06] <tomreyn> oh that had scrolled off my screen since
=== _salem is now known as salem_
=== salem_ is now known as _salem