=== jamesh_ is now known as jamesh
=== afkthairus is now known as athairus
=== Ionic is now known as Guest67057
[01:15] <shaderslayer> rbasak: any news on that docker backport
=== Guest67057 is now known as Ionic
[01:44] <psusi> sigh.. why is the libvirt bzr branch out of date/abandoned, and the source package doesn't point to any other vcs?
[01:46] <psusi> for that matter, why the hell was the bzr branch like a 1 gb download? that's nearly as big as the entire linux git repo which goes back how many hundreds of thousands of commits over the last 13 years?  whew...
[04:37] <pitti> Good morning
[04:39] <Unit193> pitti: Heya.  Oh, any news on switching from upstart user sessions to systemd user sessions?
[04:39] <pitti> Unit193: no, it's not on the agenda; I'm afraid I have my hands uber-full with system-side stuff already, and it's still mostly just me
[04:39] <pitti> Unit193: but it's much less of a switch rather than a gradual migration
[04:40] <pitti> Unit193: both upstart and systemd are running for the user session, so both can be used
[04:41] <Unit193> pitti: Ah, bummer then.  And yeah, though saw didirocks helped a bit.  Oh?  I was thinking the session management, thought that'd be more of a flip.  And yeah, noticed, I'm already using a systemd user unit. :)
[04:43] <pitti> Unit193: ah, you do? "systemctl --user -t service" is still empty here :)
[04:44] <Unit193> (I'm using one because I created one...)
[04:45] <pitti> arges: do you have time to accept the utopic/vivid postgresql SRUs? thanks in advance!
[07:17] <dholbach> good morning
[07:18] <FourDollars> dholbach: Good morning. Are you the patch pilot today?
[07:20] <dholbach> FourDollars, I was, yesterday
[07:20] <dholbach> but maybe you just mention what needs uploading?
[07:21] <FourDollars> dholbach: Could you help https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1460521?
[07:21] <ubottu> Ubuntu bug 1460521 in efibootmgr (Ubuntu) "UEFI BootOrder is not empty after I removed the last boot entry." [Undecided,New]
[07:21] <dholbach> slangasek, stgraber: ^ do you know who could take a look at this one?
[07:30] <FourDollars> dholbach: I have prepared https://code.launchpad.net/~fourdollars/ubuntu/trusty/efibootmgr/1460521/+merge/261464.
[07:33] <dholbach> yes, I saw it, but I don't know anything about efibootmgr - that's why I pinged Steve and Stéphane
[07:34] <FourDollars> I see.
[07:34] <FourDollars> slangasek: stgraber: Thx in advance.
[07:36] <caribou> Laney: I assigned myself to the bug a while ago because someone I was in touch with told me he was able to reproduce the bug
[07:36] <caribou> Laney: haven't heard from him since
=== Spads_ is now known as Spads
[07:51] <zyga> good morning
[08:15] <rbasak> shaderslayer: still working on it. The dependencies keep changing :-/
[08:40] <dholbach> mitya57, I commited the Ukrainian translations to trunk and made them available on packaging.u.c
[08:40] <dholbach> mitya57, they're now up to 70%, but maybe we still wait a few days and then make a release?
=== soren is now known as soren_
=== soren_ is now known as soren
[10:31] <brainwash> are there any news on running X as non-root (for drivers which support KMS)? the idea is old and plans did exist like 5 years ago. according to bug 1292324 , lightdm is not ready yet and there seems to be no progress
[10:31] <ubottu> bug 1292324 in Light Display Manager "Support non-root X" [Wishlist,Triaged] https://launchpad.net/bugs/1292324
[10:45] <stgraber> dholbach: maybe cyphermox
[11:04] <jamespage> barry, morning - do you know if the DPMT has considered a lintian check to compare upstream version requirements in python projects against actual versions in Debian/Ubuntu?
[11:04] <mejo> hi
[11:06] <mejo> I accidently uploaded a package to upload.ubuntu.com via ftp. The packages are not meant for ubuntu, I intended to upload them to a private repository. The packages in question are 'monitoring-plugins-inet-*'. What is the best contact to ask for removal of them?
[11:06] <mejo> I guess that they're removed anyway, just want to be sure ;)
[11:06] <cjwatson> mejo: They'll have been automatically rejected if you don't have upload permissions to Ubuntu.
[11:07] <cjwatson> mejo: Indeed, I see the rejection in the logs.
[11:08] <mejo> great, thanks for checking
[11:10] <zyga> re
[11:10] <zyga> cjwatson: I was off yesterday, I'm working on tarmac full time today
[11:11] <cjwatson> zyga: OK, I'm preparing for stakeholder meeting so unlikely to have much attention for it
[11:13] <zyga> cjwatson: thanks, I only have one request, could you help me see the roadmap you see in asana later today when you have a moment, or direct me to someone who can help me with that
[11:19] <cjwatson> zyga: that probably needs help from ev
[11:19] <cjwatson> (since he owns the containing team)
[11:19] <zyga> cjwatson: ok, I'll talk to ev then, thank you
=== MacSlow is now known as MacSlow|lunch
[12:02] <doko> pitti, in the past jamespage cared about these mismatches
[12:16] <dholbach> stgraber, cyphermox is on holidays I think
[12:30] <jamespage> doko, pitti: unfortunately my time is not scaling to cover java stuff any longer
[12:30] <jamespage> I did take a peek at junit4 - looks like upstream dropped the ant based build process
[12:31] <jamespage> rbasak, do you or anyone in the server team have capacity to look at options around the mismatches explosion in wily?
[12:34] <rbasak> jamespage: I don't think we have the capacity right now. Will have to bounce to gaughen.
=== _salem is now known as salem_
=== pat__ is now known as pmcgowan
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
=== marcusto_ is now known as marcustomlinson
[12:52] <arges> pitti: tomorrow is traditionally my SRU day, but what do you need looked at the utopic queue?
[12:52] <pitti> arges: postgresql-9.4 in utopic and vivid, for bug 1461425
[12:52] <ubottu> bug 1461425 in postgresql-9.4 (Ubuntu Vivid) "New upstream microreleases 9.1.17, 9.3.8, 9.4.3 - fixes regression in previous update" [Undecided,In progress] https://launchpad.net/bugs/1461425
[12:53] <pitti> arges: sorry for hassling; it's quite a serious regression, and somehow utopic and vivid slipped through last week's SRU rounds
[12:53] <arges> pitti: ok. i'll review. Yea that was my fault since I was waiting on it going into wily
[12:53] <pitti> arges: I'd like to verify it today, and get them into -updates this week still if at all possible
[12:53] <pitti> arges: much appreciated, thank you!
[12:57] <arges> pitti: ok done.
[12:57] <pitti> arges: cheers
[12:58] <pitti> arges: would you mind if we released at least the precise one now already (5 days/verified), as that's most affected by the regressino?
[12:59] <arges> pitti: just 9.1/precise?
[12:59] <pitti> arges: I wouldn't mind 9.1+9.3/trusty either, but it's much less affected (i. e. not affected in a default configuration)
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[13:00] <pitti> arges: actually, yes: 9.1/trusty needs to go along with 9.1/precise to avoid breaking p->t upgrades
[13:02] <arges> pitti: seems reasonable for just 9.1, and its only 1 day earlier.
[13:08] <mitya57> dholbach: Sounds like a plan, will upload on the weekend then
[13:15] <smoser> is gsettings an interface to dconf ?
[13:15] <larsu> smoser: yes
[13:16] <smoser> so why, then
[13:16] <smoser> $ dconf list /org/gnome/terminal/legacy/profiles:/
[13:16] <smoser> :63575bfd-baa0-4acd-86fc-6726b91ff51e/
[13:16] <smoser> list
[13:16] <smoser> :bdddb09c-01fe-4230-90b0-331af6389b5f/
[13:16] <smoser> default
[13:17] <smoser> $ gsettings list-recursively | grep gnome.germinal
[13:17] <smoser> ^ nothing output there.
[13:17] <smoser> well, spelling error there.
[13:17] <smoser> but:
[13:17] <smoser> $ gsettings list-recursively | grep gnome.terminal
[13:18] <smoser> doesn't hae the same content.
[13:18] <smoser> why not ?
=== MacSlow|lunch is now known as MacSlow
[13:20] <smoser> larsu, ? i'm clearly missing something.
[13:21] <barry> jamespage: i'm not aware of it, but it's an interesting idea
[13:22] <cjwatson> smoser: grep -i
[13:23] <larsu> smoser: these settings are relocatable, which list-recursively doesn't list
[13:23] <larsu> you need to pass the path at which they're stored
[13:23] <cjwatson> ah right, that too :)
[13:24] <larsu> which doesn't work for me right now for some reason... and desrt is not in here :/
[13:24] <dholbach> thanks mitya57
[13:27] <smoser> larsu, well, thanks for the input. what a pain.
[13:27] <smoser> for anyone else bothered by gnome-terminal double-click highlight, there is a config-change fix at
[13:27] <smoser>  org.gnome.Terminal.Legacy.Keybindings
[13:27] <smoser> err.. https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1463072
[13:27] <ubottu> Ubuntu bug 1463072 in GNOME Terminal "highlighting on left mouse double click ends at :" [Medium,Confirmed]
[13:27] <larsu> smoser: the syntax is schema:path, but list-recursively seems to have a bug where it always returns default values
[13:28] <larsu> smoser: hm, I was happy about this change because I can now copy/paste filenames from grep output without the :
[13:32] <smoser> larsu, yeah. both ways have annoyances. its good that it is configurable at least. thanks again for your help.
[14:30] <slangasek> dholbach, FourDollars: efibootmgr would be in cyphermox's basket, but he's out for the next two weeks
[14:31] <dholbach> can anyone else take a look at it?
[14:34] <slangasek> dholbach: if it's urgent
[14:34] <dholbach> I don't know
[14:35] <dholbach> FourDollars asked me if I could sponsor it, but it's well out my area of expertise
[14:35] <seb128> bdmurray, hey, did you see my previous pings about the trusty gtk sru?
[14:36] <seb128> wondering why it's blocked/not copied to updates despite being fixed-verified for weeks
[14:38] <xnox> seb128: bunch of regressions
[14:38] <xnox> http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html
[14:38] <seb128> xnox, those never worked on trusty
[14:38] <seb128> so not regression
[14:38] <seb128> they also are mostly not gtk issues
[14:38] <xnox> seb128: little does britney know, hence "Not considered"
[14:39] <xnox> seb128: you need release people to do hints / skips for you. e.g. ping infinity about it.
[14:39] <seb128> xnox, right, I pinged bdmurray several times asking how we can get those false positive overwriten or if the SRU team could override it
[14:39] <seb128> xnox, k, I tried that but with the SRU team
[14:39] <seb128> I figured out they would know how to deal with those issues for SRUs
[14:40] <cjwatson> The SRU team can override such things, yes
[14:40] <seb128> some of those autopkg are just buggy on trusty
[14:40] <seb128> e.g https://jenkins.qa.ubuntu.com/job/trusty-adt-deja-dup/lastBuild/ARCH=amd64,label=adt/console
[14:40] <seb128> "env: dbus-launch: No such file or directory"
[14:40] <seb128> it's not a regression from the gtk update
[14:40] <cjwatson> It's possible they don't know how, but it's in lp:~ubuntu-sru/britney/hints-ubuntu-trusty etc.
[14:40] <seb128> cjwatson, thanks :-)
[14:40] <xnox> ah, tah.
[14:54] <Laney> Oh, is p-m actually used for migration for SRUs?
[14:54] <Laney> I thought that it was simply that the tests were being run
[14:54] <cjwatson> No(t yet), but it's informational
[14:55] <cjwatson> seb128: So yeah, that's the other reason the SRU team probably doesn't care
[14:55] <cjwatson> It's not necessary at this point to get proposed-migration to pass in order to promote a package
[14:56] <cjwatson> The sort of rough roadmap I had was that we'd migrate over to using p-m for SRUs with hints set by the SRU team when things were ready to go
[14:56] <cjwatson> But that's incomplete and we never finished discussions of what tooling we'd need etc.
[14:56] <slangasek> but it does show up on the report (http://people.canonical.com/~ubuntu-archive/pending-sru.html), and things that are red there require further investigation
[14:56] <cjwatson> If somebody who's still a functional member of the SRU team wants to pick that up and run with it, it's probably not too hard at this point, and would be a nice defence against accidentally releasing uninstallable updates and such
[14:57] <cjwatson> Right, that's true, though I imagine it still at least sometimes happens that people choose to disregard those without actually making it green
[14:57] <cjwatson> Given that the trusty hints branch has had zero commits
[14:58] <cjwatson> Or else you're all heroes and are making everything pass first without ever having to hint
[14:58] <slangasek> heh
[14:58] <cjwatson> I know which I think is more likely :)
[14:59] <Laney> At what level are uploaders supposed to care about this? Proactively checking the report? Waiting for an SRU team member to ask if they need extra eyes?
[15:00] <Laney> All I knew is that the tests were being run but I thought they were considered basically noise at this point due to the level of false failures
[15:00] <Laney> Until i had a couple of pings on bugs. :)
[15:00] <arges> So it would be good to fix the false positives, I try to review all regression reports to see if they are failures not related to packages, but it takes me about 10 times a long to review a package. If it something complex like gtk+3.0 I ask for the uploader for some help reviewing those false positives
[15:00] <arges> which is what Laney did looks like
[15:01] <EvilRoey> hello all!  Question... now that rebootless kernel swapping is mainlined in the kernel, how long until we can upgrade Kubuntu releases without having to reboot?
[15:02] <rbasak> EvilRoey: maybe try the kernel team in #ubuntu-kernel?
[15:02] <EvilRoey> ah, thanks!
[15:03] <slangasek> the high rate of test regressions in trusty between the release and the time we turned adt on for SRUs has certainly been problematic
[15:09] <bdmurray> cjwatson: what information should go in hints-ubuntu-trusty?
[15:09]  * zyga sent out the first merge proposal for tarmac
[15:09] <zyga> https://code.launchpad.net/~zyga/tarmac/git-support/+merge/261528
[15:09] <cjwatson> EvilRoey: http://jwboyer.livejournal.com/50232.html may be worth reading
[15:09] <zyga> it's mostly a no-op (nothing new0
[15:09] <zyga> but I want to see who's responding
[15:09] <EvilRoey> aye
[15:09] <zyga> if you are here, please ping me, I'd like to talk about tarmac git support
[15:09] <cjwatson> bdmurray: compare lp:~ubuntu-release/britney/hints-ubuntu and see http://ftp-master.debian.org/testing/hints/README
[15:10] <bochecha_> bdmurray: hi, you've sent the ibus-cangjie update to vivid-proposed last week (thank you for that!), can I ask you to send it to utopic-proposed and trusty-proposed as well? :)
[15:11] <EvilRoey> by the way, I just wanted to express my gratitude for all of your hard work.  I've been using Kubuntu since before Warty Warthog, and I am consistently impressed by how much less administration I have to do on my own system because the system takes care of it for me.  Thanks so much ^_^
[15:13] <cjwatson> Kubuntu as such didn't exist until Hoary, but we're glad you're enjoying it :)
[15:13] <cjwatson> (The warty repositories had KDE, though, so it was probably possible to use it there)
[15:29] <EvilRoey> aye :)
[15:30] <EvilRoey> I mean.  Shit.  I remember hand-rolling my own kernel in order to support 64-bit and XFS (this was back in 2005? 2004?)
[15:30] <EvilRoey> in the days before Ubuntu.
[15:30] <EvilRoey> and all of the little modifications that I put here and there
[15:30] <EvilRoey> and all of that blisfully went away
[15:30] <EvilRoey> (still though, fuck nvidia)
[15:36] <smoser> pitti, around ?
[15:36] <smoser> systemd experts, i'm seeing https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1463461 on wily, but vivid worked/works fine
[15:36] <ubottu> Ubuntu bug 1463461 in open-iscsi (Ubuntu) "resolvconf not updated by open-iscsi systemd job" [Undecided,New]
[15:37] <smoser> it appears to me that /lib/systemd/system/ifup@.service.d/open-iscsi.conf is not getting run
[15:47] <jamespage> barry, its something that would be useful for the openstack packages, and I thought it might be generally useful as well
[15:48] <barry> jamespage: maybe open a bug against lintian in debian?
[15:48] <jamespage> br
[15:48] <jamespage> barry, that was my plan - I'm not sure my perl is up to actually writing an implementation
[15:49] <barry> jamespage: mine is so rusty you'd get tetanus
[15:54] <pitti> hey smoser
[15:54] <pitti> kees, stgraber, slangasek, mdeslaur: reminder: TB meeting in 6 mins
[15:55] <smoser> pitti, hey. see above... figured you might know something about that.
[15:55] <jamespage> barry, bug raised
[15:55] <pitti> smoser: not off the top of my head; I opened the bug, will look into it ASAP
[15:56] <barry> jamespage: thanks!
[16:00] <xnox> pitti: does ubuntu does the cgroup killing spree on logout with loginctl by default?
[16:00] <pitti> xnox: no, we don't
[16:01] <xnox> pitti: if not, how that default behaviour was changed?
[16:01] <xnox> pitti: i want that too, but can't find it.
[16:01] <pitti> xnox: it has never changed, it has always been off
[16:01] <xnox> pitti: changed from upstream that is, cause upstream is to kill by default.
[16:01] <xnox> unless "enable-linger" is done on the user account wiht logind apis.
=== tvoss is now known as tvoss|dinner
[16:02] <pitti> xnox: #KillUserProcesses=no ← ./src/login/logind.conf in trunk
[16:02] <xnox> horum, ok.
[16:13] <slangasek> bdmurray: fwiw I've seeded hints-ubuntu-trusty now with a force-badtest on gvfs - though I wonder if gvfs shouldn't be made to get a fix test, considering it itself is being SRUed
[16:13] <slangasek> bdmurray: will these hints have any effect on http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html ? i presume not
[16:17] <slangasek> bdmurray: deja-dup fails with an error about not finding 'dbus-launch', which is an environment regression; I don't remember, did we draw a line on which packages should be added back to the trusty testbed?
[16:17] <infinity> slangasek: If the hints have no effect, that would seem to defeat the purpose...
[16:18] <bdmurray> slangasek: of the top of my head I don't know what effect the hints will have on update_excuses.html
[16:18] <slangasek> infinity: the purpose of the hints is to have them actually tie into proposed-migration when we do package publications; we're not using p-m currently, we're doing manual copies
[16:18] <slangasek> infinity: so the question is, does the report consider hints
[16:19] <infinity> slangasek: Hints are being taken into account, but it might not be the right branch...
[16:20] <infinity> slangasek: Looks like it's using the main hints-ubuntu branch for everything.
[16:20] <slangasek> ok, so the report needs a slight tweak?
[16:20] <infinity> If we're meant to be using branches for hints, then britney probably needs to learn how that works, yeah.
[16:21] <slangasek> oh, sorry - that's not even what I meant
[16:21] <slangasek> what I meant to ask was, will the hints have any effect on http://people.canonical.com/~ubuntu-archive/pending-sru.html
[16:21] <slangasek> which is the report we actually use
[16:22] <infinity> slangasek: If you meant sru_report rather than update_excuses, yeah.  That could use a tweak to show ignored tests.
[16:22] <slangasek> bdmurray: ^^ ?
[16:22] <infinity> slangasek: But ignored tests won't be ignored until your hints are actually taken into account by britney. :P
[16:22] <slangasek> though maybe instead of changing the report we should just start using p-m for the publication
[16:23] <slangasek> hmm. or at least, scrape the p-m output for inclusion in the report instead of querying adt directly, if that's what we currently do?
[16:23] <infinity> slangasek: We're certainly getting closer to being able to do that, but I'm not sure we've specced out the final step yet.  As in, how do we actually let something through.
[16:23] <cjwatson> infinity: You sure?  See lp:britney/britney1 britney line 318
[16:23] <cjwatson> slangasek: the report already consumes the yaml output from p-m
[16:23] <infinity> cjwatson: I dunno.  The logs for trusty imply it's pulling the main hints.
[16:24] <cjwatson> infinity: it will pull an existing branch if there is one
[16:24] <cjwatson> so it's possible that it just needs an rm -rf in the right place
[16:24] <cjwatson> lemme look
[16:25] <infinity> cjwatson: Ahh, if it needs manual intervention to wipe out data/$dist/Hints, that's probably the missing bit.
[16:25] <cjwatson> ah, yeah, so that's a fun landmine across releases
[16:26] <infinity> cjwatson: Does britney already know if dist == devel?  If so, we can check the current branch name and wipe it if it's not a dist branch.  Or we could stop using the unversioned trunk entirely and fork a new hints-dist on each opening.
[16:26] <bdmurray> slangasek: sru-report uses the update_excuses.yaml file if that answers your question
[16:26] <cjwatson> infinity: Or we could bzr pull --remember --overwrite
[16:26] <slangasek> bdmurray: it does, thanks
[16:26] <infinity> cjwatson: I don't speak bzr well enough to know what that combination does, but sure?
[16:27] <cjwatson> it saves rebranching from scratch every time but makes sure it ends up in the right place
[16:27] <infinity> To be fair, we need to branch on each release anyway.
[16:27] <cjwatson> I mean at runtime
[16:27] <cjwatson> One moment, this would be clearer with code
[16:27] <infinity> Either we branch trunk to wily on wily release, or we branch wily to x-series.
[16:28] <infinity> The latter is less error-prone.
[16:29] <infinity> cjwatson: But yes, I get what you mean.
[16:35] <cjwatson> gah one of these days I'll use the right merge target, please ignore the garbage merge
[16:35] <cjwatson> infinity: https://code.launchpad.net/~cjwatson/britney/fix-sru-branching/+merge/261538 is what I mean
[16:35] <cjwatson> (untested)
[16:37] <cjwatson> I don't mind what you want to do with trunk or whatever, but I think this is correct anyway; makes it more certain that reality will be in sync with code
[16:38] <infinity> cjwatson: Yeah, that looks sane in the current context.
[16:38] <cjwatson> infinity: cool, can you merge and make sure it doesn't make it all explode? :)
[16:39] <infinity> cjwatson: Yeahp, will do in a bit.
[16:39] <cjwatson> ta
[16:39]  * cjwatson goes back to wrapping head around graph algorithms
[17:14] <rcj> Question for whomever about LP git support.   Trying to push to a personal repo for a distribution source package like lp:~rcj/trusty/+source/open-vm-tools but push fails with 'Project 'trusty' does not exist.'
[17:15] <rcj> And that is following the spec for urls @ https://help.launchpad.net/Code/Git
[17:16] <rcj> nm, should have been lp:~rcj/ubuntu/+source/open-vm-tools/+git/trusty
[17:21] <cjwatson> rcj: As you say, but "trusty" probably isn't a sensible repository name.
[17:21] <cjwatson> rcj: You could just have one branch for each series in a single repository, and simply push your repository for all your open-vm-tools packaging to lp:~rcj/ubuntu/+source/open-vm-tools
[17:21] <rcj> cjwatson, I'm looking to map branches to releases so that they would show up @ https://code.launchpad.net/ubuntu/+source/open-vm-tools
[17:21] <rcj> cjwatson, I would prefer that
[17:22] <cjwatson> rcj: We ask that you don't
[17:22] <cjwatson> rcj: We haven't put the UI for packaging together yet, but we expect to be putting all series into a single repository as a general practice; it's much better for easy data sharing and more convenient for people checking it out
[17:22] <rcj> cjwatson, that particular package is broken for bzr because a package was uploaded with an illegal character ('\') in a filename and now we can't use the bzr branches
[17:23] <rcj> cjwatson, one repo is great
[17:23] <cjwatson> rcj: Right, I'm just saying that the +git/trusty means a completely separate repository, which we do not advise for series branches
[17:24] <cjwatson> rcj: Nothing's going to show up on /ubuntu/+source/open-vm-tools yet, but hopefully soon
[17:25] <cjwatson> rcj: But if you just push to ~rcj/ubuntu/+source/open-vm-tools then that should do for now and we'll hopefully be able to make useful views for it soon; it could eventually be turned into a default repository for the package once we get permissions worked out there
[17:26] <rcj> cjwatson, excellent. I was hoping that would be the direction.
[17:26] <zyga> cjwatson: quick question, is there a way to rewrite the default branch for a series from bzr to git somehow?
[17:26] <cjwatson> zyga: No.
[17:26] <zyga> cjwatson: either in the gui or programmatically
[17:26] <zyga> cjwatson: so how can a bzr-based project migrate over to git?
[17:26] <cjwatson> zyga: It's almost certain to involve a manual migration; doing this right typically involves per-project care
[17:27] <cjwatson> zyga: Or, maybe I've misunderstood what you're asking exactly
[17:27] <zyga> cjwatson: yeah, sorry, I mean that if I go to code.launchpad.net/project, it shows the bzr branches and git branches are offered under a separate link (thanks for the link btw!), now for new some other project I managed to somehow make git the default
[17:27] <zyga> cjwatson: I'm curious to understand how does that work
[17:28] <cjwatson> zyga: There's going to be a switch for the project's default VCS.  It's not entirely in place yet.
[17:28] <zyga> cjwatson: checkbox (bzr main) and hwcert-tools (git main) for example
[17:28] <zyga> cjwatson: ah, perfect, thanks!
[17:30] <rcj> cjwatson, after pushing to that URL I don't see anything @ https://code.launchpad.net/~rcj/ubuntu/+source/open-vm-tools which is unexpected.  (git+ssh://rcj@git.launchpad.net/~rcj/ubuntu/+source/open-vm-tools) Is that known or a bug?
[17:31] <cjwatson> zyga: There are no projects where git can possibly be the default yet, but you may be looking at a different view.
[17:31] <cjwatson> rcj: It's known, we haven't put this together for packages yet because we're focusing on projects.
[17:31] <rcj> cjwatson, ah, okay and I found it at https://code.launchpad.net/~rcj/ubuntu/+source/open-vm-tools/+git/open-vm-tools, is that right?
[17:31] <cjwatson> Correct.
[17:31] <cjwatson> Or https://git.launchpad.net/~rcj/ubuntu/+source/open-vm-tools
[17:32] <cjwatson> Eventually they'll match, the latter path being preferred.
[17:32] <zyga> cjwatson: hmm, weird, the page https://code.launchpad.net/hwcert-tools did look different last week
[17:32] <zyga> cjwatson: anyway, thanks, I'll just wait
[17:32] <cjwatson> zyga: Yes, we temporarily had a mixed view which was a hack.
[17:32] <rcj> cjwatson, thanks for taking the time.  I've been really happy with all the git support.  Looks like I'm just getting a head of things.
[17:32] <cjwatson> zyga: What you see now is about two steps towards making it not a hack.
[17:33] <zyga> :)
[17:33] <cjwatson> rcj: A little bit, yeah.  Hopefully we'll catch up soon :)
[17:33] <zyga> little by little, I'm super happy to see everything iterate so quickly
[17:52] <zyga> cjwatson: is there a reason why git->bzr imports cannot be made from git repos hosted on launchpad
[17:52] <zyga> cjwatson: I need it to keep recipes running
[17:59] <nedbat> I've been reading about the process for becoming an Ubuntu committer (not because I will, but to design a similar process for Open edX), and have a question: this page (https://wiki.ubuntu.com/DeveloperMembershipBoard) doesn't explain how people become members of the Developer Membership Board.  Are they appointed?
=== oSoMoN_ is now known as oSoMoN
[18:00] <micahg>  nedbat they're elected by Ubuntu developers
[18:01] <micahg> I think you're looking for this page: https://wiki.ubuntu.com/UbuntuDevelopers
[18:02] <infinity> nedbat: If you're bootstrapping a new community, you do have a bit of a chicken and egg problem if you want an elected board to oversee membership. :)
[18:02] <nedbat> infinity: yes
[18:03] <infinity> nedbat: But one would generally grandfather in a few of the project founders as the initial board to then approve new developers, and when the developer base reaches critical mass (whatever you define that to be), you'd kick yourselves out of the board and have an election to elect a new one.
[18:04] <nedbat> micahg: thanks
[18:08] <nedbat> micahg: just for completeness, I'm not sure the UbuntuDevelopers page explains that the board is elected by the developers.
[18:08] <micahg> nedbat: no, that's about how to become a developer
[18:09] <nedbat> micahg: ok.  the Board page doesn't mention it either.
[18:12] <infinity> slangasek: What's with the uncommitted change in snakefruit:~ubuntu-archive/proposed-migration/code/b1/update_output
[18:12] <infinity> slangasek: Looks like it was probably you.
[18:13] <micahg> nedbat: then, I'm not sure if it's in the wiki, but that's how we've run the elections in the past, https://lists.ubuntu.com/archives/ubuntu-devel-announce/2015-February/001125.html, we use CIVS (http://civs.cs.cornell.edu/)for the ballots
[18:13] <nedbat> micahg: thanks. any idea what percentage participation you get for those elections?
[18:14] <slangasek> infinity: it certainly was not
[18:15] <infinity> slangasek: I was just assuming based on the line changed having your name in it. :P
[18:15] <micahg> nedbat: I think between 40 and 60%
[18:15] <nedbat> micahg: wow, that's good.
=== tvoss|dinner is now known as tvoss
[18:15] <slangasek> infinity: I suspect it was cjwatson; and I suspect it was fixing a problem because of my imported Debian release team status
[18:16] <slangasek> infinity: the change dates to 2013, I didn't even know how to get to snakefruit then
[18:16] <infinity> slangasek: Indeed.  Just unlike Colin to cowboy in prod.
[18:16] <infinity> slangasek: I'll poke him instead, though.
[18:16] <infinity> cjwatson: ^
[18:18] <infinity> slangasek: Honestly, I'd assume it was me, but I definitely don't remember doing it. :)
[18:18] <infinity> (yeehaw)
=== tvoss is now known as tvoss|dinner
[18:20] <slangasek> infinity: actually I checked IRC logs, I may have made this change, was britney being run from lillypilly at the time? :)
[18:20] <slangasek> infinity: feel free to revert the chunk around my name and we'll see what happens.  The rest of those changes, no idea
[18:21] <infinity> slangasek: Probably, yeah.  I think we got snakefruit somewhere around the same time we did the ppc64el bootstrap, so late 2013 or something.
[18:21] <infinity> slangasek: The changes to britney itself are a revert by me just now, but that's how I noticed your bit.
[18:22] <slangasek> ok
[18:22] <infinity> slangasek: Anyhow, if your bit is necessary, I'd rather you commit it than playing the "revert and see what blows up" game. :P
[18:22] <micahg> would we accept an SRU for desktop packages for precise anymore?  trying to figure out what to do with a backport request
[18:22] <infinity> micahg: Yes.
[18:22] <micahg> ok, I'll go ahead and process the backport then, thanks
[18:22] <slangasek> infinity: I don't *know* that it's necessary. It didn't fix the problem at the time
[18:22] <infinity> micahg: >= precise are 5y LTS for all Ubuntu products, not just server.
[18:22] <infinity> micahg: And many flavours too, for that matter.
[18:23] <micahg> oh, haha, forgot :)
[18:23] <slangasek> infinity: so it was not sufficient, and may also not be necessary.  just revert it, and if my hints fall out of circulation, I'll remember this conversation.
[18:23] <infinity> slangasek: Oh.  Hah.  Okay.
[18:23] <infinity> slangasek: Reverted, and the hack lives on in .~1~
[18:25] <infinity> micahg: To be fair, though, even for products without a 5y support commitment, there's no reason we wouldn't accept an SRU from the community, people are just less likely to generate them in the first place.
[18:25] <infinity> micahg: Lack of commitment doesn't imply active impedence.
[18:25] <micahg> infinity: I thought I remembered you saying that in the past, just thought I'd verify :)
[19:16] <zyga> cjwatson: hey, do you have any plans on adding getByUrl on git_repo/git_ref
[19:16] <zyga> cjwatson: tarmac needs it, I can work around by parsing the URL and converting that to an api.launchpad.net URL to load directly
=== pgraner is now known as pgraner-afk
[20:49] <asterai> Hi some one of developpers here?
[20:50] <sarnold> 360, give or take..
[20:50] <asterai> I want to contribute the Ubuntu, where i can get the task?
[20:50] <asterai> )))
[20:51] <asterai> I want to be one of ubuntu developpers )))
[20:51] <zyga> asterai: https://wiki.ubuntu.com/ContributeToUbuntu
[20:51] <zyga> asterai: please read that and see what you'd like to do
[20:52] <asterai> Ok, tnx. )))
[21:06] <asterai> Ok, i read all of text. And subscribed to Ubuntu kernel.
[21:06] <asterai> Where i can get the tasks?
[21:09] <asterai> Here have some one who can mentor me. How to start? And get my first task.:)
[21:09] <asterai> Here have some one who can mentor me - How to start? And get my first task.:)
[21:10] <taggart> what ubuntu releases would it be reasonable to expect users to be installing currently (including sites that might need to reinstall a host with an older but still supported release)?
[21:12] <taggart> the di-netboot-assistant config file currently looks like this:
[21:12] <taggart> https://anonscm.debian.org/cgit/d-i/netboot-assistant.git/tree/config/di-sources.list
[21:13] <taggart> so it has: hardy lucid precise saucy raring quantal oneiric
[21:13] <taggart> can any of those be dropped? what needs to be added?
[21:15] <taggart> I think last time I submitted a patch for this cjwatson or slangasek probably gave me the answer...
=== pgraner-afk is now known as pgraner
[21:23] <taggart> I am guessing:
[21:23] <taggart> LTS: Drop hardy. Add trusty
[21:23] <taggart> normal: Drop oneiric, quantal, raring. Add utopic, vivid
[21:24] <doko> taggart, lucid could be dropped as well
[21:26] <taggart> doko: Hi! lucid is still listed at http://releases.ubuntu.com/ but is it supported?
[21:27] <taggart> or i guess more importantly, is any of the installed base still on it? (reasonably)
[21:27] <doko> enoclue. but it's EOL
[21:28] <slangasek> it hasn't been dropped from the servers yet but it is EOL, yes
[21:29] <slangasek> taggart: there is an externalized package now in Ubuntu that provides this information: distro-info
[21:29] <taggart> ok, I think I will drop it from the config since there will be some delay before the package ships in a release
[21:29] <taggart> slangasek: ah sweet!
[23:24] <taggart> slangasek, doko: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788292 patch 6. once that gets uploaded it would be good to pull that into ubuntu to fix there too
[23:24] <ubottu> Debian bug 788292 in di-netboot-assistant "di-netboot-assistant: update di-sources.list" [Normal,Open]
[23:25]  * taggart bails, see ya!
[23:34] <cjwatson> zyga: not something we've thought of, it seemed a bit unnecessary since we have getByPath, but I guess we could if it makes life significantly easier.  Feel free to file a bug about it