[01:20] <mup> Bug #1609194 opened: [2.1] Neighbour monitoring emits MOVED events for bogus MACs <MAAS:Triaged by mpontillo> <https://launchpad.net/bugs/1609194>
[04:14] <bdx> wq
[04:14] <bdx> wq
[12:57] <KpuCko> hello, is there any way to deploy maas node to usb flash drive?
[12:58] <KpuCko> or removable disks are ignored by curtin?
[13:15] <Braven36> what do you mean?
[13:17] <roaksoax> KpuCko: they are ignored
[13:25] <KpuCko> roaksoax thanks
[13:26] <KpuCko> roaksoax is there any way to change this behaviour
[13:26] <KpuCko> my nodes have two sata3 500g disks, so i want to use it after the node deployment for zfs/btrfs software defined storage
[13:42] <KpuCko> roaksoax, here?
[13:48] <roaksoax> KpuCko: no there's no way to use a usb disk as place to install
[13:48] <roaksoax> bladernr: ^^
[13:49] <KpuCko> thanks a lot
[14:19] <roaksoax> err
[14:19] <roaksoax> blake_r: ^^
[17:11] <nturner> newell_: roaksoax: I filed https://bugs.launchpad.net/maas/+bug/1609496 about the power issue we were hunting last week.
[17:19] <mup> Bug #1609496 opened: Power management trips over itself when BMC doesn't properly support --cycle --on-if-off <MAAS:New> <https://launchpad.net/bugs/1609496>
[17:22] <mup> Bug #1609496 changed: Power management trips over itself when BMC doesn't properly support --cycle --on-if-off <MAAS:New> <https://launchpad.net/bugs/1609496>
[17:37] <mup> Bug #1609496 opened: Power management trips over itself when BMC doesn't properly support --cycle --on-if-off <MAAS:New> <https://launchpad.net/bugs/1609496>
[18:13] <mup> Bug #1608545 changed: "sudo maas createadmin" instructions need --username <MAAS:Invalid> <https://launchpad.net/bugs/1608545>
[19:17] <Braven36> how do change the settting of maas dhcpd.conf
[19:24] <Braven36> I just setup another server to the cluster and we able to commission but deployment keeps failing
[19:29] <Braven36> Is ayone online?
[19:38] <Braven36> So a cluster controller has the image on it


[00:00] <Scott_S> See, I would think it was that, but netstat shows that master is listening on port 25 for both * and <IP_ADDRESS>.
[00:00] <Scott_S> Which leads me to believe it is actually listening to the port, but refusing the connection.
[00:00] <sarnold> Scott_S: ah! if it's actually listening than firewall inspection is the next best step I think
[00:00] <trippeh> residential ISPs doesnt like their users having spambots spewing spam :)
[00:01] <Scott_S> trippeh, Datacenter actually, but I did request port 25 traffic be permitted and they replied back stating that they had removed the restriction filter. I'll check with them again just to make sure.
[00:01] <sarnold> Scott_S: .. it might be denied by shaw ..
[00:02] <Scott_S> sarnold, I'm able to connect to my other server properly, which is configured with Windows. It'd be ridiculous for Shaw to restrict *incoming* port 25 traffic.
[00:02] <Scott_S> Otherwise, well, no one would use IMAP.
[00:03] <sarnold> Scott_S: I meant, if you're trying to test from your home laptop, shaw might prevent you from connecting to port 25 on the way outbound, to reduce spam..
[00:04] <trippeh> Scott_S: "email clients" dont really use port 25 anymore. the client to relay traffic is SMTP on port 587
[00:05] <trippeh> aka "submission"
[00:07]  * trippeh sees if this systemd-networkd thing is working
[00:08] <Scott_S> Interesting. I'm curious why Postfix is set up to use port 25 by default.
[00:08] <trippeh> To recieve email from relays ;-)
[00:09] <trippeh> relay -> mx is still on 25.
[00:09] <Scott_S> trippeh, so IMAP uses port 587 for actually sending mail via TLS?
[00:09] <trippeh> no. IMAP does not usually send email at all.
[00:10] <Scott_S> Erm sorry, I meant for receiving mail. I know that smtp is for sending.
[00:12] <Scott_S> I think I may be screwing up my ports and services. I'll figure it out later.
[00:12] <trippeh> IMAP uses different ports, none 25
[00:12] <trippeh> and not really related to Postfix
[00:12] <trippeh> yeah :)
[00:13] <Scott_S> Shows how much I set up these things, I'm unable to send mail via SMTP, which is supposed to use port 25 (apparently).
[00:16] <sarnold> Scott_S: when debugging mail problems it's best to use the simplest tools ever: nc to specific hosts, on specific ports, and hand-type the smtp sending session..
[00:16] <sarnold> Scott_S: test from localhost, from inside the same DC, from outside the DC, etc..
[00:16] <sarnold> if you're testing using full-blown  MTAs you'll drive yourself insane quickly.
[00:22] <trippeh> ok, networkd did bring up networking, thats something I guess :)
[00:23] <trippeh> no idea how to make it set accept_ra=0 before link up hmmm
[04:49] <Scott_S> sarnold, If you're still here, I simply enabled SSL smtp, which appears to have fixed the issue as I now connect via 465. Port 25 worked from localhost, just not from external network.
[08:05] <OpenTokix> trippeh: pre-up in /etc/network/interfaces
[08:06] <OpenTokix> trippeh: or just set ipv6 to manual, or add it to /etc/sysctl.conf
[08:06] <OpenTokix> trippeh: You want it to use dhcp6?
[08:59] <Dyon> Hi - I'm trying to setup an LDS for "managed" repository mirroring, can this only be accomlished with landscape-api and do I have to know all urls by head (e.g. MAAS repo, JuJu Repo, Cloud) or is there some magic command hidden somewhere? :-)
[10:23] <lordievader> Good afternoon.
[10:53] <trippeh> OpenTokix: that is for ifupdown, not systemd-networkd.
[10:54] <trippeh> OpenTokix: anyway, ifupdown handles most of it without those kinds of hack
[10:54] <trippeh> I'm just trying out the future ;)
[10:56] <OpenTokix> trippeh: ok
[10:56] <OpenTokix> trippeh: And the future does not include autoaccept_ra? =)
[11:00] <trippeh> not yet, *it seems*
[11:00] <trippeh> got it worked aroud in dbus for now
[11:03] <OpenTokix> trippeh: What is your aversion for RA?
[11:03] <OpenTokix> trippeh: I am curious that is
[11:07] <trippeh> sometimes in server-land you want to do a fully static config, even for gateway, thats all
[11:08] <OpenTokix> trippeh: ok
[11:09] <trippeh> say, your switch may not have the required RA filtering for it to be used securily
[11:09] <OpenTokix> you mean you get some errornous ipv6-address?
[11:09] <OpenTokix> ie. malconfigured network?
[11:10] <trippeh> say, a machine in the same VLAN gets owned, and starts announcing itself as gateway for MITM
[11:10] <OpenTokix> ok
[11:10] <OpenTokix> yes, that would be a bad thing
[11:11] <trippeh> same problem with DHCP of course. good switches can snoop/filter it as well
[14:01] <giammy2290> ho aperto qusta discussione nel forum di ubuntu http://forum.ubuntu-it.org/viewtopic.php?f=28&t=598243
[14:01] <giammy2290> qualcuno riesce a darmi una mano?
[14:01] <giammy2290> thx
[14:05] <giammy2290> ?
[15:11] <sgo11> hi, is that possible to try ubuntu server before installing it? I boot the usb and don't see "try ubuntu" option. thanks.
[15:12] <lordievader> sgo11: Err, as Ubuntu Server doesn't have a gui I do not think that it is possible.
[15:13] <sgo11> lordievader, there are many linux distributions run in usb (live OS). why can't I run live ubuntu server? this is nothing about GUI from my point of view...
[15:13] <lordievader> Oh it is possible, just not with the installer that the Ubuntu Server iso comes with.
[15:14] <sgo11> lordievader, got it. thanks a lot. very sad.
[15:14] <lordievader> sgo11: You could basically take one of the live-cd's and boot with the 'text' kernel parameter....
[15:16] <sgo11> lordievader, ok. I am checking http://live.debian.net/
[15:26] <zul> smb/hallyn: libvirt 1.2.16 is building in my ppa:zulcss/libvirt-testing ppa
[15:35] <hallyn> zul: cool.  i'll make a note to test that in a bit
[15:41] <jrwren> sgo11: what do you want to do? anything the server distro can do, the desktop distro can do. You can try ubuntu server by running try on the desktop.
[15:42] <sgo11> jrwren, Just want to run a live server. I am downloading debian-live-8.0.0-amd64-standard.iso now. thanks.
[15:43] <teward> sgo11: well, that's not a 'live server' either, that's a live image, it can *run* live but it's not a server
[15:43] <sgo11> teward, why is that not a server? so how can I run a proper live debian or ubuntu server? thanks.
[15:45] <jrwren> use the ubuntu live image and run?
[15:45] <jrwren> hrm, to be honest, I don't know what a liver server is. I'll leave you to it.
[15:46] <sgo11> jrwren, a live server is just booting the server from usb and load it to ram and running from ram.
[15:47] <sgo11> for example, freenas.org
[15:47] <sgo11> based on freebsd.
[15:51] <jrwren> how is that different than live desktop?
[15:54] <jpds> sgo11: I think you'll be far off running it in a VM.
[15:55] <sgo11> jrwren, I am not an expert. I am not very sure. a server supposed to have less space, faster performance etc.. because I don't need any GUI libs and because I am not an expert, i just want to find some already optimized tuned system to use.
[15:57] <DonRichie> hi, what is the best software to monitor the services of a single machine?
[15:57] <jpds> !best | DonRichie
[15:58] <sgo11> jpds, I need the server to run in a physical machine. so I am not planning to use a VM. thanks.
[15:58] <jrwren> sgo11: lordievader's suggestion of regular live cd and 'text' mode matches that. ubuntu-server is not 'tuned' any different than desktop. The difference is in default packages.
[15:58] <jpds> sgo11: In any case, you can't try Ubuntu Server like you can the desktop.
[15:58] <jpds> DonRichie: Depends on your needs, most people need to use Nagios and friends.
[16:00] <sgo11> jrwren, jpds, OK. thanks. I will try the live debian image first. not sure what is in it. just complete my download.
[16:00] <jrwren> sgo11: what server software will you run?
[16:01] <sgo11> jrwren, samba, nfs, nginx, nodejs
[16:05] <jrwren> sgo11: cool. good luck. I'd be interested in reading about your experience
[16:05] <sgo11> jrwren, thanks a lot. :)
[16:18] <marcaddeo> hey guys, i have a ubuntu server dvd and i'm at the screen that lets you decide what to do "Install ubuntu" "Test Memory" etc... im just trying to get into text mode so i can have a terminal and try and test a potentially broken hard drive and recover my zfs pool
[16:21] <tonyyarusso> marcaddeo: Second person today...no, the server DVD doesn't have a "live environment" option.  The desktop one does, or you could create something like it by installing to a flash drive.
[16:23] <marcaddeo> tonyyarusso: i see. damnit. i tried the desktop one, but it doesn't boot because the server doesnt have real graphics
[16:24] <tonyyarusso> marcaddeo: I think there's a "dumb down the graphics" option somewhere.
[16:25] <tonyyarusso> Or a couple really
[16:25] <tonyyarusso> Change the graphics type, disable splash
[16:26] <tarpman> server installer should still have rescue mode
[16:27] <tarpman> not sure if there's a menu entry for it -- if not, edit the command line, add 'rescue/enable=true' to the end (no quotes)
[16:50] <marcaddeo> tarpman: how does rescue mode work though, it goes into a command line gui screen to start doing stuff... i just would like to get into a terminal so i can run SMART and what-not
[16:51] <tarpman> marcaddeo: follow the prompts, eventually you will have the option of mounting your existing system and getting a shell in it, or just getting a shell in the installer environment
[16:52] <tarpman> marcaddeo: if you need more features (e.g. ability to install packages with apt-get) you might have better results booting a desktop dvd in text mode (add 'text' to the end of the boot command line), like tonyyarusso suggested
[17:05] <marcaddeo> tarpman: thats what im trying to do, desktop text mode but i can't get it to work
[17:05] <marcaddeo> my kvm keeps complaining about the resolution
[17:05] <tarpman> marcaddeo: ok, boot with 'text nomodeset'
[17:05] <marcaddeo> i've tried removing quiet splash, and adding -- vga=770 text
[17:05] <marcaddeo> okay
[17:07] <marcaddeo> tarpman: should i remove the quiet splash?
[17:08] <tarpman> marcaddeo: up to you. nomodeset forces splash to be disabled iirc. removing quiet just means you see more kernel messages
[17:08] <marcaddeo> also: the docs say it should be like quiet splash -- (boot options here)
[17:08] <marcaddeo> but when im editing it, it's actuall quiet splash ---
[17:08] <marcaddeo> note the third -
[17:08] <marcaddeo> should there be three?
[17:08] <tarpman> yes, with newer kernels it's ---
[17:08] <marcaddeo> ah i see
[17:09] <tarpman> just to check, which ubuntu version is your dvd? 14.04.2?
[17:09] <marcaddeo> 15.06 i think
[17:09] <tarpman> ah
[17:09] <ObrienDave> 15.04 ;p
[17:09] <marcaddeo> whateer :p
[17:09] <tarpman> 'text' doesn't work with 15.04 -- use 'systemd.unit=multi-user.target' instead
[17:09]  * tarpman really should file a bug about that
[17:09] <marcaddeo> ah!
[17:09] <marcaddeo> you may have jsut made my day much better lol
[17:14] <marcaddeo> tarpman: is nomodeset still going to work?
[17:14] <tarpman> marcaddeo: yes
[17:15] <tarpman> marcaddeo: I'm not sure how that interacts with the --- ... if it's still giving you grief, I'd try dropping those
[17:18] <marcaddeo> it worked! thank you tarpman
[17:27] <tarpman> :)
[23:01] <hallyn> zul: feh, lots of failures in qrt with libvirt 1.2.16.  they look familiar, though
[23:01] <hallyn> something to look at next methinks


[18:09] <Scary_Guy> I feel kinda bad for #nut since there are only seven users there including me.  A project that large I'd expect a bit more.  Though I guess it has been unmaintained for a while.
[18:16] <cmaloney> I moved most of my stuff to Signal / XMPP
[18:17] <cmaloney> I prefer XMPP by a country mile, but the users are on Signal
[18:49] <Scary_Guy> XMPP is good for people who know what XMPP actually is and have the technical fortitude to set it up.  Signal is good for normies.
[18:50] <Scary_Guy> The only downside with XMPP is it doesn't do voice/video.  Session is kinda new, and they just added that.  It's slightly better than Signal but not as easy and still not federated.
[18:51] <Scary_Guy> https://speek.network I just saw this one, which is federated, but has no voice/video yet and no text based client on top of that.
[19:25] <cmaloney> XMPP is a lot of hacks and RFCs
[19:25] <cmaloney> We're using https://quicksy.im at the moment
[19:26] <cmaloney> uses a phone number as my ID, but it also takes some of the pain out of the equation.


[01:08] <Riddell> what does "Run Once" mean for test cases on iso.qa.u.c?
[01:35] <slangasek> Riddell: that the test case needs to be done once for all images, instead of once per image
[01:44] <cjwatson> [5~/wg 44
[01:44] <cjwatson> sigh
[02:35] <GrueMaster> One more image to test and I can hit the pub.
[06:11] <micahg> slangasek: I assume disabling the publisher for hours at a time before alpha2 is released would be a bad thing?
[06:57] <pitti> micahg: is "hours" more like two or 12?
[06:57] <pitti> micahg: two hours sohuld be bearable if it's urgent
[06:57] <pitti> but not much more
[06:58] <micahg> pitti: 2-3 per release (this is for the Firefox migration to -security)
[06:58] <micahg> releases == lucid,maverick
[06:58] <pitti> wow, copying packages takes that long?
[06:59] <micahg> yeah, I think it took 3 hrs per release from -proposed to -updates
[06:59] <pitti> I think that mostly was because jdstrand used copy-package.py for the gazillion langpacks, wasn't it?
[06:59] <micahg> is that not the right way?
[06:59] <pitti> it works, but is utterly slow
[07:00] <pitti> using our sru-release --pattern lucid --security language-pack script, it's a matter of 15 minutes or so
[07:00] <micahg> pitti: ah, could you please document that on the archive admin page, that's what we were trying to use
[07:01] <micahg> https://wiki.ubuntu.com/ArchiveAdministration#langpack_SRUs
[07:01]  * micahg probably won't be ready until after release in any event though
[07:01] <pitti> urgh yes, that is a bit obsolete
[07:02] <pitti> also https://wiki.ubuntu.com/ArchiveAdministration#Standard_case
[07:02] <pitti> will update
[07:02] <micahg> thanks
[07:03] <micahg> ok, so, it should be <30 minutes per release then, perfect, if I'm ready before alpha2, I'll come ask in here
[07:17] <pitti> micahg: ArchiveAdmin page updated
[07:18] <micahg> pitti: thanks
[08:27] <mvo> is vmware-view-client waiting for approval in the precise-partner queue ? and if so, could someone have a look please :)
[09:01] <pitti> mvo: I don't see it in new or unapproved
[09:02] <mvo> odd, I reupload
[09:03] <mvo> thanks
[13:24]  * cjwatson investigates lubuntu having ended up with unity-greeter
[13:33] <ogra_> wasnt there a bug about that that was fixed ?
[13:34] <cjwatson> not so you'd notice in the current images.
[13:35] <cjwatson> bug 918401 and bug 925358
[13:35] <ubot4> Launchpad bug 918401 in unity-greeter (Ubuntu) (and 1 other project) "Unity-greeter installed by default on Lubuntu, crashing on start (affects: 8) (dups: 1) (heat: 50)" [Undecided,Confirmed] https://launchpad.net/bugs/918401
[13:35] <ubot4> Launchpad bug 925358 in casper (Ubuntu) "Lubuntu Precise live CD boots to a Unity-like DE (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/925358
[13:37] <cjwatson> but germinate output looks right; trying a local livecd-rootfs build
[13:38] <ogra_> jibel, hey, when you get Bug 924993, do you actually get a keyboard selection dialog ? i wonder if these two issues i see are related (and if its probably only an oem-config vs ubiquity thing)
[13:38] <ubot4> Launchpad bug 924993 in ubiquity (Ubuntu) "wireless password field disabled when user selects a protected network (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/924993
[13:39] <ogra_> i use oem-config here, see the same behavior but somehow the keyboard selection is supressed in that scenario ... while on systems without wlan the kbd selection shows up
[13:39] <jibel> ogra_, I do, everything works as expected apart from this password field that should be enabled.
[13:39] <ogra_> ok
[13:39] <ogra_> then it might be arm or oem-config specific
[13:40] <ogra_> though arm is unlikel else kbd selection wouldnt be shown on the pandaboards
[13:40]  * ogra_ wonders wh his Y ke onl works ever 5th press
[13:51] <jdstrand> pitti: re sru-release> the name implies it can only be used for -proposed to -updates. I see now there is a --security arg to go to -security. looking at the --help, I wonder about -updates to -security for the times that things might already be out of -proposed
[13:51] <pitti> jdstrand: I could add a --security-only for this occasion, it's easy to do
[13:52] <pitti> jdstrand: the packages are still in -proposed, so copying from -proposed to -security will be fine
[13:52] <pitti> jdstrand: you could use -s as-is, then it would copy to -updates again, plus -security
[13:52] <pitti> it's just a waste of half the time
[13:52] <pitti> but it might eventually come in handy for other occasions like firefox
[13:53] <jdstrand> well, since we run copy-report automatically, I don't really see why we would want --security-only at this time
[13:53] <jdstrand> it was more just the case of 'if the packages were deleted from -proposed already, but still in -updates'
[13:54] <jdstrand> I admit I don't know when things get deleted from -proposed
[13:55] <cjwatson> whenever we c/p the lines from the pending-sru page
[13:55] <cjwatson> which appear once they're in -updates
[13:57] <pitti> right, the report just doesn't cover langpacks, as it filters them out except for -en as a representative
[13:57] <pitti> as the validation process is different, and it would clutter up the page too uch
[13:57] <pitti> so in practice they stay in -proposed all the time
[13:58] <jdstrand> well, language-pack-en shows it is no longer in -proposed, but language-pack-es is
[14:00] <jdstrand> this was more curiosity anyway. I don't know if we will have another new set of langpacks for firefox 10
[14:02] <pitti> jdstrand: right, -en might have been cleaned up already, so we need to copy that manually
[14:02] <pitti> but all the other n-hundred can be done with the script
[14:02] <pitti> jdstrand: no, we won't
[14:03] <pitti> jdstrand: this was an one-time change for 3.6->9
[14:04] <jdstrand> pitti: ah great! thanks for your time :)
[14:04] <pitti> jdstrand: so, for this one time I'd just locally comment out the copying to -updates, that's easiest :)
[14:04]  * jdstrand makes a note
[14:04] <pitti> wrt. alpha-2, I suppose there's still a potential  lubuntu rebuild?
[14:05] <pitti> (as for freeze lifting)
[14:07] <Riddell> slangasek: for Kubuntu these images should be included in alpha 2: i386 and amd64 alternate, desktop and dvd
[14:08] <cjwatson> I think I've figured out the Lubuntu problem
[14:09] <cjwatson> it'll be a livecd-rootfs upload, build/publisher cycle, rebuild images
[14:09] <superm1> skaet wanted me to mention we are planning a2 for mythbuntu
[14:10] <cjwatson> how are your tests looking?
[14:10] <superm1> last tests were a week ago, so i'm going to try to drum up the team to test candidates today
[14:13] <cjwatson> right, this looks a few orders of magnitude more sensible.
[14:14] <skaet> cjwatson,  go ahead and start on the upload and build for Lubuntu please.   We'll wait until gilir's online to decide to retest/not.
[14:14] <skaet> Last I hear from him, was that he was ok with alternates going out, but not the livecd's.
[14:15] <cjwatson> the current desktop images are definitely unreleaseable by any reasonable metric.
[14:15] <cjwatson> (lubuntu I mean)
[14:15] <cjwatson> they simply aren't as specified
[14:17] <cjwatson> this should cut their size down a fair bit too ...
[14:18]  * skaet nods
[14:19]  * skaet figures its time for all images to go on a bit of a diet as well... after A2 ;)
[14:19] <cjwatson> feel free to make suggestions ;)
[14:19] <pitti> we have some overhead due to non-empty langpack updates
[14:20] <pitti> and ubuntuone bits need to be fixed to stop using gtk 2 and webkit (underway, AFAIUI)
[14:20] <pitti> then we can drop the old webkit gtk2 bits, some 8 MB
[14:20] <pitti> I did a size analysis recently, the biggest offenders were firefox/thunderbird (+2.6 MB each), new LibO (~ 1.5 MB), and of course python3 (~ +6 MB)
[14:22] <stgraber> skaet: I prepended the resolvconf issue to the list of known issues as I'm expecting quite a lot of users to hit that one
[14:22] <stgraber> skaet: looking at Edubuntu now
[14:23] <skaet> thanks pitti.   :)
[14:23] <skaet> stgraber,  thanks!   Yes,  anyone who knows of issues that are likely to be hit,  please review the TechnicalOverview and add them.
[14:28] <cjwatson> hmm, but isn't the resulting Lubuntu system going to need to have recommends disabled too ...
[14:28] <cjwatson> grah, this is annoyingly complex
[14:28] <seb128> pitti, webkit-gtk2 ... isn't that still used by ubuntuone-control-panel?
[14:29] <seb128> pitti, and gwibber
[14:29] <pitti> seb128: yes, but I thought ubuntuone stuff would be moved to GTK3 (sso-client) and PyQt (control-panel)
[14:29] <pitti> seb128: ah, gwibber, too, I thought ken was working on it
[14:29] <seb128> pitti, I'm not sure the pyqt stuff is going to happen this cycle
[14:29] <pitti> now that we have gnome-keyring GIR bindings
[14:29] <seb128> but let's see
[14:30] <seb128> pitti, he is, that didn't land yet either though ;-)
[14:30]  * slangasek waves morning-like
[14:30] <pitti> anyway, it's the best thing we have right now wrt. size reduction
[14:30] <seb128> slangasek, hey
[14:30] <pitti> slangasek: good morning
[14:31] <skaet> slangasek,  good morning.   grab the coffee.  ;)
[14:35] <slangasek> Riddell: so you specifically don't want the amd64+mac and powerpc images published with the alpha?
[14:35] <cjwatson> I think the Lubuntu alternate CDs should be respun.  Explanation in bug 918401 comment 32.
[14:35] <ubot4> Launchpad bug 918401 in unity-greeter (Ubuntu) (and 2 other projects) "Unity-greeter installed by default on Lubuntu, crashing on start (affects: 9) (dups: 2) (heat: 58)" [Undecided,Confirmed] https://launchpad.net/bugs/918401
[14:36] <stgraber> skaet: the Edubuntu technical overview is a bit long, unfortunately it looks like most of our changes happened between alpha-1 and alpha-2 ;) (alpha-1 was roughly identical to Oneiric)
[14:36] <stgraber> skaet: I'm now just waiting for highvoltage to do a final review so it may still grow or shrink a bit :)
[14:36] <cjwatson> I am fairly sure we'll need a new ubiquity if we want Lubuntu desktop to be suitable for Alpha 2.
[14:37] <skaet> stgraber,  that's fine.   Thanks!
[14:37] <Riddell> slangasek: they are untested, you can if users are clear of that
[14:38] <cjwatson> At which point I might as well include last night's marathon NTFS installation fix there as well.
[14:38] <skaet> slangasek,  Riddell,  if they are untested,  they shouldn't go out.
[14:39] <Riddell> right
[14:42] <cjwatson> Any opinions on a new ubiquity just for Lubuntu?
[14:42] <cjwatson> I'm preparing it now anyway
[14:43] <cjwatson> IWBNI a Lubuntu developer were around here ...
[14:44] <skaet> cjwatson,  given the complexity I suspect its unlikely we'll get a home run and it all work,  however they're changes that are needed, so if they don't end up in A2, getting them in the dailies tomorrow is good.
[14:44] <cjwatson> Are all the other images golden at this point?
[14:45] <cjwatson> I agree it will be a slight fluke if they all work; however if everything else is good (at least for desktop) then going ahead with a ubiquity upload probably wouldn't hurt
[14:45] <skaet> cjwatson,  I haven't heard any other show stoppers - so all the ones that are tested are likelies at this point.
[14:46] <cjwatson> The partman-auto change technically affects non-desktops although I seriously doubt anyone would notice
[14:47] <cjwatson> OK, so how about I go ahead and if it fails we just drop Lubuntu desktop from A2 (or attempt to release it tomorrow or something)
[14:47] <skaet> cjwatson,  sounds good.
[14:48] <cjwatson> I don't see obvious drawbacks
[14:48] <cjwatson> OK
[14:50] <highvoltage> stgraber: looks good!
[14:54] <slangasek> ok, can someone tell me what ~/.isotracker.conf should look like? :)
[14:54] <cjwatson> you could grab nusakan's
[14:54] <cjwatson> though that'll have you pretending to be ubuntu-cdimage
[14:56] <slangasek> what password is it wanting?  Hopefully not the SSO password?
[14:56] <slangasek> anyway, this is for publish-image-set, so pretending is probably fine
[14:57] <cjwatson> it's its own API key
[14:57] <slangasek> hum, getting an error:
[14:57] <slangasek> ERROR: Cannot handle product Ubuntu Server EC2 EBS (Asia-Pacific-NorthEast) amd64
[14:58] <slangasek> ... but that should match the 'ignore' regexp that I see in here
[14:58] <slangasek> ignore_product_re = re.compile('Netboot |Upgrade |Server EC2|line-through')
[14:59] <cjwatson> looks like a space, quacks like a space, isn't actually a space, maybe?
[14:59] <cjwatson> ok, new ubiquity on its way
[15:00] <cjwatson> oh, it's using .match not .search
[15:01] <cjwatson> slangasek: update and try again
[15:01] <cjwatson> heh, now it dislikes uwbi
[15:01] <cjwatson> *wubi
[15:02] <slangasek> well, progress :)
[15:02] <cjwatson> which to be fair it probably can't actually handle - I don't know that there's any non-manual release handling for wubi yet
[15:02]  * slangasek nods
[15:03] <cjwatson> I've added that to the ignore regex for now
[15:03] <slangasek> thanks
[15:03] <cjwatson> it produces sensible output now
[15:03] <cjwatson> well, output
[15:03] <slangasek> :-)
[15:03] <cjwatson> sense is your problem
[15:04] <cjwatson> surprising that I'm not seeing amd64+mac anywhere in the output
[15:06] <slangasek> possibly a missing $ on the amd64 variant
[15:06] <slangasek> testing
[15:06] <slangasek> yep
[15:07] <slangasek> fix pushed
[15:07] <cjwatson> yeah, I was just getting there :)
[15:07] <cjwatson> ta
[15:07] <slangasek> so to mark things as not-for-publishing, do we have a better mechanism than disabling them on the tracker?
[15:09] <cjwatson> ah yes, broken since r320
[15:09]  * cjwatson satisfies curiosity
[15:10] <cjwatson> r330 fixed it for armel+* but not amd64+*
[15:10] <cjwatson> slangasek: not AFAIK; I think I've just manually filtered them out of the publish-image-set output when I've done this
[15:11] <cjwatson> oh, we should do a source build
[15:11]  * cjwatson goes to poke that
[15:17] <skaet> slangasek,   I'm not seeing any of the amd64+mac images with testing on them,  so they shouldn't be going out with A2.
[15:17] <skaet> (nor the powerpc ones)
[15:18] <cjwatson> I've been making some progress on scaring up powerpc testers and reminding them that they actually need to do it, but it was only a couple of days ago so they may not have got organised in time
[15:18] <skaet> do you want me to just go in and disable the definite "no go"s?
[15:19] <skaet> cjwatson,  thanks.  :)   I've also been talking to IBM (Linux manager at LCA and he was receptive to the notion of getting some of his folks lined up to help)  but it needs to be followed up on too.
[15:29] <slangasek> skaet: does disabling them prevent people from posting tests of them?
[15:29] <slangasek> I think disabling them on the tracker is probably still best if we're pretty sure we're not publishing them, but it does mean it'd be nice to have a better way for the tool to decide what to publish
[15:29] <skaet> slangasek,  yes,  but if there are no tests posted at this point,  its unlikely we'll be getting any before we release.
[15:31] <skaet> slangasek,  yes that would be good.   Maybe we can brainstorm with stgraber about it after A2 is out.   (publish ticky box?)
[15:31] <slangasek> or the tool could embed the policy directly about what's publishable or not based on testedness
[15:32] <stgraber> skaet: we could indeed create an extra build status for "ready" (trying to find a term that works for hardware testing and package testing too ;))
[15:32] <stgraber> slangasek: the data actually is available in the API, so I could give a script using our criteria and returning the list
[15:36] <skaet> embedding the policy would be nice, but it needs to be transparent on the ship/not - maybe a color change when the testing results are satisfied to indicate its now possible to ship?
[15:38] <slangasek> well, that implies embedding the policy in *two* places, one of which the release engineer can't edit ;)
[15:41] <stgraber> right, if we want it visible on the website, we'd need a few extra tricks. Otherwise I'd simply make a python script using the API and put it in ubuntu-archive-tools (well, likely just update publish-image-set.py)
[15:42] <stgraber> so if someone wants to change the policy, it's just a matter of changing the script
[15:43] <stgraber> what I could do though is have the "ready" status visible on the website, have publish-image-set.py first apply the policy to the tracker and then show the list of what's ready to be published
[15:44] <skaet> just having the ready status visible on the website was what I was looking for.  :)
[15:44] <stgraber> that'd allow for manual overrides on the tracker by manuall marking stuff as ready and still have the script apply the policy automatically for the rest
[15:44] <stgraber> then show the final list
[15:44]  * skaet nods
[15:46] <skaet> slangasek,   what are the key bugs right now preventing upgrading from 10.04 to 12.04?  I'd like to add them to the release notes.
[15:46] <stgraber> skaet: so what's the current policy exactly? we clearly don't publish anything that wasn't tested at all but do we care about the actual test results? (like not publish anything that's not fully tested or not publish something that has all its results marked as failed, ...)
[15:48] <skaet> stgraber,  we need to refine the policies and make them visible - some parts are grey right now,  and it would be good to get the expectations nice and uniform.
[15:48] <cjwatson> skaet: bug 917173 and bug 922485 come to mind (fixed in precise but not yet successfully backported)
[15:48] <ubot4> Launchpad bug 917173 in apt (Debian) (and 12 other projects) "lucid -> precise upgrade failed: Resolver failed to calculate the upgrade - dpkg-dev held back (affects: 1) (heat: 10)" [Unknown,New] https://launchpad.net/bugs/917173
[15:48] <ubot4> Launchpad bug 922485 in apt (Debian) (and 12 other projects) "Lucid Desktop i386 failed to calculate the upgrade to Precise (affects: 1) (dups: 1) (heat: 16)" [Unknown,New] https://launchpad.net/bugs/922485
[15:48] <skaet> thanks cjwatson
[15:48]  * skaet adding them now.
[15:49] <cjwatson> skaet: the bugs at this point are IMO sufficiently early in the process that we do not have a good overview of problems
[15:49] <cjwatson> I was trying to figure out why the backports failed to verify but was derailed by a2 stuff
[15:50] <skaet> cjwatson,  fair enough.  :)   expect we'll be figuring out a lot of this over next month.
[15:53] <slangasek> skaet: right, the ones cjwatson listed.  Although, does listing LTS upgrade bugs set an unreasonable expectation for people that a 10.04->12.04 upgrade is a reasonable thing for mortals to do? :)
[15:53] <skaet> slangasek,  "Upgrading from 10.04 to 12.04 still has some known issues and is not recommended at this time." - just wanted to provide some examples  ;)
[15:53] <slangasek> right-o :)
[15:55] <slangasek> skaet: as for policy on publishing... I guess I would say anything that's untested, or anything that's been tested but had only failures, should not be published, and anything else is a question of human judgement?
[15:55] <slangasek> i.e., if there's a reason we're choosing not to publish an image that *has* been successfully tested, we could still indicate that manually
[15:56] <skaet> slangasek,  yes it does seem to boil down to that.   How about I start a wiki page off after we get A2 out, and we'll get the rest of the release team's input.
[15:57] <skaet> then we can all have the same expectations on release day ;)
[16:00] <slangasek> sounds good
[16:00] <cjwatson> the good bit about testing upgrades is that you have plenty of opportunities for coffee breaks.
[16:13] <cjwatson> rebuilding Lubuntu desktop with fingers crossed
[16:14]  * skaet crosses fingers
[16:32] <stgraber> skaet, slangasek: Using http://paste.ubuntu.com/826568/ gives me http://paste.ubuntu.com/826569/ (though iterating through everything takes almost a minute ... so custom status would be nice to avoid that, then just products.get_list and builds.get_list would be required)
[16:33] <stgraber> so that's everything that's currently active on the tracker (status = 0) and with at least one mandatory testcase marked as passed
[16:35] <skaet> stgraber,  it should actually be all mandatory testcases marked as passed.... else they shouldn't be mandatory.
[16:36] <skaet> but its a judgement thing, depending where in the release cycle we are.
[16:37] <skaet> stgraber, http://paste.ubuntu.com/826569/ looks good though.  :)
[16:38] <stgraber> skaet: indeed, we definitely want all the mandatory passed at least once for final, all the run-once also passed at least once and we can probably ignore the optionals (or only consider failures?)
[16:38] <stgraber> skaet: anyway, writting down the policy will help quite a bit ;)
[16:38] <slangasek> skaet: but late in the cycle, those also typically gate whether we're ready to publish, rather than just whether a particular image should be published
[16:39] <slangasek> so I think having the tool just block untested and completely-failed images gets us to the right place as far as automation
[16:40] <skaet> slangasek, stgraber - fair enough.  Will work on writing it up tomorrow, and see if we can get it discussed next week.   I'll try to add a dimension for Alpha, Beta, Final criteria - so we're clearer.
[18:06] <slangasek> hmm, are Ubuntu Studio considered publish-ready?
[18:07] <slangasek> apparently there are no successful ubiquity installs, just a bunch of failures
[18:12] <slangasek> skaet: ^^ I'm holding off on ubuntustudio for now given the above
[18:17] <skaet> slangasek,  ack
[18:17] <skaet> scott-work, ^ any data that isn't in the tracker?
[18:21] <seb128> slangasek, skaet: is there any plan to unfreeze today?
[18:21] <slangasek> I think we should be unfreezing at this point; skaet?
[18:21] <seb128> just trying to schedule my end or day and friday
[18:21] <seb128> or->of
[18:21] <scott-work> slangasek: skaet:  i believe there were successful installs - there were cases of ubiquity failing but also lightdm not properly configured which may have been construed as "ubiquity failuers"
[18:22] <slangasek> scott-work: well, the only people who've posted test results on the tracker marked their tests as failed
[18:23] <cjwatson> Lubuntu desktop looks better to me now
[18:23] <cjwatson> at least gives me a working desktop, haven't tried an install
[18:24] <scott-work> slangasek:  it may be better to not publish for A2 then
[18:25] <slangasek> scott-work: ok
[18:25] <skaet> thanks cjwatson,   was wanting to hear how it looked before unfreezing.   No results in from any of the lubuntu folk though yet,  but at this point,  not seeing much upside in keeping it frozen.
[18:25] <skaet> scott-work,  I'll comment out the ubuntu-studio comments from the technical overview then as well.
[18:31] <slangasek> cjwatson: evidently the rules on #ubuntu-devel /topic handling have changed since last I needed to set one; can't set it directly, chanserv won't set it for me?
[18:32] <cjwatson> you have +t, you should be able to use /msg chanserv topic
[18:33]  * cjwatson tries to find what the channel mode used to be
[18:35] <slangasek> yeah, chanserv didn't like me
[18:36] <slangasek> man
[18:36] <slangasek> can't set the channel here either
[18:36] <davmor2> slangasek: you just weren't hitting it hard enough :)
[18:37] <cjwatson> hm, you know, sod it, +t isn't mlocked on -devel afaics
[18:49] <scott-work> slangasek: skaet:  sorry for dropping the ball on A2, i will be more prepared in the future
[18:55] <stgraber> slangasek: do we want to wait a bit longer for the resolvconf upload or should I go ahead and upload it nowish? (thanks for the postrm fix btw)
[18:55] <slangasek> scott-work: no skin off my nose... :)
[18:55] <slangasek> stgraber: I'm fine with you uploading it now
[18:56] <stgraber> slangasek: good. Will do a couple more tests on it and then upload, should definitely be in the archive in time for the Edubuntu daily (assuming they've been switched back on)
[18:59] <slangasek> they haven't been just yet
[19:01] <slangasek> who usually handles the cloud image publishing?
[19:01] <utlemming> slangesek: that's me
[19:01] <slangasek> utlemming: ah, hi :)
[19:01] <slangasek> utlemming: is there anything else pending from your POV before those can be published?
[19:01] <slangasek> looks like the testing is done
[19:02] <slangasek> and we're pushing out the ISOs, so I guess it's time for the cloud images to go out also?
[19:02] <utlemming> slangesek: no, we're good to go, just waiting for the go-ahead to publish them
[19:02] <Riddell> slangasek: announcing the release sometime soon?
[19:02] <slangasek> utlemming: go ahead then :)
[19:03] <utlemming> slangasek: publishing now
[19:03] <slangasek> Riddell: well, skaet will be
[19:03] <Riddell> I'm away for a few hours, I'll tell my kubuntu people to watch and put on the website when they see it
[19:04] <skaet> Riddell,  sounds good.   want me to post in the #kubuntu-devel channel,  or will someone monitor here?
[19:04] <Riddell> skaet: that would be good yes
[19:08] <utlemming> cloud-images for Alpha2 are now public
[19:17] <skaet> utlemming,  yup,  able to see them now. :)
[21:03] <skaet> Looks like we're all nicely released now for A2.    Thanks slangasek!
[21:45] <highvoltage> :)
[21:48] <balloons> gratz everyone!


[10:28] <SiDi> MacSlow: heya
[10:28] <SiDi> for the notifyosd gconf keys, we said bubble bg/shadow color, content shadow color, text title/body color, bubble opacity, text title/body font size ratio, right ? :P
[10:32] <MacSlow> SiDi, yes
[10:32] <SiDi> okey, i'm gonna write it today then
[10:38] <SiDi> MacSlow: for the variables linked to gconf/xfconf, i was thinking of creating an opaque ConfData struct in the Defaults struct, and then defaults-gconf.h / defaults-xfconf.h would define this struct. Is it ok ?
[10:40] <MacSlow> SiDi, sounds reasonable
[11:31] <SiDi> MacSlow: for multihead_focus_follow, what are the possible values apart from "focus-follow" ? And what default value should be used ?
[11:42] <MacSlow> SiDi, I've not made up my mind on that yet (also need to read the spec again :)
[11:50] <SiDi> MacSlow: okey :) for now i turned it into this : http://paste.ubuntu.com/254464/
[12:23]  * MacSlow -> lunch
[13:32] <SiDi> MacSlow|lunch: defaults-gconf.c is written, compiles, runs, and even seems to work ! \o/
[15:38] <SiDi> MacSlow: do you want separate patches for xfconf support & text size / color support, or one patch is ok ?
[15:40]  * MacSlow -> phone-call