[00:02] <kwmonroe> c0s: i need to EOW, but i'm interested in this auto-juju smoke train you're thinking about.  let's explore that monday.
[00:03] <kwmonroe> A-Kaser: if you have any more questions about deploying/charming with juju2, feel free to drop them here or shoot me an email.
[00:03] <c0s> sure, have a good weekend, I will put some comments on the doc for us to pick up next week
[00:03] <kwmonroe> take care folks!
[00:03] <c0s> cheers kwmonroe!
[00:05] <A-Kaser> kwmonroe: yes I'm trying some commands :)
[00:06] <A-Kaser> I would to force ec2 instance type, so I'm using --constraints instance-type=m3.large
[00:06] <A-Kaser> but I have make an error and type mx.larte
[00:06] <A-Kaser> /larte/large
[00:07] <A-Kaser> juju status give me error message but now I'm trying to destroy the service without success
[01:06] <stormmore> is any able to help me with a multi-vlan routing type question? setting a maas, juju, openstack cluster, got it to deploy juju-gui and it looks like it is getting the write IP but the routing on the deployed machine seems off since it is on a different vlan than the management one.
[01:06] <stormmore> I know I am missing something super simple in my configuration, just not sure where and what is the best way to setup the correct routing
[23:36]  * magicaltrout wonders if the charm store build tool takes saturday and sunday off like everyone else.....
[23:42] <rick_h_> magicaltrout: no, shouldn't
[23:43] <rick_h_> magicaltrout: but check out the latest office hiurs and new charm command to work around any issues there


[14:35] <scott-work> can anyone give guidance to helping me get some default and sane jack settings placed in the user's /home directory during installation?
[14:36] <scott-work> specifically, i only need the mechanics of installing the file during installation; the sane defaults have already been defined
[15:31] <mr_pouit> scott-work: drop a dotfile in /etc/skel ? (it would probably be better if the app had supported the dxg base dir spec though)
[15:31] <mr_pouit> micahg: mmh, I think your images might be broken by lightdm ;>
[15:32] <mr_pouit> s/your/our/, ha
[15:32] <scott-work> mr_pouit: is it really as easy as that?
[15:32] <scott-work> mr_pouit: i thought someone had told me that moderating a user's home directory was somewhat verboten
[15:32] <scott-work> and i figured there were more hoops to jump through
[15:33] <scott-work> perhaps this was post installation
[15:33] <scott-work> i.e. a package that had a reasonable chance of installation after the OS install that would moderate the user's home directory
[15:33] <mr_pouit> micahg: Bug #918401 for lubuntu, maybe we have that too (precise-desktop-amd64.manifest shows too many unity-* things here)
[15:34] <mr_pouit> scott-work: it's just used at user creation time afaik
[15:34] <scott-work> mr_pouit: i don't know if this will help but astraljava found out that mousetweeks was bringing in unity stuff as well
[15:35] <scott-work> just look at the note in our seeds; apparently mousetweaks brings in gnome-session which then pulls in a bunch of unity packages
[15:35] <scott-work> s/just look/just looked
[15:36] <scott-work> not sure if that is helpful
[15:36] <scott-work> mr_pouit: but thank you for the information about /etc/skel :)
[15:38] <mr_pouit> scott-work: huhu, we don't ship mousetweaks by default :P
[15:39] <mr_pouit> micahg: erf, nevermind, I was looking at the ubuntu image >.>  Ours seem fine ;-)
[15:39] <scott-work> oh, i thought that was brought in from the xubuntu seeds, sorry
[16:42] <knome> madnick, going to send the mail to the release ML? :)
[16:42] <knome> bbl->
[16:49] <madnick> knome: we already had the meeting
[20:37] <knome> madnick, okay


[00:31] <RAOF> Aww, yeah. Looks like removing a couple of extensions has broken my desktop's GNOME Shell!
[00:32] <RAOF> Now, rather than taking 10s to unlock, it just immediately hits the “oh, no!” screen.
[00:38] <RAOF> Hmmmm. Because apparently removing an extension from the extensions.gnome.org interface does *not* tell GNOME Shell not to try to load it next time?!
[00:43] <RAOF> Soooo.
[00:44] <RAOF> How would I disable extensions?
[00:46] <RAOF> `dconf dump /org/gnome/shell/` shows `disable_user_extensions=true` and does not have an enabled-extensions key.
[00:58] <jamesh> gnome-shell-extension-prefs?
[01:00] <RAOF> Do I need to run that from a GNOME session?
[01:00] <jamesh> not sure
[01:06] <RAOF> Well, `gnome-extensions list` returns no output, so I *think* it thinks there are no enabled extensions…
[01:09] <RAOF> After a reboot it's *still* trying to open the non-existent extension.
[01:10] <RAOF> Oh. But `gnome-extensions` is failing with exit value 2, but no output.
[01:23] <jamesh> maybe there is some detritus in ~/.local/share/gnome-shell ?
[01:32] <kenvandine> RAOF: that isn't desirable :)
[01:32] <kenvandine> robert_ancell: meeting?
[01:32] <callmepk> Good morning
[01:33] <robert_ancell> callmepk, hello!
[01:34] <callmepk> Hi robert_ancell !
[01:37] <RAOF> Ooooh!
[01:37] <RAOF> There *was* some detritus, in `~/.local/share/gnome-shell/extension-updates`!
[01:38] <RAOF> It looks like if there's something in there, GNOME Shell will unconditionally try to load the extension from `~/.local/share/gnome-shell/extensions/`. Which didn't exist.
[01:38] <RAOF> And didn't respect any of the dconf settings.
[01:38] <RAOF> I wonder if I can reproduce that…
[01:53] <duflu> Oh hi callmepk, jamesh, RAOF, robert_ancell, kenvandine, world
[02:03] <kenvandine> good morning duflu
[02:11] <callmepk> morning duflu
[06:17] <seb128> good morning desktopers!
[06:21] <duflu> Morning seb128
[06:21] <seb128> hey duflu, happy friday! how are you today?
[06:22] <duflu> seb128, going well I think. You?
[06:22] <seb128> I'm good! a bit tired but it's friday so it's ok :)
[06:22] <duflu> Life is so exciting these days I am looking forward to just leaving the house to check the mail
[06:24] <seb128> :-/
[06:25] <seb128> it's frustrating, we had grey sky and rain non stop until 10 days ago
[06:25] <seb128> and now that we are locked down it's sunny and nice every day :/
[06:25] <duflu> I have a lot of flowers in bloom and it's sunny still, so going outside is actually nice
[06:26] <duflu> Just not too far
[06:27] <seb128> that's something :)
[06:34] <didrocks> good morning
[06:36] <ricotz> good morning desktopers :)
[06:36] <ricotz> seb128, hi, regarding indicator-sound https://paste.debian.net/plain/1138187
[06:36] <duflu> Hi didrocks and ricotz
[06:36] <seb128> lut didrocks, comment ça va ?
[06:36] <seb128> ricotz, hey! how are you? thanks for the fix!
[06:38] <didrocks> hey duflu, ricotz
[06:38] <didrocks> salut seb128, ça va, et toi ?
[06:42] <seb128> didrocks, ça va bien :)
[06:44] <ricotz> seb128, I am good, yw
[07:02] <RAOF> duflu: Hopefully the gperftools trace in the GNOME Shell memory bug is helpful.
[07:03] <duflu> Sounds good. If there's an email about that it hasn't arrived yet
[07:03] <RAOF> Shell must do a lot of allocation, because gperftools absolutely murders its performance (like, 10 second pauses everywhere, minute-long login-times, and such)
[07:04] <duflu> Unless you focus only on mmaps (which I recommend)
[07:04] <duflu> HEAP_PROFILE_ONLY_MMAP
[07:24] <jibel> morning all
[07:25] <didrocks> salut jibel !
[07:25] <jibel> Salut didrocks , en forme?
[07:26] <didrocks> ça va, et toi ?
[07:26] <jibel> ça va, longue veillée pour une release qui n'est jamais arrivée
[07:26] <didrocks> ouais, j’ai vu ça :/
[07:27] <jibel> et toujours pas là apparemment
[07:29] <didrocks> nope
[07:38] <oSoMoN> good morning desktoppers
[07:39] <oSoMoN> happy Friday!
[07:43] <didrocks> hey oSoMoN
[07:45] <duflu> Hi jibel and oSoMoN
[07:46] <jibel> Good morning duflu
[07:49] <seb128> lut jibel, oSoMoN
[07:50] <seb128> jibel, they have issue with the image build time still? or is that another IS problem?
[07:50] <Wimpress> Morning desktoppers
[07:50] <seb128> hey Wimpress, how are you?
[07:50] <didrocks> hey Wimpress
[07:50] <didrocks> seb128: the image is just published
[07:51] <didrocks> seems like an issue with the network when doing the massive build tests the week of a beta
[07:51] <seb128> well done d_oko!
[07:51] <Wimpress> Bit tired, but catching up on iso build status, feeling optimistic 🙂
[07:52] <oSoMoN> salut didrocks, jibel, seb128
[07:53] <oSoMoN> hey duflu, Wimpress
[07:57] <duflu> Morning Wimpress
[08:01] <Laney> moin
[08:02] <didrocks> hey Laney
[08:03] <duflu> Hi Laney
[08:05] <seb128> hey Laney, happy friday! how is it going? had another late night waiting for ISOs that didn't come or did you manage to call it a day on time yesterday?
[08:05] <Laney> hey duflu didrocks seb128
[08:05] <Laney> no I was online until 00:15
[08:06] <Laney> when we figured out it wasn't going to finish and decided to delay
[08:06] <seb128> :-(
[08:07] <Laney> yeah was hoping to do some other stuff today
[08:07] <Laney> but I guess not really likely now
[08:07] <Laney> oh well :p
[08:19] <oSoMoN> morning Laney
[08:32] <marcustomlinson> morning all
[08:32] <didrocks> hey marcustomlinson
[08:35] <Laney> hey oSoMoN marcustomlinson
[08:49] <seb128> hey marcustomlinson, how are you?
[08:50] <marcustomlinson> seb128: tired :P but that comes with having a newborn
[08:50] <marcustomlinson> how you today?
[08:50] <seb128> indeed!
[08:51] <seb128> a bit tired as well, for me it comes from school being closed and tried to work done at the same time, proove to be challenging!
[08:52] <seb128> trying*
[08:56] <marcustomlinson> hear, hear
[08:59] <duflu> Morning marcustomlinson
[09:00] <duflu> seb128, good news: nvidia-440 does support full plymouth graphics. Just not at initrd time. And for a new reason different to the ThinkPads
[09:01] <seb128> duflu, ah, nice! what's the reason?
[09:01] <duflu> Wish I knew
[09:02] <duflu> Nvidia keeps the kernel's efifb around and it works perfectly in testing. Just not when we want it
[09:03] <duflu> Also the Nvidia driver does not VT switch reliably, so the lack of shutdown splash is a different issue
[09:04] <seb128> I should get a nvidia machine at some point, would help testing & debugging things
[09:05] <duflu> Seems to be a common sore point in the land of Ubuntu
[09:06] <duflu> That's the main reason I still use desktops, so I can switch cards without switching machines
[09:14] <xnox> du
[09:14] <xnox> duflu: oooh. I have nvidia card.
[09:15] <duflu> xnox, any help is welcome then: https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/103
[09:15] <duflu> Confusing numbers
[09:15] <xnox> duflu: "not at initrd time" how come? Surely we can do that on installer systems. Due to legal reasons, cannot do it on install media.
[09:16] <duflu> xnox: This is an *installed* system
[09:16] <duflu> Not installer related
[09:17] <xnox> Ack!
[09:56] <duflu> xnox, I don't support initrd is missing renderers/frame-buffer.so
[09:56] <duflu> ?
[09:56] <duflu> *suppose*
[09:56] <duflu> I don't suppose
[09:58] <xnox> duflu: we might have magic to force framebuffer off on Nvidia "cause it doesn't work"?!
[09:58] <xnox> In the initrd.
[09:58] <duflu> xnox, it does work after booting. Initrd never even tries it
[09:58] <duflu> It doesn't load the renderer
[09:58] <xnox> Ack. Most likely initramfs-tools bug that like blacklists framebuffer support.
[10:40] <xnox> duflu:  so, bgrt booting on bios
[10:41] <xnox> duflu:  can bgrt realiaze that there is no EFI oem logo? and can we have a stock vendor logo to show on the top? cause boot looks unbalanced with all that black space empty
[10:42] <xnox> i wonder if we can ship lenovo/dell/asus/acer logos for use in bios boot
[10:42] <xnox> horum
[10:43] <duflu> xnox, Oh I just closed that bug because I thought the Ubuntu logo is enough in that case
[10:44] <duflu> And if it bothers people, disabling legacy boot and CSM might give you back your bgrt, like my ThinkPad
[10:44] <duflu> I think black is best in that case though. Otherwise the user gets 3 logos, not just 2
[10:45] <xnox> duflu:  can you point me at the bug again?
[10:45] <duflu> ...
[10:45] <xnox> duflu:  re fsckd => i think you did everything right, and i fixed casper, and now it is pretty https://people.canonical.com/~xnox/casper-win.png
[10:45] <xnox> this is how it looks when booted under bios
[10:46] <duflu> xnox, bug 1837519
[10:46] <duflu> Oh, bigger font size?
[10:46] <Wimpress> I am on nvidia only here. Plymouth appears to working correctly.
[10:46] <duflu> Hmm
[10:46] <Wimpress> Albeit, the wrong resolution.
[10:47] <duflu> Wimpress, nvidia-440 driver?
[10:47] <Wimpress> Can't confirm the remove media prompt. But I will test a full install on another nvidia only system.
[10:47] <duflu> Nevermind I am making progress, but it's getting too late for this week
[10:47] <Wimpress> duflu: Yes 440.
[10:48] <duflu> Wimpress, yeah I know it can work because mine does after boot. Just something weird going on on my desktop
[10:48] <xnox> Wimpress:  "remove media prompt" => you are testing installer right? we are talking about post-install-booted-system plymouth not working on boot.
[10:48] <duflu> Wimpress, I verified that fix a few days ago
[10:48] <xnox> Wimpress:  installer does not use nvidia graphics, because it legally cannot.
[10:48] <duflu> it is fixed in 20200331 onward
[10:48]  * xnox is possibly confused.
[10:48] <Wimpress> Yes, I am also talking about post-install system.
[10:48] <xnox> oh, ok.
[10:48]  * xnox is confused
[10:48] <xnox> nevermind and carry on
[10:49] <Wimpress> But will do a full install test on an nvidia system later.
[10:49] <xnox> duflu:  I somehow feel we need a fallback OEM graphic, like canonical circle logo
[10:49] <xnox> (i.e. just as big as dell logo is)
[10:50] <duflu> xnox, I wouldn't because that's too many visual changes.
[10:50] <duflu> Not just because it's Friday night
[10:52] <xnox> duflu:  i wonder, if we can fix qemu firmware to ship SeaBIOS logo that works in BIOS boot in VM =)
[10:54] <duflu> It might be a problem with the structure of the bgrt, or it might be the BIOS hiding BGRT in non-pure-EFI boot modes
[10:54] <duflu> And good night
[10:54] <xnox> night!
[10:55] <duflu> Either way, we can hack SeaBIOS
[10:55] <xnox> and tianocore logo needs to improve
[10:55] <duflu> Yeah
[10:55] <duflu> Bye
[13:20] <KGB-0> gnome-shell debian/master Simon McVittie * [merge] merge request !37: WIP: 3.36.1 * https://deb.li/PVai
[13:21] <KGB-0> mutter debian/master Simon McVittie * [merge] merge request !58: WIP: 3.36.1 * https://deb.li/3cOHh
[13:27]  * Laney melts into a puddle
[13:27] <Laney> beta finally done
[13:34]  * marcustomlinson hands Laney a beer
[13:44] <Laney> thanks marcustomlinson, much required
[14:03] <hellsworth> good morning desktopers
[14:03] <marcustomlinson> hey hellsworth
[14:03] <oSoMoN> hey hellsworth
[14:03] <kenvandine> good morning hellsworth
[14:03] <hellsworth> hi yall
[14:04] <hellsworth> kenvandine: should i join the code and sysinternal snap meetings toay?
[14:05] <didrocks> hey hellsworth, kenvandine
[14:06] <marcustomlinson> also hey kenvandine
[14:06] <kenvandine> feeling the love :)


[03:05] <zul> heylo
[06:41] <fabbione> BenC: great man!
[06:42] <fabbione> BenC: finally we can have gdb working on sparc :)
[06:42] <BenC> fabbione: cool
[06:42] <fabbione> for threaded apps ;)
[06:45] <mjg59> BenC: We should have an sdhci update after the weekend
[06:45] <mjg59> The sdhci spec got publically released, so now it can be fixed up
[06:46] <fabbione> mjg59: hey dude
[06:46] <fabbione> mjg59: i did reassing the wacom-tools init script bug to you
[06:46] <fabbione> could you be so kind to give it a shot?
[06:48] <mjg59> fabbione: Yeah, I'll take a look soon
[06:48] <fabbione> mjg59: rthanks a lot
[06:50] <BenC> mjg59: ok
[07:40] <BenC> yay, I see pnp devices again
[07:47] <torkel> BenC: are you busy or do you have a couple of minutes to take a log at a bugreport that might be a kernel bug?
[07:49] <torkel> I'm not sure if it is a bug in the openafs kernel module or the kernel and I don't have any PPC64 to test and try on :-(
[08:07] <BenC> torkel: bug #?
[08:07] <torkel> BenC: 37661
[08:07] <torkel> it is in the config.log attachment
[08:11] <BenC> torkel: it's the build's fault
[08:11] <BenC> it's not using the right cflags
[08:12] <torkel> ok
[08:12] <BenC> it really needs to be getting CC and CFLAGS and such from the kernel build to alleviate this problem
[08:12] <BenC> but as a quick patch, ppc64 should be using -m64
[08:13] <BenC> the problem is default cc produces 32-bit code, and obviously for ppc64 you need 64-bit :)
[08:14] <torkel> even om 64-bits machines?
[08:14] <BenC> userspace on ppc64 is still 32-bit so the default is correct
[08:14] <BenC> ppc and ppc64 use the same userspace
[08:14] <torkel> ah
[08:15] <BenC> all of this should be invisible to the openafs build, which is why using the kernel build stuff would be best
[08:19] <torkel> You mean module-assistant should be fixed?
[08:22] <BenC> whatever produced that log needs to be fixed :)
[08:23] <torkel> Looks like it is already filed in debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334392 :-)
[08:23] <torkel> anyway thanks a lot


[07:48] <hardwire> I uh.. was sorta ushered over here from debian-boot ;)
[07:48] <hardwire> http://techbits.bogomip.com/2008/09/how-i-installed-ubuntu-amd64-server-on.html
[07:49] <hardwire> just wrote that.. and sorta maybe just discovered that the hostname and domain is being overridden by the reverse dns lookup for the static IP during the automatic install
[07:49] <hardwire> anyways to .. stop that?
[07:49] <hardwire> cause it's bad m'kay?
[09:11] <cjwatson> hardwire: unfortunately, this is a long-standing bug, namely bug 218965 (see the linked Debian bug there for more detail). The best I can offer as a workaround is to sed the hostname and domain you want into place in the relevant files in /target from a preseed/late_command hook.
[15:29] <cr3> is there a way to hook into the alternate installer to run some command when an error occurs?
[15:48] <superm1> well CIA decided to not submit a few of my last commits again.  i fixed an issue that I just saw with the build process introduced recently preventing the GTK frontend from building
[15:48] <superm1> i'm not sure if the last ubiquity upload (the .11) is affected
[15:50] <evand> cia-submit?
[15:50] <evand> but thanks
[15:50] <superm1> ah no it wasn't affected because it was FTBFS :) http://launchpadlibrarian.net/17247922/buildlog_ubuntu-intrepid-i386.ubiquity_1.9.11_FAILEDTOBUILD.txt.gz
[15:50] <CIA-44> ubiquity: superm1 * r2793 ubiquity/ (5 files in 4 dirs): update mythbuntu frontend video driver installation to use mythbuntu-common and abstract the versioning
[15:50] <evand> ah, hooray
[15:50] <superm1> there should be 4 others or so though
[15:50] <superm1> hum
[15:50] <superm1> the others were more relevant
[15:50] <CIA-44> ubiquity: superm1 * r2793 ubiquity/ (5 files in 4 dirs): update mythbuntu frontend video driver installation to use mythbuntu-common and abstract the versioning
[15:50] <superm1> oh well
[15:52] <superm1> there looks to possibly be another issue going on with partman-base from something that cjwatson committed to the tree a long time back but that was never released
[15:53] <superm1> well when luke rev'd partman-base, that commit from way back when got added
[15:59] <evand> hrm
[16:01] <evand> it appears to have built fine.  What's the issue, exactly?  Is the install failing?
[16:02] <superm1> yeah
[16:02] <evand> alternate or desktop?
[16:02] <superm1> desktop, but only using builds that are 1.9.11 or later
[16:02] <superm1> since they pull that in
[16:02] <superm1> it turns out that preseed_command isn't found
[16:03] <superm1> which i'm not sure where it was supposed to be provided from anyhow?  I quick grep didn't indicate where it's supposed to come from
[16:04] <evand> preseed
[16:05]  * evand digs
[16:05] <superm1> well the variable partman/early_command should come from preseed, but the executable/shell script what not called preseed_command doesn't seem to be sitting around in the usual places
[16:07] <cjwatson> hm, really?
[16:07] <cjwatson> oh, of course, it isn't in ubiquity, bleh
[16:07] <cjwatson> evand: might need to suck that into ubiquity's pile of imported source packages. We shouldn't need the rest of it but preseed_command looks like it should be usable standalone
[16:09] <evand> ok, will do
[17:38] <hardwire> anybody else noticed that hardy current d-i installers seem to ignore domain and hostname settings in /proc/cmdline as well as the preseed file if there is RDNS available?
[17:38] <hardwire> using static IP?
[17:39] <hardwire> here's my preseed:  http://techbits.bogomip.com/2008/09/how-i-installed-ubuntu-amd64-server-on.html
[17:39] <hardwire> in actuality, I'm not using an internal IP.. those are example settings.
[17:39] <CIA-44> ubiquity: evand * r2794 ubiquity/.bzrignore: Add mythbuntu build directory to bzrignore
[17:43] <cjwatson> hardwire: I answered you this morning
[17:43] <cjwatson> 09:11 <cjwatson> hardwire: unfortunately, this is a long-standing bug, namely bug 218965 (see the linked Debian bug there for more detail). The best I can offer as a workaround is to sed the hostname and
[17:43] <cjwatson>                  domain you want into place in the relevant files in /target from a preseed/late_command hook.
[17:43] <hardwire> cjwatson: apologies.. I had to log in to my irc proxy and scroll through the logs this morning..
[17:44] <hardwire> I didn't immediately see anything hardwire oriented :)
[17:44] <hardwire> but thanks.
[17:44] <cjwatson> no problem, sorry I can't offer anything better
[17:45] <hardwire> long standing means it's still in intrepid eh?
[17:45] <cjwatson> yes
[17:45] <hardwire> doheth
[17:46] <hardwire> hmm.. cjwatson if I could theorize for a moment.. couldn't I just "echo <IP_ADDRESS> servername.domain servername >> /etc/hosts" on the installers root?
[17:47] <hardwire> the dns resolver would prefer that anyways.
[17:47] <hardwire> not much help for DHCP folk..
[17:47] <hardwire> but hey..
[17:47] <cjwatson> if you did it before it copied those files into /target, sure
[17:47] <hardwire> I'm gonna give it a go.
[17:47] <cjwatson> and *after* it has generated them itself, otherwise it'll just blat what you did
[17:47] <cjwatson> so you can't do it in preseed/early_command
[17:48] <hardwire> oh snap
[17:48] <cjwatson> I'm surprised the DNS resolver cares what the local hostname is
[17:48] <cjwatson> oh, I suppose if you're giving a non-FQ name as the mirror or something
[17:48] <cjwatson> you could fully-qualify the mirror as a workaround
[17:49] <hardwire> I'm surprised that the installer cares at all.
[17:49] <cjwatson> it shouldn't, unless you're using a non-FQ mirror
[17:49] <cjwatson> even then I'm surprised that it cares
[17:49] <hardwire> so the hosname and domain name of the installed workstation for some reason depends on if the mirror is fully qualified or not?
[17:49] <hardwire> that seems like chaos.
[17:49] <cjwatson> no, obviously not
[17:50] <cjwatson> I meant that if the mirror wasn't fully-qualified then it might use the local domain as a base for resolution
[17:50] <hardwire> ahha
[17:50] <hardwire> "search" in /etc/resolv.conf
[17:50] <cjwatson> but looking at your blog I see you're saying it's doing a reverse DNS lookup on the local host name, so that's something different, ignore me
[17:50] <hardwire> you're allowed
[17:50] <cjwatson> does that only happen when you try to ssh in?
[17:51] <hardwire> ssh into the installer?
[17:51] <cjwatson> that's one step that I would expect to do an RDNS check
[17:51] <cjwatson> oh, you're not doing that either
[17:51] <hardwire> yar
[17:51] <cjwatson> therefore I'm confused. Are you sure the RDNS check is happening during installation, not later?
[17:51] <hardwire> the installer is simply... guessing.. what my hostname should be.
[17:51] <cjwatson> sure, I know
[17:51] <hardwire> it's all happening during the install
[17:51] <cjwatson> but I'm asking whether just fixing it up at the end of the installation would be sufficient
[17:52] <hardwire> I've tested it in subnets that have no RDNS.. and things work fine
[17:52] <cjwatson> no, stop, listen :)
[17:52] <cjwatson> if it doesn't make the installer go significantly more slowly, it doesn't matter whether you arrange for the installer to get it right to start with, or if you just have a preseed/late_command hook fix it up at the end
[17:52] <cjwatson> therefore, it matters whether the RDNS check that's causing the delay is happening during installation, or after first boot
[17:53] <cjwatson> in your blog, you're talking about waiting for the server to come up by polling port 22, which wouldn't distinguish between those two cases
[17:53] <cjwatson> that's why I'm asking
[17:53] <hardwire> ah.
[17:53] <hardwire> the end step was an attempt at humor
[17:54] <hardwire> booting a remote server with no i/o access to it, and waiting for it to install ubuntu then completely reboot itself with openssh installed.
[17:54] <hardwire> the tick tock of the clock while you panic wondering if your evil plan worked or not
[17:54] <hardwire> that's all
[17:54] <cjwatson> not unreasonable, people do do that :)
[17:54] <cjwatson> but if you aren't doing that, do you have more information about which stage the delay happens at?
[17:54] <hardwire> my server is srv001.sb.brutetech.com and for some reason serverbeach set my RDNS to brutetech.com
[17:55] <hardwire> when the machine comes back up after a fresh install it has the hostname "brutetech" and "search com" is in /etc/resolv.conf
[17:55] <hardwire> you know this of course
[17:55] <hardwire> There is no delay when dealing with RDNS
[17:55] <hardwire> it's just odd that RDNS is being used above my own preferences, which you've already told me I need a fixup for.
[17:57] <cjwatson> oh, right, I thought you were talking about the installer taking 30 minutes longer *due* to this bug or something like that. (That sort of thing does happen so I assumed that's what you were asking about.)
[17:57] <hardwire> so are we still thinking the same bug on this?
[17:58] <cjwatson> yes, same bug
[18:00] <cjwatson> I suggest something like this:
[18:00] <cjwatson> d-i preseed/late_command string sed -i 's/brutetech/srv001/' /target/etc/hostname; sed -i 's/brutetech.*/srv001.sb.brutetech.com srv001/' /target/etc/hosts; sed -i 's/search.*/search sb.brutetech.com/' /target/etc/resolv.conf
[18:00] <cjwatson> lo-tech
[18:00] <cjwatson> massage to taste
[18:00] <hardwire> cjwatson: ok.. I'm gonna try a few things
[18:01] <hardwire> Mainly because I don't like my lvm's being named wrong
[18:02] <cjwatson> oh, well, that bit *is* overridable
[18:03] <cjwatson> d-i partman-auto-lvm/new_vg_name string whatever
[18:03] <hardwire> I like your fixup for my scenario
[18:03] <hardwire> but it doesn't match other peoples rdns for their own IP's.. etc.. and I was hoping to get a howto out via that blog entry :)
[18:04] <hardwire> which, thankfully, I can still edit.
[18:04] <hardwire> I will succeed, mark my words.
[18:05] <hardwire> are you marking them?
[18:05] <cjwatson> :-) I have too much to do to fix this for 8.10, unfortunately, and Debian being more or less frozen makes it awkward too; but if nobody else beats me to it I expect to have a go at it for 9.04
[18:16] <hardwire> wowser
[18:16] <hardwire> there is no if statement surrounding seed_hostname_from_dns
[18:17] <hardwire> how absolutely strange
[18:18]  * hardwire tries to find a good hook to use
[18:24] <hardwire> cjwatson: I'm moving on for now.. requesting my RDNS be set right in the first place, or not at all.
[18:25] <hardwire> but it's a strange world in netcfg-1.40ubuntu5/static.s
[18:25] <hardwire> c
[18:25] <hardwire> I have no idea why there is no check if the hostname & domain is set up before seeding values from dns
[18:37] <cjwatson> as Joey says in the linked bug, it is "quite broken"
[18:49] <hardwire> cjwatson: I may be barking up the wrong tree here but.. even I could fix this.
[18:49] <hardwire> so what's the holdup?
[18:49] <hardwire> is there a decision pending on this very thing over at Debian HQ Global Inc?
[18:56] <cjwatson> err, no, just nobody's got round to it
[18:56] <cjwatson> personally, every time I remember about it, there's a freeze of some sort on so I go and do something else :)
[18:57] <cjwatson> it's rather delicate since you need to take into account a variety of code paths and preseeding possibilities
[19:02] <hardwire> I understand that all too well
[19:45] <hardwire> d-i preseed/early_command string echo <IP_ADDRESS> localhost > /etc/hosts; echo <IP_ADDRESS> srv001.sb.brutetech.com srv001
[19:45] <hardwire> does anything need to be escaped/quoted there?
[19:45] <hardwire> not sure how the parser for preseed stuff works
[19:46] <hardwire> it appears that netcfg.../static.c writes /etc/hosts AFTER the dns lookup
[19:46] <hardwire> so writing it before that time will cause the DNS lookup to resolve whatever I want.
[19:46] <hardwire> store that in memory.. then override the /etc/hosts file with the correct information
[20:12]  * hardwire waits for the remote install to verify his evil plan
[20:13] <cr3> if I want to modify the content of an iso, I will need to sign the Release file but how can I make my key available?
[20:26] <cr3> a simpler way might be to set debian-installer/allow-unauthenticated
[22:57] <hardwire> cr3 you could..
[22:57] <hardwire> oh