[00:22] <blackboxsw> personally I like seeing your separate commits post my last review. there's gotta be a way to do that once someone has already git push --force'd to a remote.
[00:23] <blackboxsw> I guess I could just git diff rhrper-repo/branch-name and see it before I pull
[00:24] <blackboxsw> personally I like seeing your separate commits after my most recent review.*
[01:41] <smoser> rharper: so templates/chrony.conf.debian.tmpl:
[01:41] <smoser> has a non-ascii char in it.
[01:41] <smoser> and as yo udiagnosed, that is getting decoded somewhere as ascii in python27 jinja2
[01:41] <smoser> and it just isnt ascii
[02:00] <smoser> http://paste.ubuntu.com/p/c5jxV6Rg45/
[02:00] <smoser> that recreates the basic failure
[02:04] <smoser> https://stackoverflow.com/questions/22181944/using-utf-8-characters-in-a-jinja2-template
[02:06] <smoser> well, ignore that. that failure wasnt right. but its somewhere around there.
[08:25] <apollo13> blackboxsw, rharper: thanks, any reason to prefer manual_cache_clean over /etc/cloud/cloud-init.disabled or just personal pref?
[12:57] <rcj> rharper: I see that you're working on chrony support (according to blackboxsw in https://cloud-init.github.io/status-2018-03-19.html#status-2018-03-19) Will that land for bionic?
[13:43] <smoser> rcj: yes. will land today
[13:43] <smoser> rharper: we need your network-ipv6 fix today too
[13:44] <smoser> rcj: but the images to my knowledge do not have chrony installed.
[13:45] <smoser> cloud-init will not install chrony if systemd-timesyncd is present, it will just configure that.
[13:57] <rharper> smoser: network-ipv6?
[14:01] <smoser> 10 second timeout
[14:02] <rharper> oh, netplan
[14:02] <rharper> yes, that would be really good to get an upload into bionic at least
[14:02] <rharper> even if it needs an SRU to artful
[14:03] <rharper> I have the PR in
[14:03] <cyphermox> I'll review in a bit and upload that with some other bugfixes
[14:03] <rharper> thx
[14:05] <smoser> rharper: i had thought that that was in cloud-init ... sorry i missed rthat.
[14:06] <rharper> smoser: I had a branch to disable-ra in cloud-init but after discussion with stgraber I realized the underlying issue was related to how systemd-networkd handles RA
[14:06] <rharper> and what the default netplan setting was
[14:06] <rharper> so that's probably why you thought we had some cloud-init work to do
[14:26] <smoser> rharper: and yes... thank you for seeing that. i had in 2 places seen the ~ 13 second network config and just thought "wow, their dhcp server is really slow"
[14:27] <rharper> yeah; it actually come up under the autopackage test failures on bionic in lxd containers because the network wasn't yet on line and apt update/install failed
[14:27] <smoser> well,. that needs fixing :)
[14:28] <smoser> sleep 5 && echo "everything ready!"
[14:28] <rharper> they added some retry logic
[14:29] <rharper> https://lists.ubuntu.com/archives/ubuntu-devel/2018-February/040138.html
[14:36] <smoser> very much a need in Ubuntu for "wait until system is booted" command.
[14:41] <rharper> folks disagree what "booted" means; I think that thread demonstrates that
[14:41] <Cyclohexane> Is there a known issue with any of these packages? https://pastebin.com/kwT1Fs8c I'm following https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-migrate-ipv6.html#ipv6-dhcpv6-rhel and it works absolutely fine on a fresh install, then I run yum update and the whole thing goes caput, networking dies and the server becomes inaccessible...
[14:43] <rharper> did you reboot or just after the yum update completes ?
[14:44] <rharper> cloud-init isn't active after boot, so an update to cloud-init won't affect a running instance;
[14:46] <Cyclohexane> i reboot yeah, as the amazon guide says
[14:47] <rharper> cloud-init at that level isn't going to affect the network config; it's just dhcp on eth0
[14:48] <rharper> if you look at the instance console-log, that should show if cloud-init ran, it dumps the network state of the instance
[14:50] <Cyclohexane> yeah cloud-init runs, but and updates per 99-custom-network.cfg but then when cloud-init runs netstat -rn the route table is dead so it loses connectivity
[14:50] <Cyclohexane> it works fine prior to running yum update, can reboot and it comes back up with ipv6 connectivity
[14:51] <rharper> maybe the dhcp update then ?
[14:51] <rharper> I suspect you may need to bisect your update ; upgrade a few at a time to see if keeps networking, or not
[15:09] <smoser> http://paste.ubuntu.com/p/FsDxksfVS3/
[15:24] <smoser> rharper: $ grep -r can.t templates/
[16:02] <Cyclohexane> rharper: it seems to be this https://bugs.centos.org/view.php?id=14585
[16:08] <rharper> smoser: ok, pushed an update to the branch to update template and drop the related changes
[16:11] <rharper> Cyclohexane: yeah, not much info there;   you could 1) yum upgrade  2) make a copy of /etc/sysconfig/{network,network-scripts}  3) add the 99-custom-networking.cfg to /etc/cloud/cloud.cfg.d/ and then 4) cloud-init --force --debug init --local  which will re-run the initial cloud-init stage that renders network config;  then compare /etc/sysconfig/{network, network-scripts} contents with your copy and see whats different
[16:28] <Cyclohexane> rharper: https://gist.githubusercontent.com/bytestream/cb6fa966875b902cdb34986047eca1b3/raw/1183714df137a7df9441600f242cab46df52ffa7/gistfile1.txt
[16:34] <rharper> Cyclohexane: if /etc/sysconfig/network-scripts/ifcfg-eth0 is the same before and after, then it's not the config that cloud-init is generating
[16:37] <rharper> Cyclohexane: if possible, you could add a second interface and configure that with a public ip, or a second vm in the same VPC both with dual nics in the same network; you could  then hop through the second interface to see what things look like after reboot
[16:39] <blackboxsw> smoser: we good on https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/342761?
[16:41] <Cyclohexane> rharper: it's something to do with changes between cloud-init-0.7.9-9.el7.centos.2.x86_64 and cloud-init-0.7.9-9.el7.centos.6.x86_64, I downgraded cloud-init after yum update back to .2 and it's working fine again
[16:49] <dpb1> Cyclohexane: you should file a bug, or add to that one you found already
[17:22] <smoser> blackboxsw: acked.
[17:22] <smoser> tahnks
[17:27] <smoser> rharper: you must have cherry picked my commit from trunk ?
[17:27] <smoser> 0f7745619ab0a61d7dee5bde43e1e970ddf4a9b6 is on your branch but is
[17:28] <smoser> never mind
[17:28] <smoser> noise here
[17:45] <smoser> rharper: responded on your mp
[17:46] <smoser> i like it. thank you
[18:13] <rharper> smoser: checking, thanks
[18:27] <rharper> smoser: fixed  https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/339438
[19:30] <smoser> blackboxsw:
[19:37] <rharper> https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/343122
[19:49] <smoser> rharper: isnt' there some argparse -> bash completion ?
[19:49] <rharper> smoser: maybe
[19:49] <rharper> I'll look
[19:54] <blackboxsw> ooooh raharper... nice I did bash completion for landscape, will check
[19:54] <rharper> blackboxsw: yeah, dpb1 mentioned that
[20:09] <blackboxsw> rharper: yeah per smoser's comment python3-argcomplete might do some of this work for us, and doesn't add any more dependencies besides that package
[20:09] <rharper> well, I was interested in static generate of the file
[20:10] <rharper> like build-time run argparse to shell code and pack that up
[20:10] <blackboxsw> time-saver :)
[20:10] <rharper> rather than having python runtime during tab-tab
[20:10] <smoser> yeah. you'd think something like that would exist
[20:13] <dpb1> ntp merged?
[20:16] <rharper> dpb1: y
[20:16] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343127
[20:17] <dpb1> rharper: woop!!!
[20:17] <dpb1> upload?
[20:17] <smoser> rharper: the files you got for templates
[20:17] <smoser> they were exactly from debian/ubuntu ?
[20:18] <smoser> with the "can?t"
[20:18] <rharper> yes
[20:18] <rharper> look at bionic's chrony.conf
[20:19] <rharper> lemme fire up sid
[20:20] <rharper> yeah
[20:27] <smoser> blackboxsw: around?
[20:27] <blackboxsw> smoser: yep
[20:28] <blackboxsw> hangout?
[20:28] <smoser> yeh
[20:28] <blackboxsw> release related
[20:29] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343120
[20:31] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343127
[21:02] <smoser> man. that exception_cb is a mess.
[21:02] <smoser> who wrote this stuff
[21:02] <smoser> readurl and wait_for_url are much different in what they pass
[21:32] <smoser> blackboxsw: i'll be back in in ~ 3 hours i guess.
[21:33] <blackboxsw> sounds good. just pushed robjo's changes  into my nettools branch, will have a devel branch up for you  before you get back. if you find the net-tools changes good I'll check in later to see if we want to land that
[22:09] <blackboxsw> pushed https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/343136 for bionic release to include ntp/chrony fixes
[23:58] <smoser> blackboxsw: merged yours and uploading


[00:00] <smoser> i'll try again, but i swear before i added '--debug' and it just didn't do anything.
[00:01] <smoser> hm.. for the record, i added '--verbose', not '--debug' . '--help' output mentions --verbose, not --debug.
[00:03] <wolter> slangasek, yes
[00:03] <slangasek> smoser: I honestly don't remember; I've always captured to a logfile in /dev for easier post-boot analysis, but that doesn't work here if you can't get to a shell :)
[00:03] <smoser> --debug has no effect to the console.
[00:04] <slangasek> smoser: bah.  Maybe try > /dev/console 2>&1 ?
[00:04] <smoser> at least "grep -v 'init:'" rips out just about everything. nothing really looks like mountall output
[00:04] <smoser> well, it *should* get to the console.  other tasks do, i know that. but i guess other tasks don't run so early.
[00:05] <slangasek> wolter: well, AFAIK that should entirely be handled by gnome-settings-daemon, with no pulseaudio involvement
[00:05] <slangasek> wolter: what's the hardware?  It's not a thinkpad, is it?
[00:05] <wolter> no
[00:05] <wolter> its a dell xps m1530 with sigmatel sound card
[00:05] <slangasek> wolter: ok, no idea then, sorry
[00:05] <wolter> but it used to work, so that should not matter
[00:05] <wolter> ok, attempt appreciated anyway, thanks
[00:06] <slangasek> wolter: it matters because on the thinkpad, it "worked" wrong in earlier versions
[00:06] <smoser> scratch that. retrying. hodl on
[00:06] <slangasek> but that definitely doesn't apply to Dells
[00:06] <wolter> ok
[00:09] <smoser> slangasek, http://paste.ubuntu.com/359307/
[00:10] <smoser> that is '--debug' output to mountall, and it does get to the console. user error previously.
[00:10] <smoser> it seems to think it can't mount /
[00:13] <smoser> ok. so i found the issue. or at least a fix/workaround.
[00:13] <slangasek> oh?
[00:13] <smoser> slangasek, /etc/fstab has '/dev/sda1' as root, but /dev/sda is actually root.
[00:13] <smoser> kernel cmdline has the correct value, and / does obviously get mounted
[00:14] <smoser> but mountall sits around waiting for a / that is never going to be
[00:14] <slangasek> ah
[00:14] <smoser> i think it doesn't make sense to wait for the device of /
[00:14] <slangasek> IIRC it waits for it in order to fsck it?
[00:14] <smoser> although that doesn't explain why it works with the initramdisk
[00:14] <slangasek> yeah, I don't know
[00:15] <smoser> that does make sense, to fsck, but better to listen to what is already mounted than to /etc/fstab, which can only ever be wrong.
[00:16] <smoser> at least if, between fstab and the kernel, if one is wrong, its not fstab
[00:17] <slangasek> smoser: right, well, please post this analysis to the bug and we'll consult Keybnz when he's available :)
[00:18] <smoser> k
[00:54] <smoser> slangasek, you agree that this is probably 'mountall' and not 'upstart' ?
[00:54] <cjwatson> didrocks,superm1: please use lp:~ubuntu-core-dev/user-setup/ubuntu rather than lp:ubuntu/user-setup
[00:54] <slangasek> smoser: yes, it's clearly a mountall issue
[00:55] <cjwatson> didrocks,superm1: those may become identical in future, but for now lp:~ubuntu-core-dev/user-setup/ubuntu is the correct branch
[00:55] <cjwatson> didrocks: sorry, you can ignore the above - it's just superm1 getting it wrong :)
[01:00] <smoser> slangasek, thanks for your help.  what do you want me to do for your smb bug?
[01:02] <slangasek> smoser: set log level = 3, reproduce it, and send me /var/log/samba/log.nmbd :)
[01:12] <cjwatson> superm1: I've fixed up the history, though I'd rather not have to do so again as the process is a bit tedious and manual
[01:15] <slangasek> smoser: oh, bear in mind that you need samba 2:3.4.3-2ubuntu1 or earlier to reproduce this; 2:3.4.3-2ubuntu2 includes the /etc/network/if-up.d script that will mask the problem
[01:16] <smoser> well i saw i with alpha2. i'll just use that unless it is otherwise not acceptable.
[01:16] <slangasek> yah, that's good
[01:16] <smoser> is that ok?
[01:16] <smoser> k
[01:28] <micahg> Riddell: thanks for pushing that zf backport, but I wonder if we should push 1.9.7 instead
[01:30] <Riddell> micahg: that's a question for the backports team, I only do what they approve
[01:30] <micahg> heh, ok, ScottK ^^^
[01:31] <Riddell> speaking of which, ScottK, jdong: how come nobody has complained about these not being processed for up to 6 months?
[01:41] <ScottK> Riddell: I've been busy ...
[01:52] <superm1> cjwatson, i'm sorry.  i'm so confused with different projects using lp:ubuntu/blah and others lp:~ubuntu-core-dev/blah/blah+
[01:53] <StevenK> superm1: Some of them should be equal
[01:53] <superm1> StevenK, see that's just the problem : *some of them*
[01:54] <superm1> and i'm not sure which ones those are
[01:54] <StevenK> superm1: It's a transistional period, what can you do?
[01:54] <superm1> complain :)
[01:55] <StevenK> superm1: I'd suggest asking james_w about the above
[01:58] <StevenK> superm1: Can I upload mythtv? :-)
[01:59] <superm1> StevenK, our branches are just as much a mess :)
[01:59] <StevenK> superm1: No-change rebuild for jack ...
[01:59] <superm1> StevenK, actually we've got changes queued up, i'll upload them tonight
[02:00] <StevenK> superm1: Right, well, I've just kicked libjack0.100.0-0 out of the archive, so I may have broken myth, but NBS wasn't picking it up and complaining
[02:01] <superm1> StevenK, okay.  i'll see what happens.  if it fails to build i'll just disable jack for now.  i dont know a single user that uses jack tbh.
[02:02] <StevenK> superm1: I removed the shared library, the -dev package was removed days ago, and your Build-Depends are already fine
[02:02] <slangasek> ArneGoetje: can you roll some new langpack -base packages for hardy (8.04.4)?  i386 alternate has grown, and I think re-compacting language-pack-es-base should be enough to fix this
[02:02] <slangasek> ArneGoetje: (though just in case it isn't, I would certainly suggest doing all the ones that are on the CD...)
[02:04] <cjwatson> superm1: honouring the Vcs-Bzr field in debian/control when it's set to something useful and Ubuntuish will get you out of trouble most of the time.
[02:05] <cjwatson> superm1: (BTW I've already asked james_w to move the lp:ubuntu/... links over for this case, a while back)
[02:06] <ArneGoetje> slangasek: yes, I'm working on it.
[02:06] <slangasek> ArneGoetje: ok, thanks :)
[02:06] <slangasek> ArneGoetje: when do you think that will be done?  (so I can schedule CD testing accordingly)
[02:10] <ArneGoetje> slangasek: I will start a build now and see if it runs through. Since the langpack-o-matic code has moved to another server, there are still some dependency problems when generating the mozilla translations of the langpacks, So, need to test if it's fixed now. But I hope to have at least the packages, which go on the CD ready within 10 hours
[02:11] <slangasek> ok
[02:12] <Keybnz> cjwatson: hey, dunno if you know, but the 19 install failed
[02:12] <cjwatson> Keybnz: nope, any clues as to what went wrong?
[02:12] <Keybnz> http://zelda.netsplit.com/~daily/daily-installer/20100119-max/debug
[02:13] <Keybnz> (the rookery rsync apparently doesn't work anymore)
[02:13] <slangasek> Keybnz: hi, quick question while you're about - the plymouth in initramfs is a temporary workaround until the gdm/plymouth starting race can be fixed, right?
[02:13] <Keybnz> slangasek: got it in one
[02:13] <slangasek> ok
[02:13] <slangasek> do you have an idea yet of how to fix that race? would you like me to work on it?
[02:13] <Keybnz> gdm starts before plymouth ends the world ;)
[02:14] <slangasek> yep
[02:14] <Keybnz> start plymouthd very early, separate job to show splash
[02:14] <Keybnz> so if X is up, it's a no-op
[02:14] <Keybnz> might need some work to make sure you don't get console messages, etc.
[02:14] <slangasek> ok
[02:14] <Keybnz> (since gdm deactivates plymouth when it starts and re-shows it later)
[02:15] <slangasek> I'm keen to see it resolved because I'd like to avoid having to put pango in everyone's initramfs in the interim ;)
[02:15] <Keybnz> yeah it's top of my things to do at the sprint
[02:15] <slangasek> alrighty
[02:19] <Keybnz> slangasek: feel free to give it a shot
[02:21] <slangasek> Keybnz: ok, cheers
[02:29] <cjwatson> Keybnz: rookery> people.canonical.com changed host, it's now "lillypilly" (silly name ...)
[02:29] <cjwatson> Keybnz: could you make the syslog there world-readable?  I get 403 Forbidden
[02:30] <cjwatson> Keybnz: it might be what superm1 just fixed though
[02:30] <cjwatson>   * Fix automatic login on situations where custom.conf didn't exist
[02:30] <cjwatson>     already on the target.
[02:31] <cjwatson> yeah, looks about right
[02:31] <cjwatson> I'll make sure we do a ubiquity upload tomorrow
[02:41] <StevenK> cjwatson: d-i and the surrounds are free of the -9 kernel, so I can kick it out of the archive?
[02:41] <StevenK> I've checked, just want to make sure.
[02:44] <cjwatson> StevenK: yes
[02:45] <ScottK> StevenK: Even on powerpc?
[02:46] <ScottK> Last I looked, d-i wasn't building there.
[02:47] <smoser> slangasek, log files for recreate attached. if you want anything else let me know. i'll keep the vm around for a bit.
[02:48] <cjwatson> ScottK: if memory serves, it didn't build with -9 either
[02:49] <ScottK> Ah, may be.
[02:49] <StevenK> It's because the kernel is too big
[02:49] <StevenK> I think
[02:49] <cjwatson> I've not been bored enough to investigate
[02:50] <ScottK> StevenK: I think that's right.  I looked at it enough to conclude I'm really confused by d-i and will leave it alone.
[02:52] <Keybnz> cjwatson: yeah the problem is that IS haven't copied over the special permission for the rsync
[02:52] <Keybnz> will fix the perms
[02:52] <Keybnz> unfortunately daily installs/bootcharts are down until someone manually reboots the boxes :(
[02:56] <Keybnz> ok, I want bzr reflog now
[05:05] <slangasek> smoser: thanks - that's with a stock smb.conf?
[07:18] <dholbach> good morning
[07:18] <ajmitch> morning dholbach
[07:18] <dholbach> hey ajmitch
[08:14] <doko_> ccheney: yes, please still use -O2 for the arm build
[08:24] <pitti> Good morning
[08:25] <slangasek> morning
[08:46] <abogani> Hi All, I found on our wiki instructions for add new package into Ubuntu. Where can I find instructions for request to removing package from Ubuntu? In my case the simualvr package is buggy, never used and no more developed simulator for AVR. It presence in our archive can let our users think that is a good software and let they disappointed when discover that it is a very bad software. What is the right thing to do?
[08:48] <pitti> ttx: FYI, the missing trend line start update was a problem in my cronjob; fixed last night, so they should be good now
[08:49] <jussi01> abogani: you need to file a bug - instructions are on this page: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive
[08:51] <abogani> jussi01: Yeah the missing URL! Thanks Jussy!
[08:52]  * jussi01 hugs abogani and reminds him that his name is spelt Jussi :D
[08:52] <ttx> pitti: yes, it's perfect now, thanks
[08:52] <doko_> pitti: when should we start planning which library versions to demote for lucid (boost, db4.x, readline5, ..., ???)
[08:53] <abogani> jussi01: It isn't the first time, also... Apologize for this I'll try to write your name well. :-(
[08:54] <pitti> doko_: hm, to me it seems this is the kind of work for between beta-1 and beta-2; WDYT?
[08:56] <doko_> pitti: hmm, maybe a bit late? should we try to propose versions which we do want to keep/target for lucid now/next week?
[08:56] <pitti> we can make a list of duplicates, sure
[08:57] <pitti> it just seems less intrusive than the typical alpha-2/3 targets, and we're still syncing from debian right now
[08:58] <smb> Anybody with a spare current Lucid machine, who could help me to verify something?
[08:58] <doko_> ok, I'll start a wiki page later this week
[08:58] <seb128> smb, spare like ready to break?
[08:59] <smb> seb128, Sort of yes, but recoverably (thought maybe in a scary way)
[08:59] <seb128> ok, I will pass on this one, sorry but I've a busy schedule for today
[08:59] <seb128> I can do quick testing but I need my box ;-)
[09:02] <smb> In general, after adding the following to /etc/fstab: "LABEL=NotHere /mnt ext3 defaults,user,relatime 0 0", then on reboot my installation hung. But with sysrq-i (kill all tasks) I get dropped down to a maintenance shell where I can remove the bad entry from the fstab and the system boots again.
[09:02] <smb> This entry did not cause problems until some recent update. It seems mountall gets into trouble now.
[09:04] <slangasek> smb: by design
[09:05] <slangasek> smb: based on negative feedback in karmic, Keybnz has made mountall block waiting for all local filesystems listed in /etc/fstab before declaring the filesystem "mounted"
[09:06] <smb> Though this is a drastic change in behavior.
[09:07] <smb> Those entries were in my case related to USB sticks which I wanted to get mounted with different options, when I plug them in.
[09:07] <slangasek> then you should probably have them marked 'noauto' in /etc/fstab, I think
[09:07] <slangasek> or perhaps 'nobootwait'
[09:08] <slangasek> asynchronous booting is a drastic change in behavior /in general/; we have to pick /some/ policy for handling cases like this, and there's no policy that will make everyone happy
[09:08] <smb> slangasek, Likely and maybe we should add a note to the release notes (if not already there). As updates can suffer from that surprise
[09:08] <slangasek> (I thought the policy in karmic was reasonable, but apparently plenty of users did not, and were vocal about it)
[09:08] <slangasek> smb: certainly - could you file a bug on the ubuntu-release-notes project about this?
[09:08] <smb> slangasek, Yes, will do
[09:10] <pitti> smb, apw: FYI, I just binary-NEWed the lucid kernel
[09:10] <smb> pitti, Thanks, I'll relay to apw when he gets in
[09:17] <apw> pitti, thanks
[09:30] <dholbach> pitti: heya.... czajkowski said there were a bunch of action items missing on the burndown charts... do you know what happened?
[09:31] <dholbach> czajkowski: which spec was it?
[09:31] <pitti> dholbach: I need more details, I'm afraid; what's missing?
[09:31] <czajkowski> It's not the specs so much it's the work items missing from assigness and also the -women blueprint I think is missing
[09:32] <czajkowski> http://macaroni.ubuntu.com/~pitti/workitems/canonical-community.html
[09:32] <czajkowski> going by this page
[09:32] <czajkowski> and I know there is a blueprint on -women
[09:32] <dholbach> czajkowski: do you have an example of a spec that generally shows up but your work items are missing?
[09:33] <czajkowski> dholbach: Loco council is one example then
[09:33] <dholbach> czajkowski: do you have the link to the spec?
[09:33] <pitti> czajkowski: is the missing blueprint assigned to someone not in ~canonical-community?
[09:33] <czajkowski> blueprint is up but I'm not down under asignees neither is pope
[09:33] <dholbach> pitti: ah, it doesn't show community members?
[09:33] <czajkowski> dholbach: https://blueprints.launchpad.net/ubuntu/+spec/community-lucid-loco-council-plans
[09:37] <dholbach> czajkowski: on that spec there's just one action item for you and that turns up at least on all-ubuntu-10.04.html
[09:37] <czajkowski> dholbach: :(
[09:37] <czajkowski> wait that's right
[09:38] <pitti> dholbach: it shows community WI assignees, but not specs which aren't assigned to a member of the reports' team
[09:48] <apw> TheMuso, hey ... abuot?
[09:57] <geser> could an archive admin try syncing "libxcb" again? I need a fresh OOPS for bigjools to look why it fails
[10:00] <pitti> can do
[10:01] <pitti> geser: sync-source worked; I'll try to flush it
[10:01] <seb128> geser, sorry I meant to do that yesterday but somebody started on syncs and didn't flush the queue and I didn't want to mess with things before that was sorted
[10:02] <seb128> pitti, it's flush which oops
[10:02] <pitti> 2010-01-20 10:02:05 ERROR   Exception while processing upload /home/lp_queue/sync-queue/incoming/pitti-20100120-100158 (OOPS-1481FTPMASTER1)
[10:02] <geser> pitti: thanks
[10:31] <smb> slangasek, I really would love to file a bug, but launchpad is not in the right mood for that
[11:03] <ArneGoetje> slangasek: upload the hardy langpacks directly to the archive, or go via PPA and -proposed?
[11:04] <ArneGoetje> slangasek: or split the upload? langpacks on the cd to archive, the rest via PPA and -proposed?
[11:06] <slangasek> ArneGoetje: I don't see any reason not to go directly to the archive?
[11:10] <seb128> geser, I've synced libxcb, the issue is due to the new line in the binary list in the .changes
[11:10] <seb128> I workarounded the .changes for the sync
[11:10] <seb128> pitti, ^
[11:10] <pitti> ah, good
[11:11] <geser> seb128: that explains why e.g. mono didn't autosync too, it has also a newline in the Binary: field
[11:13] <geser> directhex, Laney : ^^ that's the reason why mono doesn't autosync
[11:13] <seb128> geser, right, I already workaround mono in the past due to such issue
[11:14] <smoser> slangasek, stock smb.conf (other than adding 'log level = 3' to global section.
[11:14] <seb128> geser, https://bugs.launchpad.net/soyuz/+bug/435316
[11:14] <Laney> is there a soyuz bug for this?
[11:14] <Laney> well anticipated
[11:14] <Laney> :)
[11:14] <seb128> ;-)
[11:14] <seb128> do you need mono to be synced?
[11:15] <seb128> I can do that now...
[11:15] <Laney> I think that requires more discussion
[11:15] <Laney> do you need any help with your ftbfs?
[11:15] <Laney> I feel bad that we didn't consider ubuntu-local packages
[11:19] <seb128> Laney, no that's ok, the build-depends list has 28 items I guess those will be fixed over time
[11:20] <seb128> I will do a check around beta time to make sure we transitionned those
[11:20] <seb128> not a priority for now
[11:21] <Laney> the ones in Debian we will take care of, but ones that aren't might not get picked up by us
[11:21] <seb128> ok, no worry
[11:21] <seb128> let's wait for you to deal with the debian one
[11:22] <tseliot> slangasek: do you think I should do an "LDCONFIG_NOTRIGGER=y ldconfig" (in a postinst script) or export and unset that variable? I'm having problems with buildds.
[11:22] <seb128> then I will run another query to check what is remaining
[11:22] <cjwatson> james_w: could you please have a look at the dpkg failure?  I'm pretty certain that the problem is that get_native_part is failing to handle the case of a .tar.bz2 native package
[11:23] <tseliot> or cjwatson ^^
[11:26] <cjwatson> tseliot: err.  surely we should fix ldconfig if it's breaking?
[11:26] <cjwatson> tseliot: or are you saying you've found a case where calling ldconfig earlier matters?
[11:26] <tseliot> cjwatson: yes, exactly: http://launchpadlibrarian.net/38095009/buildlog_ubuntu-lucid-i386.octave-ad_1.0.6-3_FAILEDTOBUILD.txt.gz
[11:27] <cjwatson> tseliot: can you explain why it matters in this case but not others?
[11:27] <tseliot> otherwise octave won't find libGL.so.1 from mesa
[11:28] <cjwatson> is it because you're changing /etc/ld.so.conf.d/ and need to update ld.so.cache?
[11:28] <tseliot> cjwatson: I guess octave doesn't use libGL.so in /usr/lib/ but relies on ldconfig at build time
[11:28] <cjwatson> that explanation doesn't convince me at all, but the one I just suggested might ;-)
[11:28] <tseliot> cjwatson: yes, that too, of course
[11:29] <cjwatson> tseliot: I think LDCONFIG_NOTRIGGER=y is OK, then, but please leave a comment that it's due to the /etc/ld.so.conf.d/ change
[11:30] <cjwatson> I see there's a comment "explicit ldconfig due to alternatives" there already, so just make that clearer
[11:30] <tseliot> cjwatson: do you mean "LDCONFIG_NOTRIGGER=y ldconfig" ?
[11:30] <cjwatson> yes
[11:30] <tseliot> ok
[11:31] <tseliot> and yes of course I'll add a comment so that my change makes sense to others
[11:33] <geser> cjwatson: the problem on the buildds is that e.g. the postinst of octave3.2 runs one of its binaries (which is linked against libGL.so.1) but as the ldconfig got delayed ld doesn't find the library yet
[11:40] <issimedia> Hi guys! :) Anyone here has experience with unixODBC development? These guys don't have a channel...
[11:41] <dpm> mdeslaur, we've noticed that there is a translation template for hamster-applet on the Karmic translations import queue on LP -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/hamster-applet/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot . Normally only translations for packages in main end up in the queue, but hamster-applet is in universe. Any idea how that could have happened?
[11:41] <dpm> (note that this is not a problem for the translations team, we'll just block the template, I'm just curious to how this could happen)
[11:42] <issimedia> I have a really strange problem with different behaviours between v2 and v3 instruction sets
[11:43] <cjwatson> geser: right, the question I wanted to get resolved is that normally ldconfig is just building a cache and it doesn't matter whether it's run early or not.  I've already worked out with tseliot why it matters here.
[11:43]  * tseliot nods
[11:52] <tseliot> cjwatson: hopefully this explanation will be enough: http://pastebin.ubuntu.com/359506/
[11:54] <cjwatson> tseliot: probably overkill :), but yes
[11:55] <tseliot> heh
[11:55] <cjwatson> I'd just have said that ldconfig needs to be run immediately when changing ld.so.conf.d
[11:55] <tseliot> cjwatson: ok, I'll be less verbose then
[12:00] <tseliot> +  # ldconfig needs to be run immediately as we're changing /etc/ld.so.conf.d/ with
[12:00] <tseliot> +  # alternatives.
[12:00] <tseliot> this should better
[12:01] <cjwatson> yeah
[12:01] <cjwatson> thanks
[12:02] <tseliot> thanks for your help
[12:12] <ArneGoetje> slangasek: ok, uploading...
[12:46] <ockham> hi, can someone help me with this error http://pastebin.com/d275a5d95
[12:46] <ockham> i'm experiencing when trying to build iulib-0.4 using pbuilder?
[12:52] <mdeslaur> dpm: no, I have no idea how that happened. That's odd.
[12:53] <dpm> mdeslaur, thanks for coming back to me. No worries, I'll ask at #launchpad
[12:57] <ockham> sry for nagging, but as i can't see any communication going on here (only logon/offs): is there anybody at all?
[13:00] <cjwatson> ockham: the huge pile of joins and quits was due to problems between some of the IRC servers on the network.
[13:02] <ockham> okay, glad there's someone. soo... can anyone help me out with this:http://pastebin.com/d275a5d95
[14:06] <mathiaz> mvo: squid-deb-proxy package: nice!
[14:10] <mvo> mathiaz: yeah :) if your squid kung fu is good, double check the config
[14:11] <ogra> is that a replacement for approx7apt-proxy and the like ?
[14:11] <ogra> *approx/apt-proxy
[14:11] <mvo> not really a replacement, more a alternative implementation based on squid
[14:12] <mathiaz> mvo: would it make sense to provide a squid-core package - so that you don't pull in a complete squid configuration?
[14:12] <mvo> but yeah, that is the goal
[14:12] <mvo> mathiaz: yes
[14:12] <ScottK> doko_: re your earlier comment about library demotions: For boost, we should be ready to have 1.38 out of the archive shortly and 1.39 is already gone.  There should be nothing to decide about demotions for boost.
[14:13] <doko_> ScottK: the question would be 1.40 or 1.41
[14:13] <ScottK> doko_: Certainly.  I think we should align to whatever Debian is using for default in Squeeze.  I wrote the boost maintainers and asked their plans, but did not hear back.
[14:14]  * ScottK is hoping they don't plan another transition
[14:25] <qense> james_w: I lost track of what bug 422536 should be. There are loads and loads of people randomly changing the status and assignee. You assigned yourself to the bug report, do you know what to it should be?
[14:26] <qense> I think there were almost ten different people with 0 or 5 karma that messed with the report
[15:19] <lamont> powerpc buildds going offline for a while
[16:05] <jjardon> Hello, anjuta can't be installed in lucid due a package conflict with devhelp, should I fille a bug about this?
[16:06] <fagan> jjardon: has it been wrong for a while?
[16:06] <fagan> Or was it an update?
[16:07] <fagan> you may have installed it before the dependencies were updated
[16:08] <jjardon> fagan, the problem is that anjuta 2.28 depends on devhelp 0.23, but devhelp 2.28 is the version available in lucid. The proper solution would be update the anjuta packages
[16:08] <jjardon> or change the actual anjuta 2.28 packages to depend on devhelp 2.28
[16:09] <fagan> jjardon: looking at lucid changes anjuta hasnt been upgraded this month so id file a bug
[16:09] <cjwatson> probably just needs a simple rebuild.
[16:09] <cjwatson> libdevhelp changed its abi
[16:09] <fagan> ah
[16:13] <jjardon> indeed, devhelp 2.28 should be packaged for karmic, as It's an official GNOME 2.28 application; don't know if this is possible now
[16:20] <barry> ScottK: just a quick ping that i pushed a new rev to the distribute merge proposal.  no rush of course
[16:20] <ScottK> barry: I haven't had any time to look at it.
[16:20] <ScottK> It's on my list though ....
[16:20] <barry> ScottK: no worries.  i just wanted to make sure you weren't waiting for more information from me.  thanks!
[16:20] <ScottK> Nope.
[16:20] <barry> cool
[16:30] <jjardon> cjwatson, should I file a bug about this?
[16:41] <slangasek> ogasawara: when you have a chance, could you point the weather report at hardy for 8.04.4?
[16:41] <ogasawara> slangasek: sure
[16:52] <milanbv> slangasek: ping
[16:52] <smoser> slangasek, would you consider upstart or mountall dependency on CONFIG_DEVTMPFS a bug (bug 510130) ? or is that simply a requirement for lucid kernels.
[17:02] <cjwatson> jjardon: it's not my field, but filing a bug for an uninstallable package is certainly reasonable, if there isn't already one filed.
[17:09] <jjardon> cjwatson, ok, done: https://bugs.launchpad.net/ubuntu/+source/anjuta/+bug/508444
[17:32] <cjwatson> jdstrand: is it a good idea to attempt to backport changes for bug 379329 to Karmic?  We elected not to do so in Debian, and the version in Karmic already has the bits that I considered safe to backport (see the changelog for 1:5.1p1-5)
[17:32] <cjwatson> jdstrand: intrepid could probably do with an update for that backport
[17:33] <jdstrand> cjwatson: well, the deal with that is that it has a CVE assigned to it, but it kept showing up on the server teams lists and they would talk about it each week, so I had to do something witht he bug to get it off their list
[17:33] <jdstrand> cjwatson: what I told them is that it is on our list, but we don't have plans to update it any time soon
[17:34] <jdstrand> cjwatson: my feeling is to not update it, but I haven't looked at it closely enough (and neither has anyone from the security team) to say for sure "yes" or "no" on whether to backport it or not
[17:35] <cjwatson> jdstrand: fair enough.  well, you have my take on it now ...
[17:35] <jdstrand> cjwatson: so, is karmic not affected any more?
[17:36] <jdstrand> cjwatson: I realize exploiting this is very difficult to exploit (which is why we haven't been jumping all over it)
[17:36] <jdstrand> that was not the best sentence...
[17:37] <cjwatson> jdstrand: it's mitigated
[17:37] <jdstrand> cjwatson: via the Ciphers?
[17:37] <milanbv> kirkland: around?
[17:38]  * jdstrand is reading the changelog now
[17:39] <cjwatson> jdstrand: no, I wasn't convinced about changing that in 5.1 (I forget exactly why)
[17:39] <jdstrand> cjwatson: if you say it is mitigated in karmic, I'll make a note in our CVE database and in the bug
[17:40] <jdstrand> cjwatson: I was unaware of the mitigation
[17:40] <cjwatson> jdstrand: the packet_disconnect on padding error change reduces the probability of attack to 2^-18, and note that this attack is destructive - if you try it on somebody and it fails, it breaks the connection anyway
[17:40]  * jdstrand nods
[17:40] <jdstrand> cool, thanks
[17:40] <cjwatson> jdstrand: so you'd have to have somebody have their ssh connection broken O(2^18) times and not complain much about it
[17:40] <jdstrand> heh
[17:41] <cjwatson> at least, such is my understanding
[17:42] <jdstrand> ah, so jaunty also has the mitigation, good
[17:42] <jdstrand> 1:5.1p1-5 has packet_disconnect(), and jaunty has 1:5.1p1-5ubuntu1
[17:43] <jdstrand> cjwatson: I'm not superkeen on updating intrepid-- it was quite hard to exploit to begin with, aiui
[17:44] <cjwatson> I don't recall what the original probability was
[17:44] <jdstrand> cjwatson: though I'm noting it in the CVE/bug
[17:44] <jdstrand> cjwatson: http://www.openssh.com/txt/cbc.adv says 2^-14
[17:44] <jdstrand> but "though we suspect this
[17:44] <jdstrand> underestimates the work required by a practical attack."
[17:45] <didrocks> jjardon: I've update anjuta to last release. Just wait for the buildd to build it. It launches correctly now locally.
[17:46] <jjardon> didrocks, great! thank you very much
[17:46] <didrocks> jjardon: y/w ;)
[17:47] <jdstrand> cjwatson: I say for now we plan on fixing it in Intrepid with the next security update
[17:48] <jdstrand> cjwatson: well, by 'fixing' I mean backporting that patch
[17:48] <jdstrand> (of course)
[17:48] <jdstrand> cjwatson: does that seem reasonable to you?
[17:50] <jdstrand> well, the 2^-14 was for the 14 bits of plaintext
[17:53] <cjwatson> jdstrand: sounds reasonable, yes
[18:00] <zul> piti: ping is there a way to ask a question in apport hook if the gtk/kde interface is not installed
[18:04] <jjardon> didrocks, I'm seeing https://launchpad.net/ubuntu/lucid/+source/anjuta and current anjuta doesnt depend on libgnome, libgnomeui, libgnomecanvas, libglade, libgnomeprint or libgnomevfs
[18:06] <didrocks> jjardon: I've just adjusted deps from diff in configure.in between previous version we got and that one. Can you opened a bug and assign it to me so that I'll look at the configure.in carefully (I mean, not diff, but from scratch again) in case someone miss it in a previous upload
[18:07] <jjardon> didrocks, ok, will do
[18:07] <didrocks> jjardon: thx :)
[18:09] <pitti> zul: hi (spelling "pitti" with two t helps :) )
[18:09] <jjardon> we are working hard to remove deprecated libraries for 2.30: Gnome packages don't depend on libgnome, libgnomeui, libglade, libgnomecanvas (only evolution), libgnomevfs, libgnomeprint
[18:10] <pitti> zul: the hooks are completely agnostic about the UI
[18:10] <pitti> zul: if you run ubuntu-bug without $DISPLAY or without -{gtk,kde} installed, it will use the CLI based frontend
[18:10] <pitti> zul: and show questions/read answers from the console
[18:10] <pitti> zul: do "DISPLAY= ubuntu-bug storage" to see how it works
[18:10] <zul> pitti: sorry about that great thanks for answering my question
[18:11] <pitti> zul: np, I just missed your question for a while
[18:11] <zul> pitti: thats ok i cant spell
[18:11] <didrocks> jjardon: I know, I don't saw it when making my diff in configure.in. I guess that was done before but didn't noticed by the uploader. That's why reviewing all deps from scratch won't hurt anyone :)
[18:13] <jjardon> didrocks, no worry, I'll check the configure.ac and report any issue. Thank you again for the update :)
[18:13] <ogasawara> slangasek: I created a separate 8.04.4 weather report - http://qa.ubuntu.com/reports/ogasawara/weatherreport-8.04.4.html
[18:14] <didrocks> jjardon: you're welcome, just open the bug as a reminder for me (I won't have the time to do it tonight)
[18:20] <jjardon> Do somebody if there is a problem whith http://people.canonical.com/~scott/daily-bootcharts/ ? ( It's not updated since 13 Jan)
[18:20] <ScottK> jjardon: Known issue.  Being worked on.
[18:24] <jjardon> ScottK, ok :) BTW, maybe helps to Desktop boot up removing some deprecated libraries: libgnomecanvas or libgnome, for example
[18:25]  * ScottK doesn't have any of those libraries on boot.
[18:25] <cody-somerville> Have libraries installed that don't get used at boot aren't going to slow down boot.
[18:25] <pitti> jjardon: Keybnz is on the other side of the planet right now, so I guess it won't be fixed this week
[18:27] <lamont> who is the current debian-installer victim^wguru?
[18:27] <jjardon> cody-somerville, the problem is that there are a lot of packafes that already don't depend on libgnome, but the package is still not update in Ubuntu: try apt-get remove libgnome2-0
[18:27] <superm1> pitti, wasn't the problem just caused by user-setup not working properly though?  new media spins with the new ubiquity/user-setup should be it?
[18:28] <cody-somerville> jjardon, Thats not going to affect boot speed unless those programs are run as a part of the boot sequence.
[18:28] <jjardon> gnome-panel and gdm, for example?
[18:29] <cjwatson> lamont: #ubuntu-installer
[18:29] <lamont> ta
[18:29] <kirkland> milanbv: am now
[18:30] <cjwatson> jjardon: run-time dependencies are calculated automatically.  Anything that depends on libgnome2-0 almost certainly actually links against it.  (The situation for build-dependencies is different.)
[18:31] <pitti> superm1: ah, I haven't booted the current desktop dailies; just tried UNE today
[18:34] <milanbv> kirkland: hi!
[18:34] <ccheney> doko_: ok will update the arm patch and upload 3.2.0~rc3 today
[18:34] <milanbv> I was wondering about the issues that appear when changing password for a user with ecryptfs
[18:35] <jjardon> cjwatson, we have to wait to packages get updated to latest versions, then. For example; libgnomeui was removed from gnome-panel in 2.29.5
[18:35] <milanbv> because from users-admin an admin is allowed to change the password without providing the old one to PAM, which breaks everything
[18:35] <jjardon> If someone interested of the actual status, take a look here: http://www.gnome.org/~fpeters/299.html
[18:35] <cjwatson> jjardon: yes, the desktop team does this routinely
[18:36] <cjwatson> fear not, we have people well on top of GNOME
[18:36] <kirkland> milanbv: hmm, right
[18:36] <kirkland> milanbv: that's been around for a while
[18:36] <milanbv> yeah
[18:36] <kirkland> milanbv: perhaps we should warn the admin if they're doing so
[18:36] <kirkland> milanbv: that they may be breaking the user's encrypted home setup
[18:36] <milanbv> I'm currently working so that you change your own password, you have to provdie the old one
[18:36] <milanbv> sure
[18:36] <cjwatson> jjardon: see e.g. http://people.canonical.com/~seb128/versions.html
[18:37] <jjardon> cjwatson, :) yeah, I suppossed that you already know
[18:37] <kirkland> milanbv: wait, huh?
[18:37] <cjwatson> we appear to have gnome-panel 2.29.5 already, for instance
[18:37] <kirkland> milanbv: changing your own password works fine
[18:37] <milanbv> but do you think there could be a kind of dialog that could run on the user's session if ecryptfs detects that the password no longer corresponds to the one you need?
[18:37] <cjwatson> <IP_ADDRESS>, rather
[18:38] <milanbv> kirkland: it works fine when using the hack which runs gnome-about-me ATM - I'd like to make this cleaner
[18:38] <kirkland> milanbv: yes, that's the recommended way to change your password
[18:38] <kirkland> milanbv: or by using 'passwd'
[18:38] <milanbv> agreed
[18:39] <milanbv> what about that kind of dialog?
[18:42] <kirkland> milanbv: it's sort of out of my hands
[18:42] <kirkland> milanbv: you'd need to convince one of our desktop or foundations guys to fix that
[18:42] <kirkland> milanbv: i hate it too, fwiw
[18:42] <milanbv> hmm
[18:43] <milanbv> kirkland: another question: do you think it's possible to do something for people who may have changed their password by force, and who use encrypted *home*?
[18:43] <milanbv> i.e. when you can't mount the home dir
[18:44] <kirkland> milanbv: sure, it's easy to fix from the command line
[18:44] <kirkland> milanbv: they just need to run ecryptfs-rewrap-passphrase
[18:44] <milanbv> :-)
[18:44] <kirkland> milanbv: supplying their old, and new passphrase
[18:44] <milanbv> I mean: automatically form GDM
[18:44] <kirkland> milanbv: and then everything works again
[18:44] <seb128> jjardon, we follow GNOME closely on updates and we have no extra lib use easy to clean
[18:44] <kirkland> milanbv: again, i have nothing to do with anything above a command line
[18:44] <milanbv> OK
[18:44] <seb128> jjardon, all the libgnome* libbonobo* need to stay there this cycle
[18:45] <kirkland> milanbv: your best bet to to talk to someone like pitti or seb128
[18:45] <milanbv> and are there plans to put the passphrase in the gnome-keyring for Private dirs?
[18:45] <kirkland> milanbv: there have been many requests to improve the graphical integration of ecryptfs
[18:45] <milanbv> that would help changing passwords
[18:45] <kirkland> milanbv: unfortunately, i'm not tasked to do that
[18:45] <milanbv> sad - I'll see that we the desktop team
[18:46] <kirkland> milanbv: gnome-keyring == graphics, again, i can't really work on that
[18:46] <milanbv> anyway, I'm planning to add an option to encrypt home dirs when creating an user in users-admin
[18:46] <superm1> pitti, well even today's current desktop dailies don't have it.  either needs a respin to pickup ubiquity 2.1.12 or wait till tomorrow
[18:46] <jjardon> seb128, only tomboy depends on libgnome, there is no 2.30 gnome package that depends on libgnome (only bindings)
[18:46] <kirkland> milanbv: that would be great
[18:46] <milanbv> quite easy actually now that I've changed our protocol
[18:46] <seb128> jjardon, we stay on evo 2.28 for lucid
[18:46] <milanbv> (much easier than that password mess ;-) )
[18:46] <seb128> jjardon, 2.30 has way too many changes for a lts
[18:47] <kirkland> milanbv:  Lucid Alpha 2 released | Archive: open | MoM no longer running, use bzr! - Outstanding merges:http://people.ubuntuwire.com/~lucas/merges.html | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[18:47] <kirkland> milanbv: whoa, sorry
[18:47] <kirkland> milanbv: https://blueprints.edge.launchpad.net/~kirkland
[18:47] <jjardon> seb128, aps, didn't know that
[18:47] <kirkland> milanbv: let me try that copy-n-paste one more time
[18:47] <kirkland> milanbv: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-ecryptfs-desktop-ui
[18:48] <milanbv> nice!
[18:48] <seb128> jjardon, you are welcome to hang on #ubuntu-desktop for desktop question btw
[18:48] <milanbv> I can see your agenda is full :-)
[18:48] <kirkland> milanbv: that's a blueprint that collects ideas about what needs to be fixed in the GUI for ecryptfs
[18:48] <seb128> jjardon, or if you are interested in desktop work being done there
[18:48] <kirkland> milanbv: i recommend that you read that, and edit the whiteboard, adding the integration features you think are still missing
[18:49] <milanbv> is mrooney working on this?
[18:50] <kirkland> milanbv: not actively, that i know of
[18:50] <kirkland> milanbv: he's been around it, from time to time, though
[18:50] <kirkland> milanbv: you might poke him, see if he's working on it actively, and offer to help, if you like
[18:50] <jcastro> mdeslaur: If I'm an upstream and I want to communicate with Ubuntu on security-type things you send me to which wiki page?
[18:50] <kirkland> milanbv: you should also poke pitti
[18:50] <milanbv> not sure I'll be able to help in that regard
[18:51] <kirkland> milanbv: i think pitti was in favor of this work; he just didn't have any people to dedicate to this
[18:51] <milanbv> I'd just like to know what way I should choose
[18:51] <kirkland> milanbv: my hands are currently full doing ubuntu cloud work, and i have not much time for ecryptfs, and certainly not the desktop aspects of it
[18:51] <kirkland> milanbv: i need to run now, thanks for the feedback, patches would be welcome ;-)
[18:51] <milanbv> sure, I can understand that
[18:51] <milanbv> I'm quite busy too, actually :-)
[18:52] <milanbv> the encrypt home option is all I can do
[18:52] <tjaalton> there's a problem in the new sssd package where some deps have been trimmed from the libs, causing undefined symbols in some components
[18:52] <mdeslaur> jcastro: https://wiki.ubuntu.com/SecurityTeam/Contacts
[18:52] <tjaalton> but is it done on purpose by the default behaviour or what
[18:52] <jcastro> thanks!
[18:53] <mdeslaur> np
[18:57] <tjaalton> so I get this http://pastebin.ubuntu.com/359674/
[18:57] <tjaalton> instead of this http://sssd.pastebin.com/d4f2806e3
[19:13] <cjwatson> kirkland: bug 414986 - what crept back in, exactly?  open-iscsi-utils still seems to be a separate package with the expected contents
[19:14] <cjwatson> kirkland: and failures from ln are still ignored
[19:32] <tkamppeter> pitti, hi
[19:34] <tkamppeter> pitti, can you close http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550575? It is fixed by my new cpdftocps filter which I have introduced in 1.4.2-1 on Nov 17, 2009.
[20:40] <doko_> ccheney: did you verify that it did build?
[21:07] <ccheney> doko_: yea just did the build with the modified patch
[21:07] <ccheney> doko_: it worked on amd64 at least
[21:08] <ccheney> doko_: after looking at what changed closer it looks like the patch i made was the correct change in any case
[21:08] <doko_> ccheney: yes, but not on arm
[21:08] <ccheney> doko_: it seems they factored out part of the makefile into a generic makefile and i checked both for the Os vs O2 part
[21:09] <ccheney> doko_: it might not work even with the change that is true, rene completely disabled arm support for Debian but he didn't have this patch so not sure if this was the only issue he had
[21:09] <doko_> ccheney: I did check that it will fail. please wait with the upload
[21:10]  * ccheney isn't even really supposed to be messing with OOo, still have a huge backlog of work to do on firefox :-\
[21:10] <ccheney> doko_: the O2 still fails?
[21:10] <doko_> thumb fails
[21:11] <ccheney> doko_: ok
[21:11]  * ccheney will commit the new patch to ooo-build and wait to upload then
[21:14] <ccheney> ok pushed the change to master
[21:20] <slangasek> ogasawara: thanks; is it possible to point the weather report at hardy-proposed, in addition to hardy-updates?
[21:21] <slangasek> smoser: CONFIG_DEVTMPFS> dunno, would have to defer to Keybuk
[21:21] <slangasek> milanbv: pong
[21:22] <ogasawara> slangasek: yup, was going to ask that as I noticed the iso diff's were a little off
[21:28] <milanbv> slangasek: yeah, it was about PAM and changing passwords
[21:29] <milanbv> basically, and user is not allowed to change passwords for other users, even when providing their old password
[21:29] <milanbv> which means admins are forced to break encrypted home dirs if they want to change password for their users
[21:30] <smoser> can someone able please send my message onto -devel mailing list
[21:30] <smoser> https://lists.ubuntu.com/mailman/confirm/ubuntu-devel/fa61297872ac220b04d71ba0899e336257f2c3ae
[21:30] <milanbv> so I'm not sure what we can do about it - maybe nothing...
[21:30] <smoser> and if they can at the same time whitelist me, that'd be nice
[21:31] <smoser> i promise not to send any messages about acai
[21:33] <smoser> whoops. i realize that link was just for me. never mind all.
[21:34] <geser> was there some general hickup on the buildds recently? as I see some build logs where dpkg failed at unpacking the downloaded deb, e.g. http://launchpadlibrarian.net/38062888/buildlog_ubuntu-lucid-i386.mono-addins_0.4-6_FAILEDTOBUILD.txt.gz
[21:34] <slangasek> milanbv: well, that's not a PAM issue; it's an application-level decision not to allow changing passwords for other users
[21:34] <milanbv> sure, that's why I'm wondering about users-admin
[21:34] <ccheney> doko_: so you tested on arm with rc2 plus updated thumb patch?
[21:35] <ccheney> doko_: because with rc2 the thumb patch wasn't applied by default
[21:35] <slangasek> milanbv: and the encrypted home dirs shouldn't end up broken, it should only mean the user has to type two passwords...
[21:35] <milanbv> would there be a way to force PAM to accept the old password, even when root calls pam_chauthtok()?
[21:35] <slangasek> milanbv: doesn't users-admin just call the 'passwd' command?
[21:35] <doko_> ccheney: yes, which is a mistake
[21:35] <milanbv> ATM no
[21:35] <milanbv> in a few days, yes
[21:35] <slangasek> how does users-admin interface with PAM?
[21:36] <milanbv> but that doesn't solve the case of *other* users
[21:36] <milanbv> in Karmic, passwords are changed using chpasswd via the backends
[21:36] <slangasek> ah
[21:36] <milanbv> and for current user, via gnome-about-me
[21:37] <ccheney> doko_: so its failing in a different manner in the same area when using O2 then I guess?
[21:38] <milanbv> slangasek: what I would be interested in is a way for the privileged backends to give PAM the old password when we have it
[21:38] <doko_> ccheney: I'm currently test building, the build didn"t finish yet
[21:38] <slangasek> milanbv: pam_ecryptfs should always prompt for it when it doesn't have it; that's a per-module decision
[21:38] <milanbv> that way, admins would be able to change passwords for other users, e.g. asking them their old password (home context)
[21:39] <milanbv> you mean that pam_chauthtok() will always ask for it?
[21:40] <ccheney> doko_: ok no problem
[21:40] <slangasek> milanbv: pam_chauthtok doesn't ask for anything, the individual modules do all the prompting
[21:40] <ccheney> doko_: i committed my updates to ooo-build and ubuntu bzr
[21:40] <slangasek> so pam_ecryptfs has the opportunity to insist on getting a copy of the old password
[21:41] <milanbv> hmm, so that would be a good solution - always provide PAM with the password, except if admins don't want to provide it
[21:42] <slangasek> oh, are you not passing the prompts through to the user?
[21:42] <slangasek> PAM isn't designed for non-interactive use; if you have a UI, you ought to be passing the prompts through
[21:43] <milanbv> yeah, but there's D-Bus in between ;-)
[21:43] <milanbv> pretty complex
[21:43]  * slangasek shrugs. :)
[21:43] <milanbv> that's really messy
[21:44] <milanbv> but AFAIK you can make PAM work non-interactively
[21:44] <milanbv> I've code for that
[21:44] <slangasek> you can use PAM non-interactively and pretend it works :P
[21:44] <milanbv> why wouldn't it work?
[21:44] <milanbv> as long as I have everything it may need?
[21:45] <slangasek> PAM is not designed for non-interactive use, and if you use it that way you're going to have to apply a heuristic to the text prompt from the PAM module to figure out if it's asking for an old or new password
[21:46] <milanbv> have a look at the madness at http://git.gnome.org/browse/gnome-control-center/tree/capplets/about-me/gnome-about-me-password.c
[21:46] <milanbv> just to make passwd work from a GUI :-p
[21:46] <slangasek> (and you'll have to make sure PAM is called with LC_MESSAGES=C, because modules can localize their user prompts...)
[21:46] <milanbv> that's not better
[21:46] <milanbv> localize? they only pass me PAM_ECHO_ON/OFF()
[21:47] <slangasek> er
[21:47] <slangasek> no, there's a text string accompanying that
[21:47] <slangasek> :)
[21:48] <milanbv> maybe that's why it doesn't work
[21:48] <milanbv> the examples I found are maybe too simple
[21:48] <milanbv> so what do you think?
[21:48] <milanbv> I need to change passwords on the privileged side because I'm not allowed to do so as a normal user
[21:49] <milanbv> so I need D-Bus, thus no interactive conversation...
[21:49] <slangasek> I think if you want this to work reliably instead of repeatedly hunting corner cases, you want to make sure you can pass the text of the PAM prompts through to the user
[21:49] <milanbv> but that wouldn't be ideal either
[21:49] <milanbv> what do you want to do in a GUI with PAM prompts?
[21:49] <slangasek> have the user answer them?
[21:49] <milanbv> we don't want strange questions with custom entries...
[21:50] <milanbv> we need a defined set of entries all visible at once
[21:50] <slangasek> PAM isn't guaranteed to give you that
[21:50] <milanbv> and then send to PAM what we have - we can't provide more than old and new password, anyway
[21:51] <milanbv> hey, we're only supporting standard schemes, obviously
[21:51] <milanbv> people can't expect a password management dialog will handle their strange setup
[21:51] <slangasek> as I said, if you prompt for the old and new passwords up front, you have to use a heuristic on the text string to figure out which one to give in response to which prompt
[21:52] <slangasek> why shouldn't they expect that?
[21:52] <chrisccoulson> milanbv - have you had a look at what the gnome-screensaver lock dialog does with the text from PAM?
[21:52] <chrisccoulson> it has some bits in for handling various prompts
[21:52] <milanbv> could be interesting
[21:52] <milanbv> is that different from gnome-about-me?
[21:53] <chrisccoulson> milanbv - i'm not familiar with how gnome-about-me works
[21:53] <chrisccoulson> but i vaguely know how gnome-screensaver works
[21:54] <chrisccoulson> also, the GDM greeter will probably contain similar logic too
[21:54] <chrisccoulson> although i haven't checked that
[21:54]  * milanbv is looking at that file
[21:55] <milanbv> doesn't seem really nicer than toying with passwd directly
[21:55] <slangasek> milanbv: ecryptfs is precisely one of these "strange setups" - I can't even guarantee you which password PAM will prompt for *first* (old vs. new) in that case
[21:55] <milanbv> PAM is eveil
[21:55] <milanbv> evil
[21:56] <milanbv> if that's such a mess, I guess I'm going to keep the changes to the minimum
[21:56] <milanbv> i.e. only use passwd for current user
[21:56] <milanbv> and use chpasswd on the backends for others
[21:56] <milanbv> but that's not perfect
[21:57] <milanbv> > msg != NULL && g_str_has_prefix (msg, _("Password:")
[21:57] <chrisccoulson> milanbv - i don't know what the answer is, i'm afraid ;)
[21:57] <milanbv> what a joke we need such tricks :-)
[21:59] <milanbv> so even in your dreams there isn't an optimal solution?
[22:00] <milanbv> the fallback we have is that gnome-keyring should be able to ask for old and new password when it detects that it cannot decrypt the login keyring anymore...
[22:09] <slangasek> milanbv: the optimal solution *is to pass PAM's questions through to the user*...
[22:10] <milanbv> but that's mad from a UI design POV
[22:10] <milanbv> no UI does that!
[22:11] <milanbv> imagine a series of entries created on the fly, with obscure questions we can't even predict
[22:11] <slangasek> "no UI" - like GDM, or gnome-screensaver?
[22:12] <milanbv> they don't change passwords...
[22:12] <slangasek> GDM will
[22:12] <milanbv> only one entry
[22:12] <slangasek> (or should)
[22:12] <milanbv> it will?
[22:12] <milanbv> have people thought about this already?
[22:12] <slangasek> "only one entry" - nope, GDM has to be able to handle two-factor auth
[22:13] <milanbv> when does that happen?
[22:13] <slangasek> what do you mean?
[22:14] <milanbv> what's the second factor? :-)
[22:14] <slangasek> whatever the admin has configured?
[22:15] <milanbv> like the name of his dog? :-p
[22:16] <mathiaz> slangasek: hi - if a pakcage shows up on the " Source and binary demotions to universe " in component-mismatches.txt, is there anything else that needs to be done to demote it to universe?
[22:19] <slangasek> mathiaz: nope, it'll get processed by an archive admin at some point
[22:20] <mathiaz> slangasek: great - thanks.
[22:22] <slangasek> milanbv: you can see GDM's (thorough) PAM support in daemon/gdm-session-worker.c
[22:22] <milanbv> thanks - I'm currently reading the GUI part
[22:23] <milanbv> I'd like to see how all this is handled over D-BUs
[22:23] <milanbv> anyway, that's not something that will happen in users-admin, because the whole model of the gnome-system-tools is based on one bug D-Bus method called "set"
[22:23] <slangasek> for d-bus, I guess the server needs to generate a unique ID to attach to the message
[22:23] <milanbv> everything else is not supported, and is a pain to implement :-)
[22:24] <slangasek> hmm
[22:24] <milanbv> that would be a nice task for the new accounts-dialog that mclasen started
[22:25] <milanbv> hmm, I see how this works now
[22:26] <milanbv> directly transmitting questions to the GUI
[22:26] <chrisccoulson> milanbv - i was just going to ask you if you had seen mclasen's work
[22:26] <milanbv> that's not perfect since we can't e.g. tell the user the confirmation is not correct in real time - need to wait for PAM to fail
[22:27] <milanbv> chrisccoulson: yeah
[22:27] <milanbv> actually I've already got in touch with him
[22:27] <milanbv> I think users-admin is virtually dead
[22:27] <milanbv> I'm quite happy with the improvements I could bring in, but the general model is not very flexible for what we need
[22:28] <milanbv> (PAM is an example)
[22:28] <chrisccoulson> the new tool looks quite nice. it would be good to put some effort in there i think, and make sure it doesn't have all the issues we have currently
[22:28] <milanbv> yeah, for Lucid+1 I guess I'll switch to it
[22:29] <milanbv> but many common issues with users-admin are now fixed
[22:29] <milanbv> it's just that error reporting is still zero :-p
[22:31] <milanbv> anyway it was nice to see the problems we currently have with liboobs/users-admin
[22:31] <milanbv> that will help designing a tool that suits our needs
[22:38] <barry> anybody here with deep python-gobject and/or gdb-fu that might want to look into bug 503727 with me?
[23:35] <mathiaz> slangasek: hi - is there a reason by xubuntu.lucid/ has a server-ship seed?
[23:36] <cjwatson> mathiaz: because it was branched from ubuntu long long ago
[23:36] <mathiaz> cjwatson: ok - I'm looking at demoting elinks
[23:37] <mathiaz> cjwatson: and the xubuntu.lucid server-ship still has elinks in them
[23:37] <mathiaz> cjwatson: should I delete elinks from there as well?
[23:40] <cjwatson> mathiaz: probably
[23:40] <mathiaz> cjwatson: should I completely remove the server-ship seed for xubuntu.lucid?
[23:41] <cjwatson> if you like


[01:03] <mup> Bug #1752460 opened: [2.3.0-6434] mDNS observer problems <MAAS:New> <https://launchpad.net/bugs/1752460>
[02:35] <jvwjgames> Hello
[02:35] <jvwjgames> 'Is it possible to use maas without DHCP
[03:41] <jvwjgames> can anyone help
[04:19] <mup> Bug #1728909 changed: Maas Settings tab encountered an issue <MAAS:Expired> <https://launchpad.net/bugs/1728909>
[14:40] <mup> Bug #1651280 changed: [2.1] MAAS fails to add SSH keys if server has duplicate keys <MAAS:Fix Released by ack> <MAAS 2.3:Fix Committed by ack> <https://launchpad.net/bugs/1651280>
[14:40] <mup> Bug #1735025 changed: [2.3] Unhandled error in deferred when tgt fails to start <MAAS:Fix Released by ltrager> <MAAS 2.3:Fix Committed by ltrager> <https://launchpad.net/bugs/1735025>
[14:40] <mup> Bug #1742195 changed: [2.4 UI] Pod details page doesn't show Pod nodes anymore <MAAS:Fix Released by blake-rouse> <https://launchpad.net/bugs/1742195>
[14:46] <mup> Bug #1651280 opened: [2.1] MAAS fails to add SSH keys if server has duplicate keys <MAAS:Fix Released by ack> <MAAS 2.3:Fix Committed by ack> <https://launchpad.net/bugs/1651280>
[14:46] <mup> Bug #1735025 opened: [2.3] Unhandled error in deferred when tgt fails to start <MAAS:Fix Released by ltrager> <MAAS 2.3:Fix Committed by ltrager> <https://launchpad.net/bugs/1735025>
[14:46] <mup> Bug #1742195 opened: [2.4 UI] Pod details page doesn't show Pod nodes anymore <MAAS:Fix Released by blake-rouse> <https://launchpad.net/bugs/1742195>
[14:49] <mup> Bug # changed: 1453878, 1651280, 1672947, 1719640, 1735025, 1742195
[15:43] <mup> Bug #1752616 opened: [2.4, snap] In the snap, chrony fails to start when running in the default user and while setting time <MAAS:In Progress by andreserl> <https://launchpad.net/bugs/1752616>
[15:46] <mup> Bug #1752616 changed: [2.4, snap] In the snap, chrony fails to start when running in the default user and while setting time <MAAS:In Progress by andreserl> <https://launchpad.net/bugs/1752616>
[15:49] <mup> Bug #1752616 opened: [2.4, snap] In the snap, chrony fails to start when running in the default user and while setting time <MAAS:In Progress by andreserl> <https://launchpad.net/bugs/1752616>
[18:45] <jtcressy> Is it considered out-of-support for a MaaS server to manage virtual machines? I cant get a single machine to deploy. It always fails and never gives any log output. Others cant be having this much trouble, right?
[18:45] <jtcressy> using virsh for power control and it's actually working. Nodes are comissioned without any problems.
[18:46] <jtcressy> I want to use MaaS in a production environment, but not if it means it's never going to actually work consistently.
[18:47] <mup> Bug #1752687 opened: Quanta D52B-1U unable to PXE-boot in EFI mode <hwcert-server> <MAAS:New> <https://launchpad.net/bugs/1752687>
[18:57] <jtcressy> Some of the same issues I'm having, with the same desired goal of installing openstack, about a year ago unanswered. https://askubuntu.com/questions/897675/maas-node-memory-detection-problem
[18:58] <jtcressy> *big thumbs up*   ... yeah i'm going to ditch maas and figure out something else.
[19:03] <ahasenack> I use vms all the time with maas
[21:07] <_bladernr_> does maas still write to /var/log/maas.log?
[21:07] <_bladernr_> or are regiond.log and rackd.log (and others) the only active logs now?
[21:08] <_bladernr_> roaksoax, ^^
[22:09] <kurt_> I see it writes to /var/log/maas/maas.log - there is other logging there too
[23:05] <mup> Bug #1752737 opened: [2.3.0-6434] mDNS observer problems <MAAS:Triaged> <https://launchpad.net/bugs/1752737>


[16:13] <pleia2> yay, Ubuntu Hour this week in SF! Not sure if I can make it since I have an 8AM flight the next morning, but I'll see what I can do http://loco.ubuntu.com/events/ubuntu-california/3804-ubuntu-hour-san-francisco/
[19:20] <hangar18> hey lyz you around?
[19:54] <grantbow> pleia2: yay :-)
[20:04] <hangar18> i'm around if anyone needs me


[06:30] <dholbach> good morning
[06:31] <smartboyhw> Thinking why suddenly a lot of channels are marked red, and it's dholbach! Good afternoon dholbach
[06:31] <dholbach> :)
[14:30] <jcastro> hey mhall119
[14:30] <jcastro> explain this gui toolkit to me
[14:30] <jcastro> did some guy just go and make this?
[14:43] <mhall119> jcastro: ?
[14:59] <popey> mhall119: lucas
[15:03] <mhall119> oh
[15:04] <mhall119> jcastro: he's a community guy who wanted an easy way to show off the look of all the SDK components
[15:12] <jcastro> man
[15:12] <jcastro> that is so badass
[15:52] <mhall119> yeah, Lucas is a fantastic contributor, did you know he's been contributing designs to a bunch of the core apps, and did a lot of icons for the showdown entries too?
[15:53] <jcastro> no
[15:53] <jcastro> I just became a huge fanboy though
[15:53] <smartboyhw> That's what I call "talented":P
[16:32] <dholbach> all right, I'm calling it a day - see you all tomorrow!
[16:32] <nigelb> g'nite dholbach!
[16:32] <dholbach> night nigelb
[16:43] <pleia2> just as a heads up - it would be nice to see more CC nominees before we close the nomination period tomorrow, so if there is anyone anyone here can think of it would be great to see a nomination come in :) http://fridge.ubuntu.com/2013/09/19/community-council-call-for-nominations/
[16:44] <pleia2> we have no one working on apps or phone stuff
[16:44] <pleia2> surely there are great people there, and in juju too
[16:59] <bkerensa> nigelb: :) Are you ok?
[16:59] <pleia2> I spoke to him earlier, so I think the hangover didn't kill him ;)
[16:59] <pleia2> unless it was zombie nigelb I spoke with
[17:00] <pleia2> hard to tell on a monday morning
[17:01] <bkerensa> pleia2: amazing he was drinking when I went to bed :)
[17:08] <mhall119> I bet even a zombi nigelb is happy and energetic
[17:08] <pleia2> no wonder he made a coffee in the evening suggestion
[17:09] <bkerensa> https://twitter.com/mfinkle/status/387084824411774976/photo/1
[17:09] <bkerensa> pleia2:  ^ that happened and to Miley Cyrus - We cant stop
[17:09] <pleia2> I think someone put something in your alcohol
[17:10] <bkerensa> pleia2: nah I think we just all had too much :)
[17:10] <pleia2> hehe
[17:10] <bkerensa> it was like UDS x1000
[17:10] <bkerensa> and I feel much worse too
[17:11] <bkerensa> pleia2: some how I released doc in the midst of it all
[17:11] <bkerensa> :)
[17:13] <pleia2> hooray
[19:11] <nigelb> bkerensa: I'm alive.
[19:11] <nigelb> That was good alcohol, so I'm ok.
[19:12] <nigelb> pleia2: Yes, you see my plan. However, a fellow webdev is taking me out for drinks tonight. That's where I'll stay sober.
[19:12] <nigelb> mhall119: Right now, I'm like "fooooooooooood"
[19:12] <nigelb> Headed to Pinterest office once I find out where it is.
[19:15] <elfy> out the door and turn left
[19:16] <elfy> it'll either be a short way or a long one :)
[19:16] <mhall119> wait, does the Pintrest office actually *have* the food you see on Pintrest?
[19:16] <mhall119> I didn't think that stuff was possible
[19:23] <pleia2> nigelb: haha
[19:45] <mhall119> jose: it's been one of those days :)
[19:46]  * mhall119 needs a nap
[19:47] <jose> :P
[21:41] <nigelb> mhall119: It doesn't. But it was just as good ;)
[21:46] <pleia2> nigelb: ah, pintrest is over by zynga, I never knew :)
[21:46] <pleia2> (I knew they were around, just can't keep track)
[21:46] <nigelb> pleia2: ah,I didn't know zynga was just over there :)
[21:47] <pleia2> there was a shooting there a couple months ago, fun times
[21:47] <nigelb> oh joy.
[21:48]  * mhall119 can't help but thing that birds were involved


[06:41] <Calis_Moonelf> Hello folks! I'm looking for a bit of help upgrading from 16.04 LTS to 16.10.
[06:42] <ObrienDave> what would you like to know?
[06:45] <Calis_Moonelf> I think I understand the process well enough, but software updater tells me that there is only an update available to Ubuntu Studio 16.10. I installed the packages for Studio some time back. I don't want to thrash my Mate....will this kill it?
[06:45] <ObrienDave> no
[06:46] <Calis_Moonelf> Just wanted to check, I'm really liking Mate. Thanks!
[06:46] <ubuntu-mate> Hello
[06:46] <ObrienDave> all *buntus share the same core system. they only differ in DEs and installed packages
[06:46] <ubuntu-mate> i am mow in live ubuntu mate
[06:46] <ubuntu-mate> where is the first moderator
[06:47] <ObrienDave> which mod was that?
[06:47] <Calis_Moonelf> as I thought, I just didn't want to have to contend with another DE. Thanks, again.
[06:48] <ObrienDave> sure, you can select which DE you like at the logon screen
[07:22] <ubuntu-mate> who is the first moderator
[07:27] <ObrienDave> there is no FIRST moderator. to whom were you cpeaking with?
[07:27] <ObrienDave> *speaking
[08:02] <randall> this irc is totally un moderated, let the anarchy flow
[08:03] <ObrienDave> glwt
[08:05] <randall> but seriosly there was a guy a few weeks ago that pasted a huge log file into the chat, we really could've used a mod for flood control
[08:05] <ObrienDave> all you have to do is call them using !ops
[08:06] <randall> really?
[10:22] <kurt_> hallo grüße euch allen ein frohes neues jahr
[10:23] <NeoNamo> hello
[10:23] <kurt_> was kann ich machen das bei ubuntu mate 16.10 mein dvd laufwerk wekannt wird
[10:24] <kurt_> dank
[10:24] <NeoNamo> I'm afraid I can't understand or speak German :(
[10:25] <SuperEngineer> !DE
[10:25] <SuperEngineer> ;-)
[10:25] <NeoNamo> oh :)
[10:25] <NeoNamo> !ES
[10:25] <NeoNamo> !CS
[10:25] <NeoNamo> oops
[10:25] <NeoNamo> !CA *
[10:25] <NeoNamo> !CA
[10:25] <SuperEngineer> !ENOUGH
[10:25] <NeoNamo> !CAT
[10:26] <NeoNamo> ok, sorry :P
[10:26] <SuperEngineer> ;-)
[10:26] <NeoNamo> just checking if there was Catalan
[10:28] <SuperEngineer> NeoNamo: somewhere on the interwebs there is a list of ubotto thingies [but can't remeber atm]
[10:28] <NeoNamo> somewhere over the web? :3
[10:29] <SuperEngineer> http://ubottu.com/factoids.cgi  might be it
[10:30] <SuperEngineer> ubottu> Sorry, I don't know anything about ENOUGH
[10:30] <SuperEngineer> lol
[10:31] <NeoNamo> xD
[14:38] <nik__> I have Ubuntu 15.10 and can not change screen resolution ?
[14:38] <nik__> mate
[14:39] <nik__> ubuntu mate...
[14:39] <nik__> I am bulgarian...
[14:41] <nik__> can I get answer?
[14:43] <nik__> I'm beginers
[14:43] <nik__> & I am retire-78 ysold?!
[14:44] <nik__> X-chat
[14:59] <pandabeertje> hi there.. I just keep getting this error when i try to update:  Fout:13 http://ppa.launchpad.net/gerardpuig/ppa/ubuntu yakkety/main i386 Packages
[14:59] <pandabeertje>   404  Not Found
[14:59] <pandabeertje> how can i fix that
[18:54] <hetii> hey :)
[18:55] <hetii> I just connect samsung tv 40" instead my regular screen, and under mate the fonts looks so ugly that i`m almost not able to read it
[18:55] <hetii> I use gtx 1070 as output and not sure if the issue is with drivers or mate settings
[18:57] <hetii> btw under windows 10 all is fine.
[19:11] <randall> have you tried changing the fonts? the resolution?
[20:41] <gunnarniels_> Hello, how do you log out of ubuntu mate 16.10?
[20:42] <gunnarniels_> I only see options to suspend, restart, or shutdown the machine?
[20:43] <Akuli> gunnarniels_, i think there's a separate log out button wherever you got the shutdown dialog from
[20:44] <gunnarniels_> Akuli: ah, missed it. under the system tab. Thank you
[21:55] <jack-the_ripper> hey im trying to install another linux distro along with mate and i cant get it to install
[21:55] <sinewav> are you talking dual-boot?
[21:55] <sinewav> What other distro and why, may I ask?
[21:56] <jack-the_ripper> kali linux for bug bounty
[21:56] <sinewav> It might be better to install it as a virtual machine instead
[21:56] <sinewav> Are you familiar with virtual machines?
[21:56] <jack-the_ripper> yep
[21:56] <jack-the_ripper> i didnt know they had an image for kali
[21:57] <jack-the_ripper> is on there site
[21:57] <sinewav> well you can install a virtual machine using an ISO, just like anything else.
[21:57] <sinewav> I use Oracle's VirtualBox
[21:57] <sinewav> Just download the Kali ISO and create a machine with VirtualBox
[21:58] <sinewav> Otherwise you'll have to make a partition on your machine and install Kali to that.
[21:58] <jack-the_ripper> o i thought it had to be a actual vm image
[21:58] <sinewav> NOPE!
[21:59] <sinewav> If you have never used VirtualBox, you may have to change a setting in your BIOS/UEFI to allow a hypervisor to access the hardware. Or something like that.
[22:00] <jack-the_ripper> theres no option in the unetbootin that says to install
[22:00] <jack-the_ripper> so i cant even start the operation
[22:00] <sinewav> Usually a setting that says "allow virtualization" or similar.
[22:00] <jack-the_ripper> but ill just use it as vm
[22:01] <sinewav> yeah, VMs are the way to go. I never dual boot anymore. Haven't in years.
[22:01] <jack-the_ripper> they have windows vm?
[22:01] <jack-the_ripper> and coulkd you play games in it
[22:03] <sinewav> Sure. I have a windows VM on my ubuntu-mate machine I use to work with some proprietary software and files. You could probably play games, but you might run into some graphics problems.
[22:06] <jack-the_ripper> is there a way to make the screen bigger '
[22:06] <garandil_> jack-the_ripper: install guest additions
[22:07] <jack-the_ripper> guest additions?
[22:07] <garandil_> KVM, vBox, VMware... all supply guest additions, i.e better drivers etc.
[22:09] <jack-the_ripper> install from command line?
[22:09] <garandil_> usually supplied in an iso you can mount through the hypervisor
[22:18] <jack-the_ripper> is that guest session going to help make the screen bigger?
[22:18] <garandil_> They usually allow more than 1024x768 resolution in the VM
[22:25] <jack-the_ripper> one of my games says its not installed?
[22:25] <jack-the_ripper> i had it installed?
[22:36] <jack-the_ripper> nvm was an update
[22:37] <jack-the_ripper> when i went to install that vm it said grub error
[22:41] <chatter> hey guys
[22:41] <chatter> allah is doing
[22:41] <chatter> sun is not doing allah is doing
[22:41] <chatter> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
[22:46] <randall> not you again
[22:47] <randall> that zealot found the open mw irc last week


[08:28] <oSoMoN> Saviq, Mirv: ever seen regressions similar to those at http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#webbrowser-app (qmluitests.sh failing at the dh_auto_configure phase, Checking for module 'unity-shell-application=14')?
[08:28] <oSoMoN> Mirv, and would re-running those tests make them pass (i.e. was it a transient failure)?
[08:29] <Mirv> oSoMoN: not familiar, maybe there's a real unity8 FTBFS in yakkety at the moment?
[08:29] <Saviq> oSoMoN, Mirv, needs a re-run with --all-proposed
[08:30] <Saviq> because that's old unity8 trying to test with new unity-api
[08:30] <Mirv> no such switch in that UI
[08:30] <Saviq> Mirv, oSoMoN, no - need to ask pitti for that atm
[08:30] <Saviq> unless Mirv you got access to snakefruit https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests
[08:34] <oSoMoN> Mirv, in the meantime, would you mind merging https://requests.ci-train.ubuntu.com/#/ticket/1387 on my behalf? this will allow rebuilding other webbrowser-app silos
[08:40]  * Saviq thinks we should ignore britney results for yakkety for now
[08:41] <Mirv> sorry, on hangout
[08:41] <Mirv> Saviq: no snakefruit
[08:42] <Mirv> oSoMoN: ok
[08:42] <oSoMoN> thanks
[08:42] <Mirv> there might be yakkety Qt build problem now anyway because qtchooser got autosynced 3h ago... I uploaded new qtbase 30mins ago
[08:43] <Saviq> pstolowski, ↑↑ Mirv's already on it
[08:43] <pstolowski> Saviq, great, thanks
[08:44] <Saviq> jibel, I think we need to ignore yakkety britney results for a few days, wdyt?
[08:47] <jibel> Saviq, for which packages?
[08:48] <Saviq> jibel, well, for one, unity8 won't pass for anyone in yakkety until a new unity8 goes into the release pocket
[08:51] <jibel> Saviq, okay then, it seems we don't have a choice
[08:52] <Saviq> jibel, https://requests.ci-train.ubuntu.com/#/silo/58 is failed because it's uninstallable on yakkety https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-058/excuses.html until http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-shell releases, and that one is waiting for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api
[08:57] <Saviq> jibel, so yeah, I'd be obliged if you made silo 58 QA Ready - it's only failed because of the dependency chain
[09:09] <Mirv> sil2100: so in short they moved a couple of files from qtbase-opensource-src and qt4-x11 to qtchooser. so now absolutely about everything trying to install Qt 5 or Qt 4 fails due to conflicts since only qtchooser was updated in Ubuntu...
[09:09] <Mirv> new qtbase https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-17ubuntu1 and qt4-x11 are building in archives https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.7+dfsg-5ubuntu5
[09:09] <sil2100> :|
[09:16] <jin_> davmor2: buddy, thank you
[09:16] <jin_> davmor2: I know the ticket is under testing by you
[09:16] <jin_> davmor2: anything please let me know, cool!
[09:16] <davmor2> jin_: yeap I took it as I knew what it was about :)
[09:16] <davmor2> jin_: will do
[10:25] <Saviq> sil2100, can you please ♻ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api - it's failed because of Qt being uninstallable but that should be good again now https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-17ubuntu1
[10:26] <Saviq> hmm or not yet
[10:26] <Saviq> need to wait for the arm builds to complete
[10:46] <sil2100> Saviq: oh, ok
[10:48] <Saviq> sil2100, you could rerun them now - amd64 and i386 of qt is published now
[11:24] <Mirv> Qt always surprises like today. You start with a plan in the morning and then it gets completely thrown out in favor of something that needs to be done first :)
[11:25] <Mirv> on the plus side I managed do to necessary SIM card roulette with my secondary operator and can now officially devote my krilling for development while the necessary SIMs are in my turbo
[11:25] <pstolowski> Mirv, any idea about libubuntu-location-service-dev in Y? https://launchpadlibrarian.net/261192027/buildlog_ubuntu-yakkety-s390x.unity-scopes-shell_0.5.7+16.10.20160523.2-0ubuntu1_BUILDING.txt.gz
[11:33] <Saviq> pstolowski, at least x86 installs build-dep for u-s-shell fine now
[11:33] <Saviq> pstolowski, so I'd say that's temporary
[11:36] <Mirv> pstolowski: tested in container, I don't see problem installing it even with yakkety-proposed
[11:37] <Saviq> Mirv, could be a temporary s390x issue
[11:38] <Saviq> sil2100, did you ♻ http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api after all?
[11:38] <Mirv> Saviq: oh, s390x, yes I don't have container for s390x :)
[11:39] <Mirv> Saviq: pstolowski: uh oh it's waiting for s390x platform-api https://launchpad.net/ubuntu/+source/location-service/3.0.0+16.04.20160405-0ubuntu4/+build/9658051
[11:39] <sil2100> Saviq: now I did, didn't see your last message ;)
[11:39] <Mirv> but why, err, it's even trying https://launchpad.net/ubuntu/+source/platform-api/3.0.1+16.10.20160523-0ubuntu1
[11:40] <Saviq> Mirv, but papi is waiting for location-service...
[11:40] <Saviq> https://launchpad.net/ubuntu/+source/platform-api/3.0.1+16.10.20160523-0ubuntu1/+build/9791743
[11:40] <Saviq> sounds like a circular build dep :-S
[11:41] <Mirv> lol
[11:41] <Mirv> sil2100: ^
[11:41]  * sil2100 stopped caring about yakkety after being so busy with vivid and xenial
[11:41] <Mirv> oh, what a mess, with the Qt thrown into it too
[11:41] <sil2100> uh oh
[11:42] <sil2100> Ok, just kidding, will look into that later
[11:42] <Mirv> sil2100: I can feel you :)
[11:42] <Saviq> sil2100, thanks, let's see if that completes - we needed a --all-proposed before, not sure if that sticks
[11:43] <Mirv> Saviq: well the platform-api FTBFS also in general on all archs, so it would not even help if there wasn't a circular dependency to location...
[11:43] <Mirv> https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.7+16.04.20160505-0ubuntu2
[11:43] <Saviq> Mirv, https://launchpad.net/ubuntu/+source/platform-api/3.0.1+16.10.20160523-0ubuntu1 hmm?
[11:44] <Mirv> Saviq: oh right sorry I meant the scopes ftbfs
[11:44] <Saviq> right, that's new
[11:44] <Mirv> "scope-uri.cpp:35:46: error: ‘vector’ does not name a type" etc
[11:45]  * Saviq pings api folk
[11:49] <pstolowski> Mirv, on it
[11:50] <pstolowski> Mirv, ok to add the fix to existing silo?
[11:53] <Saviq> pstolowski, depending on the fix we could maybe skip QA and unblock things quicker
[11:53] <pstolowski> Saviq, ack
[12:06] <Mirv> pstolowski: sure
[12:06] <Mirv> whatever suites best
[12:07] <pstolowski> Mirv, Saviq her eyou go https://code.launchpad.net/~stolowski/unity-scopes-shell/fix-yakkety-ftbfs/+merge/295459 , build here in Y chroot
[12:07] <pstolowski> Mirv, it's a trivial fix.. so yeah let's land directly
[12:08] <Saviq> ok /me pops a silo
[12:08] <pstolowski> k
[12:09] <Saviq> jibel, agreed ↑↑ can skip QA?
[12:09] <Saviq> it's just new gcc being stricter with includes
[12:11] <kenvandine> anyone know why xenial packages are going to the unapproved queue instead of the overlay PPA?
[12:12] <jibel> Saviq, +1
[12:27] <Saviq> kenvandine, because you didn't trio-ify your silo?
[12:28] <Saviq> kenvandine, if you had a vivid+xenial silo, it will be a SRU since last week
[12:28] <kenvandine> ah... i had read that
[12:29] <kenvandine> but didn't catch the part about it being an SRU
[12:29] <abeato> sil2100, hey, tarballs generated in the usual places: http://people.canonical.com/~abeato/avila/ubuntu/device_frieza-20160523.0.tar.xz and http://people.canonical.com/~abeato/avila/cooler/ubuntu/device_cooler-20160523.0.tar.xz
[12:29] <kenvandine> i manually copied it to yakkety
[12:36] <Mirv> kenvandine: what I've done with the remaining dual silos is copy-package the built packages manually to overlay and then the xenial package without binaries to yakkety
[12:37] <kenvandine> Mirv, that's what i did
[12:37] <kenvandine> i just hadn't realized the xenial build would be an SRU, must have missed that part
[12:37] <kenvandine> Mirv, i took care of it :)
[12:37] <kenvandine> thx
[12:41] <Mirv> kenvandine: oh right and you'll need manual merge reportedly
[12:44] <kenvandine> Mirv, done :)
[12:45] <kenvandine> ugh... yakkety fails to build because of depends
[12:50] <Mirv> kenvandine: yes, qtchooser autosynced from Debian in the morning since it doesn't have Ubuntu changes. I've had a "couple" of pings related to that :) I think your armhf might just have missed the publishing of qtbase armhf https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.5.1+dfsg-17ubuntu1
[12:50] <Mirv> it moved files around so everything Qt 5 or Qt 4 broke
[12:51] <Mirv> because of conflicting files when installing build deps
[12:53] <kenvandine> Mirv, ah...
[12:53] <kenvandine> Mirv, so if i wait a bit and retry i might be good?
[12:53] <Saviq> Mirv, kenvandine, it's still not in proposed for armhf indeed
[12:53] <Saviq>  libqt5core5a | 5.5.1+dfsg-16ubuntu11  | yakkety-proposed | armhf
[12:53] <Saviq>  libqt5core5a | 5.5.1+dfsg-17ubuntu1   | yakkety-proposed | amd64, arm64, i386, powerpc, ppc64el, s390x
[12:56] <Mirv> kenvandine: yes
[13:18] <Mirv> publisher seems slowish, the armhf is still not published while the build was finished >1h ago
[13:30] <rvr> kdub: ping
[13:30] <kdub> hello rvr
[13:30] <rvr> kdub: Hi
[13:30] <rvr> kdub: I'm testing silo 69
[13:31] <rvr> kdub: There is a problem in frieza. When I launch a X11 app on desktop mode, it only starts when I click the window to set it to full screen mode.
[13:31] <rvr> It only happens with the silo installed
[13:32] <kdub> rvr, thanks, sounds like something to fix
[13:33] <jhodapp> sil2100, ping
[13:33] <rvr> kdub: I am failing the silo. Ping me the silo is ready for QA again.
[13:33] <kdub> rvr, sure
[13:33] <Saviq> kenvandine, Mirv libqt5core5a | 5.5.1+dfsg-17ubuntu1   | yakkety-proposed | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
[13:34] <kenvandine> Saviq, thx!
[13:34] <Saviq> mterry, can you please retry this build https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-077/+build/9792770
[13:34] <mterry> Saviq, done
[13:37] <Mirv> Saviq: \o/
[13:37] <Saviq> mterry, thanks, that will get us just a bit closer to unblocking things (currently waiting to see results from a unity8 --all-proposed run in excuses, should make all the unity8 reds out)
[13:37] <Saviq> s/out/go away/
[14:04]  * Saviq cries a little
[14:32] <Trevinho> sil2100: hey, since we're stuck in landing unity in yakkety because a s390x build-dep (upstart is  not built there), can we just proceed with a forced landing and then we'll remove unity7 from that arch at all?
[14:32] <Trevinho> robru: (maybe) too ^
[14:40] <sil2100> Trevinho: hey! We could consider force-merging that if needed, but from what I heard foundations wanted to have unity7 available on the s390x just-in-case
[14:40] <sil2100> But it was a few weeks ago when I heard this
[14:40] <Trevinho> sil2100: we were discussing this in -devel with seb128 and pitti, and they agree on removing it
[14:42] <Saviq> trainguards, help please https://requests.ci-train.ubuntu.com/#/ticket/1450 ?
[14:43] <tedg> Saviq: Not sure, but is it because your s390 buildx are depwait?
[14:43] <Saviq> tedg, it was always depwait on s390x
[14:44] <tedg> Ah, okay.
[14:44]  * tedg will be curious to see what that error is
[14:44] <sil2100> hmm
[14:44] <Saviq> it's as if something uploaded to yakkety that the train didn't expect?
[14:45] <Saviq> but it would've complained when building, wouldn't it
[14:45] <Saviq> I could IGNORE_VERSIONDESTINATION
[14:46] <Saviq> just not sure I wanna without understanding what the issue is
[14:46] <sil2100> Strange, I don't see any uploads
[14:46] <sil2100> Let me just check the queue real quick
[14:47] <sil2100> No, nothing, hm
[14:48] <sil2100> I guess let's ignore dest version, since this seems to be not an issue
[14:48] <Saviq> sil2100, will publish with ↑↑ then
[14:48] <sil2100> I suppose it's the train getting confused
[14:48] <sil2100> Saviq: ACK
[14:49] <Saviq> success
[14:49] <Saviq> oh well
[14:57] <robru> Saviq: sil2100: tedg: manual upload: https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.7+16.04.20160505-0ubuntu2
[14:57] <Saviq> robru, yeah, but shouldn't the train complain when it was building?
[14:57] <Saviq> robru, that upload is from last week, and that silo was only created a few hours ago
[14:58] <robru> Saviq: yeah, it should, hm
[15:00] <robru> Saviq: anyway that upload is not on trunk, so that's definitely what it was complaining about.
[15:00] <Saviq> robru, ack
[15:01] <dobey> Saviq: doesn't matter how old a manual upload is, if nobody ever noticed and merged the changes back to trunk
[15:01] <Saviq> dobey, sure, I just meant that I would've "expected" that error if the upload happened between build and publish
[15:02] <robru> sil2100: I'm not sure where you were looking that you didn't see your own upload and realize that's what it was complaining about
[15:02] <Saviq> so basically the train should've complained when building (as it usually did in that case) that there's a version in Ubuntu that isn't in trunk
[15:02] <Saviq> robru, is it looking at proposed?
[15:02] <robru> Saviq: yes
[15:03] <robru> Saviq: yeah I'll have to look why it didn't complain during build, but the publish check is correct
[15:03] <dobey> it never complains during build
[15:04] <robru> dobey: no there's definitely a "dest version missing from changelog"check that fails, which is why there's a force option.
[15:04] <dobey> the source packages build and upload to the PPA just fine. but then when a build fails, or the builds are completed, the status will say something about dest version missing from trunk, iirc
[15:06] <dobey> at least, that's my experience
[15:07] <sil2100> robru: but it was there when the silo got built, so it's not an unexpected upload IMO
[15:07] <sil2100> robru: unexpected upload for me is a situation when you built a silo and then someone uploaded
[15:07] <robru> sil2100: well your wrong.
[15:07] <sil2100> robru: in this case, the silo was assigned today, and built today
[15:08] <sil2100> Probably, I don't give a fuck
[15:08] <dobey> any upload that happened outside the silo is an "unexpected upload" i would think
[15:08] <robru> sil2100: and the build did not include the last upload in proposed
[15:08] <robru> Yes
[15:13] <Saviq> robru, it could mention which upload was unexpected, would be easier to grok what's wrong
[15:13] <robru> Saviq: file a bug please
[15:18] <Saviq> will do
[15:37] <Saviq> grr grr how long before it shows up in proposed :/
[15:49] <robru> Saviq: 29 minutes ago
[15:53] <Saviq> robru, where?
[15:53] <Saviq> now it's there
[15:54] <robru> Yeah
[16:07] <Saviq> gaah
[16:07] <Saviq> Mirv,  qdbus : Depends: qtchooser (>= 55-gc9562a1-1~) but it is not going to be installed
[16:08] <Saviq>  qtchooser : Breaks: libqtcore4 (< 4:4.8.7+dfsg-7~) but 4:4.8.7+dfsg-5ubuntu5 is to be installed
[16:23] <Mirv> Saviq: yep, qt4 is not fixed yet, including qdbus (vs qdbus-qt5)
[16:24] <Mirv> Saviq: so this is the real deal for Qt 4 users https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.7+dfsg-7ubuntu1
[16:24] <Mirv> shouldn't everything be ported to Qt 5 already though, Qt 4 reached end of support in December :)
[16:52] <dobey> mterry, sil2100, kenvandine: can someone restart this test please? https://autopkgtest.ubuntu.com/request.cgi?release=vivid&arch=amd64&package=unity8&trigger=pay-service%2F15.10%2B15.04.20160520-0ubuntu1&ppa=ci-train-ppa-service%2Fstable-phone-overlay&ppa=ci-train-ppa-service%2Flanding-056
[16:53] <sil2100> dobey: on it
[16:53] <dobey> thanks
[16:53] <sil2100> hm, I get an error
[16:53] <sil2100> Oh, ok
[16:53] <sil2100> Now it's good
[16:55] <dobey> great, thanks
[16:55] <dobey> oh good, at least autopkgtests queue isn't completely insane any more
[16:56] <dobey> i wonder how much longer the molasses migration of yakkety is going to take
[17:48] <sil2100> Mirv: looking into why platform-api is not migrating from -proposed right now... looks like the dependency chain somewhere seems to lead to qtchooser
[17:49] <sil2100> Mirv: it's just a first look of mine, but it looks like it's not any of our actual newly pushed touch stuff, just the Qt madness you mentioned earlier
[17:56] <jhodapp> sil2100, does this require an SRU? https://requests.ci-train.ubuntu.com/#/ticket/1436
[17:56] <sil2100> jhodapp: let me take a look
[17:57] <sil2100> hmm, I guess it could but, considering that all our touch packages for xenial are in the xenial-overlay anyway, I guess that would be the best place to start
[17:58] <sil2100> jhodapp: just in case, wouldn't this change be good to land to all 3 series?
[17:59] <sil2100> jhodapp: like, it looks like it would work on vivid as well
[17:59] <sil2100> jhodapp: you wouldn't have to create a separate xenial trunk then, just include it in a normal triple landing silo
[17:59] <sil2100> jhodapp: that way the same change would be in xenial and also in the latest devel series, so yakkety
[18:00] <jhodapp> sil2100, it will merge the package change for all 3 (merged into trunk for qtubuntu-media) but it wouldn't only copy over the package for xenial
[18:01] <sil2100> Wouldn't it be better to keep all distros in sync?
[18:01] <jhodapp> sil2100, but it fails to compile on vivid and yakkety
[18:01] <sil2100> hm
[18:01] <jhodapp> for arm64
[18:01] <jhodapp> no platform-api packages for arm64 on those
[18:01] <sil2100> Well, it was always failing for arm64 on vivid, right?
[18:01] <jhodapp> yup
[18:01] <sil2100> So releasing this change would have no effect
[18:02] <sil2100> But at least all 3 would be in sync
[18:02] <jhodapp> so just keep it triple landing then?
[18:02] <sil2100> Yeah, I would say that's the best option, we don't want to get confused by different versions on different serieses
[18:02] <davmor2> sil2100: ha you foolish mortal ;)
[18:02] <jhodapp> sil2100, cool, I'll do that and then hand over to QA
[18:02] <jhodapp> davmor2, does your team have an arm64 device to test on?
[18:02] <sil2100> jhodapp: thanks! It should be basically a no-op for QA so not much trouble
[18:03] <jhodapp> yeah
[18:03] <davmor2> sil2100: I have every faith in jhodapp ability to break the universe in new and interesting ways ;)
[18:03] <davmor2> jhodapp: nope
[18:03] <jhodapp> davmor2, thanks for believing in me!
[18:03] <sil2100> ;)
[18:03] <jhodapp> davmor2, alright
[19:39] <Mirv> sil2100: ok. Qt should be fixed now but all migration is now intertwined so lots of autopkgtest kicking would probably needed. I'm on my Meizu now so I won't check at this hour but I will in the morning.
[19:45] <sil2100> Mirv: thanks!
[19:45] <sil2100> Excellent :)