[07:53] <dpm> good morning all
[08:13] <dpm> hi henninge, good morning. What was the branch you subscribed me to regarding the crontab export schedule changes? I didn't receive any notification of the subscription
[08:14] <henninge> Hi dpm!
[08:14] <henninge> Maybe I did it wrong...
[08:14] <henninge> but the changes were merged yesterday.
[08:15] <henninge> dpm: This is the branch: https://code.launchpad.net/~deryck/lp-production-crontabs/update-lang-pack-export-schedule/
[08:16] <henninge> dpm: but the merge proposal is gone ...
[08:17] <dpm> henninge, hm weird. In any case, if the changes were merged, I guess the new schedule is already in place?
[08:17] <henninge> dpm: yes, I understand they are.
[08:17] <dpm> ok, thanks henninge
[12:09] <yurchor> Hi! I was added to administrators of lp-ukrainian: https://launchpad.net/~lp-l10n-uk  and have changed the homepage to show more information on translations. Can this help to solve https://answers.launchpad.net/launchpad/+question/155900  ?
[12:20] <dpm> yurchor, sure, let me do this now
[12:22] <yurchor> Thanks. :)
[12:23] <dpm> yurchor, can you remind me where your guidelines are, if you've got any? I'll then add them as a link to the team
[12:24] <dpm> Are these the ones? http://docs.linux.org.ua/Переклади:_як_це_робиться%3F
[12:25] <yurchor> General guidelines are here: http://docs.linux.org.ua/Ïåðåêëàäè:_ÿê_öå_ðîáèòüñÿ%3F
[12:25] <yurchor> Yes.
[12:32] <dpm> yurchor, done, happy translating! ;)
[12:33] <yurchor> dpm: Many thanks! :)
[12:34] <dpm> yurchor, no worries. One question: I've seen you mention super tux kart on the team's page. Are the upstream translations managed in Launchpad? (I see translations are exposed in LP, but I'm not sure if they are using them)
[12:35] <dpm> oh, they do: http://supertuxkart.sourceforge.net/Translating_STK excellent :)
[12:35] <dpm> I didn't know
[12:36] <yurchor> They imposed "Restricted" for their translations. :'(
[12:41] <RawChid> Good day
[12:41] <dpm> yurchor, yeah, I know your view on that, but other people have equally strong opinions in favour of Restricted policies to ensure the quality of translations
[12:42] <dpm> hey RawChid ;)
[12:44] <RawChid> Hi dpm, I was looking to the ul10n tools. In search, one TODO is --extended-regexp. But I don't understand that.
[12:45] <RawChid> I heard that Pythons re is a superset of extended regex. So why do you want this?
[12:48] <dpm> RawChid, it might be a leftover from the previous implementation before using polib. I can't remember what I was using, but perhaps something like msggrep, which might have allowed that option. I think the option can go away now, but we should add a note on the help message explaining that regexps are allowed as the search argument, and which format of regexps we support
[12:50] <RawChid> Oke. I can do that. We support Pythons re i.e. Perl Compatible Regex
[12:51] <RawChid> Is that self-explanatory enough?
[12:52] <RawChid> Oh wait, now I'm not totally sure if that's true
[12:55] <RawChid> Oke, what I said is true, sorry for the inconvenience
[12:59] <dpm> :)
[12:59] <dpm> yeah, that should be enough
[13:54] <RawChid> Hey dpm, I was looking into the get-team-info
[13:59] <RawChid> Hmm, never mind.
[14:00] <dpm> RawChid, what was the actual question?
[14:01] <RawChid> Well, I thought it was looking for teams starting with ubuntu-l10n* (but some are lp-l10n).
[14:02] <RawChid> But the code is weird/untested, because it does both or something like that. Let me look further into it
[14:02] <dpm> the script is a bit involved, as there is no API to access translation groups, so I'm doing all sorts of workarounds there. It should look only for ubuntu-l10n-* teams
[14:03] <dpm> the code might be weird, but not untested, I've used it in the past, but it's been a while since I last used it
[14:04] <RawChid> Ok. Here https://translations.launchpad.net/+groups/ubuntu-translators I find 154 groups. But the script gives me 146 (while it says it gives me 141)
[14:06] <RawChid> The last one is a forgotten total += 1 (no big issue). But can you tell me why it don't give me 154?
[14:13] <RawChid> Ah, maybe only "Open subscription"? I doubt if it's useful to put a lot of effort in this script. What is your opinion?
[14:25] <RawChid> I understand that the 154 contains duplicates
[14:38] <dpm> RawChid, I haven't looked at the code in a while. I agree that this is not the script with the most priority to look at, but it still gives us important info. So if you're looking for todos, this might be a nice one to tackle :)
[14:44] <dpm> RawChid, on the other hand, forget what I've just said: for now it might be more useful to have a lp_set_pot_name script that does the same as lp_set_pot_priority but for setting the name instead of the priority
[14:57] <RawChid> Oke
[14:59] <RawChid> dpm, I get an error when running the set_pot_priority script. lazr.restfulclient.errors.Unauthorized: HTTP Error 401: Unauthorized   I thought you gave me permission for these actions?
[15:00] <dpm> RawChid, I gave you permission on staging, so either the staging database has been synced with production and thus I have to set the permissions again, or you're not using staging
[15:01] <serfus> old translation bugs which are invalid today should be "also affectes ubuntu-translation" ?
[15:02] <dpm> RawChid, it should work now, I re-added you to https://staging.launchpad.net/~ubuntu-translations-coordinators
[15:02] <serfus> (i'm not sure why ubuntu translation is not set as also affected)
[15:02] <dpm> serfus, I'm not sure I understand the question, could you give me an example of such bug?
[15:02] <serfus> https://bugs.launchpad.net/ubuntu/+source/language-pack-he/+bug/324448
[15:02] <ubot4> Launchpad bug 324448 in language-pack-he (Ubuntu) (and 1 other project) "TypeError traceback immediately after start (affects: 1) (heat: 4)" [Undecided,New]
[15:03] <serfus> i'm closing hebrew related bugs
[15:03] <serfus> this one is clearly affecting the ubuntu-translation project but is not shown there
[15:03] <serfus> the bug is invalid (i just confirmed this)
[15:04] <serfus> so i was wondering if i should add the ubuntu-translation project as affected
[15:04] <RawChid> Thnx dpm!
[15:04] <kelemengabor> serfus: it the bug is no longer there, why?
[15:04] <dpm> serfus, as it's a really old bug and confirmed to be invalid, I'd just mark the language pack task as invalid. No need to add an ubuntu-translations task and generate unnecessary e-mail
[15:05] <serfus> kelemengabor, didin't get you
[15:05] <serfus> dpm, alright
[15:05] <RawChid> dpm, I still get the same error. Maybe I need to wait some time till the changes are applied?
[15:06] <RawChid> (I'm using staging)
[15:06] <kelemengabor> serfus: I meant, it the problem is already fixed, then there is no need to track it
[15:06] <dpm> RawChid, hm, I'm not sure why. The changes should be effective immediately.
[15:06] <serfus> kelemengabor, okay then
[15:10] <dpm> RawChid, I'm not sure why you're getting the errors. Would you mind asking on #launchpad-dev, telling them what you're trying to do, that you're using staging, that you've got the permissions in staging, etc., etc.? They should be able to help, as they're the most knowledgeable people on how the LP API works
[15:11] <RawChid> Oke, I'll do that
[15:13] <RawChid> dpm: how can I see that I got the permission?
[15:13] <RawChid> Being member of https://staging.launchpad.net/~launchpad-translators ?
[15:20] <dpm> RawChid, see the link above ^^ I made you a member of https://staging.launchpad.net/~ubuntu-translations-coordinators, who should have the permissions to change template properties
[15:21] <RawChid> ack
[15:26] <j1mc> dpm: i passed along your contact info to the docs lead of openstack in case she has any questions about some translations stuff. (they use launchpad.) she is very smart and resourceful, so i don't think she'll overwhelm you with questions... i just wanted to give you a heads-up.
[15:26] <j1mc> she may not even be contacting you any time soon.
[15:26] <j1mc> her name is anne gentle
[15:27] <dpm> j1mc, sure, no worries, I saw it this morning. Don't ever worry about passing my contact info if you think it's useful :)
[15:27] <j1mc> dpm: oh, she contacted you?  thanks for being willing to be a resource for translations. :)
[15:29] <dpm> j1mc, no, no, she didn't contact me, with "I saw it this morning" I meant the e-mail you CC'd me on
[15:29] <j1mc> ah, gotcha
[15:36] <dpm> :)
[20:26] <serfus> i'm seeing a spelling mistake in synaptic but in launchpad it's translated correctly
[20:26] <serfus> any idea how this could have happend, or rather how can this be fixed?


[06:47] <luna__> There was no Daily or Canary builds of 22.10 yesterday, any specific reason?
[06:51] <luna__> got an answer from @seb128 mirrors was down yesterday
[10:32] <Habbie> hello! latest systemd-resolved on ubuntu:kinetic in Docker fails to install because it can't overwrite/move /etc/resolv.conf - because Docker does not allow that
[10:32] <Habbie> I looked in launchpad but did not see a ticket
[10:32] <Habbie> has anybody perhaps already looked into this problem?
[11:23] <athos> Habbie: this is an interesting one :) Would you mind filing a bug in https://bugs.launchpad.net/ubuntu-docker-images ?
[11:24] <athos> What is happening there is that /etc/resolv.conf is a special file in docker containers (it is mounted in the running container)
[11:27] <athos> now, during systemd-resolved installation, dpkg tries to create a link of the file (note that overwritting the file is not an issue), which fails because we cannot create hard links across mounts
[11:34] <Habbie> indeed, i was aware of that docker property
[11:34] <Habbie> will file
[11:35] <Habbie> (was not aware of the separate project)
[11:39] <athos> I am unsure if that should be the proper place to file it, since right now I am unsure about where a fix should go (could be dpkg, systemd, docker, ...)
[11:39] <Habbie> same
[11:39] <Habbie> i also couldn't figure out how 'apt install devscripts' pulled resolved in
[11:39] <Habbie> --no-install-recommends stops that
[11:40] <athos> But I'd say, let's bring this to the folks building the images, and we can expand from there :)
[11:40] <Habbie> (i don't need resolved - i just need devscripts)
[11:40] <Habbie> yes
[11:40] <athos> let me know when you have a bug!
[11:41] <athos> Habbie: oh, I was wondering why you needed systemd-resolved at all in a docker image, now I get it
[11:41] <Habbie> i'll note that in the ticket too
[11:42] <Habbie> https://bugs.launchpad.net/ubuntu-docker-images/+bug/1988300
[11:44] <Habbie> athos, ^
[11:49] <athos> btw, I was about to suggest that not installing recommended packages would be a workaround for you :) I see you added that to the bug! thanks
[11:52] <Habbie> yes
[11:52] <Habbie> currently testing that in my CI over all debian/ubuntu-variants
[11:52] <Habbie> because it would not be a surprise if that dropped something i did need
[12:08] <Habbie> it worked :)
[13:24] <luna__> and no new images today as the Canonical datacenter in London has sad network today
[19:15] <nteodosio> nicolasbock: A normal apt upgrade, not a dist-upgrade, correct?
[19:20] <nicolasbock> Well it was a dist upgrade
[19:20] <nicolasbock> Let me paste the logs
[19:23] <tomreyn> is there some place to read the first part of your conversation? i *did* read the part in #ubuntu
[19:23] <jbicha> I missed the earlier discussion too
[19:25] <tomreyn> (don't worry if you'd just like to sort it out between yourselves, though.)
[19:25] <nicolasbock> Sorry tomreyn , we switched channels. I ran a `dist-upgrade` yesterday which among other packages upgrade `gnome-shell`. Since then `gdm3` throws an error message.
[19:25] <nicolasbock> It's just a grayish screen with a general message stating that "something went wrong"
[19:25] <nicolasbock> I have logs and will paste those in a second
[19:26] <jbicha> when was the last time you upgraded that machine?
[19:26] <nicolasbock> The day before yesterday
[19:27] <nicolasbock> I typically upgrade every day at least once
[19:27] <nicolasbock> However I do not log out of gnome every day
[19:27] <nicolasbock> Only if I am told that a reboot is required
[19:27] <nicolasbock> This might have broken earlier and I didn't notice
[19:28] <jbicha> we did a big upgrade of evolution-data-server stuff that landed around Monday evening. Before that, gnome-shell 43 Beta landed on Thursday of last week
[19:29] <nicolasbock> evolution-data-server is still being kept back
[19:29] <nicolasbock> But the 43-beta is installed
[19:29] <nicolasbock> Jee, that log is pretty long
[19:29] <nicolasbock> Can't I upload a file to paste.ubuntu.com?
[19:29] <jbicha> that's your problem. You definitely need evolution-data-server 43 to be updated
[19:30] <jbicha> It's not possible to run apps or services that directly link against both libsoup2 and libsoup3 simultaneously
[19:30] <nicolasbock> How should I do that upgrade?
[19:30] <nicolasbock> A regular upgrade keeps it back
[19:30] <jbicha> you should do a   sudo apt dist-upgrade
[19:30] <nicolasbock> Ad is a dist-upgrade
[19:31] <nicolasbock> Right now `evolution-data-server gnome-calendar gnome-clocks gnome-initial-setup libgweather-4-0` are being held back by a dist-upgrade
[19:31] <jbicha> please post a paste of the exact error
[19:32] <nicolasbock> https://paste.ubuntu.com/p/76D6nQy2Tw/
[19:32] <jbicha> I probably should have added more Breaks relationships to the evolution-data-server transition. What I added was enough if you were able to upgrade everything
[19:32] <tomreyn> did you actually mean to do a release upgrade to kinetic, though, or did you actually do that, or were you already on kinetic (on purpose)?
[19:32] <jbicha> sudo apt install evolution-data-server
[19:34] <nicolasbock> https://paste.ubuntu.com/p/z5H6nVWPN8/
[19:34] <nicolasbock> tomreyn: I am already on kinetic
[19:34] <nicolasbock> And yes, on purpose :)
[19:35] <jbicha> sudo apt update; sudo apt dist-upgrade
[19:36] <jbicha> the version of gnome-settings-daemon available in kinetic is 43~beta-1ubuntu3
[19:36] <nicolasbock> Same thing jbicha
[19:36] <jbicha> sudo apt install gnome-settings-daemon
[19:37] <nicolasbock> https://paste.ubuntu.com/p/Cxt37GzyWk/
[19:37] <jbicha> you shouldn't be using Pop!_OS repos on Ubuntu
[19:38] <nicolasbock> Ok, let me disable those
[19:38] <jbicha> sudo apt install --mark-auto gnome-settings-daemon gnome-settings-daemon-common/kinetic
[19:38] <jbicha> just disabling isn't enough. You need to get back to the Ubuntu versions
[19:38] <nicolasbock> https://paste.ubuntu.com/p/XHSFJKPZkg/
[19:39] <arraybolt3[m]> nicolasbock: If this is Pop!_OS that you're trying to morph into Ubuntu Kinetic... you are going to have a lot more work to do than just disabling repos.
[19:39] <jbicha> sudo apt install --mark-auto gnome-settings-daemon/kinetic gnome-settings-daemon-common/kinetic
[19:39] <arraybolt3[m]> You'll probably want to just download a Kinetic daily ISO and install from scratch. (And if you can't do that because this is a production system, then you should probably wipe everything and install a stable version of Ubuntu.)
[19:39] <jbicha> ppa-purge is great for disabling PPAs & trying to get back to baseline. The PPA needs to be enabled first. I've never tried if ppa-purge works for other apt repos
[19:39] <nicolasbock> That last one worked jbicha
[19:40] <nicolasbock> arraybolt3[m]: Hmm, I am starting to realize that :/
[19:40] <jbicha> that /kinetic suffix (or whatever series of Ubuntu you are on) is really useful for trying to get back to the baseline if you know exactly which packages you need to change
[19:40] <nicolasbock> I didn't know that trick jbicha
[19:40] <jbicha> If you're using Pop!_OS, you're on your own. Pop!_OS wouldn't be able to adapt to our changes that quickly
[19:41] <nicolasbock> I wasn't really on Pop!_OS but was using their power manager only
[19:41] <nicolasbock> Which I guess I'll need to stop
[19:41] <jbicha> nicolasbock: are you using a PPA for that?
[19:41] <nicolasbock> Yes theirs
[19:41] <jbicha> I encourage you to run ppa-purge on their PPA (like I said, it needs to be enabled first)
[19:42] <nicolasbock> For a while I was using my own PPA and built packages from theirs for kinetic
[19:42] <nicolasbock> Ok will do that jbicha
[19:42] <nicolasbock> I'll try gmd3 now
[19:42] <jbicha> ideally, they would get their improvements upstream into Ubuntu (perhaps even into Debian) but honestly, they haven't done much of that yet
[19:43] <jbicha> perhaps they see some competitive advantage to have unique fixes in their repos. Or perhaps they're really busy. Or perhaps they just don't see the benefit yet
[19:47] <jbicha> your system could have been broken for a while. We did the gnome-desktop transition 3 weeks ago
[19:48] <jbicha> but maybe it didn't break good until this week's evolution-data-server transition
[19:52] <nicolasbock> Thanks jbicha for your help!
[19:52] <nicolasbock> It's working again
[19:53] <nicolasbock> I purged all of the POP!_OS packages
[19:53] <nicolasbock> I agree, it would be nice if they upstreamed their changes
[19:54] <nicolasbock> I think I didn't notice the breakage until I rebooted the system
[19:54] <jbicha> the power management thing is interesting because GNOME went a different way with power-profiles-daemon
[19:54] <nicolasbock> The one thing I care about are their charging thresholds
[19:54] <nicolasbock> You can set a max chanrge on your laptop
[19:54] <jbicha> is it a system76 computer?
[19:54] <nicolasbock> Yes
[19:56] <jbicha> you could file an issue with system76/pop about the conflict. But honestly, you might just need to stick with distro releases System76 supports (so no Ubuntu alpha for you)
[19:56] <nicolasbock> Yeah :/
[19:57] <nicolasbock> They seem to be moving away from a more vanilla Ubuntu experience to doing their own thing
[19:58] <nteodosio> Ah, glad to see this was solved already! Going forward, it should be a good idea to mention non-official sources upfront since many times they are the cause of the issue.
[20:04] <nicolasbock> Yes good point
[20:12] <nicolasbock> OMG it's nice to be on Gnome after having to use KDE for a while :)
[21:06] <enigma9o7[m]> Apperantly epiphany is testing extensions, I hope when it's released to regular beta, there'll be an extension to use the gnome extensions website integration.
[21:06] <enigma9o7[m]> It has seemed odd to me that site would tell me it doesnt detect gnome when i was using gnome web!
[21:24] <jbicha> enigma9o7[m]: yeah, it doesn't look like the Firefox extension works for Epiphany yet. Also Epiphany 43 currently disables extensions by default.


[11:45] <AlanBell> spd-say "ubuntu oh-nigh-ric osselot" <- does that sound right?
[11:45] <AlanBell> spd-say "ubuntu oneiric ocelot" <- compared to that
[15:10] <javierrivera> hi, someone can help me with python and indicators?
[15:12] <javierrivera> I have made a simple program that shows an indicator and works 11.10, but in 10.04 there is no icon. There is a space on the indicator bar, and the menu is there if you hoover with the mouse, but it doesn't show the icon
[20:55] <andyrock> DBO, where you read that xdnd data can change during the drop? can you pass me the link please?


[12:58] <cjwatson> cody-somerville,persia,geser,nixternal,soren,stgraber: DMB meeting in three minutes, by my calendar
[12:58] <cjwatson> two
[12:58] <cjwatson> bagsy not chair, since I chaired the last mega-meeting
[13:00] <cody-somerville> I should note that I won't usually be able to make this time. I saw an e-mail about there being a proposed time change but I thought I'd have more time to respond before the change was actually made.
[13:00] <cjwatson> the discussion dragged on for months
[13:00] <cjwatson> I'm sorry you didn't feel there was enough time to respond, but in any event it was clear that no one time was good for everyone.  Can you make the 1900 UTC slot in the rotation?
[13:01]  * stgraber waves
[13:02] <cody-somerville> I haven't had a chance to read the e-mail yet. I was sick for most of last week and on vacation the week before.
[13:02]  * geser is here
[13:03] <geser> but as I'm at work, I'm not the best candidate for chair
[13:03] <cjwatson> Date: Tue, 31 Aug 2010 13:22:45 +0100
[13:03] <cjwatson> Please speak now or forever hold your peace (at least until the next
[13:03] <cjwatson> time).
[13:03]  * barry waves
[13:04]  * stgraber is also at work with a face-to-face meeting in 57 minutes (just after DMB) so probably not the best to chair that one either, sorry.
[13:05] <cody-somerville> cjwatson, Yea, 1900 UTC shouldn't be a problem at all.
[13:05] <cjwatson> there was also a thread from early July that AFAICS you didn't follow up to, Cody
[13:05] <cjwatson> ok, good
[13:05] <cjwatson> cody-somerville,geser: can one of you chair, perhaps?
[13:06] <geser> cjwatson: how far up on your TODO list is setting up the voting for the free DMB seat?
[13:06] <cjwatson> we appear to have basic quorum at least
[13:06] <cjwatson> geser: not very; if you'd like to take it over, please do
[13:06] <geser> is there a howto for it?
[13:07] <cjwatson> I don't think so
[13:07] <cjwatson> which is one reason I haven't done it yet
[13:07] <raphink> Hi guys, Raphael Pinson here, hope I'm not too late for the DMB
[13:08] <cody-somerville> I guess I can chair.
[13:08] <cody-somerville> #startmeeting
[13:08] <MootBot> Meeting started at 07:08. The chair is cody-somerville.
[13:08] <MootBot> Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE]
[13:09] <cody-somerville> Do we have quorum?
[13:10] <stgraber> we are at least 4 on IRC from what I can see, so I think so.
[13:11] <cjwatson> chair> thanks
[13:11] <cody-somerville> [TOPIC] Administrative Matters: Review Marco Rodrigues participation in Ubuntu Development
[13:11] <MootBot> New Topic:  Administrative Matters: Review Marco Rodrigues participation in Ubuntu Development
[13:11] <cody-somerville> [LINK] https://wiki.ubuntu.com/MarcoRodrigues/ParticipationApplication
[13:11] <MootBot> LINK received:  https://wiki.ubuntu.com/MarcoRodrigues/ParticipationApplication
[13:13] <cody-somerville> He doesn't appear to be here.
[13:13] <cjwatson> we should consider in absentia I think
[13:14] <cjwatson> I find ScottK's comment disturbing, and am looking for a citation so that I can read more about it
[13:14] <cjwatson> (regarding debian-games)
[13:14] <cody-somerville> Indeed.
[13:15] <cjwatson> does anyone have one to hand?
[13:15] <cjwatson> (this is not doubting ScottK; I'm looking for a citation so that I can see how recent it is and make my own judgement about the circumstances)
[13:15] <geser> that should be around the same time as his trouble in Ubuntu
[13:16] <geser> at least I don't know of any more recent one
[13:16] <ScottK> It's not particularly recent.  It was shortly after he was asked not to contribute to Ubuntu.
[13:16] <ScottK> (I looked for the relevant message on the debian-games archive and couldn't find it)
[13:17] <ScottK> The issue I was attempting to bring up was not that it was a recent problem, but that his description of his involvement with Debian is at best incomplete.
[13:18] <cody-somerville> He seems active in Debian in other teams.
[13:19] <cjwatson> his endorsements would be OK (if sparse) for a new application, but they seem a bit half-hearted for the standard of "MOTUs supporting this wish actively" (https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/003067.html)
[13:20] <cjwatson> to be honest, what I would be looking for is people saying "he's great now, we'd really like him back because it would take so much load off our shoulders"
[13:20] <cody-somerville> Its not clear to me what exactly Marco wants.
[13:21] <cjwatson> I certainly appreciate his efforts in cleaning up bugs against removed packages in Debian, although it is worth noting that ftpmaster is looking to do that automatically instead
[13:21] <cjwatson> cody-somerville: he is banned from participating in Ubuntu development; he wants that ban lifted
[13:22] <cjwatson> (see https://lists.ubuntu.com/archives/ubuntu-motu/2008-January/003067.html)
[13:22]  * persia apologises for being tardy
[13:25] <cjwatson> does anyone else have an actual opinion here?  mine seems to currently be: I'm not seeing a pressing reason to lift the ban, although I kind of dislike having to ban people as a general rule and understand that it is worth reviewing any bans we do have to impose from time to time
[13:26] <cjwatson> and what I'd really appreciate in trying to form a more complete opinion is more strong opinions from other developers who've interacted with Kmos recently
[13:28] <stgraber> I'd also appreciate getting more feedback (be it negative or positive) and ideally more documented than what we currently have
[13:29] <geser> some more feedback would be nice, I see currently on two weak endorsements from ~ubuntu-dev and one comment against lifting from ~ubuntu-dev
[13:29] <persia> I don't really like administering the ban, and the few bits of feedback I've received have been positive, but I'll admit to not having much feedback.
[13:30] <cjwatson> perhaps it would be worth deferring, and have the minutes of this meeting explicitly call for comments from developers?
[13:30] <cody-somerville> I guess my question is, is it justified to require more from kmos than any other to allow him to participate because of his history? Should no longer being disruptive but instead on par with any new contributor be the necessary threshold to permit Marco to participate again?
[13:30] <cjwatson> cody-somerville: my feeling is that lifting a ban should require more than the normal threshold, simply because we have that prior history
[13:31] <cjwatson> that said, I don't think bans should be unalterably for life
[13:31] <persia> I think it ought require a lower threshold than we might require for other sorts of approvals we perform, simply because he's not permitted to engage in most of the activities we typically review.
[13:31] <cjwatson> interesting, and I see your point.  perhaps a different kind of threshold
[13:31] <persia> "different kind" is a better way of phrasing it, indeed.
[13:31] <cody-somerville> We don't require any review though for an individual to be able to participate.
[13:31] <cjwatson> I guess what I mean by a higher threshold is that it ought to require a higher level of enthusiasm from *people*
[13:32] <cjwatson> given that many of the problems were essentially social
[13:32] <persia> I believe we also must judge based on the criteria in the ban email, rather than anything else.
[13:33] <cjwatson> I agree, and I'm trying to extemporise "MOTUs supporting this wish actively" into something we can apply
[13:33] <cody-somerville> Why would a Ubuntu developer get enthusiastic about someone who isn't allowed to participate in Ubuntu development?
[13:33] <cjwatson> I don't know about you but I develop in more than just Ubuntu :-)
[13:33] <cjwatson> plenty of people have Debian experience for instance
[13:34] <persia> And plenty who don't end up spending time reviewing changes coming from Debian.
[13:34] <geser> is Kmos allowed to contribute through proxies (other MOTUs)?
[13:34] <cjwatson> the positive comments so far seem to be essentially "I got a few patches and they seemed OK"
[13:34] <cjwatson> and that kind of thing
[13:34] <persia> geser, That's a complex question: I'd say that some of the work he's done with pitti skirts the edge of banned behaviour, whereas I was confortable with his work with liw (computer-janitor)
[13:35] <cjwatson> Lucas' comment involves some of the most direct experience, and is the most positive
[13:35]  * persia spends some time each week reviewing apparent activity in Ubuntu and Debian, and counselling when there is an appearance of Ubuntu-development-related work
[13:35] <cjwatson> persia also commented in the report "The vast majority of the reports I have received about his work in Debian have been positive, especially those received in the last year"
[13:35] <cody-somerville> I think we should give Marco a second chance, ie. a probationary period.
[13:36] <cody-somerville> At the end of the probationary period, we can evaluate any comments or complaints made against kmos after that time and make a decision if he can continue to participate or not.
[13:36] <cjwatson> I'm ambivalent about the ban-skating; on one hand I disapprove of working around bans, but on the other it seems somehow mean to complain based purely on that
[13:37] <persia> I don't think it requires a probationary period.  I think the question before us is simply: shall we allow him to start as a new contributor.  If he doesn't behave, there's plenty of precedent to ask him to stop.  The risk is that we cause annoyance for developers, some of whom have already spent way too much time untangling from past actions.
[13:37] <cjwatson> persia: were the three cases of ban-skating recent?
[13:37] <cjwatson> the ones that caused developers to report them
[13:38] <cody-somerville> persia, If we let him start as a new contributor than the same burden of proof to ban a new contributor will be required to ban him again.
[13:38] <geser> how recent is "recent"?
[13:38] <cjwatson> how about "how long ago were they?"
[13:38] <persia> One of them was somewhere around lucid release (I think after beta freeze).  The others were earlier.  I'd have to dig logs to get exact dates.
[13:39] <cjwatson> rough impression is OK
[13:39] <cody-somerville> We need to move on.
[13:39] <geser> how severe were those annoyances?
[13:40] <persia> More common behaviour is to watch IRC (he's only +q), and when something he can sort comes up, passing the answer to someone in /query, which I tend to tolerate so long as nobody complains and it's not too obvious.
[13:40] <persia> geser, People saying "Isn't he banned"?  I don't recall any cases where there was something he did that caused specific cleanup issues.
[13:40] <cody-somerville> I motion to postpone consideration.
[13:41] <persia> Let me qualify that: I don't remember any such after the initial issues related to implementation of the ban.
[13:42] <cjwatson> I second Cody's motion as long as the postponement includes a call for feedback from developers
[13:42] <cjwatson> (otherwise we'll just postpone indefinitely)
[13:42] <geser> he should get allowed to work through a proxy (a MOTU) to get some actual feedback
[13:43] <ScottK> Given that the threshold to get banned is SO high, it seems odd to me to consider it was a mistake.
[13:43] <persia> geser, I'm not sure how that is different from any other participation by a non-member of ~ubuntu-dev: to me that is equivalent to lifting the ban.
[13:44] <cody-somerville> [VOTE] Postpone consideration of Marco Rodrigues's request and call for feedback from developers.
[13:44] <MootBot> Please vote on:  Postpone consideration of Marco Rodrigues's request and call for feedback from developers..
[13:44] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[13:44] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[13:44] <persia> ScottK, I very much don't consider the ban a mistake.  I think it was important that it happened.  I happen to know that Kmos agrees.
[13:44] <cjwatson> it's different because the proxy is volunteering to essentially be exposed to somebody who may turn out to waste their time
[13:44] <cody-somerville> +1
[13:44] <MootBot> +1 received from cody-somerville. 1 for, 0 against. 0 have abstained. Count is now 1
[13:44] <cjwatson> and to take responsibility for the actions that result that are visible to other Ubuntu developers
[13:44] <persia> I'm just under the impression that he's close to having reached the threshold required in the ban terms.
[13:44] <persia> +1
[13:44] <MootBot> +1 received from persia. 2 for, 0 against. 0 have abstained. Count is now 2
[13:44] <geser> +1
[13:44] <MootBot> +1 received from geser. 3 for, 0 against. 0 have abstained. Count is now 3
[13:44] <cjwatson> +1 # with comments above
[13:44] <MootBot> +1 received from cjwatson. 4 for, 0 against. 0 have abstained. Count is now 4
[13:44] <stgraber> +1
[13:44] <MootBot> +1 received from stgraber. 5 for, 0 against. 0 have abstained. Count is now 5
[13:44] <cody-somerville> #endvote
[13:45] <cody-somerville> whats the command to end the vote?
[13:45] <geser> persia: eg. a new contributor can use requestsync, he should send them first to his proxy instead of directly to LP and ~ubuntu-sponsors
[13:45] <cjwatson> [ENDVOTE]
[13:45] <cody-somerville> [ENDVOTE]
[13:45] <MootBot> Final result is 5 for, 0 against. 0 abstained. Total: 5
[13:45] <persia> geser, Ah, so another oversight period.  Let's discuss next time, but I think I could accept that sort of thing, if there were volunteers.
[13:46] <cody-somerville> [ACTION] cody-somerville: Call for feedback from developers on Marco Rodrigues's request
[13:46] <MootBot> ACTION received:  cody-somerville: Call for feedback from developers on Marco Rodrigues's request
[13:46] <cody-somerville> [TOPIC] PerPackageUploader Applications: Barry Warsaw for gtimelog
[13:46] <MootBot> New Topic:  PerPackageUploader Applications: Barry Warsaw for gtimelog
[13:46] <cjwatson> FIFO order for the rest of the agenda is barry then raphink
[13:46] <cjwatson> ah yes :)
[13:46] <cody-somerville> [LINK] https://wiki.ubuntu.com/BarryWarsaw/MyApplication
[13:46] <MootBot> LINK received:  https://wiki.ubuntu.com/BarryWarsaw/MyApplication
[13:47] <barry> hi guys
[13:48] <cody-somerville> barry, Please briefly introduce yourself and the rationale for your request.
[13:49] <barry> barry warsaw here.  i'm on platform foundations, and a long time python core dev.  i have ppu for a handful of packages and was recently given upstream commit privs to gtimelog.  since i'll be spinning packages for it i'd like to get ppu for gtimelog in ubuntu
[13:49] <cody-somerville> barry, How many times have you uploaded gtimelog to Ubuntu?
[13:50] <barry> cody-somerville, one sponsored upload.  the version in lucid was *way* out of date (squeeze too), so i worked w/upstream to get a new version out, then fixed the packaging and got sponsor to upload
[13:51] <cody-somerville> barry, Does gtimelog use any patch system?
[13:51] <barry> quilt3
[13:52] <persia> barry, How is the state of gtimelog in Debian?
[13:52] <geser> barry: I guess doko reviewed the new packaging before sponsoring. Did he found any issues you needed to fix?
[13:53] <barry> persia, we need to get 0.4.0 into debian.  i've contacted the debian maintainer and between him, myself, and upstream author, we're trying to work out a transfer or cooperation
[13:53] <barry> geser, no, i don't think so
[13:53] <barry> persia, iirc the current registered deb maint for gtimelog is mia
[13:54] <cody-somerville> barry, Do you you build your packages in a chroot before uploading to Ubuntu?
[13:54] <persia> It's orphaned, actually: Debian bug #585145
[13:54] <cjwatson> cody-somerville: (I don't ;-) )
[13:55] <barry> cody-somerville, yep, and a ppa (~gtimelog-dev)
[13:55] <cody-somerville> barry, Are you subscribed to bug reports filed against gtimelog in Ubuntu?
[13:56] <barry> cody-somerville, i am
[13:56] <barry> cody-somerville, upstream uses lp for bugs and i am now an admin for ~gtimelog-dev so i'm watching everything (at least i think i am ;)
[13:56] <cody-somerville> Any other questions for barry before I call the vote?
[13:57]  * stgraber doesn't have any.
[13:57]  * cjwatson has none, other than get on with building enough breadth that we can just make you a MOTU already :-)
[13:58] <persia> Or something else, as appropriate.
[13:58] <barry> cjwatson, :)
[13:58] <barry> persia, i actually think we should add some kind of python packageset
[13:58] <cody-somerville> [VOTE] Grant Barry Warsaw PPU permission to gtimelog
[13:58] <MootBot> Please vote on:  Grant Barry Warsaw PPU permission to gtimelog.
[13:58] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[13:58] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[13:58] <cjwatson> +1
[13:58] <MootBot> +1 received from cjwatson. 1 for, 0 against. 0 have abstained. Count is now 1
[13:58] <stgraber> +1
[13:58] <geser> +1
[13:58] <MootBot> +1 received from stgraber. 2 for, 0 against. 0 have abstained. Count is now 2
[13:58] <MootBot> +1 received from geser. 3 for, 0 against. 0 have abstained. Count is now 3
[13:58] <cody-somerville> +1
[13:58] <MootBot> +1 received from cody-somerville. 4 for, 0 against. 0 have abstained. Count is now 4
[13:59] <persia> +0 : insufficient prior history of work with the package: one upload does not show maintainance history
[13:59] <MootBot> Abstention received from persia. 4 for, 0 against. 1 have abstained. Count is now 4
[13:59]  * stgraber is off to another meeting now
[14:00] <cody-somerville> [ENDVOTE]
[14:00] <MootBot> Final result is 4 for, 0 against. 1 abstained. Total: 4
[14:00] <barry> persia, ack. it's a rather slow moving package, but i do intend to do more bug fixing on it
[14:00] <soren> o/
[14:01] <cody-somerville> Is that successful?
[14:01] <cjwatson> oh hello soren
[14:01] <persia> barry, Understood.  Note that I was +0 rather than -1 because I know you'll do a good job on it, but I think that you don't qualify under PPU guidelines according to https://wiki.ubuntu.com/UbuntuDevelopers
[14:01] <persia> cody-somerville, Yes.
[14:01]  * barry nods
[14:02] <soren> Sorry, apparantly I suck at timezones.
[14:02] <cody-somerville> [VOTE] Ubuntu Core Developer Application:  Raphaël Pinson (recovery)
[14:02] <MootBot> Please vote on:  Ubuntu Core Developer Application:  Raphaël Pinson (recovery).
[14:02] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[14:02] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[14:02] <cody-somerville> err..
[14:02] <cody-somerville> [ENDVOTE]
[14:02] <MootBot> Final result is 0 for, 0 against. 0 abstained. Total: 0
[14:02]  * cjwatson doesn't interpret the "uploads" there as a strict plural; it depends on the circumstances
[14:02] <cody-somerville> [TOPIC] Ubuntu Core Developer Application:  Raphaël Pinson (recovery)
[14:02] <MootBot> New Topic:  Ubuntu Core Developer Application:  Raphaël Pinson (recovery)
[14:02] <raphink> hehe ;)
[14:02] <cody-somerville> [LINK] https://lists.ubuntu.com/archives/devel-permissions/2010-August/000098.html
[14:02] <MootBot> LINK received:  https://lists.ubuntu.com/archives/devel-permissions/2010-August/000098.html
[14:02] <raphink> I can give a summary here :-)
[14:03] <cody-somerville> raphink, please do and please include a link to your launchpad page
[14:03] <raphink> Hello, I'm Raphael Pinson. Some of you probably know me from my involvment in Kubuntu as a core-dev, mostly between 2005 and 2007. Since then, I have mostly worked as a Systems Engineer for a major telecom company and built a buildd/wanna-build/reprepro system to automate the creation of Debian/Ubuntu packages for a fleet of about 3000 servers. My recent involvment in Ubuntu has mostly been on projects like byobu (with kirkland) or augeas (
[14:03] <raphink> with nxvl).
[14:03] <raphink> Like I posted on the ML, some time ago, I lost my ubuntu-dev, ubuntu-coredev and ubuntu-members upload rights as I hadn't renewed my LP memberships. Thanks to the advice of canonical employees, I was able to get my ubuntu-members membership back so I can use my @ubuntu.com email again, but I would like to recover my upload rights as well. I have quite a few packages to contribute (mostly server software such as db5.0, mysql-server-5.1 or db
[14:03] <raphink> xml) and I'd be happy to upload them.
[14:03] <raphink> LP page: https://launchpad.net/~raphink
[14:03] <soren> I hope none of that is intended for Maverick?
[14:04] <cody-somerville> [LINK] https://launchpad.net/~raphink
[14:04] <MootBot> LINK received:  https://launchpad.net/~raphink
[14:04] <raphink> the wiki page is a bit oldish probably ;-)
[14:04] <raphink> soren: I'm not in a hurry to upload anything, and when it comes to db5.0 for example, I would certainly speak to the db4.8 package maintainer first ;-)
[14:05] <raphink> although db5.0 doesn't exist in the repositories yet, so it wouldn't hurt
[14:05] <nixternal> woo, i see raphink \o/
[14:05] <raphink> haha, hi nixternal :-)
[14:06] <cody-somerville> How long ago did your membership expire?
[14:06] <raphink> hmmm probably almost a year ago I would say, not sure of the date
[14:07] <raphink> the LP page for core-dev used to list deactivated members with the date
[14:07] <soren> Expired on 2009-03-13
[14:07] <cjwatson> Subject: raphink expired from team
[14:07] <cjwatson> Date: Fri, 13 Mar 2009 05:15:10 -0000
[14:07] <raphink> ok :)
[14:07] <soren> (According to https://edge.launchpad.net/~ubuntu-core-dev/+members  )
[14:07] <raphink> you're better than me at finding these info :-)
[14:07] <geser> raphink: what did you do to get up-to-date with current processes?
[14:08] <persia> raphink, What caused you to let your development lapse?
[14:08] <raphink> family :-)
[14:08] <raphink> there's priorities in life, contributing is important to me, but it's not the #1 priority
[14:08] <raphink> as far as processes and techiques geser
[14:08] <raphink> like I said, I'm ftpmaster at my work
[14:09] <raphink> so I'm the one training all the packagers in my company with all the packaging technos and processes (debian policy) when they need to
[14:09] <raphink> that doesn't necessarily ensure I know everything about the latest processes inside Ubuntu
[14:09] <raphink> but I'm up-to-date as far as packaging techniques go
[14:10] <raphink> I would certainly ask if in doubt
[14:10] <raphink> I know enough people around here to find experts in processes if I need to
[14:11] <cody-somerville> I'm quite hungry so I'd like to call the vote if nobody has any other questions.
[14:11] <raphink> hehe ;)
[14:13] <cjwatson> no questions
[14:13] <soren> I'm good.
[14:13] <cody-somerville> [VOTE] Ubuntu Core Developer Application:  Raphaël Pinson (recovery)
[14:13] <MootBot> Please vote on:  Ubuntu Core Developer Application:  Raphaël Pinson (recovery).
[14:13] <MootBot> Public votes can be registered by saying +1/-1/+0 in the channel, private votes by messaging the channel followed by +1/-1/+0  to MootBot
[14:13] <MootBot> E.g. /msg MootBot +1 #ubuntu-meeting
[14:13] <soren> +1
[14:13] <MootBot> +1 received from soren. 1 for, 0 against. 0 have abstained. Count is now 1
[14:13] <cody-somerville> +0
[14:13] <MootBot> Abstention received from cody-somerville. 1 for, 0 against. 1 have abstained. Count is now 1
[14:13] <persia> +1
[14:13] <MootBot> +1 received from persia. 2 for, 0 against. 1 have abstained. Count is now 2
[14:13] <geser> +1
[14:13] <MootBot> +1 received from geser. 3 for, 0 against. 1 have abstained. Count is now 3
[14:14] <cjwatson> +1 # generally happy for people to return as long as they can put some time in again and have put some effort into catching up
[14:14] <MootBot> +1 received from cjwatson. 4 for, 0 against. 1 have abstained. Count is now 4
[14:14] <cody-somerville> [ENDVOTE]
[14:14] <MootBot> Final result is 4 for, 0 against. 1 abstained. Total: 4
[14:14] <soren> (While I would prefer if people would just renew their memebership when Launchpad tells them to, I believe re-granting them their membership should be a formality)
[14:14] <cody-somerville> [TOPIC] Select a chair for the next meeting
[14:14] <MootBot> New Topic:  Select a chair for the next meeting
[14:14] <raphink> soren: sometimes you're on vacation when this happens ;-)
[14:15] <soren> They could be as up-to-date (or out-of-date) as the ones who manage to click "Renew".
[14:15] <raphink> thanks guys, enjoy your meal cody-somerville
[14:15] <soren> raphink: Precisely.
[14:15] <geser> the next meeting is at 19:00 UTC, right?
[14:15] <cody-somerville> yup
[14:15] <geser> then I should be able to chair it
[14:16] <cody-somerville> [ACTION] geser to chair next meeting
[14:16] <soren> Sorry about missing the first hour. /me adjusts calendar. :(
[14:16] <MootBot> ACTION received:  geser to chair next meeting
[14:16] <cody-somerville> #endmeeting
[14:16] <MootBot> Meeting finished at 08:16.
[14:16] <persia> soren, I like to hear why people left, and what they plan to do when they come back.  We had a couple cases in the past where people seemed to want things for vanity reasons, and I think it's important we don't encourage our repositories to be more vulnerable.
[14:17] <soren> persia: If they explicitly left, sure.
[14:17] <soren> persia: If they exired, less so.
[14:17]  * persia doesn't see much difference, since it's impossible to understand the mindset of folks not pressing the button
[14:17] <soren> persia: Is you're really serious about checking up on people every once in a while, we shoulnd't let people refresh on their own, but always come before the DMB to get it refreshed.
[14:17] <persia> That said, we could do a much better job about poking people who expire to ensure it's intentional.
[14:18] <raphink> that's more work for sure
[14:18] <persia> soren, I would prefer that were the case, personally.  The few discussions about it in which I've participated always fall down somewhere along the way.
[14:18] <soren> persia: /me finds it equally impossible to understand the mindset of people who /do/ press the button.
[14:18] <persia> raphink, I think that's the main reason we don't do it that way :)
[14:19] <persia> soren, Compeltely agreed.
[14:19] <raphink> from my experience, having your membership expire can be discouraging
[14:19] <persia> soren, Weel, identically impossible, rather.
[14:19] <raphink> as in, it might prevent you from uploading some things because you don't want to go through a process of renewal, DMB, etc.
[14:20] <persia> Ideally that shouldn't be something people consider hard or scary.
[14:21] <raphink> mhm
[14:22] <persia> Note that getting from here to my ideal world is a long, long journey :)
[14:22] <raphink> haha
[14:22] <geser> raphink: is the renewal process to hard/easy?
[14:22] <raphink> once you know about it, it's rather easy ;-)
[14:22] <raphink> maybe it's lacking documentation (or I'm bad at finding it)
[14:23] <geser> probably the first
[14:39] <persia> I think the (limited) documentation is some email to the MC list a long time ago.
[14:45] <raphink> persia: you were my documentation in that case iirc
[14:46] <persia> heh, yeah.  I need to upload increasing chunks of my memory to the wiki, a bad habit I've had for years now, sadly.
[14:47] <raphink> well, same here
[18:07] <kees> mdeslaur, jdstrand, sbeattie, robbiew, nxvl, jjohansen: security team meeting! ready?
[18:07] <jdstrand> o/
[18:07] <mdeslaur> hi!
[18:08] <sbeattie> hey
[18:08] <kees> quorum!
[18:08] <kees> okay, I'll start.
[18:08] <jjohansen> \o
[18:08] <kees> the update I was going to be working on has been delayed by upstream, so I'm going to find something else to do.
[18:08] <kees> the CVE triage last week was mysteriously light. it scares me.
[18:09] <mdeslaur> calm before the storm
[18:09] <sbeattie> kees: that's because the week before, it was painful
[18:09] <kees> ah-ha.
[18:09] <sbeattie> kees: feel free to go back and review the umpteen webkit/chromium and other issues I triaged.
[18:09] <robbiew> 0/
[18:09] <kees> I've been fighting with the rng qrt; dieharder is yelling about minor stuff
[18:09] <kees> sbeattie: let's hire someone to do that. :)
[18:10] <kees> I'm working on an embargoed issue, but that's mostly done and the solution is simple and in the hands of who needs it.
[18:10]  * jdstrand triaged some of the chromium ones
[18:11] <kees> I've got a topic for the end, so I'll stop here. jdstrand is up
[18:12] <jdstrand> last week I beat down a number of bugs in libvirt. one of them gave me a better understanding for my update
[18:13] <jdstrand> I still have to do lucid testing of all the peripheral applications as mentioned before... maybe this is the week that happens...
[18:13] <jdstrand> I'm on triage this week
[18:13] <jdstrand> I plan to do the get_file_list.sh audits (as part of ReleaseCycle) as well as do the qrt testing of applications that have apparmor profiles
[18:14] <jdstrand> I need jjohansen's network mediation fix though
[18:14] <kees> you mean maverick testing, yes?
[18:14] <jdstrand> jjohansen: do have an amd64 kernel for maverick
[18:14] <jjohansen> jdstrand: duh, I'll get you a kernel in about an hour
[18:14] <jdstrand> kees: yes-- run the qrt tests on maverick
[18:14] <jdstrand> kees: well, all of it-- all maverick, all the time
[18:15] <jdstrand> these things and any new bugs that come in should keep me busy this week
[18:15] <jdstrand> that's it from me. mdeslaur?
[18:15] <mdeslaur> my turn
[18:15] <mdeslaur> so, I finally released the fixes for CVE-2009-3555
[18:16] <jdstrand> \o/
[18:16]  * mdeslaur punches ubottu
[18:16] <mdeslaur> and there hasn't been any bugs reported against them so far, so it's looking good :)
[18:16] <jdstrand> mdeslaur: great, great job
[18:16] <jdstrand> jjohansen: oh, I forgot to thank you. thanks!
[18:17] <kees> yeah, awesome work mdeslaur
[18:17] <mdeslaur> this week, I'll be releasing: avahi, libgdiplus, libhx, libmikmod, lvm2 and mako updates
[18:17] <kees> wooo!
[18:17] <jdstrand> mdeslaur: is that all?
[18:17] <jdstrand> slacker
[18:17] <mdeslaur> lol
[18:17] <jdstrand> :)
[18:18] <kees> hehe
[18:18] <mdeslaur> that's it from me
[18:18] <mdeslaur> sbeattie?
[18:18] <sbeattie> I was on community last week.
[18:18] <sbeattie> I released a quassel update and also moved ant from security-proposed.
[18:20] <sbeattie> I still need to do an SRU upload for openjdk/lucid to address the haxb regressions, but want to look for other potential SRU fixes as well.
[18:20] <sbeattie> this week I'm in the happy place, so I should be able to do that.
[18:20] <sbeattie> I'm also hoping to pick up and push out a couple more updates.
[18:21] <sbeattie> I think that's everything.
[18:21] <sbeattie> Oh, as an aside, kees wasn't joking when he mention hiring someone for webkit security: http://webapps.ubuntu.com/employment/canonical_UP-USE/
[18:22] <sbeattie> (in case anyone reading is interested in applying)
[18:22] <jdstrand> yep
[18:22] <kees> that might be a twitter-worthy url, actually. I'll send that out.
[18:22] <sbeattie> that's all from me.
[18:22] <mdeslaur> oh! yeah, if you're a webkit hacker, please come join the coolest team: security! :)
[18:22] <jdstrand> (as well as Mozilla and Chromium)
[18:22] <jdstrand> and mozilla and chromium-- don't leave them out either :)
[18:22] <mdeslaur> and mozilla and chromium
[18:23] <mdeslaur> :)
[18:23] <jdstrand> I have a quick item for the end as well
[18:23] <kees> "Want to hack on webkit, chromium, firefox? Join the Ubuntu Security Team! http://webapps.ubuntu.com/employment/canonical_UP-USE/" <- sound good?
[18:24] <mdeslaur> yes
[18:24] <sbeattie> Works For Me.
[18:24] <jdstrand> s/firefox/and firefox/
[18:24] <jdstrand> but yes, sounds fun and positive :)
[18:24] <kees> edited and sent
[18:25] <kees> okay, jdstrand, you first on items
[18:25] <jdstrand> we may want to do the same in #ubuntu-mozillateam, since that is where all the browser guys hang out
[18:26] <jdstrand> oh, me, yes
[18:26] <jdstrand> it would be good if we all peeked at https://bugs.launchpad.net/ubuntu/maverick/+bugs for anything that we touch
[18:26] <jdstrand> I did this morning and believe the apparmor and libvirt ones are in hand, but other people's eyes would be great
[18:26] <mdeslaur> jdstrand: yeah, I took a look at the earlier
[18:26] <jdstrand> I think there are ~142 bugs there
[18:26] <jdstrand> cool
[18:27] <jdstrand> that was all I had
[18:27] <mdeslaur> there's libtiff that looked related to us
[18:27] <mdeslaur> kees: ^
[18:27] <kees> there are still a few libtiff issues that upstream is working on or worked on, yeah
[18:27] <mdeslaur> cool
[18:27] <kees> I wanted to have us think outloud about UDS planning.
[18:28] <kees> we already talked about how we wanted to have roundtables and scatter ourselves around the UDS to help guide stuff, but do we have anything more specific we want to do?
[18:29] <mdeslaur> kees: you mean stuff we'd like to cover in our roundtables?
[18:29] <kees> mdeslaur: no I meant more specifically. blueprints we think we can't do without, etc?
[18:30] <kees> mdeslaur: i.e. instead of last UDS's planning style ("what is anything we might be interested in?") I figured we could do "what is absolutely required?"
[18:31] <jdstrand> kees: we need to meet as apparmor upstream for sure
[18:31] <sbeattie> kees: I'm hoping to do a session with the qa team on increasing collaboration and usage of qa-r-t (again).
[18:31] <jdstrand> most of my stuff last time is moving BPs forward to track things todo
[18:32] <jdstrand> that sounded weird
[18:32] <kees> I'd like to talk to soyuz folks again; I'd like to see incremental publication so we can publish amd64 kernels while we wait on sparc, for example.
[18:32] <jdstrand> I have a lot todo; I'd like time to do it, but don't have a lot to discuss
[18:32] <jdstrand> kees: that would be very welcome
[18:33] <kees> jdstrand: yeah, agreed
[18:33] <kees> okay, so I guess we'll each make the bps we're interested in and go from there. :) that's really it from me.
[18:33] <jdstrand> kees: we could schedule some time to go through all the BPs and prioritize them into reality
[18:34] <kees> jdstrand: all the existing ones, you mean?
[18:34] <jdstrand> kees: ie, all the ones that didn't get completed-- at least for lucid and maverick
[18:34] <jdstrand> kees: that is the idea, yeah
[18:34] <jdstrand> we can reprioritize things
[18:34] <jdstrand> (if needed)
[18:35] <jdstrand> you know, so we don't lose track of old stuff that never got implemented due to time constraints and that we didn't move forward
[18:35] <jdstrand> maybe there isn't a lot, but I feel like it would be worth reviewing
[18:35] <kees> yup, totally. we did that for maverick too
[18:36] <jdstrand> cool
[18:37] <jdstrand> kees: speaking of bps, can you update https://blueprints.launchpad.net/ubuntu/+spec/security-m-gpg-migration? should probably be at least 'Started'
[18:37] <kees> yeah, good point.
[18:38] <kees> "slow progress"
[18:38] <jdstrand> mdeslaur: fwiw, evo in maverick seems just fine with the new keys
[18:38] <jdstrand> mdeslaur: I bet you already knew that though
[18:38] <mdeslaur> jdstrand: oh? I'm surprised
[18:39] <jdstrand> kees: I bet tbird is going to be ok too, since lucid and maverick have tbird >= 3.0
[18:39] <jdstrand> mdeslaur: I can verify sbeattie's USNs fine. I didn't try all the other stuff
[18:39] <mdeslaur> jdstrand: oh, the problem was with sending email, not verifying it
[18:39] <mdeslaur> jdstrand: but, it's probably fixed now
[18:39] <kees> yeah, once we validate tbird, it's probably time to do the GPG migration. I will write up the how-to.
[18:40] <jdstrand> kees: well, mdeslaur and I need evo to work :)
[18:40] <mdeslaur> I'll test evo this week
[18:40]  * sbeattie adds an apparmor todo item to migrate that project's key.
[18:41] <kees> jdstrand: I thought evo was okay? "evo in maverick seems just fine with the new keys"
[18:41] <kees> oh, er, I somehow skipped over "problem was with sending email"
[18:41] <jdstrand> kees: a) mdeslaur said sending was an issue and b) part of the bp is lucid compatibility.
[18:42] <kees> lucid!? that's so OOOOLD ;)
[18:42] <jdstrand> though if all but lucid/evo worked, I wonder if we could consider migrating our keys anyway
[18:42] <jdstrand> perhaps a disussion for after mdeslaur does his evaluation
[18:42] <kees> sounds good.
[18:43] <kees> sbeattie: did you follow the migration process that the debian folks published?
[18:43] <sbeattie> kees: yes.
[18:43] <jdstrand> kees: I don't have anything more wrt UDS otoh. I'd like to think about it more though
[18:43] <mdeslaur> well, if our users are running evo on lucid and can't verify our email signatures, that would be bad(tm)
[18:44] <jdstrand> mdeslaur: well, verifying does work on maverick-- but like you said, it needs to be evaluated fully
[18:44] <jdstrand> (ie, maybe verifying worked in lucid too)
[18:44] <kees> okay, anything else anyone wants to bring up?
[18:45] <jdstrand> kees: you are only working on dieharder with the rng?
[18:46] <jdstrand> I was planning to fire up some ec2 instances for rng !dieharder
[18:46] <kees> jdstrand: yeah, haven't done the non-dieharder tests. saw "$100" and decided to stay away :)
[18:47] <jdstrand> kees: hehe
[18:47] <jdstrand> I was told that is not a problem
[18:47] <jdstrand> kees: I'll take non-dieharder
[18:47] <kees> jdstrand: okay, cool
[18:49] <kees> alright, sounds like we're done. thanks!
[18:51] <jdstrand> thanks kees!
[18:51] <mdeslaur> thanks!


[10:57] <mpt> newz2000, you mentioned too many links as a clue to lack of credibility in a Web site
[10:58] <mpt> http://www.zmogo.com/gear/the-new-year-linux-resolution-day-5/ includes the morsel: "So, the first step in my clandestine scheme is to get Wine set up. I chose Wine mainly because its site is more appealing looking than VMware’s, which has all the sleek design features and well-considered organization of an expired domain name..."
[11:02] <mpt> and looking at the respective sites you can see he has a point
[14:53] <newz2000> mpt: yes, good examples
[14:55] <newz2000> yet if you worked at VMware what would you tell the people on your team was wrong with your website?
[14:55] <mpt> It hadn't occurred to me that I can tell whether a site is a parked domain within about 1 second
[14:55] <mpt> not sure why
[14:56] <mpt> Maybe I have a subconscious synonym detector. :-) (Parked domains often have lots of synonyms)
[14:57] <newz2000> Wow, that would have to be a remarkably fast synonym detector to operate within 1 second
[14:57] <newz2000> mpt: do you like the wine website better than vmware's?
[14:58] <mpt> They're both pretty dire
[14:59] <mpt> but the Wine one has at least stuff that's obviously supposed to be looked at first
[14:59] <mpt> It has a focus.
[14:59] <mpt> With the VMWare site, there are five-ish areas of text that have almost identical emphasis, and the other big block looks like a banner ad.
[15:01] <mpt> I think the single biggest improvement to the VMWare site would be to freeze the animation, and make it colored text on white background instead of white text on colored background.
[15:01] <mpt> That would make it look 90% less like an ad.
[15:02] <newz2000> By banner ad do you mean somethign that people instintctively ignore?
[15:02] <newz2000> i.e. is that why you dislike it?
[15:05] <newz2000> I mean why do you dislike the idea of banner ads on a homepage promoting stuff? You've mentioned this complaint before about the graphics on ubuntu.com
[15:05]  * newz2000 is curious, not trying to go psychiatrist on you
[22:27] <jpds> newz2000: I think I'll sigh at bug #258444.
[22:28] <ubot3> Malone bug 258444 in ubuntu-website "Please change Turkish mirrors location to Europe" [High,New] https://launchpad.net/bugs/258444


[01:47] <jono> jcastro, around?
[03:40] <mhall119> yo jono, how's that Bq?
[10:09] <czajkowski> mhall119: I'm getting mine soon :p
[10:10] <silverlion> happy valentines day to all the couples here ;)


[01:06] <hallyn> tomreyn: making 64-bit the default has been proposed many times.  i thought it might happen this cycle...  guess it didn't
[01:14] <slangasek> hallyn: the cycle's not over yet
[01:16] <tomreyn> i remember there were limitations regarding 64-bit releases in the past, as mentioned on the release notes
[01:16] <tomreyn> but maybe those could just be shifted if maintaining stuff for both archs involves too much effort
[01:17] <tomreyn> i bet people looked into this already...
[01:18] <sarnold> I think it's more to do with end-user confusion and success-rates for not knowing much about their computer when they download something to burn to disc.
[01:21] <hallyn> slangasek: here's hopin' :)
[05:35] <pitti> Good morning
[06:59] <dholbach> good morning
[07:00] <mlankhorst> morning
[07:00] <mlankhorst> @pilot in
[07:05]  * dholbach hugs mlankhorst
[07:45] <pitti> jdstrand: apparmor's Vcs-Bzr: is 6 versions behind, are we not using this any more?
[07:47] <pitti> jdstrand: I'm about to do an upload for bug 1227520, so I'll just use the UDD branch
[07:49] <pitti> doko_: good morning, how are you?
[07:49] <pitti> doko_: does the patch in bug 1233185 look okay to you?
[07:52] <infinity> pitti: That looks sane, except that it might be nice to see what "all" evaluates to currently, to see if you're leaving anything out.
[07:54] <ogra_> cjwatson, classmate-tools ?
[07:54] <ogra_> i wasnt aware thats still in the archive
[07:58] <infinity> pitti: Either way, regressing for some random arch we don't ship in favour of fixing things on ARM seems a safe option for today.
[08:00] <pitti> infinity: I'll have a look how I can find out what "all" does; hopefully it's just some kind of static macro that will get expanded in config.h or so
[08:04] <infinity> pitti: Looks like it ends up with ALL_64_TARGET_OBS + ALL_TARGET_OBS = \
[08:04] <infinity> pitti: From gdb/Makefile.in
[08:04] <infinity> pitti: But then I'm not sure why ARM wouldn't work, as arm-linux is in there.
[08:07] <pitti> infinity: but maybe not arm-linux-gnueabihf/arm-linux-gnueabi ?
[08:08] <infinity> pitti: Not sure gdb has such a distinction there.
[08:12] <infinity> pitti: All the same objects included in 'arm*-*-linux*)' in configure.tgt are also included in ALL_TARGET_OBS, so it's a bit confusing why this change would work.
[08:13] <infinity> pitti: Unless what's actually happening is that including some OTHER targets (like arm-symbian, etc) ends up breaking arm-linux.
[08:13] <pitti> infinity: I don't know, I'm afraid; I bisected it down from "broken since precise" to that change, but I have no idea how gdb works internally or what that "wrong size of gregset" thingy wants to tell me :(
[08:13] <infinity> pitti: Anyhow, disabling a bunch of targets we don't deeply care about seems like the path of least resistence for now, until someone can unwind this further.
[08:14] <pitti> infinity: ah, so now one could bisect the targets to see whether/which one breaks arm-linux, or whether something with "all" is broken in general?
[08:15] <infinity> pitti: Yeah.  My hunch is that if you keep adding new arm* targets (armbsd, arm-symbian, etc), you'll find that one of them blows up your arm-linux support.
[08:15] <infinity> pitti: And then maybe we could just patch that target out of all in Makefile.in
[08:15] <infinity> pitti: But, like I said, I doubt anyone deeply cares about debugging Solaris binaries on Ubuntu and, since they couldn't do so in precise either, meh.
[08:16] <infinity> pitti: Your fix should work for now, and an upstream and/or Debian bug on the matter should probably happen.
[08:16] <pitti> infinity: right, I was going to forward it to Debian
[08:16]  * pitti uploads for now
[08:22] <infinity> pitti: Can you do me a favour and copy and paste the above conversation into the bug, so context doesn't get lost the next time someone wants to look into it?
[08:22] <infinity> I need to pretend I'm sleeping.
[08:22] <pitti> infinity: yes, I will
[08:22] <pitti> infinity: so, good night!
[08:23] <infinity> pitti: Oh, and rejecting.  Please add aarch64 to your static list.
[08:24] <infinity> pitti: We should probably at least support all the arches in the archive, after all. :)
[08:24] <pitti> infinity: I guess that's not the literal value?
[08:24] <pitti> ack
[08:25]  * pitti still has trouble grepping for what "all" does, even greppign for "arm-linux" is rather unhelpful
[08:25] <infinity> 'aarch64*-*-linux*)' is the case.  aarch64-linux-gnu should work.
[08:25] <pitti> infinity: thanks; doing a test build with that, and reuploading
[08:27] <infinity> pitti: Grepping your build log for aarch64-linux-tdep.o should probably show if it's being built and linked in.
[08:27] <pitti> infinity: still, I want to test it; it might be that aarch64 is the very thing that breaks armhf, after all
[08:27] <infinity> pitti: Could be.  That would be a shame.
[08:28] <infinity> But indeed not implausible, if aarch64 was a cargo-cult from arm, and linking both arm.o and aarch64.o ends up overloading some rather useful symbol.
[08:34] <pitti> infinity: *phew*, build with aarch64 still works
[08:34] <infinity> pitti: I was almost hoping it wouldn't, as we would have found our culprit. :P
[08:34] <infinity> pitti: But yay.
[08:34] <pitti> uploaded
[08:34] <pitti> submitted to Debian
[08:38] <infinity> Tempted to say we probably want to update to 7.6.1 too, but it might be a bit late to validate that.
[08:38] <infinity> It looks like almost entirely bugfixes, some of which looks nice.
[08:38] <infinity> Actually, no almost about it, it's nothing but bugfixes.
[08:39] <infinity> Maybe I'll mull that over in the morniing.
[08:39] <infinity> But I see no mention of your bug, so it's probably still an issue.
[08:39] <pitti> infinity: you could keep it in -proposed for a few days and send a call for testing?
[08:42] <infinity> pitti: https://sourceware.org/bugzilla/show_bug.cgi?id=15415 in particular is a bug that drives me batty and is fixed in 7.6.1
[08:42] <infinity> pitti: Yeah, I'll give some thought to an update tomorrow.  And ping you to test a build with and without 'all' for curiosity, though I expect it to be broken still.
[08:44] <cjwatson> ogra_: Generally when something is broken I prefer fixing it over arguing whether it should still be there.  The latter can be done separately. :-)
[08:47] <ogra_> cjwatson, yeah, i just wasnt aware it is still there :)
[08:48] <ogra_> i'll file  a removal bug
[08:48] <zyga> hey, supposedly there is a bug somewhere around mounting nfs on boot that affects 12.04, what would be the best way to try to debug that?
[08:49] <zyga> I use a few nfs mounts on my box, including /home and a few with bootwait
[08:50] <zyga> my boot success rate is about 30%, the rest fails on one of the remote volumes not mounting (and basically hanging the box on plymouth)
[08:50] <xnox> zyga: and you are not hitting bug #1217041 ?
[08:50] <zyga> looking
[08:50] <xnox> zyga: ah, if you do succeed it's probably not that.
[08:50] <zyga> xnox: no, I'm on 3.2 here
[08:51] <zyga> xnox: I found too many issues with backported kernels overall and I've decided to stick with 3.2
[08:51] <xnox> zyga: in that case mountall debug output would be useful. In saucy it's as easy as booting with "--debug" in the kernel cmdline, but in precise you need to modify mountall.conf job to add "--debug"
[08:52] <zyga> so generally, i have a freenas box with a bunch of nfs shares and a 12.04 desktop wired together, the network is flawless, no packet loss or anything, networking is via network manager (but I tried with static for the same effect)
[08:52] <zyga> xnox: ok, let me try that
[08:55] <zyga> xnox: if I get a hang, what can I do to look at logs or just poke around?
[08:55] <zyga> xnox: I recall M or S used to work but I don't see those anymore (maybe it's just not displayed)
[08:56] <xnox> zyga: those key-combos should work. pressing Esc should show boot messages (or boot without quiet). Plus will you have a local /var available? in that case logs will be saved in /var/log/upstart/mountall.log.
[08:56] <zyga> ok, it seems like it has hanged again, I see (after hitting esc on the early boot screen)
[08:56] <zyga> local 2/2 remote 0/3 virtual 11/11 swap 0/0
[08:57] <zyga> xnox: could it be a bug in my nfs setup? like /home/ and /home/zyga/source being both mounted in the wrong order/causing stalls
[08:57] <zyga> xnox: note, I cannot use either M or S to jump to any console,
[08:58] <xnox> zyga: stgraber recently had a problem, how does your fstab look like?
[08:58] <zyga> xnox: yeah, /var is local
[08:58] <zyga> xnox: I'll try to pastebin it in a sec, I cannot tell from memory
[08:58] <xnox> zyga: stgraber did a bind-mount by UUID, instead of proper LVM names.
[08:59] <zyga> xnox: also the output from mountall/upstart is very confusing -- I see 'mount /home [495] zakńczone normalnie' (finished normally), then, 'mounted event handled for /home' but then, confusingly 'local 2/2 remote 0/3 ...' (as if nothing remote was mounted yet)
[08:59] <zyga> xnox: I don't use LVM here, just a small SSD with large nfs mounts
[09:03] <zyga> so still hanged, no way to get to a shell, should I just reboot?
[09:07] <zyga> xnox: fstab http://paste.ubuntu.com/6178860/
[09:07] <zyga> xnox: no mountall logs as far as I can see
[09:08] <zyga> xnox: modified mountall.conf http://paste.ubuntu.com/6178865/
[09:10] <xnox> zyga: i usually do without "--daemon" to get logs.
[09:10] <zyga> ah, ok
[09:11] <zyga> xnox: should I also remove 'expect daemon' theh?
[09:13] <xnox> zyga: yes.
[09:14] <zyga> ok, trying again
[09:18] <zyga> xnox: rebooted ok, no mountall logs in /var/log/upstart
[09:19] <xnox> =/ hm.
[09:20] <zyga> http://paste.ubuntu.com/6178893/ mountall.conf just to be sure
[09:34] <jodh> zyga: try changing /etc/init/tty6.conf to specify 'start on startup' so that you can login to a shell. I wonder if mountall is crashing (ls /var/crash/? )
[09:37] <zyga> jodh: thanks, worth checking!
[09:40]  * zyga reboots to try again
[09:41] <zyga> ok, given the tty now, I'll reboot till it hangs
[09:42] <zyga> jodh: so mountall isn't crashing
[09:43] <zyga> I'm in a shell now, with the boot hanged as before
[09:43] <zyga> network is up and working
[09:43] <zyga> http://pastebin.com/f5xxu3Xu
[09:43] <zyga> that's ps aux
[09:44] <jodh> zyga: Still no mountall.log? What does /var/log/boot.log show?
[09:45] <zyga> jodh: no mountall.log, nope
[09:45] <jodh> zyga: ah - you need to change mountall.conf to include "console log".
[09:45] <zyga> jodh: doh :) right, I'll patch that
[09:45] <zyga> quick question, how can I change early boot to english so that everyone can read it?
[09:45] <zyga> jodh: boot.log http://pastebin.com/tkMD5qxz
[09:46] <zyga> ok, rebooting
[09:47]  * zyga thinks of a magic key sequence that starts tty6
[09:47] <zyga> jodh: ^^ :)
[09:48] <zyga> ok, stuck again
[09:48] <zyga> inspecting logs
[09:49] <zyga> jodh: so _no_ mountall logs again, no idea why though
[09:49] <zyga> mountall is _not_ running
[09:50] <zyga> jodh: initctl list -> http://paste.ubuntu.com/6178962
[09:50] <zyga> note that I have my pastebin conf and that home has mounted
[09:50] <zyga> I actually wonder why it is stuck, it seems _everything_ is mounted now
[09:51] <zyga> mount -> http://paste.ubuntu.com/6178964
[09:54] <zyga> xnox, jodh, any idea on why it's not proceeding now? I'm looking at initctl list and I have no idea what might be wrong
[09:57] <zyga> jodh: having commented out 'expect daemon' from /etc/init/mountall.conf, and removed '--daemon' from 'script' below, should that job work okay?
[09:57] <zyga> jodh: I just noticed that mountall.conf has 'console output' already with a funny comment above ti
[09:58] <zyga> jodh: my console log was _above_ the pre-existing console output so we probably didn't get any logs because of that
[09:58] <xnox> zyga: do you get logs without "console output"
[09:58] <zyga> xnox: checking now, I'll reboot again
[09:58]  * xnox should check how i used to get logs from mountall
[09:58] <zyga> (it's quite interesting why the failure rate is now 100%)
[09:58] <zyga> rebooting
[09:58] <zyga> xnox: I think we'll get logs now
[09:59]  * zyga would like to switch to platform team for a cycle and work on mir early boot and upstart-and-friends verbose development boot monitoring support
[09:59] <zyga> xnox: mountall.log \o/
[10:00] <zyga> mountall.log <- http://pastbin.com/F7tBU1mi
[10:00] <zyga> (note, I type-copy each pastebin URL, if they don't work please tell me)
[10:01] <jodh> zyga: that pb doesn't work for me.
[10:02] <zyga> http://pastebin.con/RzNZHRz1
[10:02] <zyga> jodh: I think I made a typo in pastebin.com above (forgot one 'e'), this is a fresh one now
[10:02] <xnox> http://pastebin.com/RzNZHRz1
[10:03] <zyga> how do I switch locale to C.UTF-8 or something like that?
[10:03] <xnox> zyga: that seems to show everything is ok.
[10:03] <zyga> xnox: so indeed I have all the things mounted
[10:03] <zyga> xnox: but ... no desktop
[10:03] <zyga> xnox: fallback graphics is curious
[10:03] <xnox> well then =)
[10:03] <zyga> could it be the case
[10:03] <zyga> that fallback graphics kicks in somehow
[10:03] <zyga> (because of nfs boot delay)
[10:03] <zyga> and somehow stops my normally working graphics?
[10:04]  * xnox installed nvidia by accident (i have intel) and that breaks dekstop / lightdm. Also installing ubuntu-touch / surface-flinger breaks things.
[10:04] <zyga> udev-fallback-graphics.log is full of vesafb insertion errors
[10:04] <zyga> xnox: I don't have those installed here
[10:05] <xnox> zyga: anything interesting in lightdm logs?
[10:05] <zyga> I've adde manual to fallback grapics
[10:06] <zyga> xnox: aww, I just rebooted, IIRC lightdm didn't start though
[10:06] <zyga> xnox: (I moved all old logs aside and i dind't see any lightdm logs this time)
[10:06] <xnox> zyga: they are under /var/log/lighdm/*
[10:06] <zyga> ah
[10:06] <xnox> *lightdm
[10:07] <zyga> ok, cleared logs and trying again
[10:07] <zyga> and it does hang each time now
[10:07] <zyga> I wonder if I made it worse
[10:07] <zyga> or are we just lucky for debugging
[10:08] <zyga> xnox: lightdm doesn't start at all, no logs
[10:09] <zyga> xnox: upstart/plymount-ready-startup.log has just one line "Terminated"
[10:10] <zyga> jodh: so why does mountall.log claim that remote 0/3 is mounted: I have many more filesystems _and_ they are mounted
[10:11] <xnox> zyga: well at the end it claims "local 2/2 remote 2/3 virtual 11/11 swap 0/0"
[10:11] <zyga> xnox: now it claims 0/3
[10:11] <xnox> if that's a full pastebin that is, and there is nothing that was after.
[10:11] <xnox> hm
[10:12] <zyga> I keep rebooting after changing something to see if it helps
[10:12] <jodh> zyga: can you remove "--verbose" from mountall.conf as it's overriding "--debug" I think.
[10:12] <zyga> xnox: http://pastebin.com/W3BxKFSY
[10:12] <zyga> jodh: ok
[10:13] <zyga> rebooting
[10:13]  * zyga wants to rewrite mountall into rust/go/python
[10:14] <zyga> C is great but after a few years in python C feels like middle ages :/
[10:14] <zyga> jodh: http://pastebin.con/iuv4XtEv
[10:14] <xnox> zyga: *shrug* all of those are too heavy and too big that early in the boot process.
[10:15] <zyga> xnox: heavy? big?
[10:15] <zyga> xnox: python, yeah, rust/go
[10:15] <xnox> zyga: and with libnih, C looks quite neat.
[10:15] <zyga> xnox: and python would be easier to maintain probably (if having access to all glibc stuff wasn't a probleM)
[10:15] <zyga> anyway
[10:15] <zyga> xnox: true
[10:15] <zyga> xnox: libnih is very nice
[10:15] <zyga> hey, note that I seem to randomly get pastebin.com pastebin.ubuntu.com, it's still a random mount or not here
[10:16] <jodh> zyga: looks like you fstab is invalid - you have specified "1" the fsck field for /home/zyga/source, but "1" is reserved for the root FS. Change it to "2" (or "0" like the rest).
[10:16] <zyga> and it's mounted now (/home)
[10:16] <zyga> oh
[10:16] <zyga> cool
[10:16] <zyga> jodh: fixed, trying again
[10:16] <zyga> what are the last two fields for?
[10:16] <zyga> dump and pass
[10:17] <zyga> (I used 0 this time)
[10:17] <jodh> zyga: man fstab
[10:17] <zyga> ah
[10:17] <zyga> ok, same result
[10:17] <jodh> zyga: last pb also invalid
[10:18] <zyga> jodh: com not con, it should work, sorry
[10:18] <zyga> jodh:
[10:18] <zyga> \o/ desktop up, after a slight delay
[10:18] <zyga> let's retry
[10:18] <jodh> zyga: try commenting out the nfs entries in fstab starting with /home/zyga/source to see if they are causing the problem.
[10:20] <zyga> jodh: ok, rebooting, commented out 'source' and switched locale to C.UTF-8
[10:20] <zyga> jodh: could the wrong value of pass cause the problem?
[10:21] <zyga> mountall.log (nothing mounted yet) pastebin.com/rmsTYkf1
[10:22] <zyga> jodh: desktop up, everyting got mounted
[10:22] <zyga> jodh: mountall.log just a moment later, pastebin.com/q21qQrbW
[10:23] <rbasak> pitti: any opinion on an FFe for subversion for bug 1209493? This is to enable libapache2-svn again after it got dropped from the Apache 2.4 transition. It just got an NMU upload to DELAYED/5 to Debian and the diff looks sensible (presumably we'd want to wait for it to land first, certainly).
[10:23] <zyga> rebooting, I'll keep trying to see if I can hang it
[10:23] <cjwatson> Some days I hate optipng
[10:24] <pitti> rbasak: sounds good to me (although please note that I don't have formal u-release powerrs)
[10:24] <rbasak> pitti: understood. Thanks!
[10:24] <pitti> rbasak: but it was obviously a temporary dropping of the package, so bringing it back seems right if it builds now
[10:25] <rbasak> Perhaps I misunderstand what we do with optipng, but where it is effective, can we send the optimised png back upstream? And then perhaps keep a list of hashes for pngs that we already know are optimised.
[10:26] <jodh> zyga: great. Please can you raise a bug on this (with details of when this stopped working if possible).
[10:26] <zyga> jodh: hmm, wait, I'm not yet sure what the problem is, I can only report that I had a problem and commenting out that nfs share (and fixing pass value on it) made it go away
[10:27] <doko> pitti, I'm fine with it. I think that was introduced by lool some time ago. but then we need aarch64-linux-gnu too in this list
[10:27] <zyga> jodh: let me reboot a number of times again to check if it's the same
[10:27] <pitti> doko: yes, infinity already brought that up, and I added it
[10:27] <zyga> jodh: also, I'd like to get that share back there, I mean, if it's the root cause the I can manage but I don't know that yet
[10:27] <pitti> doko: thanks
[10:28] <jodh> zyga: that's prolly enough for now if we can recreate the bug with a setup similar to yours. When did this problem first start? Has a recent update caused the breakage?
[10:29] <zyga> jodh: no, it was bugging me ever since I started using nfs about a year ago
[10:29] <zyga> jodh: I was just not rebooting
[10:29] <zyga> jodh: I didn't have 'bootwait' before
[10:29] <zyga> jodh: and I manually started mounting after (rare) reboots
[10:29] <zyga> jodh: the only thing I made now (recently) was to put /home on nfs
[10:29] <zyga> jodh: but that's the equivalent of bootwait
[10:29] <zyga> jodh: and I had that for a while earlier after reading mountall to find out about it (I don't think it is documented)
[10:32]  * zyga thinks he spoke too soon, rebooted, it seems to have hanged (no changes made)
[10:33] <zyga> http://paste.ubuntu.com/6179062
[10:33] <zyga> yup, stuck
[10:40] <jodh> zyga: upstart appends to its logs files. would be clearer if rotate/delete the existing files each boot.
[10:41] <zyga> jodh: ah, true, thanks
[10:41] <jodh> zyga: unclear what the problem is atm, but please raise the bug as slangasek is the nfs guru.
[10:41] <zyga> ok
[10:42] <zyga> thanks for the help jodh, xnox!
[10:46] <zyga> jodh: on mountall?
[10:47] <xnox> zyga: nfs and mountall =)
[10:47] <xnox> zyga: bug against mountall.
[11:06] <zyga> jodh: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1233610
[11:06] <zyga> jodh: does that look good?
[11:10] <jdstrand> pitti: it is used, we are just horrible at keeping it up to date. I saw the change, we'll update the branch
[11:16] <rbasak> If a package provides a daemon, would it be considered a requirement that the daemon is listening (in this case on a Unix socket) when the package postinst finishes? I have a race with another package that depends on this, and it seems that the daemon is taking a little while longer to start up.
[11:17] <xnox> rbasak: well, does it have an upstart job?
[11:17] <cjwatson> I don't know about a requirement but I would consider it good software engineering.  I suggest that you fix the upstart job to wait properly
[11:17] <cjwatson> (You might find "expect stop" useful)
[11:17] <rbasak> This is libvirt-bin starting libvirtd. It does have an upstart job.
[11:18] <rbasak> I'm not sure how to amend the upstart job though. I think it's waiting until the daemon forks, so upstart considers it "started".
[11:18] <cjwatson> Like I say, "expect stop" is handy
[11:18] <rbasak> I'm patching libvirt with a sleep to test that hypothesis now, as it's a bit tricky to reproduce
[11:18] <cjwatson> You need to arrange to run without forking to use that, but it lets you cause upstart to consider the job started at the exact point of your choosing
[11:19] <cjwatson> With a patch to the daemon, typically, but a trivial one
[11:19] <rbasak> Ah - I see. So the daemon needs to send SIGSTOP to pid 1?
[11:19] <cjwatson> No
[11:19] <cjwatson> The daemon needs to send SIGSTOP to itself
[11:20] <cjwatson> Pid 1 will send it SIGCONT once it's noticed
[11:20] <rbasak> I get it - thanks. This would be an Ubuntu-only patch, then?
[11:20] <cjwatson> It's fairly crude, but effective :)
[11:20] <cjwatson> Could be pushed to Debian
[11:20] <cjwatson> This is of course assuming there isn't some other way, but if it doesn't listen until after it daemonises ...
[11:21] <rbasak> Wouldn't it break the daemon using another init system? I guess I'd need a command line option to enable that. Would you consider such an option mandatory for an Ubuntu patch?
[11:24] <xnox> rbasak: you can check if there is UPSTART_JOB in the environment ;-)
[11:24] <rbasak> xnox: that feels even worse! :)
[11:24] <rbasak> Thanks for the discussion. I'm investigating the code in more detail now.
[11:25] <xnox> jodh: shouldn't upstar texport UPSTART_EXPECTS_STOP in the environment, when launching expect stop jobs?
[11:31] <rbasak> It looks like there's code in libvirtd to not exit the foreground (pre-fork) process until the second child has start listening on the socket. But my understanding of upstart's docs is that it waits for the second fork only with "expect daemon". So I guess I need a script stanza that does daemonize but then kill -STOP $$ or something instead of an exec, and then "expect stop" instead?
[11:35] <rbasak> Hmm. But then upstart won't be tracking the correct pid.
[11:57] <cjwatson> rbasak: I used an environment variable when I did this in openssh
[11:58]  * rbasak looks
[11:59] <cjwatson> rbasak: It's not in the archive yet, but http://anonscm.debian.org/loggerhead/pkg-ssh/openssh/trunk/revision/3578
[12:00] <cjwatson> sshd's upstart job already arranges not to fork
[12:00] <cjwatson> not on startup anyway
[12:00] <cjwatson> rbasak: with the code in libvirtd you describe, maybe "expect daemon" is all you need
[12:01] <cjwatson> rbasak: that pattern isn't a totally unusual one, and should be manageable; "expect stop" is for when the daemonising isn't quite lined up with "ready to operate"
[12:02] <rbasak> cjwatson: thanks. I'll use that as a model. libvirt-bin already uses "expect daemon". I think the problem is that on the fork itself, we aren't at "ready to operate". The code signals instead by the first process exiting. But I think that upstart uses the second fork instead of additionally wait()ing on the top level process.
[12:02] <rbasak> Would there be any harm if upstart also waited on the top level process for "expect daemon" or "expect fork"?
[12:10] <zyga> slangasek: ping?
[12:17] <smoser> mvo, if you have some time, i'd appreciate thoughts on bug 1233486
[12:18] <smoser> if there is someone more appropriate to request from let me know that too
[12:18] <mvo> smoser: sure, I should find some time to look at this today - btw, what ever happended to the by-hash requirement for apt? is this still a issue or was this solved in a different way?
[12:19] <smoser> its still an issue.
[12:19] <smoser> rbasak, has just not gotten around to fixing it.
[12:19] <smoser> i think the biggest reason that it becaame much less problematic was that canonical IS changed a setting in the mirrors that made squid happier.
[12:19] <smoser> but i dont recall the details of that.
[12:20] <rbasak> I would still like to fix it. But I find working on apt very time consuming, needing me to disappear in a corner for a week at a time, and I haven't had time to do that recently :(
[12:20] <rbasak> That part of apt's source is very spaghetti-like.
[12:21] <smoser> rbasak, be nice :)
[12:24] <rbasak> I've filed bug 1228210.
[12:25] <rbasak> I've written up everything I know right now and I'd appreciate comment.
[12:26] <mvo> rbasak, smoser thanks for the update and yes, its unfortunately relatively ugly code that deals with that part in apt
[12:28] <rbasak> mvo: yeah it's unfortunate. I don't mean to criticise anyone specifically there - it's quite obvious how it's come about - a pile of needed features (security, compression, etc) without anybody having the time to refactor it.
[12:33] <smoser> rbasak, i knew you weren't *actually* being mean, and i think mvo did too.
[12:33] <mvo> yeah, no worries :)
[12:34] <rbasak> Phew :)
[12:48] <mlankhorst> Can someone accept mesa, xorg-server and glamor-egl? A few bugs popped up after the introduction of egl and after some testing I believe those are fixed now with the uploads. :)
[13:30] <diwic> zequence-work, ping, do you have upload rights for ubuntu-studio packages?
[13:32] <smartboyhw> diwic, zequence-work and OvenWerks are trying to get upload rights, but they currently don't.
[13:32] <diwic> ok
[14:10] <xnox> diwic: i did a few uploads for ubuntu-studio lately. what's up?
[14:13] <cjwatson> slangasek: Could you please merge multistrap to make pdebuild-cross installable in saucy?
[14:13] <diwic> xnox, wanna sponsor a ftbfs ?
[14:14] <xnox> diwic: do you have URL?
[14:14] <infinity> diwic: Wouldn't sponsoring something that builds be better? :)
[14:15] <diwic> xnox, http://pad.lv/1233685
[14:15] <diwic> infinity, nah, I don't think you have enough work already. :-)
[14:18] <cjwatson> bigon,kenvandine,dholbach: Is there any point in keeping the meta-telepathy source package in the archive?  It has never been in Debian, has no reverse dependencies, seems to attract bugs that should live somewhere else, and apparently telepathy-devel-gtk has been uninstallable since lucid without anyone noticing or caring
[14:18] <diwic> xnox, hold it
[14:19] <diwic> xnox, actually, it still fails, when you start it. *facepalm*
[14:19] <dholbach> cjwatson, no, very likely not - I don't know anyone using it - it stems from a time when the telepathy stack was just a 5-10 not-very well interconnected pieces of software
[14:19] <dholbach> cjwatson, shall I file a bug for that?
[14:19] <cjwatson> Please
[14:20]  * kenvandine agrees
[14:20] <kenvandine> i forgot it even existed
[14:21] <dholbach> cjwatson, bug 1233702
[14:21] <dholbach> thanks for bringing it up
[14:21] <bigon> cjwatson: +1
[14:24] <cjwatson> removed, thanks
[14:25] <dholbach> great
[14:35] <diwic> xnox, ok, so the ardour interface seems to start as it should. So probably an improvement after all, compared to not building at all. But there are more linker failures to sort out too...
[14:56] <slangasek> zyga: hi, so what's the symptom you're experiencing with nfs?
[14:56] <slangasek> cjwatson: ack
[15:02] <zyga> slangasek: hey
[15:02] <zyga> slangasek: I've tried to do my best to describe it in a bug report, let me pull it up
[15:04] <zyga> slangasek: https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1233610
[15:40] <mlankhorst> @pilot out
[15:40] <mlankhorst> bb
[16:02] <slangasek> xnox: more useful than a /var/log/mountall.log from a successful boot would be one from a failed boot...
[16:02] <slangasek> er, sorry
[16:02] <slangasek> zyga: more useful than a /var/log/mountall.log from a successful boot would be one from a failed boot...
[16:12] <jamespage> doko, any chance you could do the honours on bug 1213915
[16:32] <rbasak> xnox: do you know of a bug or blueprint to track EXITED in upstart, please? If not, should I add a wishlist bug for that? I figure that if something is planned then a minimal workaround in the meantime would be best, which in this case could be a simple wait-for-the-socket in uvtool-libvirt.postinst.
[16:33] <zyga> slangasek: I'll provide one to the same bug report as soon as I can, we have an important release today
[16:42] <xnox> rbasak: combination of https://bugs.launchpad.net/upstart/+bug/530779 and https://bugs.launchpad.net/upstart/+bug/406397
[16:43] <xnox> slangasek: what's the new mechanism that keybuk keeps on talking in those bug reports?  This - http://netsplit.com/2011/02/09/the-proc-connector-and-socket-filters/ ?
[16:45] <rbasak> xnox: thanks!
[16:45] <jodh> xnox: the proc connector is a netlink facility, but it doesn't work in containers.
[16:46] <xnox> jodh: i'm not sure what netlink is, and define containers - doesn't work in lxc?
[16:46] <slangasek> xnox: you mean "proc connector"?  It's... proc connector :)
[16:47] <jodh> xnox: kernel socket thing. yes, it fails in lxc.
[16:47] <slangasek> fails in lxc> boo
[16:47] <slangasek> even with user namespaces?
[16:48] <jodh> slangasek: haven't tried that.
[16:48] <slangasek> well, they're fairly new AIUI
[16:49] <xnox> slangasek: well keybuk in those bugs doesn't say that he was planning to use "proc connector", only some random commenter said that.
[16:50] <jodh> xnox: https://lists.ubuntu.com/archives/upstart-devel/2011-August/001707.html
[16:52] <xnox> jodh: ah, thanks. That's from before my time =)
[16:56] <xnox> jodh: `* Introduce "expect exit <n>" syntax.' sounds highly unreliable, if there is a variable amount of exits.
[16:56] <slangasek> xnox: ah, misread your original question and didn't look at the bugs, sorry.  Yes, I think proc connector was his long-term vision for fixing this problem
[16:57] <slangasek> xnox, jodh: yeah, I don't like 'expect exit <n>'.  People can fix their code to daemonize sensibly, or not at all + SIGSTOP.
[16:58] <jodh> xnox: the link was primarily for you wrt the proc connector; we're not now planning to implement 'expect exit' :)
[16:58] <jodh> slangasek: ack
[17:08] <xnox> slangasek: with respect to tracking exits, we'd need to build a tree of all forked processes (and forks of thereof) and monitor both FORK and EXIT and mark off in the the tree those that exited, and then what? -> for expect fork, take the first fork that is still running after the parent has exited? -> for expect daemon, take the first double fork that is still running after the parent has exited? and if there are no such declare defeat.
[17:11] <slangasek> xnox: I don't think you actually need a tree; you just track parent + child, and if the child exits before the parent, you scratch that pid off the list and wait for the next child
[17:11] <pitti> yay, lots of autopkgtest failures due to uninstallable X on amd64
[17:11] <pitti> jibel: ^ FYI; can retry tomorrow morning, or if you are still around later tonight, maybe you can
[17:11] <pitti> plars: ^ or you
[17:14] <xnox> slangasek: well, what if the child[2] is the one that ultimately does the double fork? for "expect fork" yeah one can use list(parent, child1, child2, child3) and simply take the first still alive child after parent has exited.
[17:14]  * xnox somehow thinks for "expect daemon" we need "grand-children"
[17:15] <plars> pitti: is there a process you normally follow for identifying when it's ready to retry, and which ones to retry?
[17:16] <slangasek> xnox: we can assume a daemon has certain characteristics, such as the fact that the "grandparent" doesn't exit until its currently lead child is the one that's going to fork again to give us the daemon
[17:16] <pitti> infinity: you could keep it in -proposed for a few days and send a call for testing?http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html stops spitting out a gazillion xorg packags
[17:16] <pitti> WTF
[17:16] <pitti> infinity: ^ sorry about that, that was an utter paste fail
[17:16] <slangasek> xnox: we don't need to support all crazy combinations of fork+exit, only the ones that make sense for a daemon - and for other cases, we just need upstart to not get wedged
[17:17] <pitti> plars: as soon as http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html stops spitting out a gazillion xorg failures
[17:17]  * pitti waves good night
[17:17] <pitti> hmm, we are down to two amd64 builders, of which one is offline :/
[17:18] <slangasek> rbasak: ah, nice post on upstart-devel, are you the one who triggered this current discussion? ;)
[17:18] <xnox> slangasek: I see, i keep fearing that "leading child" is "pre-warm cache long task" which eventually dies after the parent has exited, with the second child (untracked) which did the double fork.
[17:18] <rbasak> slangasek: thanks. Yes. I was chasing a race and wasn't aware of the previous discussion on this.
[17:18]  * pitti bumps https://launchpad.net/ubuntu/+source/xorg/1:7.7+1ubuntu5/+build/4970241 but it seems it doesn't even get an ETA
[17:18] <pitti> anyway, waaay past my EOD time, cu all
[17:18] <xnox> slangasek: yes, rbasak triggered this irc -> email -> irc discussion.
[17:20] <slangasek> xnox: it's possible that such things exist, but I don't see any way to make that work with 'expect daemon' anyway - how is upstart supposed to know that child[1]->grandchild[1][0] is the real daemon, and child[0] is the long task, instead of child[0] being the daemon still starting up and grandchild[1][0] being the task which happens to have double-forked?
[17:21] <slangasek> we have to have some assumptions
[17:22] <rbasak> I found https://blueprints.launchpad.net/upstart/+spec/return-pid-from-exec when I was googling earlier. Did that prompt any further discussion, and could it be useful for the really obscure cases?
[17:22] <rbasak> (as a generic catch-all)
[17:22] <rbasak> Effectively allowing complex cases to deal with the required logic themselves
[17:45] <xnox> slangasek: well, in that case doesn't this reduce to: keep tracking forks as we do + track parent (patient0) exit => declare started when we found our fork + patient0 has exited?
[17:46] <slangasek> xnox: yes
[18:50] <cjwatson> pitti: The one that's disabled isn't actually amd64, it's just temporarily faking it so that we still see the amd64 queue length even when all the builders are assigned to i386 to clear the test rebuild queue there faster.
[18:51] <cjwatson> pitti: I've given amd64 another builder for a bit, but the non-test-rebuild saucy queues are still strongly imbalanced (i386: 75, amd64: 16) so I think 6:2 is about as much towards amd64 as we ought to go for now
[18:52] <cjwatson> pitti: And the problem isn't the amd64 queue anyway, it's the build failure on i386 ...
[18:53] <cjwatson> Hmm, unexplained abort in the test suite
[18:53]  * cjwatson retries it in the hope that it might stick
[18:54] <cjwatson> pitti: https://launchpad.net/ubuntu/+source/xorg/1:7.7+1ubuntu5/+build/4970241 is arm64, not amd64
[18:54] <cjwatson> pitti: arm64 isn't going to build for a while :-)
[18:56] <cjwatson> pitti: I've scored that back down - it's not appropriate for it to be second in the arm64 queue
[18:57] <cjwatson> (For avoidance of doubt, if you aren't involved in the arm64 bootstrap, please leave its build scores alone)
[18:57] <cjwatson> Though I realise it was a mistake here
[18:59] <cjwatson> There we go, xorg-server/i386 looks happier now on a retry
[20:23] <jibel> pitti, adt jobs fixed after a retry.
[21:04] <stokachu> stgraber: http://paste.ubuntu.com/6181286/, am i missing something to allow my image to be mounted within lxc under precise?
[21:08] <stokachu> stgraber: http://paste.ubuntu.com/6181297/ the bottom portion shows the output failure from within lxc
[21:09] <stgraber> stokachu: I don't think your problem is with apparmor but instead with you not allowing loop devices in the container config
[21:10] <stokachu> stgraber: in my lxc.customize parameter ive setup "aa_profile", "lxc-container-default-with-loops"
[21:11] <stokachu> stgraber: should i be adding something else to that?
[21:15] <stokachu> stgraber: i found your post about it<EMAIL_ADDRESS>[21:24] <stgraber> stokachu: did you add the lxc.cgroup.devices.allow lines?
[21:27] <stokachu> stgraber: cgroup.devices.allow = b 7:* rwm and cgroup.devices.allow = c 10:237 rwm
[21:27] <stokachu> stgraber: was that all i needed?
[21:27] <stgraber> should be
[21:27] <stokachu> ok lemme kill this container and try once more
[21:44] <stokachu> stgraber: sweet! it worked :D:D
[21:56] <stokachu> stgraber: im not finding much documentation on lxc+pxe boot, is that something that isn't supported?
[22:01] <slangasek> stokachu: lxc+pxe <blink>?
[22:01] <slangasek> lxc is a container; it doesn't get its own kernel; what would lxc+pxe mean?
[22:04] <stokachu> ah sorry the guests would not be lxc
[22:20] <sarnold> a friend is curious if there's a path forward for this packaging request: https://bugs.launchpad.net/ubuntu/+bug/1231114
[22:23] <cjwatson> It'd need to get re-maintained and back into the Ubuntu development series first, preferably by way of renewed maintenance in Debian, before there's any chance of having it in a stable Ubuntu release
[22:27] <sarnold> cjwatson: thanks :) probably it isn't the answer he'd like to hear, but .. porting from python 2.ancient to newer doesn't sound like fun unless you -need- that package. Thanks!
[22:28] <cjwatson> Porting to 2.7 probably isn't that horrible
[22:28] <cjwatson> Indeed that's stated in the bug
[22:29] <cjwatson> We like to have Python 3 support, but it isn't yet a requirement for archive inclusion, neither in Debian nor in Ubuntu
[22:29] <cjwatson> So I don't think that's the point - it needs somebody taking care of the package enough to cancel out the reasons it was removed from Debian in the first place
[22:31] <sarnold> so many packages, so little time..