[05:23] <pitti> Good morning
[06:08] <alkisg> Hi, I'm upstream for an app in universe + in debian. My app is translated in launchpad. When is my translations deadline? DebianImportFreeze? NonLanguagePackTranslationDeadline?
[06:26] <slangasek> alkisg: NonLanguagePackTranslationDeadline is the deadline by which translations should be finished, but if you're planning to incorporate those translations into a new upstream release, you need to be mindful of the feature freeze
[06:28] <slangasek> and having a no-new-features upstream release that meets the freeze criteria *available* is no guarantee that anyone will have a chance to upload it in time
[06:28] <alkisg> slangasek: thank you, so, without me doing any new upstream releases, new language translations can still be added after feature freeze, right?
[06:28] <slangasek> they can, sure
[06:28] <alkisg> (the app is new so it's only been translated to 7 languages so far, and I want to send a call for translators)
[06:29] <alkisg> Thanks!
[07:03] <slangasek> apw: heh - I think I'll remove the lpia-linux-restricted-modules source from the archive now
[07:48] <dholbach> good morning
[07:49] <SpamapS> dholbach: buenos dias
[07:50] <dholbach> hey SpamapS
[08:20] <\sh> dholbach: happy birthday :)
[08:20] <dholbach> thanks \sh :)
[08:21] <nigelb> ooh
[08:21] <nigelb> HAPPY BIRTHDAY dholbach!
[08:21] <dholbach> thanks :)
[09:08] <dholbach> can new packages also be synced with the syncpackage now?
[09:08] <seb128> dholbach, hey, how are you?
[09:09] <dholbach> hey seb128
[09:09] <seb128> dholbach, guess they could but you will hit NEW, it might be easier for archive admins to sync and new
[09:09] <seb128> dholbach, if that's custom uploads it's harder to make sure the version was synced from debian and not a custom uploads with a -1 I guess?
[09:10] <seb128> though I'm not sure
[09:10] <dholbach> seb128, for other syncs I got an email, for NEW packages I didn't
[09:10] <seb128> I would tend to want to review stuff others uploaded where I'm fine directly NEWing archive syncs
[09:10] <dholbach> but the 2 newest entries on https://launchpad.net/ubuntu/precise/+queue are the ones I synced
[09:10] <seb128> dholbach, right, make sense
[09:10] <seb128> new sources go to the new queue
[09:11] <dholbach> I just asked because I didn't get an email :)
[09:11] <seb128> dholbach, oh ok
[09:12] <seb128> well imho we should still discuss if new sources should be synced this way, it might make NEWing harder
[09:13] <seb128> but I might be overlooking an easy way to confirm that those are actual syncs to discard versions screwups (i.e somebody who uploads a source to ubuntu using -1 by error, those should be reviewed, where we usually don't review stuff from Debian)
[09:13] <dholbach> hm
[09:46] <cjwatson> seb128: it doesn't make NEWing harder - you can tell that they're actual syncs because queue says "X-" in the type column for them, and they're annotated in some way in the web UI too
[09:47] <cjwatson> IMO there's no reason why people shouldn't sync new packages with syncpackage
[09:48] <cjwatson> usually I check with rmadison that it matches the version in Debian but that's about t
[09:48] <cjwatson> *it
[09:48] <seb128> cjwatson, ok, works for me, I was unsure if it was easy to say what was synced from debian
[09:48] <cjwatson> oh, and in fact the web UI even says that it's synced from Debian
[09:49] <cjwatson> look at https://launchpad.net/ubuntu/precise/+queue and use the expanders on the top two entries
[09:49] <seb128> "Sync from Primary Archive for Debian GNU/Linux", indeed
[09:49] <seb128> nice
[09:49] <cjwatson> if anything it's easier to process NEW sources this way :)
[09:50] <seb128> ;-)
[11:45] <jamespage> iamfuzz: around? wanted to discuss reverting groovy back to 1.8.x series
[13:36] <danger89> Hi
[13:36] <danger89> We developed your own deb & ppa for Ubuntu
[13:37] <danger89> namely Bumblebee
[13:38] <astraljava> cjwatson: Hiya, I'm about to start working on the Studio live-dvd. I noticed you had a word with Scott about it, but since he's awfully busy, I thought I could test the wind beneath my wings. :)
[13:38] <danger89> however the user still needs to manually add there own username to the bumblebee group. This is because the installation runs at root. Has anyone any idea how to fix the installer to add the current user automatic to the bumblebee group?
[13:40] <Lekensteyn> in addition to what danger89 has said, we're granting write permissions to a socket for a specific group to give a sense of security
[13:42] <stokachu> danger89, Lekensteyn : you  may get a better response in #ubuntu-app-devel
[13:42] <danger89> stokachu: ok thanks
[13:43] <stokachu> danger89, no problem
[13:54] <apw> a dist-upgrade wants to remove gdm-guest-session, is that right or wrong
[13:57] <dholbach> apw, gdm-guest-session is safe to go - I don't have it installed either and it's removed from the archive
[13:58] <apw> dholbach, thanks ... /me hits return
[14:28] <pitti> cking: hey Colin, how are you?
[14:29] <cking> pitti, doing fine thanks!
[14:29] <pitti> cking: FYI I stacked most of the rest of pm-utils cleanup in debian git now, we'll do an upload soon
[14:29] <pitti> cking: there's one remaining thing
[14:29] <cking> ..what's that?
[14:29] <pitti> cking: the sata_alpm hook is currently disabled by default
[14:29] <pitti> cking: seems our bug reports are from 2009, and your recent crowd sourcing looked promising
[14:30] <pitti> cking: I'm interested in whether there were recent kernel developments which might make this safe(r) to enable by default?
[14:30] <cking> pitti, well, I'm not 100% sure it is safe, so let's keep it disabled for now
[14:30] <pitti> it WFM, but I have an X201 which is generally well supported
[14:31] <pitti> I never had a problem in 2009 either, so I'm a bad test case
[14:31] <pitti> cking: ack
[14:31] <cking> pitti, I'm going to construct a USB live image that can do read tests on H/W so we can identify hardware where it fails w/o killing users data
[14:32] <cking> but I suspect this is a longer term test for P+1 now
[14:33] <cking> pitti, thanks for sorting out the pm-utils changes for me, much appreciated :-)
[14:33] <pitti> no worries :)
[14:34] <diwic> is it possible to upgrade from 11.04 to 12.04? I'm running "update-manager -d" but only 11.10 comes up.
[14:40] <pitti> diwic: you need to upgrade through 11.10 first indeed; although it should work (sudo apt-get dist-upgrade), it hasn't really been tested
[14:41] <diwic> pitti, well, since it hasn't been tested, I figured it would be an interesting test case to file bug against
[14:42] <pitti> diwic: indeed; it won't be officially supported, but most of what breaks should also affect lucid->precise
[14:43] <diwic> pitti, hmm, ok, but if nobody is going to care about the possible bugs anyway it would be stupid to throw oneself in there
[14:43] <pitti> diwic: no, I meant that anything you run into will most likely be a real bug for upgrades from lucid
[14:43] <pitti> so it actually does sound useful
[14:44] <pitti> if apt-get dist-upgrade proposes to remove half of your desktop, you should not start it, though :)
[14:45] <cjwatson> astraljava: OK; maybe if you sketch out how you think the seeds ought to look in a branch, perhaps using the Edubuntu seeds as a general reference, and I can look over it?
[14:45] <cjwatson> astraljava: do you have a clear specification of how you want the resulting image to behave in terms of what should be available in a live session and what should be available after installation?
[14:48] <diwic> pitti, hmm, I guess that isn't enough: "sudo apt-get dist-upgrade" or "sudo apt-get -t precise dist-upgrade" just says the system is updated
[14:48] <pitti> diwic: you need to change /etc/apt/sources.list from "natty" to "precise" first, sorry
[14:48] <diwic> pitti, ah, assumed something like that
[14:51] <diwic> hmm, looks not too unsafe (44 to remove)
[14:52] <pitti> diwic: paste?
[14:52] <astraljava> cjwatson: We're in the early stages so far, but as you suggested, I will start to go over the Edubuntu seed now. Is it okay if I ping you again when I have it in some coherent form?
[14:52] <diwic> pitti, too late
[14:52] <diwic> It's not an installation I care that dearly about anyway
[14:52] <astraljava> cjwatson: I'm not sure about the behavior, I'll talk to Scott about it, I guess.
[14:53] <diwic> some indicators and some python related stuff
[14:54] <pitti> diwic: these might be genuine cleanup indeed; there's a rather large GTK3/GIR transition involved
[14:54] <diwic> pitti, yeah I thought so too
[14:55] <cjwatson> astraljava: sure ... it's just probably more efficient if you have slightly more specific questions, since giving you complete directions might more or less amount to doing the work :-)
[14:56] <cjwatson> astraljava: definitely having a clear spec of what packages are present in live vs. installed system will be useful, though
[14:56] <astraljava> cjwatson: Yeah I understand that. :) I was just needing a direction, really. But you've given me that, so I'll go with that now.
[14:56] <cjwatson> astraljava: (they're bound to be different in some way; for example the installer itself should not be present in the installed system)
[14:57] <astraljava> cjwatson: Good point. Ok, I'll compile such a list as well. Thanks for now!
[15:12] <cking> pitti, should I report apps that wakeup frequently to the ubuntu power consumption project even if I'm not sure if wakeups are a feature and not a bug of the software?
[15:14] <pitti> cking: I think reporting can't hurt, we can analyze it on the bug report then and set as invalid if appropriate
[15:14] <cking> pitti, ack
[15:14] <pitti> cking: btw, I added u-p-c tags to your recent bugs, to have them all under one roof
[15:15] <cking> ok - I will remember to tag them appropriately in future
[15:16] <pitti> cking: s/tag/add affected project/
[15:16] <pitti> cking: right, I meant to say "tasks", not "tags", duh
[15:16] <cking> ah, OK :-)
[15:16] <pitti> https://bugs.launchpad.net/ubuntu-power-consumption/+bugs
[15:17] <cking> pitti, I added 917156 to that list :-(
[15:18]  * cking notes its like whack-a-mole
[15:18] <pitti> cking: ah, we don't even install that by default any more
[15:18] <pitti> but it's an issue of course
[16:42] <cjwatson> barry: well, first run of python3 porting seems pretty successful - I think I have a functional python3-germinate now
[16:42] <cjwatson> barry: not that that was anywhere on your list ;-)
[16:42] <cjwatson> (easier to start with something I maintain for practice purposes, though)
[16:43] <barry> cjwatson: nice!  btw, i'm going through your email now, though about to take a lunch break.  thanks for the feedback.  one of the tricky bits (and why there was some asymmetry b/w the py2 and py3 versions) was that for py3, we can install the debug .so's right next to the production .so's, whereas for py2 we can't
[16:44] <barry> cjwatson: the branch head probably had more churn in it than necessary, so apologies for that.
[16:50] <cjwatson> barry: ok - if I've got any of the layout wrong, I'm guessing it might be easier to fix it with the approach I took, anyway :)
[16:50] <barry> cjwatson: :)
[16:56] <ScottK> barry: ping re python-dbus recomments python-gobject.  This pulls python-gobject and a stack of other things into the Kubuntu seeds that aren't otherwise needed.  Do you think it could be dropped?
[16:56] <ScottK> ... recommeds ...
[16:57] <ScottK> Sigh.  Can't type today.  Anyway ...
[17:24] <jtaylor> doko_: can you remove the argparse provide from python-defaults, it breaks builds bug 916188
[18:17] <tumbleweed> can a moderator please let my ubuntu-devel-announce mail through
[18:58] <achiang> does anyone know why precise libqt4 is built without phonon? (just curious)
[18:59] <debfx> achiang: phonon is built from its own source package
[18:59] <achiang> debfx: ah, thx
[20:42] <broder> lifeless: i'm confused about your closure of bug #612391. were you talking about re-targeting merge proposals? because i suspect that will only exacerbate one of the other major issues with SRU MPs, which is that you can't open a MP against foo-proposed when that package hasn't already been SRU'd
[20:43] <broder> (possibly also if the SRU has already been moved into -updates - i'm not sure)
[20:45] <lifeless> broder: it looks to me like there are no code changes in LP needed for that specific bug; there are other bugs in the area, that is true.
[20:46] <lifeless> broder: the -proposed thing having no branches seems like an operational issue as much as anything else - sure, we could do something fancy and have fake branches, but really the udd importer could instantiate sru branches matching the release, shortly after the release.
[20:46] <broder> ah, i see. you're suggesting a script to go and mangle the MPs that runs as the branch importer or something?
[20:56] <haraldj> Hello, any SRU members online?
[21:03] <haraldj> I'm currently facing requests for package upgrades in stable Ubuntu releases...
[21:05] <lifeless> broder: handwave, yes :)
[21:05] <broder> lifeless: ok. i guess the importer is considered to be a separate project from lp itself? i'll go open a new bugtask so we don't lose the bug
[21:06] <lifeless> broder: you could add a task if you like; 'udd' is the project
[21:07] <lifeless> broder: lp is a bit drowned in bugs atm; I'm trying to make sure that the bugs are a) really code bugs (or at a pinch operational things which someone in the LP team needs to look at) and b) not dups, not stale etc
[21:07]  * broder nods
[21:10] <tumbleweed> haraldj: generally minimal patches are preferred for SRUs, excepting patckages which maintain stable releases and have recevied "micro release exceptions" in Ubuntu
[21:11] <haraldj> Well that may be a problem...
[21:11] <haraldj> tumbleweed: the package in Hardy is really old...
[21:12] <tumbleweed> hardy is really old, that's to be expected :)
[21:13] <tumbleweed> we really don't want to cause regressions in SRUs. Usually new versions are backported only when the package is totally broken
[21:13] <haraldj> tumbleweed: Ok that's true but the problem is that even Debian Lenny has a younger version - and this version is even deprecated by upstream
[21:13] <haraldj> Absolutely understandable
[21:14] <haraldj> I do work on the Debian package since 22 months and released two weeks ago a security update
[21:14]  * tumbleweed isn't on the SRU or security team, so I can't give you their views
[21:15] <haraldj> clear but there are currently 4 open CVEs for Hardy and at least 2 other bugs (more or less critical)
[21:18] <haraldj> Maybe anybody of the release or security team is online?
[21:18]  * tumbleweed is on the release team
[21:18] <haraldj> Sorry meant the SRU
[21:20] <haraldj> I'm somewhat concerned about the state of the package... as openswan is a security package there needs to be taken extra care of it
[21:20] <tumbleweed> security team have an IRC channel (#ubuntu-security, IIRC) and also see bugs marked as security issues. Otherwise just lurk until someone turns up :)
[21:21] <haraldj> Hmmm well I would prefer to talk to one member of SRU and one of security at the same time so we could find the best solution for the issues of security and usability
[21:21] <tumbleweed> seems pretty head here now. Maybe in the (UTC) morning...
[21:22] <haraldj> Ok will try tomorrow morning then :-)
[21:23] <haraldj> Wish you a nice evening/good night and thanks for your help
[21:24] <tumbleweed> np
[21:24] <haraldj> :-) bye