[03:33] <aeoril> darkxst arrrggghhh!  All this time I have been working on the icon bug with plain old Ubuntu, not Ubuntu-Gnome!  Anyway, I got everything to boot and ran a compiled Ubiquity install from the live CD in a VM, but the info icon was fine *before* I included the fix in my compile for regular Ubuntu - now I have to do it all for Ubuntu-Gnome!  Teach me to read the bug report better ... I'll
[03:33] <aeoril> work on it again tomorrow.  Made good progress on learning the ropes, though
[03:35] <aeoril> darkxst note that I had to do "sudo apt-get -f install" to fix up the ubiquity dependencies after "dpkg -i ..." for the compiled .deb files
[03:35] <aeoril> (but it seemed to work fine)
[04:36] <aeoril> darkxst can I use a ubiquity build done with debuild/sbuild on an Ubuntu machine (the .debs) to test out ubiquity on an Ubuntu-Gnome livecd?  Or do I have to do the build originally on a Ubuntu-Gnome machine?
[04:37] <ScottK> aeoril: You can do it on an Ubuntu machine.
[04:38] <aeoril> ScottK ok, thanks - then my problem now is trivial.  What a relief! How does sbuild determine "flavours" for builds?  Or does that only matter if you are building the livecd for the "flavour?"
[04:38] <ScottK> It determines if the package build dependencies in debian/control have been satisfied.
[04:39] <ScottK> Ubiquity is built with different front ends sometimes for different flavors, but it's all one build from the same source.
[04:45] <aeoril> ScottK speaking of dependencies, when I ran "bzr debuild" to get the source package built before I could run sbuild, it could not find some dependencies.  However, I looked in debian/control and the missing packages seemed to be there (pyflakes, pep8 and d-i, I think - something like that).  I had to manually install them before I could do the build.  I wonder why?  When I made a recipe
[04:45] <aeoril> on launchpad, it failed as well because of dependency issues.
[04:47] <aeoril> "bzr debuild -S" actually ...
[04:58] <ScottK> debuild won't install build-deps.  You have to do that yourself.
[05:03] <aeoril> ScottK I wonder why the recipe failed though?
[05:03] <aeoril> (I could paste the log)
[05:03] <ScottK> No idea.  I've never done anything with LP recipes.
[05:03] <aeoril> well, just point you to it ...
[05:03] <aeoril> oh, ok
[05:04] <aeoril> ScottK do many people use recipes at all?
[05:04] <ScottK> I've known of a few.
[05:04] <ScottK> I think they are mainly used by upstreams trying to do things like nightly builds on LP.
[05:04] <aeoril> oh, ok - do most people use sbuild?
[05:06] <aeoril> darn, my VM seems to have locked up installing dependencies using "sudo apt-get -f install"
[05:06] <aeoril> (for the ubiquity I compiled)
[05:39] <pitti> stgraber: ah yes, that must be an ancient bug which nobody saw so far as we install it by default
[05:40] <pitti> Good morning
[05:43] <pitti> sarnold, stgraber, dobey: bug 777224 sounds like ^, I duped/triaged it
[05:47] <pitti> stgraber: ureadahead does work on an SSD in principle, it just doesn't make much sense
[05:52] <pitti> bdmurray: hm, ubuntu-release-upgrader build failure, why does it build-dep on itself?
[05:52]  * pitti removes the -proposed version
[05:54] <pitti> I removed all of its  binaries from -proposed
[06:23] <Mirv> pitti: I rekicked khtml autopkgtest, it showed as "Test in progress" since yesterday while it was not
[06:24] <pitti> *nod*
[06:50] <darkxst> aeoril, the only real difference in ubiquity between Ubuntu and Ubuntu GNOME is the slideshow, the icon issue will be the same for both
[07:06] <pitti> bdmurray: FYI, https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:15.04.9 built now, after cleaning up the previous botched binaries
[07:42] <dholbach> good morning
[07:49] <ari-tczew> hello dholbach
[07:50] <dholbach> hi ari-tczew
[08:20] <LocutusOfBorg1> hi folks!
[08:20] <LocutusOfBorg1> do you have any advice for bug 1424769 ?
[08:20] <LocutusOfBorg1> the problem is that it needs a rebuild
[08:39] <mlankhorst> LocutusOfBorg1: in general vm's should use the unrenamed stack, and trusty 14.04.1
[08:40] <mlankhorst> you can still use the lts-utopic kernel if you want
[08:40] <LocutusOfBorg1> mlankhorst, I'm the virtualbox maintainer lol
[08:40] <LocutusOfBorg1> I'm asking how to (if possible) fix the "bug"
[08:40] <mlankhorst> create a virtualbox-x11-lts-utopic :P
[08:41] <LocutusOfBorg1> yes, I was thinking about something like that, how to trigger the rebuild with the -lts-utopic packages?
[08:41] <LocutusOfBorg1> and how can I be sure users will pick up it?
[08:41] <LocutusOfBorg1> seems a big trouble
[08:41] <mlankhorst> they won't pick it up, you need to create a rename for the -lts-utopic package
[08:42] <mlankhorst> you need to create a separate virtualbox-lts-utopic package
[08:42] <LocutusOfBorg1> and maintain it ;)
[08:42] <mlankhorst> or advise users to stay on 14.04.1, they can upgrade the kernel if they want
[08:42] <mlankhorst> the problem is that newer xorg may break the x11 api, so you can't just rebuild the old virtualbox against a newer xorg in some cases
[08:54] <LocutusOfBorg1> I guess I need (in case of breakage) to patch the code like I do with the kernel
[08:54] <LocutusOfBorg1> can I quote the irc conversation or can you please just reply there?
[08:55] <mlankhorst> sure quote if you want
[09:00] <ricotz> LocutusOfBorg1, hi, what is up with the vbox driver inclusion in vivid kernel?
[09:01] <LocutusOfBorg1> ricotz, sorry I don't get the question
[09:02] <ricotz> LocutusOfBorg1, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-vivid.git;a=commit;h=8180b966d33c0551503f6cd362d573c69d9b7d80
[09:03] <LocutusOfBorg1> thanks I saw on -devel mail list something about it, apw what is that supposed to do?
[09:04] <LocutusOfBorg1> to avoid the dkms package?
[09:04] <ricotz> meaning how are you dealing with that? (regardless the network module is failing here)
[09:04] <ricotz> tainting the kernel by default doesnt seem a good idea
[09:06] <LocutusOfBorg1> nobody ping'd me about it, so I presume if they want to integrate the driver in the kernel, they will also patch vbox to stop producing the dkms package
[09:06] <LocutusOfBorg1> I guess once the kernel team finished the work somebody will ping me about it
[09:06] <LocutusOfBorg1> (I hope at least)
[09:06] <ricotz> right, and of course slipping out the ddx as well
[09:06] <ricotz> which i would assume mlankhorst heard of ;)
[09:07] <ricotz> *even "splitting out"
[09:07] <ricotz> LocutusOfBorg1, i see, i was hoping you are already aware of it
[09:08] <LocutusOfBorg1> (un)fortunately I really try to avoid the kernel stuff, and the dkms is already making me loose so much time in rebuild and patch vbox at each kernel-lts update
[09:09] <LocutusOfBorg1> I have a new breakage with kernel 4.0rc1
[09:11] <ricotz> not much of a surprise ;)
[09:15] <apw> LocutusOfBorg1, that is to do with vagrant images, to have a single image which works on all clouds you need those drivers without a compiler
[09:16] <apw> LocutusOfBorg1, those are exactly the same as the dkms module and built literally from it
[09:20] <LocutusOfBorg1> so apw should I change something on virtualbox side? I presume not
[09:20] <apw> LocutusOfBorg1, no i don't think we would want anything to change with how that works no as things are
[09:21] <LocutusOfBorg1> ;) wonderful! thanks
[09:22] <apw> LocutusOfBorg1, things seem to be working rather well with it to be honest, and i assume that is all your hard work
[09:22] <LocutusOfBorg1> s/hard/cherry-picks/ :)
[09:22] <apw> :) that is the kind of work i like
[09:26] <LocutusOfBorg1> I hope one day I'll be an ubuntu developer, to stop bothering people about my cherry-picks
[09:27] <apw> LocutusOfBorg1, sponsors you mean?  do feel free to poke me with them
[09:28] <LocutusOfBorg1> fortunately dholbach is a nice sponsor ;)
[09:29] <LocutusOfBorg1> (and I started my debian NM process, so I hope to become a DD soon and start soonafter the ubuntu process)
[09:29] <mlankhorst> DD can take a while :P
[09:30] <tjaalton> yep..
[09:33] <LocutusOfBorg1> if my AM doesn't send me the questions I presume yes ;)
[09:34] <pitti> sarnold, dobey, stgraber: ureadahead -19 uploaded with the upgrade fix
[09:34] <mlankhorst> took me half a year even after AM was done
[09:37] <LocutusOfBorg1> ough
[09:37] <LocutusOfBorg1> so you think I have any chance to start also the ubuntu one?
[09:39] <Riddell> ricotz: bdmurray: looks like there were still problems from the pyflakes tidying I did in release-upgrader, I'll fix and do an upload
[09:41] <apw> LocutusOfBorg1, there is no reason you can't start ubuntu in parallel imo
[09:42] <LocutusOfBorg1> I guess I need some advocate, right?I guess there isn't anything for Debian Maintainers, even if in DM list
[09:47] <apw> LocutusOfBorg1, normally you work with a sponsor or two for a bit, and they then recommend whne you should go for rights for yourself, mostly when you annoy them by being right all the time
[09:52] <mlankhorst> what if they start uploading without checking? :P
[09:52] <xnox> mlankhorst: then i will notice that.
[09:54] <LocutusOfBorg1> thanks
[10:09] <flexiondotorg> infinity, Are you available?
[10:51] <flexiondotorg> cjwatson, Can I pick your brains for a sec?
[10:52] <cjwatson> flexiondotorg: Better to just ask rather than asking to ask
[10:53] <flexiondotorg> cjwatson, There are some new packages in the official Ubuntu MATE images.
[10:53] <flexiondotorg> cjwatson, I'd like to try an understand how they've been pulled in.
[10:54] <flexiondotorg> For example, xterm is included. 'aptitude why' tell mes it is required 'xorg'
[10:54] <flexiondotorg> xorg says is can be satisfied by 'xterm | x-terminal-emulator'
[10:54] <flexiondotorg> mate-terminal provides x-terminal-emulator.
[10:55] <darkxst> flexiondotorg, they only work with tasks
[10:55] <flexiondotorg> What only work with tasks?
[10:55] <darkxst> 'xterm | x-terminal-emulator'
[10:55] <flexiondotorg> So the livefs is not built using tasks?
[10:56] <cjwatson> It is built using tasks
[10:56] <cjwatson> germinate output is better than aptitude why for investigating this stuff
[10:57] <flexiondotorg> cjwatson, I've read your comment about blacklisting.
[10:57] <flexiondotorg> cjwatson, Does blakclisting actually do anything?
[10:57] <cjwatson> No
[10:57] <cjwatson> I mean only in very subtle ways that you should not attempt to use
[10:58] <flexiondotorg> cjwatson, Can you elaborate a little?
[10:58] <cjwatson> You can read germinate(1) in which I elaborated
[10:58] <darkxst> flexiondotorg, you should really be fixing the deps that cause problems
[10:58] <flexiondotorg> cjwatson, OK.
[10:59] <darkxst> hacks, will just break again sometime
[10:59] <cjwatson> They probably won't even work to start with :)
[10:59] <cjwatson> Anyway let me actually investigate please
[10:59] <cjwatson> So your problem here is that you're attempting to use your "core" seed to provide things that are needed by the desktop-common seed
[11:00] <cjwatson> Such as mate-terminal, which is in ubuntu-mate.vivid/core, but satisfies a dependency of xorg which is in platform.vivid/desktop-common
[11:00] <cjwatson> But germinate works seed by seed from the inside out
[11:01] <flexiondotorg> cjwatson, Ah. So I should fold core into desktop to resolve this?
[11:01] <cjwatson> No
[11:01] <cjwatson> That won't make the slightest difference
[11:01] <cjwatson> Can you give me a few minutes please?
[11:01] <flexiondotorg> cjwatson, Sure.
[11:03] <cjwatson> There's something very confusing going on here
[11:07] <cjwatson> flexiondotorg: I don't know yet whether this is connected, but why does your cloudtop seed declare the exact same Task-* headers as desktop?  That isn't legitimate and can only cause confusion.
[11:07] <flexiondotorg> cjwatson, I'll just take a peek...
[11:07] <cjwatson> flexiondotorg: It should surely at least declare that it generates a different task name with a different key package and description.
[11:08] <flexiondotorg> cjwatson, Yes, that is an error.
[11:45] <flexiondotorg> cjwatson, I am more than happy to make some changes to the seeds.
[11:46] <flexiondotorg> cjwatson, Or are you still looking at the Ubuntu MATE seeds?
[11:51] <cjwatson> flexiondotorg: I'm still working on it, pdb on germinate is slow
[11:51] <flexiondotorg> cjwatson, Thanks very much for helping.
[11:52] <cjwatson> flexiondotorg: ah, here we go, I see the problem
[11:53] <cjwatson> flexiondotorg: so mate-terminal is only in core indirectly, rather than being seeded explicitly: it's a dependency of mate-desktop-environment-core
[11:53] <flexiondotorg> cjwatson, Ah.
[11:53] <cjwatson> flexiondotorg: when germinate is processing desktop-common and encounters xorg Depends: xterm | x-terminal-emulator, it does look through "nearby" seeds to find something it can promote to satisfy that, for preference
[11:53] <flexiondotorg> Understood.
[11:53] <cjwatson> flexiondotorg: but it only looks through directly-seeded entries (this is sort of analogous to some similar behaviour in apt)
[11:54] <cjwatson> flexiondotorg: adding an explicit entry for mate-terminal to your core seed fixes this
[11:54] <flexiondotorg> cjwatson, OK.
[11:54] <cjwatson> so I suggest you do that, and fix up the cloudtop seed headers
[11:54] <flexiondotorg> cjwatson, What is the authoritative bzr repository for Ubuntu MATE seeds now that Ubuntu MATE is official?
[11:55] <flexiondotorg> cjwatson, Do I also need to submit a new meta package for upload?
[11:55] <cjwatson> flexiondotorg: hasn't changed, lp:~ubuntu-mate-dev/ubuntu-seeds/ubuntu-mate.vivid
[11:55] <flexiondotorg> If I change the seeds.
[11:55] <cjwatson> flexiondotorg: in general you should do that reasonably frequently, although I believe that it happens not to be necessary in this case
[11:56] <flexiondotorg> cjwatson, I'll make those changes now.
[11:56] <cjwatson> just changing the seeds and waiting a bit should be enough to fix the Task fields in the archive, which should be sufficient here
[11:56] <flexiondotorg> cjwatson, We'd like to target PowerPC for Ubuntu MATE 15.04. My merge proposal include PowerPC. What needs to be done to enable PowerPC images?
[11:56] <cjwatson> (because apt will mark all the packages with matching Task fields for installation and only then attempt to fix any broken dependencies, and by that point mate-terminal will be marked for installation so it won't consider xterm | x-terminal-emulator as broken)
[11:59] <cjwatson> flexiondotorg: http://bazaar.launchpad.net/~ubuntu-cdimage/ubuntu-cdimage/mainline/revision/1499, done now
[11:59] <flexiondotorg> cjwatson, Thanks!
[12:02] <strikov> Hi guys. Should this be theoretically possible to run daily 15.04 inside virtualbox? I just pulled the latest bits from cdimage.ubuntu.com but display is broken with and without 3d acceleration enabled in vbox. Display is broken == pixels of different colors fill the screen, resolution is very low (300x200 or something). Does it make sense to try older
[12:02] <strikov> images or just forget about vbox?
[12:03] <flexiondotorg> cjwatson, I've pushed those seed changes.
[12:05] <flexiondotorg> cjwatson, I've also noticed that some packages are being pulled in a 'recommends' even though I believe I've requested recommends should not be followed.
[12:08] <cjwatson> flexiondotorg: Not following Recommends is usually a recipe for pain.  Are you sure?
[12:08] <cjwatson> flexiondotorg: Some of the lightweight flavours do it, but it seems a bit odd for MATE.
[12:09] <flexiondotorg> cjwatson, Well, if recommends are followed I ended up with most of Unity and GNOME3 being pulled in.
[12:09] <cjwatson> And you can't fix the recommends to avoid that?
[12:09] <flexiondotorg> cjwatson, Well, I could but that might break Ubuntu proper.
[12:09] <cjwatson> We can make livecd-rootfs handle this if necessary (it needs more than just the seed configuration), but I'd like to make sure there's no plausible alternative.
[12:10] <flexiondotorg> cjwatson, Are you saying that currently the livefs will follow recommends, regardless of my seed headers?
[12:10] <cjwatson> Yes.
[12:10] <flexiondotorg> cjwatson, OK. Then this is interesting.
[12:11] <cjwatson> Also, "feature no-follow-recommends" in STRUCTURE doesn't actually work yet, although this is a germinate bug IMO.  It'll need " * Feature: no-follow-recommends" in at least some individual seeds too (probably core, desktop, cloudtop).  Compare lubuntu.
[12:11] <flexiondotorg> cjwatson, In which case there are only a few packages being pulled in that Ubuntu MATE really doesn't need.
[12:11] <flexiondotorg> cjwatson, I did follow what lubuntu did.
[12:11] <cjwatson> No, you didn't.
[12:12] <cjwatson> Or at least not successfully. :-)
[12:12] <cjwatson> <cjwatson@amber ~/src/ubuntu/seeds/lubuntu.vivid>$ grep follow-recommends *
[12:12] <cjwatson> STRUCTURE:feature no-follow-recommends
[12:12] <cjwatson> core: * Feature: no-follow-recommends
[12:12] <cjwatson> desktop: * Feature: no-follow-recommends
[12:12] <cjwatson> <cjwatson@amber ~/src/ubuntu/seeds/ubuntu-mate.vivid>$ grep follow-recommends *
[12:12] <cjwatson> STRUCTURE:feature no-follow-recommends
[12:13] <cjwatson> flexiondotorg: BTW there is no need to remove packages not yet in the official archive from your seeds, if you intend them to be in the official archive in the nearish future.
[12:13] <flexiondotorg> cjwatson, That is the hope but the upstream Debian team are super busy so it may not happen.
[12:28] <flexiondotorg> cjwatson, I've pushed the no-follow-recommends changes.
[12:30] <cjwatson> flexiondotorg: Ah, I see that livecd-rootfs in fact already has the necessary --no-install-recommends code.
[12:30] <cjwatson> So this may be enough.
[12:31] <flexiondotorg> cjwatson, Should I revent my change to the seeds?
[12:31] <cjwatson> flexiondotorg: No, I mean that this may be enough in combination with your seed change.
[12:31] <cjwatson> Don't revert it.
[12:31] <aeoril> darkxst no, the icon issue does not appear to happen in Ubuntu.  Witness:  http://i.imgur.com/rI96eJP.png It does in Ubuntu-Gnome, however.  Witness: http://i.imgur.com/QTyVJ1W.png
[12:33] <flexiondotorg> cjwatson, OK
[13:13] <mlankhorst> I uploaded a package to debian-experimental, but it's stuck in the NEW queue there, can I sync this package to ubuntu somehow?
[13:14] <mitya57> mlankhorst: unfortunately no
[13:15] <mlankhorst> meh I'll just upload 0ubuntu1 for now then
[14:04] <aeoril> darkxst this is the new icon for gnome info, I guess:  http://i.imgur.com/MbotQ24.png  A lightbulb?  That seems odd ...
[14:08] <aeoril> darkxst looks like that is correct:  http://commons.wikimedia.org/wiki/GNOME_Desktop_icons#mediaviewer/File:Gnome-dialog-information.svg
[14:25] <flexiondotorg> Laney, regarding debdiffs for GTK2 in Trusty etc. Do you want complete debdiffs which debian/changelog updated?
[14:56] <Laney> flexiondotorg: that's easiest
[14:56] <flexiondotorg> Laney, Thanks.
[15:02] <cyphermox> flexiondotorg: did you get my message yesterday about mate-tweak missing an upstream branch for 3.4.4 ?
[15:02] <flexiondotorg> cyphermox, No, I missed that.
[15:02] <flexiondotorg> cyphermox, Morning BTW 😃
[15:02] <cyphermox> makes it a little hard to build ;)
[15:02] <cyphermox> morning ;)
[15:03] <flexiondotorg> cyphermox, Crap http://status.bitbucket.org/
[15:03] <flexiondotorg> cyphermox, When they are back I'll make sure the build is tagged.
[15:03] <cyphermox> ok
[15:12] <jfmcarreira> heyyy guys
[15:12] <jfmcarreira> can anyone guide me on how to build nightly package for a personal app
[15:12] <jfmcarreira> i would like them to be compatible with lauchpad
[15:26] <flexiondotorg> cyphermox, I see a tarball for mate-tweak 3.4.4 here - https://bitbucket.org/flexiondotorg/mate-tweak/get/3.4.4.tar.gz
[15:26] <flexiondotorg> cyphermox, Upstrem releases are tagged, not branched.
[15:26] <flexiondotorg> Only the 'debian/' folder is in a branch.
[15:27] <cyphermox> ok, but I meant on the git branch on alioth -- you should have a upstream/3.4.4 import of the upstream git version 3.4.4
[15:29] <caribou> bdmurray: Hi, any chance of having the CUPS SRU completed for trusty ? it got released to -updates only for Utopic
[15:30] <caribou> bdmurray: LP: #1352809
[15:37] <stgraber> utlemming: ubuntu-cloud packageset created
[15:37] <utlemming> stgraber: most appreciated :), thank you
[15:41] <flexiondotorg> cyphermox, The upstream branch is 'ubuntu/15.04' and just includes the 'debian' folder.
[15:41] <flexiondotorg> cyphermox, The upstream branch on alioth that is.
[15:41] <cyphermox> flexiondotorg: right, you also need an upstream/3.4.4 branch if you want to release 3.4.4, otherwise we can stick to 3.4.3
[15:42] <cyphermox> anyway, for releasing with git-buildpackage
[15:42] <flexiondotorg> cyphermox, Only the 'debian' folder comes from git. The upstream project is a tarball.
[15:42] <flexiondotorg> cyphermox, Excuse my ignorance.
[15:43] <flexiondotorg> sunweaver, Can you interpret for me? ^^^^^^^
[15:43] <cyphermox> there's also an import of the upstream code so that there tarball can be generated :)
[15:55] <bdmurray> caribou: bug 1386241 needs verification too.
[15:56] <bdmurray> caribou: oh, no sru-report is wrong. Okay, I'll sort it out.
[15:57] <caribou> bdmurray: np
[16:28] <LocutusOfBorg1> shame on you ubuntu developers!
[16:28] <LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1424769/comments/10
[16:28] <LocutusOfBorg1> ^^^^^
[16:29] <LocutusOfBorg1> :)
[16:34] <plm> Hi all
[16:34] <plm> This is right place for ubuntu core? Anyway, how I install vim on it?
[16:35] <ogra_> plm, do you mean snappy ?
[16:35] <ogra_> there is a #snappy channel
[16:35] <josepht> plm: #snappy might be better
[16:36] <plm> ogra_: yes.
[16:36] <plm> josepht: ok
[17:15]  * ejat brb
[17:15] <infinity> flexiondotorg: I'm around now, but I'm guessing Colin sorted out what you were going to ask me?
[17:18] <flexiondotorg> infinity, Yes Colin did help with some stuff 😃
[17:19] <flexiondotorg> infinity, mate-menu is in the upload queue is it possible for you to review it? It has the updated copyright.
[17:20] <infinity> flexiondotorg: Yup, I'll look at it in a second.
[17:20] <flexiondotorg> infinity, Many thanks.
[17:26] <alexbligh1> rbasak, any chance you got anywhere with https://bugs.launchpad.net/ubuntu/trusty/+source/apache2/+bug/1366174 ?
[17:27] <rbasak> alexbligh1: thank you for the reminder. It's now top of my list.
[17:27] <alexbligh1> rbasak, thanks :-)
[17:27] <rbasak> I'm not sure it's worth starting it right now as I finish in half an hour, but I'll do it tomorrow.
[17:28] <alexbligh1> rbasak, thanks once more
[20:03] <xnox> elmo: if i can get ipv6 tunnel, configure it and use it to get ipv6 internets, so can you. Could you please please make http://start.ubuntu.com/ ipv6 accessible? This should unbreak ubiquity on ipv6-only networks.
[20:03] <elmo> xnox: dude, are you high?
[20:04] <elmo> xnox: the problem isn't me needing to get an IPv6 tunnel
[20:04] <xnox> elmo: i didn't do tunnel however. I vpn in native ipv6 =)
[20:04] <elmo> xnox: as should be evidenced by the fact that things like archive.ubuntu.com are IPv6 enabled already
[20:04] <xnox> elmo: i'm not high, but clueless.
[20:05] <xnox> elmo: the start.ubuntu.com search box default provider is google which also has ipv6 connectivity.
[20:05] <elmo> xnox: well I'm just not sure why you'd choose to start a conversation with such an aggressive tone ("If even *I* can do this, surely you can too").  it's not constructive
[20:06] <xnox> elmo: right, a constructive feedback would be - given that there is ipv6 on some *.ubuntu.com could you please serve http://start.ubuntu.com/connectivity-check over ipv6
[20:06] <xnox> ?
[20:06] <xnox> elmo: sorry about the non-constructive opening.
[20:09] <elmo> xnox: so, there's several bugs an RTs about this; but I can't find a public one right now.  unfortunately adding v6 support for stuff behind our firewalls is non-trivial; ti's been on our todo list, but it's not been a huge priority
[20:09] <mdeslaur> xnox: please don't get elmo mad :)
[20:10] <elmo> xnox: part of that is because I'm not convinced anyone actually uses IPv6 only networks in the real world.  I mean what could you do with a v6 only internet connected machine?  go to google and look at all the sites you can't visit?
[20:10] <xnox> elmo: ok. i think connectivity-check lives there out of convenience rather than necessity.
[20:11] <elmo> xnox: it lives there because it's a URL we (Canonical IS) have committed to holding to a very high SLA
[20:11] <xnox> elmo: how hard would be to serve the file http://start.ubuntu.com/connectivity-check somewhere else which has ipv6 & ipv4?
[20:11] <xnox> elmo: hm, right.
[20:12] <xnox> elmo: i also believe there are very little ipv6 only machines, but there are some that are ipv6 only at install time, as there are bug reports that did tickle down to ubiquity about that.
[20:12] <elmo> xnox: well
[20:13] <elmo> xnox: the thing is I would argue that ubiquity is doing the right thing
[20:13] <xnox> elmo: and it didn't look like "i am a hipster who finished growing beards and testing ipv6-only environment for giggles"
[20:13] <elmo> if the check is "Do you have access to the general internet?" and your connectivity is v6 only, I would say "no" is the correct response
[20:13] <sarnold> but ipv6 is sufficient to get ubuntu updates, right?
[20:14] <xnox> elmo: in practice we use it to do $ apt-get update; download language packs; download updates; possibly live ugprade installer
[20:14] <elmo> sarnold: only if you have a v4 to v6 DNS translation; our nameservers also don't do v6
[20:14] <sarnold> elmo: ahhh
[20:14] <elmo> this is what I mean
[20:14] <xnox> elmo: thus accessing archive.ubuntu.com only.
[20:14] <elmo> the whole 'v6 only' thing strikes me as house of cards built on a bed of lies
[20:15] <elmo> you're already not true v6 only if you can resolve start.ubuntu.com
[20:15] <xnox> elmo: at the moment failure to resolve start.ubuntu.com -> prevents in ubiquity to access archive.ubuntu.com on ipv6-only.
[20:15] <elmo> xnox: well, hang on
[20:15] <xnox> elmo: and archive.ubuntu.com has ipv6 resolution.
[20:16] <elmo> xnox: which is it?
[20:16] <elmo> xnox: no, dude, it doesn't
[20:16] <elmo> xnox: you're confusing different things
[20:16] <elmo> xnox: archive.ubuntu.com has quad-A records
[20:16] <elmo> xnox: but ns{1,2,3}.c.c don't
[20:16] <infinity> archive.ubuntu... What he said.
[20:16] <elmo> xnox: so in a true v6 only environment you can't even *resolve* archive.u.c's AAAA
[20:17] <infinity> So, arguably, one shouldn't make connectivity-check available over v6 until after the nameservers also are, or it's a bit of a lie for our use-case.
[20:17] <xnox> elmo: i see - $ host archive.ubuntu.com -> shows ipv6 address; $ host -6 archive.ubuntu.com does not
[20:18] <maswan> elmo: you might have a dual stacked resolver on a v6-only host though
[20:18] <xnox> elmo: are 2001:67c:1360:8c01::18 2001:67c:1360:8c01::19 some kind of special v4->v6 things?
[20:19] <xnox> elmo: i'm seriously considering to change ubiquity connectivity check to curl http://archive.ubuntu.com/ubuntu/dists/$release/Release.gpg and check that it starts with -----BEGIN PGP SIGNATURE-----
[20:19] <elmo> maswan: sure and I think most people do.  but again, my overarching point is that I believe a true 'v6 only' environment is a magical unicorn.  it's a nice idea, but they're not useful in practice and I'm not even sure they exist
[20:19] <xnox> elmo: because all i need is downloadable archive.ubuntu.com rather than working start.ubuntu.com
[20:20] <elmo> maswan: because you inevitably add compromises like "oh, we're v6 but, we need v4 to actually resolve stuff"
[20:20]  * maswan has a few non-production servers on v6 only, v4 space getting constricted in a few places. but can put in a proxy and reslover and stuff in place when needed. real servers are dual-stacked.
[20:20] <maswan> elmo: yeah
[20:22] <xnox> maswan: yeah, i haven't seen things ipv6-native and _without_ NAT64 gateway -> thus start.ubuntu.com would work for those.
[20:22] <elmo> xnox: well, you can do what you like to ubiquity, but personally I think it's a bit silly.  the connectivity-check thing is well established and adding load of all ubiquity users to archive.u.c for this tiny handful of v6 only people because you're not patient enough to wait for a proper fix, is, IMO a bad trade off
[20:23] <xnox> elmo: i just think that start.ubuntu.com will never bubble up the priority to get ipv6 connectivity. =(
[20:23] <maswan> xnox: yeah, at least for proper end users. If I bring up a few v6-only VMs, I should be clueful enough to know which archive mirror to point them to, etc.
[20:24] <infinity> It's also mostly a non-bug, since ubiquity works Just Fine offline.
[20:24] <infinity> And then you reboot, and if you can see archive.ubuntu.com, you can update.  No big deal.
[20:24] <elmo> xnox: well, I don't know what you want me to say.  it almost sounds like you're threatening to make a bad decision unless I somehow commit to fixing your issue in a specific time.  if that's what's happening, I'm afraid I'm not going to play that game
[20:25] <xnox> elmo: i don't think causing mischief will get things moving either.
[20:25] <elmo> xnox: I mean do you have *any* way to quantify this?
[20:25] <elmo> because my gut feeling is that this is a tiny fraction of our userbase
[20:25] <elmo> and if that's true, I don't think it not being a priority to fix is actually the wrong call
[20:27] <xnox> elmo: well, i want to say - i could log a recoverable ubiquity bug report, and whoopsie would upload it post install..... but daily.ubuntu.com is ipv4 only as well.
[20:27] <xnox> elmo: i think daisy.ubuntu.com is actually a bigger one - we get no info from ipv6 users.
[20:28] <xnox> ev: ^
[20:33] <xnox> elmo: i concur. if it becomes a priority, and start.ubuntu.com gets enabled all releases will retroactively work.
[20:50] <smoser> pitti, are you still around ?
[20:59] <aeoril> darkxst I have fixed the bug, and am preparing to do a merge proposal.  I get the following lintian error as I check the build one last time:  "E: ubiquity changes: bad-distribution-in-changes-file vivid" - here is I believe the line it does not like I added:  "ubiquity (2.21.13) vivid; urgency=medium" - I assume I can ignore this error because vivid is a valid, but new, distribution?
[20:59] <aeoril> Here are the full lintian errors and warnings - should I worry about any of them?  http://paste.ubuntu.com/10395889/
[21:00] <aeoril> darkxst that line is in debian/changelog ...
[21:02] <darkxst> aeoril, maybe because you are building source on trusty
[21:02] <darkxst> other warnings are harmless
[21:02] <aeoril> darkxst should I build on vivid to make sure?
[21:03] <aeoril> or just submit
[21:04] <darkxst> its probably ok
[21:08] <darkxst> aeoril, and the ubuntu icon theme still has legacy icons I suppose,
[21:09] <aeoril> darkxst well, I have not tested that - I could always check ... it did before the fix ...
[21:10] <aeoril> I assume therefore it will now ...
[21:12] <darkxst> aeoril, just check that all icon names you are replacing are symlinks to your new names (in Ubuntu icon theme)
[21:18] <aeoril> in /usr/share/icons? darkxst
[21:19] <darkxst> aeoril, ^icons/Humanity
[21:34] <jdstrand> sarnold: thanks for the review! fyi, the loop you mentioned is actually basically the same as before, except now it is now under the 'for ext in ["additional", "override"]:' loop
[21:34] <aeoril> darkxst all the Ubuntu icons for dialog-information.svg point to legacy icons (gtk-info.svg).  I changed from gtk-dialog-info.svg to dialog-information.svg.  However, all the icons for dialog-warning.svg appear to be correct, which I changed from gtk-dialog-warning.svg
[21:35] <jdstrand> sarnold: but yes, I had to look at the 'for i in tmp_json' bit too. the idea is it will skip individual keys but still try ok ones
[21:35] <aeoril> darkxst I guess nothing breaks, then, just that the Ubuntu icons remain legacy ...
[21:36] <jdstrand> sarnold: really, I could just drop the 'invalid entry' bit, but I wanted to be helpful. Ill give the issubset() some thought
[21:38] <aeoril> darkxst all of the original referenced icons (gtk-dialog-info.svg) point to dialog-information.svg except two, which specifically point to gtk-info.svg, so really I think for Ubuntu my changes have no impact, all the info icons will remain legacy ... from what I can tell
[21:40] <aeoril> darkxst I am getting nervous!  I have commitment issues!
[21:40] <aeoril> lol
[21:51] <darkxst> aeoril, ok create a bzr branch with your changes and link to the bug
[22:00] <darkxst>  aeoril humanity does use icon-naming-utils, so should be fine
[22:45] <sarnold> jdstrand: yeah, it's not exactly -new- code, but it does take some time to think it through, and that often leads to problems ;)
[23:35] <jfmcarreira> heyy guys
[23:35] <jfmcarreira> is it possible to make bzr branch lp:playuver for example in a branch that was imported from git?
[23:54] <aeoril> darkxst should I follow these instructions?  http://packaging.ubuntu.com/html/fixing-a-bug.html#committing-the-fix
[23:55] <aeoril> (just want to make sure because of my fear of committment)
[23:55] <darkxst> aeoril, yes
[23:55] <aeoril> darkxst ok, cool - will do.  Thanks.