[00:57] <Noskcaj> It appears http://qa.ubuntuwire.com/bugs/rcbugs/ is broken
[00:57] <Noskcaj> wgrant, That's one of your pages isn't it? ^
[01:01] <wgrant> Noskcaj: ajmitch knows that code better, I think, but I'll have a look if he doesn't.
[01:01] <wgrant> It was probably the dist-upgrade last week.
[01:01] <ajmitch> wgrant: I'll poke it & see
[01:02] <wgrant> ajmitch: The webapp was working fine at the time, but maybe the import script is unhappy.
[01:02] <wgrant> I didn't think to check that.
[01:04] <ajmitch> partly because it's so old & outdated
[01:10] <ajmitch> Noskcaj: fixed
[01:11] <wgrant> ajmitch: Thanks. What was the issue?
[01:12] <ajmitch> wgrant: using a python extension that linked to libapt_pkg for version comparisons
[01:13] <ajmitch> not something packaged, so it just needed to be rebuilt
[01:13] <wgrant> Ahh
[01:14] <wgrant> We ran into the same problem with LP a couple of months ago.
[01:14] <ajmitch> it's only about 10 years old
[01:15] <ajmitch> plus there was a script trying to run python2.5 (since 2.4 was just too old)
[04:02] <pitti> Good morning
[04:03] <pitti> hallyn: ah, the init.d script is broken and doesn't actually stop virtd? that needs to be fixed then indeed (or a proper unit added)
[06:41] <dholbach> good morning
[07:26]  * mgedmin wants to ask about https://bugs.launchpad.net/bugs/1384188
[07:33] <seb128> cyphermox, ^ it might be one for you? (updating gfxboot-theme-ubuntu with a new translations export)
[07:33] <seb128> mgedmin, ^
[07:51] <pitti> infinity: can you please remind me and mbiebl_: why do we need *both* the sysvinit (update-rc.d) and the systemd trigger update?
[07:56] <infinity> pitti: Different corner cases.  Either one addresses the simple "policy compliant deb that calls update-rc.d but not invoke-rc.d" case, but each addresses different cases that aren't that.
[07:57] <infinity> pitti: sysvinit also covers the "install without a package, but use update-rc.d" case, and the trigger also covers the "install from a deb that doesn't use update-rc.d" case.
[07:57] <infinity> pitti: Neither one addresses every possible corner case (only fixing systemd itself could do that), but both together cover enough that it's probably "good enough for now".
[07:57] <pitti> infinity: ah, ok; the first case sounded a bit strange to me, but sure
[07:58] <pitti> infinity: but as the latter would be an RC bug in that particular package, I'm not sure how happy the Debian release team would be about such a change two weeks before the release; or did you already happen to talk to them?
[07:59] <infinity> pitti: I'll talk to them.  The fix is (I think) obviously non-invasive and not regression-inducing.  A tiny performance impact, but nothing worth fretting about (and a no-op on upgrades from wheezy, since systemd isn't running yet).
[08:00] <pitti> ack; I'll do the commit/upload then
[08:01] <infinity> pitti: Actually, I'm not sure the latter WOULD be a policy violation.
[08:01] <infinity> pitti: Policy says "However, it must not be assumed by maintainer scripts that this method is being used, and any automated manipulation of the various runlevel behaviors by maintainer scripts must be performed using update-rc.d as described below and not by manually installing or removing symlinks."
[08:02] <infinity> pitti: One could infer from that that if you wanted to install an init script that *doesn't* have rc.d symlinks and is only started/stopped by hand, you don't need to call upadte-rc.d
[08:02] <infinity> pitti: And systemd should still be aware of those scripts, so you can start them properly.
[08:03] <infinity> pitti: Later, there's a "should register with update-rc.d", but not a must.
[08:04] <infinity> pitti: So, yeah, I'd say it's not RC to ship an init script with no runlevel, just weird.
[08:04] <infinity> pitti: But having it fail to work would be RC, so...
[08:04] <mbiebl_> morning pitti, infinity
[08:04] <pitti> hey mbiebl_
[08:04] <mbiebl_> just checked all the packages shipping init scripts in the Debian archive
[08:05] <mbiebl_> i didn't find one which one installs without update-rc.d
[08:05] <infinity> mbiebl_: To be clear, I didn't think the trigger would be necessary for packages in the archive.
[08:05] <infinity> I just think it's still the right thing to do.
[08:05]  * infinity shrugs.
[08:05] <mbiebl_> infinity: hm, k
[08:05] <infinity> (Well, it would have been necessary without the update-rc.d fix, but yeah...)
[08:05] <mbiebl_> right
[08:06] <mbiebl_> my impression from our discussion was, that we needed one or the other but not necessariliy both
[08:06] <mbiebl_> (btw, thanks for the sysv upload)
[08:06] <pitti> mbiebl_: so, I don't mind committing this to master if the RT agrees; it just feels way below RC to me
[08:09] <infinity> pitti: I think it's right from a point of view of "polish", which isn't always "RC" in the "completely broken" sense, but it still seems right.
[08:09] <infinity> pitti: But I can get a release ack before upload, if that makes you feel better.
[08:11] <mbiebl_> pitti: something else I wanted to discuss with you (and possibly didrocks) is the default-display-manager behaviour
[08:11] <mbiebl_> It just happened to me the other day, that I wanted to test a boot without graphical login
[08:11] <mbiebl_> so I ran systemctl disable gdm.service
[08:12] <mbiebl_> which did remove the display-manager.service symlink
[08:12] <mbiebl_> upon reboot, gdm was running though
[08:12] <mbiebl_> it took me a while to remember that the generator had created a start symlinks because of /etc/X11/default-display-manager
[08:13] <mbiebl_> and I don't think it should do that
[08:13] <mbiebl_> because /e/X/d shouldn't decide about the enabled/disabled state
[08:14] <mbiebl_> only about which one is the configured one if multiple are installed
[08:15] <didrocks> there are a lot of dms not transitionned in debian to use a systemd unit
[08:15] <didrocks> that would mean, there is no way to ensure not 2dms (a systemd ones and an init-only one) would not be started
[08:16] <didrocks> hence the whole work and discussion to have /etc/X11/default-display-manager as the source of truth
[08:17] <darkxst> didrocks, except that is just a bunch of packaging hacks currently, no?
[08:18] <mbiebl_> didrocks: it's ok to make /e/X/d decide which one is the configured default
[08:18] <didrocks> darkxst: the d-d-m setting default? It's not, it's a generator
[08:18] <pitti> well yes, obviously it'd be better to fix all the DMs in sid/vivid, but we aren't there yet (and freeze, etc.)
[08:18] <mbiebl_> but the generator should not automatically re-enable services which have been disabled by the admin
[08:18] <didrocks> mbiebl_: it's not if it's masked
[08:18] <didrocks> which was your latest request, that is implemented IIRC
[08:19] <darkxst> didrocks, isnt it generated by debconf?
[08:20] <pitti> the link is
[08:20] <didrocks> darkxst: it's a systemd generator, see above ^ we are not talking about the postinst thingy
[08:20] <pitti> the systemd generator turns that into unit config
[08:20] <mbiebl_> didrocks: I did remember that we discussed that a while ago and i think I mentioned the same issue back then
[08:21] <pitti> mbiebl_: still better IMHO than attempting to start two DMs
[08:21] <pitti> let's face it -- systemd can only do so much while we still have broken DM packages
[08:21] <didrocks> mbiebl_: you were ok at the time that masking would be sufficient
[08:22] <mbiebl_> pitti: two DMs are only started if you have a combination of native .service file and sysv init script
[08:22] <mbiebl_> only sysv init scripts -> all existing ones have the check for /e/X/d-d-m
[08:22] <didrocks> not nodm
[08:22] <mbiebl_> only systemd units -> only one can provide the symlink
[08:23] <mbiebl_> didrocks: nodm is broken, so I don't really care
[08:23] <pitti> mbiebl_: precisely that was the case, no? e. g. gdm + nodm
[08:23] <didrocks> well, that was one of the inputs to get it fixed though
[08:23] <didrocks> we got bug reports about it
[08:23] <didrocks> (doesn't impact ubuntu as we don't have nodm)
[08:24] <mbiebl_> if nodm doesn't check /e/X/ddm it's also broken under sysv?
[08:25] <darkxst> oh right, I see
[08:26] <mbiebl_> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748668
[08:26] <mbiebl_> I don't see nodm mentioned there
[08:26] <mbiebl_> it's about mixing non-systemd enabled DMs like slim with e.g. gdm
[08:27] <didrocks> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770219
[08:28] <didrocks> didn't start because another dm was started through systemd IIRC
[08:28] <didrocks> (when doing some vm tests)
[08:28] <didrocks> this is quite months old, don't remember exactly
[08:28] <mbiebl_> doesn't look systemd specific
[08:28] <mbiebl_> as said, the nodm package just looks broken and I don't think we should model around that package
[08:30] <mbiebl_> didrocks: all I would do, if both a sysv DM is installed and a native systemd DM unit
[08:30] <mbiebl_> and the display-manager.service symlink exists but doesn't match /e/X/ddm
[08:31] <mbiebl_> is to runtime mask that service
[08:31] <mbiebl_> easy and simple
[08:31] <didrocks> I'll let you and pitti sorting it out, TBH, I'm a little bit tired about the bikeshedding around it
[08:31] <didrocks> there was a need, we addressed it, was almost RC for some
[08:31] <didrocks> if you want to drop it, ok
[08:40] <pitti> tjaalton: I think I might have found a likely candidate for your "bridge does not come up" problem, I followed up to bug 1430675 (one-second check)
[09:28] <pitti> cjwatson: hm, did the RTM upload target/machinery change recently?
[09:29] <pitti> cjwatson: on ubuntu-phone@ it was mentioned that the langpacks are out of date, and indeed https://launchpad.net/ubuntu-rtm/+source/language-pack-touch-es is from March 24
[09:29] <pitti> cjwatson: but my cron build and upload logs show success (last log from yesterday), and the continued succession in https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs proves this too
[09:30] <pitti> nothing in https://launchpad.net/ubuntu-rtm/14.09/+queue?queue_state=1 either
[09:30] <pitti> so it seems they are just silently getting rejected now?
[09:32] <tjaalton> pitti: oh, nice catch! sounds like it'll get fixed for me too
[09:32] <tjaalton> I don't have the rcS.d symlink
[09:32] <pitti> tjaalton: ah, you also don't have that link?
[09:32] <pitti> tjaalton: great, thanks for confirming! this seems to be a rather widespread plague
[09:32] <pitti> and it looks like it's already rather old, just got hidden by the networking upstart job
[09:33] <tjaalton> yeah
[09:33] <tjaalton> this install is 2,5y old
[09:35] <cjwatson> pitti: Not as far as I know.
[09:36] <cjwatson> Let's see what our logs say.
[09:37] <pitti> cjwatson: hm, I recently had to renew the gpg key validity for language-packs@ubuntu.com, I wonder if that's related
[09:37] <cjwatson> pitti: 2015-04-06 05:23:32 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150406-052225-005790/ubuntu-rtm/language-pack-touch-ast_14.10+rtm14.09+20150405_source.changes': GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150406-052225-005790/ubuntu-rtm/language-pack-touch-ast_14.10+rtm14.09+20150405_source.changes failed: Verification failed 3 times: ["(7, 153, u'Key ...
[09:37] <cjwatson> ... expired')", "(7, 153, u'Key expired')", "(7, 153, u'Key expired')"]
[09:37] <cjwatson> pitti: Indeed.  How recently did you do that?
[09:37] <pitti> cjwatson: on March 30 according to the file timestamps
[09:38] <pitti> I updated it on macquarie, I guess I also need to update it on Launchpad somehow
[09:38] <AntiSol> hello devs! I'm having a strange problem with patch and was hoping somebody could help: I'm trying to apply the patch from http://permalink.gmane.org/gmane.comp.file-systems.ext4/18338. I did apt-get source e2fsprogs and saved the patch from that page. when I do 'patch -p1 < patchfile.patch' it tells me that it's patching the files but it doesn't make any changes to the files. I also tried patch --verbose: http://paste.ubuntu.com/10771372/
[09:38] <cjwatson> pitti: Did you push it to keyserver.ubuntu.com?
[09:38] <pitti> ah! no
[09:38] <pitti> done now
[09:39] <cjwatson> pitti: Thanks, that should do the trick
[09:39] <pitti> cjwatson: so, sorry for the noise, thanks for pointing out
[09:39] <AntiSol> any ideas? I have checked that I have permissions, and patch gives a 0 return code. I have NFI what's going on
[09:47] <pitti> cjwatson: http://keyserver.ubuntu.com:11371/pks/lookup?op=vindex&search=0x5E7C4A8E07EABA1B is updated, but I figure LP needs some time (cron?) to update its internal keys; I'll check tomorrow's cronned uploads then
[09:47] <pitti> (my immediate re-uploads didn't work yet)
[09:55] <cjwatson> pitti: There may be a cache between it and the keyserver, I forget.
[09:55] <pitti> cjwatson: don't worry
[11:33] <infinity> pitti: I got a "that seems sane" from adsb on both the sysvinit and systemd fixes, with the caveat that I ask KiBi, since it'll be a new udeb.
[11:33] <infinity> mbiebl_: ^
[11:33] <pitti> infinity: cheers
[11:33] <infinity> mbiebl_: Did you decide you needed a systemd upload for other reasons (the ddm thing) too?
[11:34] <pitti> infinity: it won't affect d-i/the udeb anyway, so that should be fine
[11:34] <pitti> infinity: yes, I've backported a few other nice and safe fixes too
[11:34] <infinity> pitti: Yeah, won't affect it except to trigger a respin if he's keeping d-i in sync with the archive.
[11:34] <infinity> pitti: Okay, cool, if the upload is happening anyway, please backport the trigger, then.
[11:34] <infinity> pitti: And we'll beg forgiveness from KiBi for the udeb churn. :)
[11:35] <pitti> infinity: already committed to git
[11:35] <infinity> pitti: Ta.  When the upload hits, I can submit the unblock bug for both, if you like.
[11:36] <pitti> infinity: I'll send the systemd unblock, I can explain the other changes
[11:36] <pitti> infinity: and for that trigger part refer to your conversation with adsb
[11:49] <infinity> pitti: Alright, sysvinit unblock filed, I'll leave the systemd stuff in your capable hands.
[11:50] <infinity> pitti: PS, let's never deal with two distros in freeze at the same time again, it's irksome.
[12:03] <pitti> infinity: heh, tell me :)
[12:03] <infinity> jodh: golang-juju-loggo?  Why the trailing "go"?  No other go packages seem to do that.
[12:03] <jodh> infinity: that's it's name - https://godoc.org/github.com/juju/loggo
[12:04] <infinity> jodh: I suppose I'd also question why we need Yet Another Logger (there seem to be a couple already), but whatever.  Tis the curse of a new language that everyone needs to NIH five times.
[12:10] <infinity> jodh: Your build-dep is on debhelper 9, but debian/compat is 7.  Intentional mismatch?
[12:13] <rbasak> juju-loggo? What's this for, OOI? Juju itself bundles the dep.
[12:14] <infinity> rbasak: Given the uploader, I'm going to assume it's being used for something snaptastic.
[12:18] <rbasak> I wonder if there's anything we can do to avoid duplication. That might mean a huge amount of pain though :-/
[12:18] <jodh> infinity: that build-dep will be an oversight :)
[12:22] <infinity> rbasak: Stop using a language/ecosystem that promotes bundling and static linking as the norm? :P
[12:22] <rbasak> :-/
[12:56] <Mate> hi. how could i get debug symbols for upstart=1.5-0ubuntu7.2? it's missing from precise-updates on ddebs.ubuntu.com (but arm* is there)
[13:05] <infinity> Mate: The symbols do indeed seem to be missing, there's no way to get them back.  But you could try -0ubuntu7.3 from precise-proposed, which does have symbols on all arches.
[13:06] <Mate> I have a core file to investigate
[13:27] <Odd_Bloke> dannf: Would you expect a "error: no suitable video mode found." from GRUB when booting the arm64 UEFI image with -nographic?
[13:27] <infinity> Odd_Bloke: Yeah.
[13:28] <Odd_Bloke> Great!
[13:28] <infinity> Odd_Bloke: We get the same misfeature on PPC, it's clearly a bug in both cases, but a mostly harmless one.
[13:30] <Odd_Bloke> That just leaves me with "error: file `/boot/grub/fonts/unicode.pf2' not found."; /boot/grub/unicode.pf2 exists, and I can't see any reason for grub to look in that particular directory.
[14:03] <flexiondotorg> infinity, I saw mention of PPC.
[14:04] <flexiondotorg> infinity, There is a serious regression in X for PowerPC :(
[14:05] <flexiondotorg> infinity, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/1434036
[14:06] <flexiondotorg> https://bugs.freedesktop.org/show_bug.cgi?id=89862
[14:08] <hallyn> pitti: well no, the /etc/init.d/libvirt-bin script *looks* correct.  and sometimes it kills it fo rme.  but often it does not.  I haven't yet figured out why.
[14:29] <tjaalton> flexiondotorg: does startx work?
[14:30] <flexiondotorg> tjaalton, Good question. I don't know. I'll ask them to test that. My PowerPC test machine is at home so I can't test right now.
[14:33] <Odd_Bloke> infinity: And do we expect to get a pause before boot continues, when we see that error?
[15:15] <Riddell> tseliot: so d_ed pointed out a couple of issues with your displaystop patch :(  you also say it needs to set /etc/X11/default-display-manager ? what's that used for and do you know what sets it in the lightdm package? all these postinsts and config files are hard to follow
[15:33] <dannf> Odd_Bloke: we know the cloud images have a mis-installed grub, that is being worked on
[15:33] <dannf> Odd_Bloke: but yeah, for now you have to press a key to continue
[15:35] <Odd_Bloke> dannf: I am, in fact, working on it. :)
[15:35] <dannf> Odd_Bloke: oh, didn't "real name" you - cool, thanks! let me know what i can do to help
[15:35] <Odd_Bloke> dannf: I've got to the point where we see an "error: no suitable video mode found." message, a (~10 second) pause and then boot continues.
[15:36] <dannf> Odd_Bloke: yeah - grub has a boot delay there, but you can hit esc to see the grub menu - make-it-boot-now
[15:36] <Odd_Bloke> dannf: So does what I've got sound like roughly what we'd expect?
[15:37] <dannf> Odd_Bloke: sounds like it
[15:37] <Odd_Bloke> OK, cool.
[15:37] <dannf> i think the only remaining open issue was to make the boot non-interactive by fixing the grub install
[15:38] <dannf> well - issue *for you* - i'm still working on fixing up various other bits for utopic/vivid, but that's all kernel
[15:38] <Odd_Bloke> I'll see if I can iron out some of the hackiness that I've got in place, but I expect vivid dailies will be fixed by the end of the week.
[15:38] <Odd_Bloke> (And probably other releases, but I'm only testing vivid ATM)
[15:38] <dannf> awesome!
[15:38] <dannf> yeah, utopic/trusty will need hand holding to boot even after the images are fixed. utopic should be fine after the next SRU cycle
[15:40] <Odd_Bloke> dannf: The "fs0:; cd efi; BOOTaa64.EFI" dance is still fine for "non-interactive" boot?
[15:40] <Odd_Bloke> (That is presumably the result of the BIOS that we're using, rather than the images?)
[15:40] <dannf> Odd_Bloke: oh, no - that needs to be repaired
[15:41] <dannf> Odd_Bloke: think about it in an openstack environment, where you can't talk to the vm until ssh is up
[15:42] <Odd_Bloke> dannf: So when the "The default boot selection" countdown hits 0, we should be straight in to grub?
[15:43] <Odd_Bloke> dannf: (Yeah, makes sense, I had just assumed that there was EFI/BIOS magic that did something something *waves hands*)
[15:43] <dannf> Odd_Bloke: yeah. it could be a problem w/ the bios image as well - but i thought they had the right entries
[15:43] <Odd_Bloke> dannf: http://paste.ubuntu.com/10774114/ is what I see.
[15:44] <dannf> Odd_Bloke: and then [1] fails i take it?
[15:44] <Odd_Bloke> dannf: Yep.
[15:44] <dannf> Odd_Bloke: http://www.linaro.org/app/resources/WhitePaper/VMSystemSpecificationForARM-v1.0.pdf
[15:44] <dannf> ^ that's what we're aiming for
[15:45] <dannf> so the "firmware" should be defaulting to boot "\efi\boot\bootaa64.efi"
[15:45] <dannf> Odd_Bloke: if manually running that works, and the firmware just isn't calling it correctly, then probably something to look at on our end
[15:46] <dannf> Odd_Bloke: from your "dance" commandline, it looks like it might be under \efi, not under \efi\boot?
[15:46] <Odd_Bloke> Ah, looks like we're creating \efi\bootaa64.efi
[15:46] <Odd_Bloke> :)
[15:46] <dannf> jinx :)
[15:46] <Odd_Bloke> /kick Odd_Bloke JINX
[15:47] <Odd_Bloke> dannf: OK, I'll get that in the right place and see if boot becomes non-interactive
[15:47] <dannf> cool - hope that's it :)
[16:06] <flexiondotorg> pitti, Anything I can do to help with https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/953875
[16:06] <flexiondotorg> pitti, See my comments 61 and 62
[16:29] <Odd_Bloke> dannf: Hm, if I enter the Boot Manager and Add Boot Device Entry, then I can boot using that option in the boot menu.
[16:38] <dannf> Odd_Bloke: you  mean w/o moving it under 'boot\'?
[16:39] <flexiondotorg> Will anyone be piloting today?
[16:39] <dannf> Odd_Bloke: yeah - i'd expect that to work. but that wouldn't let us autoboot on someone else's complaint EFI firmware blob
[16:40] <Odd_Bloke> dannf: No, having moved it under boot; it still didn't work having moved it.
[16:41] <Odd_Bloke> dannf: The first option I have in the boot menu is "Linux (EFI stub) on virtio31:hd0:part0"; is that trying to load the kernel directly rather than go through grub?
[16:42] <dannf> Odd_Bloke: ah, maybe
[16:43] <dannf> Odd_Bloke: in that case, i think it's a bad fw blob. which blob are you using? i don't recall which one i suggested
[16:44] <Odd_Bloke> dannf: http://people.canonical.com/~vorlon/edk2-aarch64/QEMU_EFI.fd.native
[16:45] <dannf> oh, ok. i'll try to come up with a better one to test with.
[16:45] <dannf> Odd_Bloke: do you have a cloudimage build i can use to do that, or should i just wait for a daily?
[16:46] <Odd_Bloke> dannf: I'll push up something I've built locally for you, give me a minute.
[16:47] <dannf> Odd_Bloke: ack
[17:02] <tseliot> Riddell: grepping through the lightdm sources, I've found debian/lightdm.config which contains the following (stolen from xdm): http://pastebin.ubuntu.com/10774657/
[17:03] <tseliot> Riddell: also, what I was saying is that my patch is useless since things won't work on log out anyway, as sddm won't restart X on logout
[17:20] <Riddell> tseliot: so it's based on X restarting which sddm doesn't do?
[17:22] <tseliot> Riddell: yep. So having a working login is the only thing we can get now (which is still better than a black screen)
[17:23] <tseliot> Riddell: and for that we simply need: 1) the default display manager file, 2) a slight change in gpu-manager (which I only have to upload), and 3) the DisplayCommand entry in sddm.conf
[17:25] <Riddell> tseliot: 3) is done, I guess I need to work out what this .config file is doing
[17:26] <tseliot> Riddell: it's just debconf black magic. I think a simple copy & paste should work
[17:30] <tseliot> Riddell: so, the .config file, and the relevant parts of .postinst and .prerm. You really can't miss them, as they have $DEFAULT_DISPLAY_MANAGER_FILE in them
[17:30] <tseliot> copy & paste those parts and it should work
[17:32] <mdeslaur> Riddell: can you test the fix for 1400730 please? Else, it will get superseded by a security update soon.
[17:32] <Riddell> bug 1400730
[17:33] <Riddell> ah yes that's been on my todo list for months
[17:33] <mdeslaur> Riddell: thanks
[17:38] <Riddell> tseliot: nothing there seems to create DEFAULT_DISPLAY_MANAGER_FILE it only does something if it exists
[17:44] <tseliot> Riddell: that's what the .config script does. I also forgot to mention the .templates file. This document explains how it works: http://www.fifi.org/doc/debconf-doc/tutorial.html#AEN113
[17:46] <Riddell> tseliot: I think it's lightdm.postinst which makes the file
[17:47] <tseliot> Riddell: if it doesn't exist, yes: echo "$DAEMON_NAME" > "$DEFAULT_DISPLAY_MANAGER_FILE"
[17:47] <Riddell> right
[17:47] <tseliot> you need debconf only to ask the user if more choices are available
[20:43] <octoquad> Hi, for Remmina upstream patches, should this be provided as a debdiff or bzr branch for affected releases?
[21:56] <freyes> octoquad, it's up to the maintainer of the package, but they usually prefer a debdiff
[22:11] <infinity> dannf / Odd_Bloke: You shouldn't actually have to press a key to continue (despite the prompt claiming otherwise), it times out in a few seconds.
[22:12] <infinity> dannf / Odd_Bloke: If that's not true, it's not the bug I'm thinking of, but I'm pretty sure it it.
[22:12] <dannf> infinity: i think there are 2 bugs - one w/ the video error, the other due to a misinstalled grub spitting syntax errors
[22:13] <infinity> dannf: Ahh, the syntax error thing is different indeed.  The video mode and "press any key to continue" bits, though, we see on PPC, and they're harmless, just annoying.