[07:46] <mdke> artnay: I don't know if you can do this through the Launchpad Translations interface, this is a question probably for the Launchpad developers. However one way to do this is to look at revisions to the pot file in our bzr branch
[07:47] <mdke> artnay: http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-docs/oneiric/changes?filter_file_id=ubuntuhelp.pot-20110503072936-b25cviz4wq12g9ne-35
[07:47] <mdke> artnay: see revisions 58 and 59
[07:48] <mdke> artnay: if your language is fully translated, the amendments will appear as new strings to translate
[08:15] <artnay> mdke: sure, thanks. I figured that out yesterday but having versioning on the actual Rosetta interface would be a huge plus. at least bzr diff view is better than nothing.
[14:33] <kelemengabor> dpm: ping
[14:33] <dpm> hey kelemengabor
[14:33] <kelemengabor> what's your opinion about bug #877461 ?
[14:33] <ubot4> Launchpad bug 877461 in ubuntu-translations "Dist Upgrade displays wrong version number in GB English (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/877461
[14:33] <dpm> looking...
[14:36] <dpm> kelemengabor, I think what you are suggesting makes sense (contact mvo to do an export). However, will an export+upload do or do we need a new langpack? Are the update-manager translations handled in the package or in the language packs?
[14:36] <kelemengabor> both! :)
[14:36] <kelemengabor> the normal UI is in the langpacks
[14:37] <kelemengabor> however, when you want to upgrade your previous release, it will download a tarball
[14:37] <kelemengabor> with the new release of the dist-upgrade tool
[14:37] <kelemengabor> this one contains translations
[14:38] <kelemengabor> so a new build is needed
[14:39] <dpm> I see, so we can get away with just an export, I guess?
[14:39] <kelemengabor> it was created today for bug #873905, but with this severe mistranslation in en_GB
[14:39] <ubot4> Launchpad bug 873905 in update-manager (Ubuntu Precise) (and 3 other projects) "Update-manager not using current translations during upgrade (affects: 1) (heat: 12)" [High,In progress] https://launchpad.net/bugs/873905
[14:39] <dpm> yeah, I remember having seen it
[14:40] <kelemengabor> so basically, we should not release this proposed package, but redo it - if mvo is okay with it
[14:42] <dpm> kelemengabor, I think that's the way to go, yes.
[14:45] <kelemengabor> okay, pinged him on ubuntu-devel
[14:58] <dpm> cool, thanks kelemengabor


[02:51] <k_sze> Does Ubuntu 18.04 server edition suffer from the same problem? https://news.ycombinator.com/item?id=20463251
[02:53] <k_sze> I *think* I noticed my Linode instance taking much longer to accept SSH connections after reboot, after upgrading to 18.04, though I'm not sure if that's the cause.
[06:17] <lordievader> Good morning
[07:49] <cpaelzer> good morning lordievader
[13:10] <jamespage> coreycb: swift in eoan-proposed is a bit foobar - the python3-swift has python2.7 module installed
[13:10] <coreycb> jamespage: hrm, ok i'll take a look. should we give a ping to the release team on the RM bugs?
[13:11] <jamespage> yah probably as that's blocking migrations - doko might help us there
[13:16] <coreycb> jamespage: ok
[13:16] <jamespage> coreycb: pinged him in -devel with three bug reports
[13:17] <coreycb> jamespage: thanks, i'll send any others
[14:01] <coreycb> jamespage: i'm not sure why python3-swift is pulling in python - https://paste.ubuntu.com/p/sB2GJtW7kk/
[14:12] <smoser> rbasak: have a minute?
[14:14] <rbasak> smoser: o/
[14:14] <smoser> when we rebase logical delta in git-ubuntu...
[14:14] <smoser> that is actually *not* a rebase, right? but a merge
[14:15] <smoser> right? no history is lost
[14:15] <rbasak> smoser: it's a rebase
[14:16] <rbasak> I think. If I understand you, etc.
[14:16] <rbasak> We did experiment with different commit graphs to represent that.
[14:16] <smoser> hm.
[14:16] <rbasak> But the plan going forward is that we'll just take your rebase commit exactly as-is, with nothing else in the DAG.
[14:16] <rbasak> (no tie to previous)
[14:17] <smoser> ok.
[14:17] <smoser> but the history would still be available because the tag
[14:17] <rbasak> Right
[14:17] <rbasak> However git-ubuntu doesn't care about what you provide as long as it matches.
[14:17] <smoser> of the previous release head *that* logical delta there.
[14:17] <rbasak> If you have fun with the DAG, git-ubuntu won't care.
[14:17] <smoser> so the ubuntu/devel git history is always debian/<something> + new changes
[14:17] <smoser> is that right?
[14:18] <smoser> (where new changes >= 0)
[14:18] <rbasak> As long as some assumptions are correct.
[14:18] <rbasak> We trust the uploader's debian/changelog
[14:18] <rbasak> So it's possible to create disconnected ubuntu/devel git history I think.
[14:18] <rbasak> Let me share my draft spec with you.
[14:22] <rbasak> I suspect the precise answer to your question can be determined from my draft spec, but it might not be trivial to correctly answer in case of the edge cases.
[14:22] <smoser> :)
[14:23] <rbasak> smoser: note that the current implementation doesn't exactly match the spec. Changes are in progress still.
[14:24] <ahasenack> what's DAG?
[14:26] <lordcirth> ahasenack, directed acyclic graph
[14:27] <lordcirth> the data structure that git (and anything else that uses hashed objects to refer to other hashed objects) uses
[14:29] <ahasenack> heavy
[14:29] <ahasenack> thanks
[14:34] <rbasak> ahasenack: specifically, here, I meant the graph of commits, and the upload-tag-supplier's choice of what parents the upload tagged commit has, recursively.
[19:31] <nacc> bryce: hiya!
[19:31] <nacc> bryce: we'll need to be a bit async, but i'm happy to chat a bit while i'm in meetings
[19:32] <bryce> nacc, sure that's fine with me
[19:37] <nacc> bryce: so you're looking at 7.2 -> 7.3, right?
[19:38] <ahasenack> you are happy to chat *while* in meetings? :)
[19:38] <nacc> bryce: so basically, in your ppa, you'd upload a new php-defaults that points to php7.3 rather than 7.2
[19:38] <nacc> ahasenack: i'm a manager now, let's leave it at that :)
[19:38] <bryce> nacc, right
[19:38] <ahasenack> haha
[19:38] <nacc> bryce: and then you'd need to see what will fail it's autopkgtests once you do that
[19:38] <nacc> ideally it won't be too much
[19:39] <nacc> but you'll probably need to bootstrap things like phpunit (without tests)
[19:39] <bryce> nacc, what I'm seeing is that 7.3 is indeed present but it's also detecting 7.2 is available, so attempts to compile against both, and fails when it finds the latter
[19:39] <nacc> bryce: do you have a log / exmaple?
[19:39] <bryce> yeah
[19:39] <bryce> https://launchpadlibrarian.net/433527551/buildlog_ubuntu-eoan-amd64.php-igbinary_3.0.0-1build1_BUILDING.txt.gz
[19:39] <bryce> nacc, also summarized my analysis in the email I sent, maybe a bit tldr
[19:40] <nacc> ack, reading
[19:43] <nacc> bryce: ok, have you reproduced this locally on your machine?
[19:43] <bryce> I've found in building locally in a container, if I force uninstall php7.2-common (and php7.2) the build proceeds fine.  Just wondering if there's a trick to doing the same within a PPA.  But if this doesn't sound at all familiar, perhaps there's something new going on.
[19:43] <nacc> right, so you need to figure out *why* php7.2-common is being pulled in
[19:43] <nacc> php7.3-common shoudl be sufficient
[19:43] <nacc> but you might be missing some other dependency link
[19:45] <bryce> I suspect it's pulling it in via the build-depends for the package in question.  Wondering if maybe phpdefaults needs a conflicts against 7.2 or something?
[19:46] <nacc> let me look at the pkgsrc
[19:46] <nacc> sorry, it's going to take me a second to context switch myself in
[19:46] <bryce> a bunch of packages have this same issue, and same workaround, that haven't had significant packaging changes in quite some time, so guessing it's not just needing the package control tinkered with
[19:47] <bryce> nacc, no prob, really I just wanted to see if this was a known problem for you, but sounds like it's not.  I can dig more on my own.
[19:47] <nacc> you might need to rebuild php-apcu first
[19:47] <nacc> https://launchpad.net/ubuntu/eoan/amd64/php-apcu/5.1.17+4.0.11-1
[19:47] <nacc> it provides php7.2-apcu only currently
[19:47] <bryce> mm, yeah I can try that
[19:47] <nacc> so basically now that you have that rebuilt php-defaults, you have to rebuild a bunch of thigns
[19:48] <nacc> so that they all refer to 7.3 only
[19:48] <nacc> and some thigs will need backports
[19:48] <nacc> although ideally a lot less than in the past, since debian has already transitioned
[19:48] <nacc> oh there's another thing you can reverse-depend check on
[19:48] <nacc> phpapi-20170718
[19:48] <nacc> that's the 7.2 API version
[19:49] <nacc> you don't want anything to reverse-depend on that
[19:49] <bryce> ok
[19:49] <nacc> you should be able to see what string you want for that instead with 7.3
[19:49] <nacc> https://people.canonical.com/~ubuntu-archive/transitions/html/html/php7.3.html
[19:49] <nacc> i assume you know about that?
[19:49] <nacc> that's the pile of things taht will need rebuilds, etc.
[19:50] <nacc> there will be more, because you'll get dep8 failures
[19:50] <bryce> yep, that's the link I've been working from
[19:50] <nacc> but you basically have to boostrap the core first to get to 7.3 (even if it's in universe for now) then transition the whole rest of the stack
[19:50] <nacc> symfony is usually the worst
[19:50] <nacc> but i can help you deal with that eventually
[19:50] <nacc> i can also help sponsor uploads as needed
[19:51] <bryce> nacc, I did notice though that for the 5->7.0 transition you had a much longer package list - 400-some.  But most of those no longer exist, so was curious about the story there
[19:52] <bryce> I've managed to successfully build the majority of what's on php7.3.html, only about half a dozen failures
[19:52] <nacc> bryce: right that was much more painful :)
[19:52] <nacc> bryce: we were ahead of debian (they supported both, not just 7.0) and we had to remove some/many
[19:53] <nacc> bryce: that's great (half dozen is way more tractable)
[19:53] <nacc> bryce: so yeah, i'm guessing if you rebuild & bump php-apcu, php-igbinary will work
[19:53] <nacc> i would go ahead and just do all of those in that same PPA
[19:53] <bryce> ok great
[19:54] <nacc> if tests fail, you can upload once with tests disabled, so it builds, then upload again with tests enabled
[19:54] <bryce> yeah I think I've lucked out between you and debian things are reasonably clean for my first go :-)
[19:54] <nacc> it chews versions, but it also is a way to bootstrap without root archive access
[20:00] <bryce> nacc, thanks, this gives me some directions to chase, I'll touch base next week or so if I have any other questions, thanks again!
[20:07] <nacc> bryce: definitely, i'll be around; i'll try to respond within 24 hours
[23:59] <foo> Is it possible to allow 1 user to restart a systemd server? I normally use sudo ... but I only want them to restart a service (after some files change)... I don't think a server can automatically restart when files echange
[23:59] <foo> hmm


[00:01] <arraybolt3> I know several flavors got good testing.
[00:03] <guiverc> So you should ; http://iso.qa.ubuntu.com/qatracker/reports/testers has you 3rd on focal.6 testing !  Thank you good Sir
[01:08] <guiverc> arraybolt3, i just saw dbungert's reply on openbox issue... I can test for issue later today on debian/testing  (if helpful)
[01:11] <arraybolt3> Thanks.
[01:14] <arraybolt3> Sigh. Many of the things dbungert is requesting are things that I legitimately should have known but didn't, and it's starting to get a bit frustrating to have a critical patch need so many extra revisions when we're in a time crunch. Maybe we should add some more suggested reading or required reading to our Wiki, I dunno.
[01:17] <guiverc> We're all learning.. I fear if more is added, it may have the effect of scaring newbies off  (info overload etc, but extra links of additionally useful detail maybe okay)...  You are doing well Aaron regardless
[01:19] <arraybolt3> Valid point. I guess frustration later on is better than fear early on.
[02:22] <arraybolt3> guiverc: Thanks for the encouragement :) I finished getting things ready, here's hoping that was the last round of changes needed.
[03:59] <arraybolt3> WOOHOO we made it! Openbox finally accepted!
[04:48] <guiverc> :)    Well done arraybolt3 !
 Hello 😊
[23:43] <arraybolt3> @salih4187: o/
 Is Android Development good choice?
[23:46] <arraybolt3> @salih4187: I think this is probably the wrong room for that question. This is the room for discussing the development of Lubuntu.
 Oh sorry
 I will ask in another group


[00:51] <superm1> is there a workaround for this PPA's out of space issue?  i've got a couple of daily build ppas for ~mythbuntu that have been sending emails for days now about being full even though there are almost no packages there
[01:00] <wgrant> superm1: Sure, ask at https://answers.launchpad.net/launchpad/+addquestion for a quota increase
[03:58] <superm1> wgrant: oh that's the only workaround?  with how much the builds churn from day to day, that would probably only help for another day or two
[05:50] <persia> superm1: Rumours indicate that a fix should land early next week, so that might be enough
[09:04] <tsdgeos> https://launchpad.net/~aacid/+archive/qt5hacks/+build/3962969 "failed to build" and no other explanation at all?
[09:12] <geser> tsdgeos: try a "retry" if you can
[09:13] <tsdgeos> geser: well, it's going to take 24 hours again, i'd like to know what failed to be honest
[09:14] <geser> my guess is LP lost track of the build
[09:14] <StevenK> If it seriously did take 24 hours, and if the build spent 5 hours on one step with no output, it gets killed.
[09:15] <tsdgeos> StevenK: it took 24 hours in the queue, it's not my fault stuff the servers are overloaded
[09:15] <tsdgeos> i'll retry
[09:15] <StevenK> I can bump it up if you wish to watch
[09:15] <tsdgeos> nah it's ok, i have other things to do
[09:15] <tsdgeos> it's just 4 hours this time
[09:16] <StevenK> Not any more ...
[10:07] <tsdgeos> StevenK: thanks
[12:35] <jochensp> Hi, what happens to a binary package in a PPA if the source package doesn't provide it anymore, will it be delete from the PPA?
[12:37] <TheLordOfTime> jochensp:  i dont think it'll be purged from a PPA unless you hit the delete button...
[12:37] <TheLordOfTime> but i'm not sure.
[12:37]  * TheLordOfTime pokes czajkowski who might know
[12:39] <jochensp> TheLordOfTime: thanks for the answer, but I need a definite statement because I would need to redesign my packages otherwise
[12:39] <TheLordOfTime> jochensp:  you realize i poked someone who'd know?
[12:39] <TheLordOfTime> also, patience.
[12:39] <jochensp> TheLordOfTime: yes, just wanted to thank you :)
[12:40]  * TheLordOfTime assumes people automatically don't thank him, thereby it eradicates the issue of impoliteness :P
[12:40] <TheLordOfTime> but...
[12:40] <TheLordOfTime> thanks for thanking me.
[12:40] <czajkowski> TheLordOfTime: one moment
[12:40] <czajkowski> am in the middle of one thing :)
[12:40] <TheLordOfTime> :P
[12:40] <czajkowski> also patience :)
[12:41] <TheLordOfTime> czajkowski:  i'm not the one asking the question :P
[12:41]  * TheLordOfTime realizes he broke nginx and goes to fix it
[13:09] <czajkowski> jochensp: normally they are deleted every 6 hours, but we currently have a bug open about that which is being worked on
[13:09] <jochensp> czajkowski: thanks
[13:10] <czajkowski> np
[13:18] <mdeslaur> Can someone confirm that there's no API to delete a nomination? I see getNominations() and addNomination(), but nothing to delete...
[13:22] <mdeslaur> oh, actually...an approved nomination is then called a task, right?
[13:23] <mdeslaur> Is there an api to delete a task?
[13:24] <mdeslaur> ah, found it, nm
[15:02] <SpamapS> How come https://bazaar.launchpad.net/~work-items-tracker-hackers/launchpad-work-items-tracker/trunk is "not a branch" to bzr, but without the https, it works fine?
[15:02] <czajkowski> mgz: ^^
[15:03] <SpamapS> Or, perhsp to the bigger issue, is there any way to fetch branches over https or bzr+ssh anonymously
[15:11] <tedg> sinzui, Hey, so it seems that I can't make a series private, is that correct or am I missing something?
[15:13] <sinzui> Lp doesn't have private series
[15:13] <sinzui> Beta testers can create Proprietary projects which are private
[15:14] <tedg> Okay, I see.
[15:14] <tedg> Thanks sinzui
[15:14] <sinzui> tedg, In general the who project can be Proprietary or Embargoed to make it confidential. Bugs, Branches, and Blueprints can be made confidential on Public projects
[15:15] <sinzui> s/who/whole/
[15:15] <tedg> sinzui, Yeah, I was hoping to use a private series for private milestones in my blueprints.
[15:16] <tedg> sinzui, Not worth making another project to be private.
[15:26] <mgz> SpamapS: no, but you can register a bot and give it a dedicated ssh key
[15:27] <mgz> or fetch over http and check signatures on the branch, if they're used
[15:52] <SpamapS> mgz: is there any technical reason https doesn't work though?
[15:58] <mgz> SpamapS: just not plumbed in I think
[15:59] <mgz> though there may be twisty launchpady reasons why that's not easy to do
[15:59] <SpamapS> its weird because hitting it in the browser gives the same result
[15:59] <SpamapS> 301 -> changes
[16:02] <mgz> right, the https one is actually a different box, hence the redirect
[16:06] <chrisccoulson> hmmm, can i get more space for https://launchpad.net/~mozillateam/+archive/firefox-next/ and https://launchpad.net/~mozillateam/+archive/thunderbird-next/ please, whilst bug 1071562 still exists?
[16:11] <czajkowski> chrisccoulson: sure
[16:11] <czajkowski> should be fixed shortly though
[16:11] <chrisccoulson> thanks
[16:12] <czajkowski> chrisccoulson: done
[16:12] <chrisccoulson> cool, thanks :)
[16:39] <twoxyo> hi ! Is there somebody available 5 min ? I try to update the trunk branch of a launchpad project from a Bazaar branch to a github project : https://launchpad.net/glances/trunk/ ;
[16:39] <twoxyo> When I try, I have the following message : This foreign branch URL is already specified for the imported branch ~2xyo/glances/master.
[16:40] <mdeslaur> so, are we generally supposed to be using "1.0" or "devel"?
[16:58] <mgz> twoxyo: seems someone else already has that git branch imported?
[16:59] <mgz> mdeslaur: that's a small mystery to me too, though I've seen a couple of places where devel was deliberately used because 1.0 lacked a particular api
[16:59] <mdeslaur> mgz: right, that's what I'm hitting now
[16:59] <mgz> in which case, using devel is what people seem to do :)
[17:04] <mgz> twoxyo: so, it seems the current state on launchpad is what you want? and irc doesn't like nicks that start with numbers.
[17:39] <SpamapS> hrm, is there a way to get launchpadlib to keep an HTTPS connection open for a while? Watching the work items tracker scrape all the blueprints, each one requiring a new SSL handshake, is a little painful
[20:21] <alesage> is it possible to just upload something to launchpadlibrarian?  I need to be able to "attach" a file to a Launchpad merge proposal
[20:36] <maxb> no, it isn't. I'd suggest attaching it to a bug, creating one if necessary
[20:37] <alesage> thx maxb
[21:03] <Sweetshark> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1017125/+nominate <- no nomination for quantal possible? is that intentional?
[21:12] <maxb> Sweetshark: Looks to already be done to me
[21:14] <maxb> Or, if you're asking about permissions, I think series nomination is quite locked down, to prevent overly-excited users nominating bugs for series without regard to an understanding of Ubuntu's processes
[21:19] <Sweetshark> maxb: hmm, but I can nominate every series except quantal -- that just seems wrong.
[21:20] <Sweetshark> launchpad is teasing me.
[21:20] <Sweetshark> ;)
[21:27] <maxb> Sweetshark: as I said, quantal is already nominated there
[21:28] <Sweetshark> maxb: gah!
[21:28]  * Sweetshark needs to take his drugs ;)
[21:28] <Sweetshark> <- facepalm
[23:33] <simplew> can anyonetell if is possible to get a diff from the last changes made in launchpat for a certain project ?


[07:50] <didrocks> hey mmrazik
[07:50] <didrocks> what was the bzr misconfiguration you are talking about?
[07:52] <didrocks> thanks for the report btw :)
[09:20] <didrocks> larsu: on this not so sunny Friday, do you want some really free karma? https://code.launchpad.net/~didrocks/indicator-power/bootstrap/+merge/134623
[09:28] <larsu> didrocks, sure! done ;)
[09:28]  * larsu love lp karma
[09:29] <didrocks> larsu: thanks! I knew you live for karma!
[10:04]  * apw has recently updated on Quantal and the messaging indicator is gone, i assume this is not expected
[10:06] <larsu> apw, yes it is: the messaging menu is only shown when you have applications that integrate with it. And you need to start them manually once
[10:08] <apw> larsu, oh, hmmm, is that new behaviour or am i just unobservant
[10:09] <apw> larsu, i thought i used to start the applications from that menu ...
[10:09] <ppisati> i've same problem as apw
[10:09] <ppisati> and i always had the envelope icon
[10:09] <larsu> apw, you'll be able to, you just need to start them once and they'll show up again
[10:09] <ppisati> first thing i did in the morning was to start irc, msn, skype, ectec
[10:10] <larsu> beware: not all applications have been ported to the new API yet
[10:10] <ppisati> and i did it going to the messaging menu, and mrking myself as avilable there
[10:10] <apw> larsu, indeed starting gwibber did make the menu appear
[10:11] <ppisati> now, how am i supposed to login in msn if all the dialogues went through it? (and the icon/menu is not there anymore)
[10:11] <larsu> apw, and it will stay there now :) (until you uninstall gwibber or disable messaging menu integration in its preferences)
[10:12] <apw> larsu, so did that happen when i updated P->Q and i just didn't notice?
[10:12] <larsu> apw, yep
[10:13] <apw> an pidgin which i use most isn't apparently connected to it hense its not appeared again before
[10:13] <larsu> apw, yeah pidgin is one of the apps that aren't ported yet. But there's already a patch attached to https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1040259
[10:16] <larsu> apw, fyi: http://design.canonical.com/2012/04/status-menus/
[10:16] <apw> larsu, thanks for the explanations; i am not sure the user supprise this clearly engenders was the best user experience possible, not that any of that is your fault
[10:17] <ppisati> larsu: so, if i start an application that uses that menu, it appears, right?
[10:17] <ppisati> larsu: but wasn't empathy supposed to start automatically at boot?
[10:18] <larsu> ppisati, no, empathy doesn't start automatically afaik
[10:18] <ppisati> larsu: well, then it did when you select "available" in the envelope men
[10:18] <ppisati> u
[10:22] <larsu> ppisati, you only have to start the application once to make it appear in the menu forever from that point on (even after you close the app or reboot)
[10:22] <ppisati> larsu: ack, done
[10:22] <ppisati> larsu: thanks
[10:23] <apw> larsu, is there a way to get rid of things you never use from it which you used in the past and no longer do ?
[10:23] <ppisati> larsu: but i don't get why it shouldn't be there after a P->Q transition
[10:23] <larsu> ppisati, apw, I agree it's not a perfect experience for users upgrading from P -> Q, but due to the new API it was practically impossible to write migrations
[10:23] <larsu> it was a tradeoff, we chose the minor annoyance of starting the app once
[10:23] <ppisati> larsu: ok
[10:24] <larsu> apw, a well-behaved application will offer a preference. Otherwise you can remove it from dconf-editor (com.canonical.indicator.messages.applications)
[10:24] <larsu> of course, uninstalling an application will also remove it
[10:26] <ppisati> larsu: another question, i was used to have the skype icon show up in the iconbar
[10:26] <ppisati> larsu: but is not there anymore, you know why?
[10:26] <ppisati> of course, skype is running now
[10:26] <larsu> ppisati, it shows up for me, right next to the messaging menu
[10:26] <ppisati> :(
[10:26] <ppisati> nt for me...
[10:26] <ppisati> i've it in the unity bar
[10:26] <ppisati> but not up there
[10:28] <larsu> ppisati, no idea, sorry. There doesn't seem to be a preference, either
[10:31] <ppisati> larsu: do you know if there's a place (directory, gconf entry, etcetc) where all the icons that show up in the bar are listed?
[10:31] <larsu> no, there isn't
[10:49] <mhr3> ppisati, try adding "skype" to com.canonical.unity.panel.systray-whitelist
[10:49] <mhr3> (in dconf)
[10:53] <ppisati> mhr3: so we still need to whitelist it, ok
[10:54] <ppisati> mhr3: question: since it's such a common app (and it's integrated with the messaging menu), why don't we whitelist by default?
[10:54] <mhr3> it's weird, i remember it using indicator previously, now it isn't :/
[10:54] <mhr3> larsu, i guess because of the api changes?
[10:55] <ppisati> s/it's integrated/it's not integrated/
[10:56] <larsu> mhr3, yep, but somebody seems to be working on it: https://bugs.launchpad.net/skype-wrapper/+bug/1040259
[10:58] <larsu> mhr3, I don't have skype on the whitelist. I think its an appindicator already
[10:58] <mhr3> larsu, that's what i said, but it disappeared for me after moving to 12.10
[10:59] <larsu> mhr3, oh, you mean skype in the messaging menu or skype on the panel?
[11:03] <mhr3> larsu, panel
[11:04] <mhr3> or maybe it's just a qt lib that's no longer installed with skype
[11:05] <larsu> mhr3, might be. Does the sykpe binary export the /org/kde/statusnotifieritem objects for you?
[11:05] <larsu> and do you have indicator-application installed
[11:06] <mhr3> larsu, it doesn't export that
[11:06] <larsu> that's the problem, then :)
[11:06] <larsu> which skype version are you running?
[11:06] <mhr3> the question is why :)
[11:06] <mhr3> <IP_ADDRESS>
[11:06] <larsu> okay, same for me
[11:12] <larsu> mhr3, do you have sni-qt installed?
[11:13]  * larsu found agateaus blog post about it: http://agateau.com/2011/07/19/statusnotifieritem-for-qt-applications/
[11:13] <larsu> skype seems to use QSystemTrayIcon still, and sni-qt is a plugin that turns systray icons into app indicators
[11:13] <mhr3> larsu, i do :/
[11:13] <larsu> :(
[11:14] <mhr3> and that's what happens when aurelien leaves
[12:08] <conscioususer> larsu: do you know where I can find some UOA docs for third party app devs? just reading the api is being insufficient for me
[12:10] <conscioususer> mhr3: I heard some people solved this issue by installing the correct arch of sni-qt
[12:12] <mhr3> conscioususer, bingo, installing the i386 variant fixed it
[12:13] <mhr3> larsu, ^^
[12:13] <conscioususer> :)
[12:15] <mhr3> now if only the skype menu didn't flicker everytime i click on it
[12:16] <larsu> conscioususer, awesome, thanks!
[12:17] <larsu> conscioususer, I'm not sure about docs for uoa, let me find out
[12:18] <conscioususer> larsu: thanks :)
[12:23] <didrocks> larsu: hey, I have an other simple and dummy merge for your karma :) https://code.launchpad.net/~didrocks/indicator-power/changes_from_trunk.12.10/+merge/134643
[12:24] <larsu> didrocks, sure - but I'll wait to see the diff. Not that I don't trust you.......
[12:24] <didrocks> larsu: sure sure :)
[12:25] <larsu> conscioususer, meet amigadave :)
[12:25] <amigadave> conscioususer: hi!
[12:25] <amigadave> conscioususer: mardy wrote https://docs.google.com/a/canonical.com/document/d/1MVsDdwzff6LqQ6i3z-cSgg8dHjb5DaHMXFeWtIa6Cvo/edit which is some general developer documentation for UOA
[12:25] <amigadave> conscioususer: is that more what you were looking for?
[12:27] <conscioususer> amigadave: probably, as I'm specifically looking for info for 3rd party clients
[12:27] <conscioususer> amigadev: at a first glance this seems enough, thanks :)
[12:27] <amigadave> conscioususer: we are working to get all of that documentation into the API references too
[12:28] <amigadave> let us know if you have any feedback :)
[12:29] <conscioususer> amigadave: will do, thanks :)
[12:31] <larsu> didrocks, approved
[12:32] <larsu> didrocks, I'm really looking forward to seeing how daily landing will turn out in practice
[12:33] <didrocks> larsu: same here, we are >< <- that close
[12:33] <larsu> \o/
[12:33] <didrocks> larsu: just need a commit after the bootstrapping so that it can detect there are some changes
[12:33] <didrocks> larsu: let's find something useful for each project :)
[12:35] <larsu> didrocks, yep :)  btw, did you decide on a rule on when to mark bugs as "fix released"?
[12:36] <didrocks> larsu: right now, I only open the downstream bug and it will be marked as fix released, I don't touch the upstream one until you decide to do your own release
[12:36] <didrocks> larsu: it's really as you prefer, if you think it should close it, we can discuss it :)
[12:37]  * larsu is unsure
[12:37] <larsu> still :)
[12:41] <didrocks> let's see how it goes that way :)
[13:50] <conscioususer> amigadave: er, why does uoa store user passwords for oauth-based accounts?
[13:55] <amigadave> conscioususer: so that it can reauthenticate without the user having to enter the credentials again
[13:55] <conscioususer> amigadave: isn't this what the access token is for?
[13:56] <amigadave> conscioususer: if the token expires, then the user would otherwise have to re-enter the username and password
[13:57] <amigadave> i think that refresh tokens were tried (with Google, specifically) but they did not work reliably
[13:57] <amigadave> and Google has very short token validity :/
[13:57] <conscioususer> amigadave: but what about oauth1.0 services like twitter?
[13:58] <conscioususer> amigadave: btw, what do you mean by "not work reliably"? I'm curious on that one because I use google refresh tokens on an app of mine
[13:59] <amigadave> conscioususer: mardy knows the full details
[13:59] <amigadave> conscioususer: and #accounts-sso might be a better place for these questions :)
[13:59] <conscioususer> oh, of course
[13:59] <conscioususer> sorry, will move there :)
[14:53] <davidcalle> mhr3, does this kind of bug fall under your new jurisdicition? (frequency of recommendations and sources calls to *search.ubuntu.com) https://bugs.launchpad.net/ubuntu/+source/unity-lens-video/+bug/1079699
[14:53] <mhr3> pawel is looking at it
[14:54] <mhr3> i mean, pstolowski
[14:54] <davidcalle> Ok
[14:56] <pstolowski> davidcalle, mhr3: hey, yep. it's basically "by design", I'll check with server side guys if we can query it less often for recommendations.
[14:57] <mhr3> pstolowski, are the sources checked that way too?
[14:58] <pstolowski> mhr3: yes, same interval
[14:58] <pstolowski> mhr3: this is definately too often for sources
[14:58] <mhr3> i can imagine that sources should be checked just once
[14:58] <mhr3> + on location change
[14:58] <mhr3> which i'm not sure can be detected easily
[14:59] <davidcalle> mhr3, I think that tedg has made some work on Ubuntu geoclue last cycle, maybe he could give a hint?
[15:00] <mhr3> yea, i'm pretty sure the time indicator or whatever behind it knows, just don't think it exposes changes to location as some signal
[15:01] <tedg> mhr3, We poll occasionally, it's GeoIP though so it really only changes on reboot.  But it's all just GeoClue.
[15:01] <tedg> mhr3, So if you cache an address then you can get the new one.
[15:02] <tedg> mhr3, If you grab indicator-location you can see what you've got easily.  Also, some simple sample code.
[15:02] <pstolowski> mhr3, davidcalle: we could consider location for R, but for P or Q we should only fix the frequency
[15:03] <mhr3> tedg, i'm not a fan of polling, i want to be notified :)
[15:03] <mhr3> pstolowski, sure
[15:03] <davidcalle> pstolowski, +1
[15:04] <tedg> mhr3, Well, you'll be notified on changes.  For GeoIP we can't get notified.
[15:30] <Squarism> java is the most popular programming language, intellij is the most popular IDE... tons of hotkeys in intellij conflict with Unity. Please solve this to make ubuntu alot more user friendly for a big number of programmers
[15:31] <larsu> [citation needed]
[15:34] <bregma> Squarism, is there a bug in Launchpad you can reference?
[16:55] <MCR1> smspillaz: Hi :) Thanx 4 the ultra-fast approval...
[17:44] <mterry> didrocks, what does the jenkins error in https://code.launchpad.net/~mterry/unity-scope-gdrive/rename/+merge/134567 mean?
[17:45] <didrocks> mterry: I don't really know, it seems something similar to my check I did with tarmac, like "check that the approved rev id is the latest rev on the branch"
[17:45] <didrocks> I think they do the same on jenkins
[17:45] <didrocks> mmrazik? ^
[17:45] <didrocks> hum, not here…
[17:46] <didrocks> mterry: so, I approved agian
[17:46] <didrocks> now see:
[17:46] <didrocks> Approved revision: 30
[17:46] <didrocks> sometimes, it can be "unknown"
[17:46] <didrocks> due to launchpad timeout I guess
[17:46] <didrocks> maybe that was the case
[17:46] <didrocks> let's bet on this
[17:47] <MCR1> didrocks: Hi :) Could we change the way expo is patched for Ubuntu ? It seems to create quite some problems...
[17:47] <didrocks> (it seems they have the same check, see "Unapproved changes made after approval.")
[17:47] <didrocks> MCR1: how do you want to change it?
[17:47] <MCR1> Hmm, maybe with some ifdefs or so...
[17:48] <MCR1> COMPILE_FOR_UBUNTU_UNITY or something like that
[17:48] <MCR1> the problem is that for example this patch fails all the time: https://code.launchpad.net/~mc-return/compiz/compiz.merge-fix1009592-and-1074487-expo-xml-tooltip-fixes/+merge/132754
[17:48] <didrocks> MCR1: what do you mean? it's still a patch applied
[17:49] <didrocks> MCR1: with inline packaging, you can now try and apply it yourself :)
[17:49] <didrocks> and fix it
[17:49] <didrocks> or convince upstream who did the patch to take it by default
[17:49] <MCR1> yeah, that is what I mean
[17:49] <didrocks> I would love that it's upstream
[17:49] <MCR1> it should be in upstream, otherwise things are really hard to fix
[17:50] <didrocks> if you can push for that, please try :)
[17:50] <didrocks> (I already tried)
[17:50] <didrocks> having patches to maitain is a burden
[17:50] <MCR1> and expo is currently very broken in various ways (the ubuntu patch is breaking it...)
[17:50] <didrocks> well, the ubuntu patch was done by upstream, you know ;)
[17:50] <MCR1> for example brightness and saturation settings are ignored...
[17:51] <MCR1> *of inactive viewports
[17:51] <MCR1> and other issues
[17:51] <didrocks> if you feel fixing them, that would be awesome!
[17:51] <MCR1> so I got to convince smspillaz and duflu ?
[17:51] <didrocks> exactly!
[17:51] <MCR1> ok
[17:51] <MCR1> thx
[17:51] <MCR1> 4 the info
[17:52] <didrocks> yw
[20:33] <Munchor> Hello guys
[20:33] <Munchor> When an appindicator does not remove itself properly, what is actually done


[00:17] <melmoth> is rebooting a zookeeper node on a maas installation supposed to work ?
[00:18] <melmoth> i did it on 2  sepearate installations, and after a reboot, the agent-state of the zookeeper node is being kept on "not-started" state
[00:18] <lifeless> thats more a #juju question, sorry!
[00:18] <lifeless> SpamapS: ^
[00:18] <melmoth> zookeeper runs, but it s log does mention thing likes "xpiring session 0x139bcf841700004, timeout of 10000ms exceeded"
[00:20] <SpamapS> as long as the address doesn't change, you should be able to reboot node 0
[00:20] <SpamapS> agents should poll/reconnect eventually
[00:20] <melmoth> thanks.
[00:21] <smoser> roaksoax, around ?
[00:31] <smoser> jtv, https://code.launchpad.net/~smoser/maas/packaging.lp1049177/+merge/124083
[00:34] <smoser> roaksoax, ^ for you too.
[00:38] <bigjools> smoser: I'll look
[00:43] <bigjools> smoser: do you need something to uninstall all that when the package is removed?
[00:45] <smoser> well ther ei sonly the one thing installed, and its will be removed just as any other file
[00:45] <smoser> the one thing ... /etc/apparmor.d/dhcpd.d
[00:46] <bigjools> smoser: ok - I didn't know if it was automatically removed or not
[00:46] <bigjools> smoser: can you do a packaging.precise merge as well please
[00:46] <smoser> yeah, its just a file.
[00:47] <smoser> ackaging.precise will depend on sru of the isc-dhcp fix also.
[00:47] <bigjools> yeah
[00:47] <smoser> and i'd like to wait until this at least is baked a bit before uploading that.
[00:47] <bigjools> yup
[00:48] <smoser> tomorrow i'll try to do a pakaging merge for precise though and just have the mp ready
[00:49] <bigjools> cool
[02:19] <jtv> Thanks smoser!
[02:23] <bigjools> hello jtv
[02:23] <jtv> Hi
[02:30] <jtv> bigjools: saw that email where DEFAULT_MAAS_URL turns out to tie into the UI somehow.  Damnation.
[02:30] <bigjools> jtv: yes - I asked diogo exactly how it breaks
[02:30] <bigjools> damnation indeed
[02:30] <jtv> No idea where that happens.
[02:30] <bigjools> back to the drawing board for you :)
[02:31] <matsubara> bigjools, jtv: if I dpkg-reconfigure the package and choose <IP_ADDRESS> (the internal interface where pxe /provisioning runs) then the web server stops listening on <IP_ADDRESS>
[02:31] <jtv> Hi there matsubara
[02:31] <matsubara> jtv, hey
[02:32] <bigjools> hey matsubara
[02:32] <jtv> Hmmm... this sounds as if the connection between UI and the setting is made in the packaging somewhere.
[02:32] <bigjools> that's a bizarre thing for the web server to do
[02:32] <bigjools> sounds like packaging
[02:32] <jtv> Yup.
[02:32] <jtv> It should definitely be listening on both interfaces.
[02:32] <bigjools> not sure why we need to tell apache where to listen, all interfaces seems more reasonable to me
[02:32] <jtv> Because it must service both you (the human) and the workers/nodes in the MAAS.
[02:32] <bigjools> yeah
[02:34] <matsubara> bigjools, jtv: when I run dpkg-reconfigure maas, it stops the apache server but doesn't restart it again
[02:34] <bigjools> matsubara: haha!
[02:35] <jtv> That does kind of explain...
[02:35] <matsubara> in any case it looks like a bug, reconfigure should restart apache, shouldn't it?
[02:35] <bigjools> yes
[02:35] <bigjools> not sure why it needs to restart it at all
[02:36] <matsubara> it stops it for some reason :-)
[02:36] <bigjools> if you restart it, does the UIU and everything else work?
[02:36] <bigjools> UI*
[02:37] <jtv> I wonder where it stops apache...  it seems to be only the postinst and such that mess with apache.
[02:38] <matsubara> yes, restarting it seems to bring the UI back up
[02:38] <roaksoax> matsubara: there's a bug where reconfigure does not restart apache and I'll deal with that
[02:39] <jtv> \o/
[02:39] <bigjools> woo
[02:39]  * bigjools heads out to lunch
[02:39] <jtv> roaksoax: out of interest, where does it stop apache?  I would have expected to see that in maas.config.
[02:39] <jtv> (Because I'm not a packaging expert)
[02:40] <roaksoax> jtv: we don't stop apache2
[02:40] <roaksoax> jtv: maybe it is crashing for some reason? the restart stops and start the daemon agian
[02:40] <roaksoax> maybe that is it?
[02:40] <jtv> Ohhhh
[02:40] <roaksoax> jtv: no error logs?
[02:40] <roaksoax> apache2 error logs that is
[02:40] <jtv> Ask matsubara :)
[02:40] <roaksoax> matsubara: http://paste.ubuntu.com/1201757/
[02:40] <roaksoax> matsubara: try that
[02:41] <jtv> I guess it's just a way to restart the wsgi processes..?
[02:41] <roaksoax> matsubara: can you, however, directly point me to bugs or issues you find with packaging otherwise I'll lots in bugmail
[02:41] <roaksoax> jtv: yes
[02:42] <roaksoax> jtv: so dpkg-reconfigure maas, change IP should restart apache2 to pick the new IP and things should be just fine
[02:42] <roaksoax> matsubara: ^^
[02:42] <jtv> Wait... what new IP?
[02:42] <jtv> Apache should be listening on all interfaces.
[02:42] <jtv> MAAS must be aware of the new address, but not apache, right?
[02:43] <roaksoax> jtv: yes, it is for maas to pick up the new IP
[02:43] <roaksoax> and stuff
[02:43] <matsubara> roaksoax, I'm looking at the apache logs. let me paste it for you
[02:44] <roaksoax> jtv: the dpkg-reconfigure maas sets a new ip in DEFAULT_MAAS_URL
[02:44] <roaksoax> s/in/for
[02:44] <matsubara> roaksoax, https://pastebin.canonical.com/74380/
[02:45] <roaksoax> matsubara: do you have a  node deployed where I can test?
[02:45] <roaksoax> matsubara: err log in and test?
[02:45] <roaksoax> that's maybe upstream error
[02:45] <matsubara> roaksoax, the maas server is running but there's no node deployed
[02:46] <roaksoax> matsubara: yeah can you tell me your steps to reproduce the issue you encountereD?
[02:46] <matsubara> roaksoax, sudo dpkg-reconfigure maas
[02:46] <matsubara> change the ip
[02:46] <matsubara> the apache server is stopped but not restarted
[02:47] <matsubara> feel free to log in the Lenovo lab
[02:47] <matsubara> https://wiki.canonical.com/Launchpad/QA/MAASLenovoLab
[02:47] <roaksoax> matsubara: yeah that's a bug
[02:48] <roaksoax> matsubara: there's a restart_apache2 missing on dpkg-reconfigure
[02:48] <roaksoax> matsubara: http://paste.ubuntu.com/1201757/
[02:49] <matsubara> I see
[02:50] <roaksoax> matsubara: try now
[02:50] <matsubara> is it a known bug?
[02:50] <roaksoax> matsubara: yes it is a known bug, I will fix it tomorrow
[02:50] <roaksoax> matsubara: i was concentrated on getting the releases support into maas
[02:51] <roaksoax> matsubara: pastebin /etc/maas/maas_local_settings.py after the dpkg-reconfigure
[02:51] <matsubara> roaksoax, yes, now it restarted fine
[02:52] <roaksoax> matsubara: alright cool then
[02:52] <matsubara> roaksoax, do you still need that pastebin?
[02:52] <roaksoax> bigjools: btw.. if you can take a look at https://code.launchpad.net/~andreserl/maas/add_ubuntu_releases_lp1013146/+merge/124092 and tell me how is it looking, it would be great
[02:52] <roaksoax> matsubara: nah!
[02:53] <matsubara> cool. thanks
[02:53] <roaksoax> matsubara: i'm sure the above fix has fixed things
[02:57] <roaksoax> jtv: so can we ship our own maas-dhcp upstart job then?
[02:57] <smoser> roaksoax, fwiw, there are python bindings to distro-info
[02:57] <jtv> And hi smoser
[02:57] <smoser> roaksoax, yeah you can do that.
[02:57] <smoser> (i'm not really here)
[02:57] <jtv> That explains.
[02:57] <roaksoax> smoser: python-bindings as in import DistroINfo etc etc or similar?
[02:58] <smoser> right
[02:58] <jtv> roaksoax: I have a handy example of a modified upstart job if you want it.
[02:58] <roaksoax> smoser: ah cool, willk use that intstead then
[02:58] <roaksoax> jtv: sure, i wont merge it tonight though as I'm in zombie mode
[02:58] <roaksoax> but will do tomorrow
[02:58] <roaksoax> i'd like to get this fixed tomorrow
[02:58] <jtv> @#$% timezones
[02:58] <jtv> I'd be most grateful.  Hang on, I'll paste my upstart script.
[02:59] <smoser> roaksoax, http://paste.ubuntu.com/1201799/
[02:59] <smoser> thats a patch to cobbler that i used to use it there.
[02:59] <smoser> might just get you started
[02:59] <smoser> but its very simple
[02:59] <roaksoax> smoser: nice, thanks!
[03:00] <jtv> roaksoax: I named it maas-dhcp-server — http://paste.ubuntu.com/1201804/
[03:00] <roaksoax> jtv: awesome, will merge it tomorrow and test
[03:00] <jtv> Thanks!  We'll need to make corresponding changes to trunk as well, as we need to restart dhcpd.
[03:01] <roaksoax> jtv: you can go ahead and make then later in your day today, so that tomorrow morning I can make the ones in packaging
[03:01] <roaksoax> and we should be good
[03:01] <jtv> \o/
[03:01] <jtv> Thanks again.
[03:02] <smoser> jtv, that looks reasonable.
[03:02] <smoser> did you see my note that we will need packaging of that?
[03:02] <smoser> as right now maas-dhcp just has 1 file
[03:03] <roaksoax> smoser: i'll take care of that tomorrow morning :)
[03:03] <jtv> smoser: If I'm thinking of the same note, then yes.  But that was quite some time ago now, so maybe there's something I'm missing.
[03:03] <smoser> jtv, so how are you going to configure $INTERFACES ?
[03:03] <jtv> /etc/default/maas-dhcp-server
[03:03] <jtv> Which also needs packaging.
[03:04] <smoser> jtv, no, my merge proposal had comment about it.
[03:04] <jtv> Oh
[03:04] <smoser> so you cant really do that
[03:04] <jtv> Didn't see that.
[03:04] <jtv> Why not?
[03:04] <smoser> hm..
[03:04] <smoser> so /etc/default/maas-dhcp-server is going to be a conf file
[03:04] <smoser> and if you edit it
[03:04] <smoser> and then the package upgrade
[03:05] <smoser> it will force a prompt
[03:05] <smoser> er... if the package'd file changes and there were local file changes.
[03:05] <roaksoax> smoser: we need to handle that automatically i'm afraid
[03:05] <jtv> Then... can we put it somewhere else?
[03:05] <smoser> roaksoax, right. so /etc/default/maas-dhcp-server is not the right place.
[03:05] <smoser> right.
[03:05] <jtv> /var/lib/maas/dhcp-interfaces?
[03:05] <smoser> for the things that you're configuring there, what i would suggest is some config not in /etc/
[03:05] <roaksoax> smoser: i already have an idea of how to handle that automatically
[03:05] <smoser> that maas managers
[03:06] <smoser> but what you *could* do is have /etc/default/maas-dhcp invoke 'maas-shell get-my-dhcp-interfaces'
[03:06] <smoser> or somethign like that.
[03:06] <smoser> but having maas edit that file i think is not right.
[03:07] <jtv> That's getting a little roundabout, given that all we want here is to set a variable.
[03:07] <jtv> Why not just...
[03:07] <jtv> if [ -f /var/lib/maas/dhcp-interfaces ]; then
[03:07] <smoser> you can do that. but i'd not bother with 'dhcp-interfaces'.
[03:07] <jtv>     INTERFACES=`cat /var/lib/maas/dhcp-interfaces`
[03:07] <jtv> etc?
[03:08] <smoser> but rather a shell sourceable file there.
[03:08] <smoser> and then you can set other things in it there also
[03:08] <smoser> rather than needing multiple settings potentially.
[03:08] <jtv> Well then we can do one better: just add a management command that prints out the interfaces.
[03:08] <smoser> thats what my suggestion above was
[03:08] <smoser> (/etc/default/maas-dhcp invoke 'maas-shell get-my-dhcp-interfaces')
[03:08] <jtv> Ah, then that'd be "maas" not "maas-shell," right?
[03:08] <smoser> sure. whatever it was.
[03:08] <smoser> or should be
[03:09] <smoser> but yes, ask maas what the value is
[03:09] <smoser> as it is the thing that knows
[03:09] <roaksoax> smoser: that's a cool idea
[03:09] <jtv> That's fine, yes.
[03:09] <smoser> anyway
[03:09] <smoser> bed time
[03:09] <smoser> good night.
[03:10] <jtv> nn
[03:12] <bigjools> so why is apache only listening on the one interface?
[03:13] <roaksoax> it is not, MAAS has as DEFAULT_MAAS_URL the IP of one interface
[03:13] <roaksoax> as a best effort attempt
[03:14] <roaksoax> to automatically determine what interface to be used
[03:14] <bigjools> ok
[03:14] <bigjools> to be used by what?
[03:14] <roaksoax> s/interface/address
[03:14] <roaksoax> to be used by MAAS as DEFAULT_MAAS_URL
[03:14] <roaksoax> in packaging that is
[03:14] <bigjools> I think we're confused about what it means
[03:15] <bigjools> as far  as the code is concerned, it's the internal-facing URL for the nodes to contact for API
[03:15] <roaksoax> bigjools: yep
[03:15] <roaksoax> bigjools: i know that :)
[03:15] <bigjools> ok :)
[03:16] <bigjools> so we need to prompt for it on installation
[03:16] <bigjools> it only does it on reconfigure
[03:16] <bigjools> or is that deliberate?
[03:16] <roaksoax> bigjools: that's deliberate. We cannot, should not prompt for it on installation
[03:16] <bigjools> in any case it picks the wrong ip/interface in the qa lab
[03:17] <bigjools> ok
[03:17] <roaksoax> bigjools: that's why we display a message saying that if it is the wroing address it should be changed
[03:17] <bigjools> gotcha
[03:17] <bigjools> it's coming back to me now
[03:17] <roaksoax> bigjools: if we always proimpt for it, it will break MAAS installation on the CD
[03:17] <roaksoax> s/on/from
[03:18] <bigjools> yeah
[03:19] <roaksoax> alright
[03:20]  * roaksoax is off to bed
[03:20] <roaksoax> goognight all
[03:21] <bigjools> nn
[08:45] <jam> jelmer, mgz: https://plus.google.com/hangouts/_/6b0c81dbfeb8a772657f16370d380d1e26c9a4d3?authuser=0&hl=en-GB
[12:32] <Daviey> roaksoax: not urgent today.. but can you explore using freeipmi-tools as a config option in maas upstream?
[12:34] <roaksoax> Daviey you mean instead of ipmitool?
[12:37] <Daviey> roaksoax: right
[13:09] <mgz> hm, I can't make after updating trunk because buildout is timing out trying to get repl
[13:11] <mgz> where do I need to remove it from to skip over that? it's not in versions.cfg and removing from buildout.cfg didn't help
[13:12] <mgz> ah, need to edit the makefile
[13:34] <smoser> roaksoax, do you happen to know why maas uses 'python-twisted'  as a dependency
[13:34] <smoser> doku was asking me if that was necessary, versus a more fine grained list of what it actually uses.
[13:39] <roaksoax> smoser pserv and txlongpoll need it
[13:39] <smoser> but they dont need the blanket package
[13:40] <smoser> they need specific things it depends on
[13:40] <roaksoax> smoser why is that is it still uninstallable?
[13:41] <smoser> are you asking whether or not it is uninstallable? or asking *why* it is
[13:41] <smoser> i think doku probably fixed it, or if not is on it
[13:41] <smoser> and it will be fixed
[13:41] <smoser> but specifying a meta package when you dont need it is just wasteful
[13:41] <smoser> (not a big deal, just we probably get things we dont need)
[13:42] <roaksoax> python-twisted is a met package?
[13:55] <roaksoax> smoser smoser: http://bazaar.launchpad.net/~maas-maintainers/maas/trunk/view/head:/required-packages/base
[13:57] <smoser> roaksoax, http://paste.ubuntu.com/1202679/
[13:57] <smoser> it sure looks as "mostly meta"
[13:58] <smoser> http://paste.ubuntu.com/1202680/
[13:58] <smoser> roaksoax, its low priority
[13:58] <smoser> but doku asked me
[13:58] <smoser> as we wouldn't have seen the uninstallable if we didn't depend on that package :)
[14:06] <smoser> rvba, around ?
[14:06] <smoser> {{kernel_params(arch="amd64") | kernel_command}}
[14:07] <smoser> what does that do ? in the templates
[14:07] <smoser> is it "call kernel_params *or* use kernel_command ?)
[14:07] <smoser> "
[15:23] <roaksoax> smoser: hold on
[15:24] <roaksoax> smoser: why was python-twisted uninstallable in the first place?
[15:24] <roaksoax> smoser: cuase the reason why maas was uninstallable in your case was becuase a dependecy was uninstallable, not becuase it depended on a meta-package
[15:25] <smoser> right.
[15:25] <smoser> you are correct, roaksoax . python-twisted should never have become uninstallable (that was a valid issue) and prevented maas from being installed.
[15:25] <smoser> but it just raised the question of "why were you depending on that meta package" rather than the specific packages you need
[15:26] <roaksoax> smoser: now, we need to find out what dependencies of python-twisted are needed by maas
[15:26] <roaksoax> allenap: ^^
[15:28] <roaksoax> smoser: well upstream mentioned that as a dependes, maybe they just need python-twisted-core, or maybe just need the whole of python-twisted
[15:29] <roaksoax> smoser: as pserv runs a twisted daemon
[15:31]  * allenap looks
[15:32] <allenap> smoser, roaksoax: python-twisted-{core,web} is all I think for direct deps.
[15:37] <roaksoax> allenap: ok cool, i think we can update that then
[15:38] <allenap> Cool.
[16:03] <allenap> mgz: bzrlib.osutils.get_user_encoding() reports "ascii", but my args do seem to be encoded as utf-8. Would you happen to know if this is something my terminal has done, when I pasted in from charmap? Or a bug in get_user_encoding()?
[16:04] <mgz> it's based on your C locale setting
[16:04] <allenap> mgz: I'm tempted to use sys.getfilesystemencoding() but I'm not sure that's a good idea.
[16:04] <allenap> mgz: en_GB.UTF-8
[16:04] <allenap> LC_ALL
[16:06] <mgz> okay, you probably are using bzrlib from a script but aren't calling `locale.setlocale(locale.LC_ALL, '')`
[16:07] <allenap> mgz: Ah ha, such are the runes needed. Thanks.
[16:34] <guimaluf> anyone can tell me what can be generating this error in my node syslog? Sep 12 17:34:26 <IP_ADDRESS> main-menu[582]: (process:2659): wget: server returned error: HTTP/1.1 500 Internal Server Error
[16:34] <guimaluf> Sep 12 17:34:26 <IP_ADDRESS> main-menu[582]: WARNING **: Configuring 'network-preseed' failed with error code 1
[16:34] <guimaluf> Sep 12 17:34:26 <IP_ADDRESS> main-menu[582]: WARNING **: Menu item 'network-preseed' failed.
[16:41] <mgz> guimaluf: are you filing bugs about the issues you run into?
[16:41] <mgz> everyone: there's a really basic "what is maas" question on the openstack mailing list
[16:42] <mgz> I'd reply if I knew how to give a pithy answer.
[16:43] <guimaluf> mgz, no i'm not. I don't understand the cause of this issue. It happened out of nothing. :/
[16:45] <mgz> guimaluf: if no one is around to answer on irc, it's good to follow up with either a bug report, or a message to the mailing list with more details
[16:46] <mgz> people are in different timezones, there's no guarentee someone who can answer your questions will be on at the same time as you
[16:47] <guimaluf> I know :/
[16:47] <guimaluf> I'm trying to get information about my issue, but I dont know where to go :/
[16:51] <mgz> so, hm, the launchpad MaaS page also suggests using askubuntu with the tag maas
[16:51] <mgz> but when you've got a bug, I'd just file against maas on launchpad
[18:06] <guimaluf> mgz, I found out the issue. the char 'é' inside comments on maas.pressed :/
[19:49] <melmoth> what does it mean when "juju deploy" on a maas server ends up with the new machine kept in "pending state" ?
[19:49] <melmoth> on a working install, as soon as i deploy something, i see a new machine id, with info about it
[19:50] <melmoth> but here, on the real cloud i try to install, the machine is still in pending, and no new machine are set into "allocated to root" on the web page
[20:22] <guimaluf> melmoth, have you check the ssh-keys? in my case I'd give up to use maas + juju + openstack.
[20:22] <guimaluf> cause of this. all my servers kept in pending state.
[20:22] <melmoth> yep, not the ssh key.. turned out zookeeper was having problem, did not investigate , we are on our way to a new bootstrap
[20:25] <guimaluf> melmoth, exactly! zookeeper problem!
[20:29] <guimaluf> anyone know how can I set up a smarter partition scheme when deploying a node? I've tried late-command, but isn't working. :/
[20:34] <melmoth> guimaluf, http://pastebin.com/gtxGJgt3
[20:35] <melmoth> this is a preseed i used on a 1 disk machine where i wanted to have a nova-volumes vg separate from the vg used by the system done at installation stage
[20:36] <melmoth> i guess doing something similar in the preseed file used by maas should work (but you dont have to bother creating the nova-volumes vg, the nova-volumes charms takes care of it)
[20:36] <guimaluf> melmoth, partman can only handle with one disk. I want to make sd[b-z] also avaible
[20:36] <melmoth> havent try with several disk, my main problem was that i had only 1 anyway :)
[20:38] <guimaluf> I had, and partman dont deal with more then one disk. also none of my recipes had been aplied
[20:55] <melmoth> grumble same stuff again
[21:05] <melmoth> ahhh, note for later: dont put <IP_ADDRESS> for the maas server in the juju environment.yaml :)
[21:05] <melmoth> things seems better now


[06:47] <ara> good morning!
[10:40] <ara> morning primes2h
[10:47] <primes2h> morning ara :-)
[10:57] <davmor2> morning all
[11:05] <sp> morning
[11:05] <sp> I just did my daily upgrade, which caused a partial upgrade for me and removed both gnome and gnome-compiz
[11:06] <sp> now the story is that desktop effects were disabled and upon logging out, logging on again and trying to enable effects again Appearance Properties seems to have crashed
[11:06] <sp> well, not actually crashed, it's just not responding after clicking 'keep settings' in the dialog with the same name
[11:07] <sp> I haven't followed development closely, but I am not sure about whether both compiz and compiz-gnome should have been removed in the first place... could someone give me insight on that before I file a bug report?
[11:14] <sp> mhh... seems like metacity breaks on compiz-gnome < 1:0.8.4-0ubuntu14, where ubuntu13 is my current candidate, so nevermind :)
[11:29] <ara> sp, there's one
[11:29] <ara> sp, let me check
[11:29] <ara> sp, https://launchpad.net/bugs/559054
[11:29] <ubot4`> Launchpad bug 559054 in compiz (Ubuntu) "compiz-gnome needs to be removed during partial upgrade (affects: 2) (heat: 14)" [Medium,New]
[11:29] <sp> ara: thanks
[11:30] <ara> sp, can you please confirm the issue?
[11:31] <ara> sp, and can you complete the report with the apt logs and/our output, please?
[11:32] <sp> ara: well, it's quite obvious, compiz and compiz-gnome got removed due to a Breaks: in metacity
[11:32] <sp> the actual bug seems to be in Appearance Properties, which only checks for /usr/bin/compiz to be installed before allowing to enable desktop effects
[11:32] <ara> sp, yes, but it will be nice to have the version numbers :)
[11:33] <ara> sp, rather than something like "newest metacity"
[11:33] <ara> sp, which vary along the way :)
[11:33] <sp> unfortunately, that alone is not enough... filed a bug report against gnome-control-center (LP:559106).
[11:33] <sp> ara: ok, I will update the bug report accordingly
[11:33] <ara> sp, thanks
[11:34] <ara> bug 559106
[11:34] <ubot4`> Launchpad bug 559106 in gnome-control-center (Ubuntu) "Appearance Properties hangs on Keep Settings dialog without compiz(-gnome) installed (affects: 1)" [Undecided,New] https://launchpad.net/bugs/559106
[11:39] <davmor2> ara: added extra info
[11:43] <sp> same here, attached extra info + relevant portions of apt.log
[11:44] <sp> anyways, compiz 1:0.8.4-0ubuntu14 (and 0ubuntu15) seems to have been uploaded/built already, so this should fix itself once that hits the archive
[11:45] <ara> apparently is transitional
[11:45] <ara> compiz needs to be compiled
[11:46] <ara> and it is being compiled now
[11:46] <sp> at least that way we found that bug in Appearance Properties :)
[11:46] <ara> :)
[11:51] <jpds> sp: It's hitting the archive for i386 now.
[11:55] <sp> jpds: ok, great
[11:55] <sp> I'm looking into fixing the bug in Appearance Properties
[11:55] <sp> checking for the existance of /usr/share/doc/compiz and /usr/share/doc/compiz-gnome should be enough, any objections?
[12:07] <jpds> sp: amd64 puslishing now and will be on mirrors with the hour.
[12:08] <sp> again, great... I'm just building gnome-control-center and will test it in a few minutes
[12:09] <sp> oh, I implemented the check as I mentioned before, due to lack of any objections :)
[12:20] <sp> just pushed my bugfix branch, available from lp:~speijnik/gnome-control-center/bug-559106 (also linked it against the bug report and created merge proposal for lp:~ubuntu-desktop/gnome-control-center/ubuntu)
[12:28] <sp> mhhh... now effects are enabled but gnome-appearance-properties still hangs
[13:46] <davmor2> morning fader_ cr3
[13:46] <fader_> davmor2: Hey dude


[12:52] <balor> What do I put in my debian/changelog to build on multiple distributions (saucy, precise, etc...)?  I've tried 'unstable' -- the standard Debian way.
[12:54] <wgrant> balor: It's not possible for a single upload to build on multiple releases. unstable (aka. sid) is a single Debian release.
[12:54] <wgrant> If it really needs to build separately for each series, you'll need a different version number for each (often by appending ~ubuntuYY.MM.1)
[12:54] <wgrant> But in many cases binaries built for an old series will continue to function on a newer one, so you can just copy them.
[12:57] <balor> wgrant, So I should target the oldest distro the binary is known to work on?  How do my users then use my ppa on, say, Raring if I've build for Saucy?
[12:58] <balor> actually, that should be the other way around.  Build for raring (older) using on saucy (newer)
[12:58] <wgrant> balor: You'll see a "Copy packages" link on your PPA's page. Usually you'd copy from older to newer, which will generally work unless there's been an ABI break somewhere.
[12:59] <balor> I don't see "copy package" anywhere.
[12:59]  * balor did follow those instructions before asking here
[13:00] <wgrant> You might need to click "View package details" first.
[13:00] <balor> I have
[13:00] <balor> I'd imagine this is a dumb-user problem.
[13:01] <wgrant> There should be a "Copy packages" link on the right.
[13:01] <wgrant> Which page are you on?
[13:02] <balor> wgrant, I'm on https://launchpad.net/~a-j-delaney/+archive/gubbins-ppa/+packages which is my PPA
[13:02] <wgrant> balor: There's a "Copy packages" link on the right hand side, near the top.
[13:02] <wgrant> Unless you're not logged in.
[13:03] <balor> stupid users!
[13:03] <balor> wgrant, thanks
[22:31] <replaceafill> anyone knows if there's a problem with launchpad bug email and yahoo.com addresses?
[22:32] <replaceafill> i haven't received bug updates i make since last week
[22:36] <cjwatson> Could well be Yahoo's DMARC policy change
[22:36] <cjwatson> e.g. http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html
[22:37] <cjwatson> Perhaps use a provider that doesn't think it's appropriate to break this sort of thing with no meaningful notice to the internet community
[23:36] <replaceafill> cjwatson, ah thanks, i'll try to set up an alternative email then


[03:18] <lamont> rtg: does the -j16 make it go faster?
[08:09] <kraut> amitk: thanks for the info
[08:10] <kraut> did anyone of you verified http://www.linux.it/~md/software/novmsplice.tgz?
[08:10] <kraut> it's an workaround against this vmsplice issue. that's a c-code where you could compile your own kernel-module.
[08:10] <kraut> it should disable vmsplice
[08:20] <kraut> moin
[08:20] <alex_joni> kraut: I thought there's a fix in <IP_ADDRESS> ?
[11:29] <abogani> rtg, amitk: Hi Tim, Hi Amit! Please don't forget to enable ati closed driver (fglrx) in -rt l-r-m. Thanks.
[11:30] <tjaalton> abogani: does it build?
[11:30] <amitk> abogani: why was it disabled?
[11:30] <abogani> tjaalton: When i submit the patch it compile fine.
[11:31] <amitk> abogani: also the meeting is at 1700 UTC, wiki has been corrected...
[11:31] <tjaalton> abogani: ok, cool
[11:33] <abogani> amitk: Thank you! I have corrected the topic in this room.
[11:34] <amitk> great
[11:34] <abogani> tjaalton: Let me re-check build of l-r-m...
[11:35] <abogani> amitk: Could i add a topic for today meeting (as Open Discussion)?
[11:35] <amitk> abogani: go ahead
[11:35] <abogani> amitk: Should i add it to wiki page?
[11:35] <amitk> abogani: yes
[11:36] <abogani> amitk: Ok, Thanks.
[11:39] <abogani> Done
[11:40] <abogani> tjaalton: Compilation test in progress...
[11:43] <tjaalton> there's also a request to enable nvidia/fglrx for -server
[12:05] <abogani> for server?
[12:10] <abogani> server + GUI? shudder...
[12:12] <tjaalton> the server kernel is useful in some situations
[12:12] <tjaalton> in a workstation
[12:14] <tjaalton> bug 153011
[12:15] <ubotu> Launchpad bug 153011 in linux-restricted-modules-2.6.24 "no nvidia-glx or fglrx for server kernels" [Medium,Triaged] https://launchpad.net/bugs/153011
[12:24] <abogani> tjaalton: Compilation test successfully. Patch still good.
[12:26] <abogani> amitk: Could you enable in debian/rules the fglrx driver for l-r-m, please?
[12:27] <amitk> abogani: was your patch already integrated?
[12:27] <abogani> Yes!
[12:28] <amitk> ok, I'll see that it is done
[12:28] <abogani> You can find it at ati/patches/1-rt-compat-symbols.diff in source package.
[12:28] <abogani> Ok, Thanks!
[12:37] <jdahlin_> It seems that hardy kernels takes a lot longer to startup than gutsy ones
[12:37] <jdahlin_> the part 'looking for new hardware', took 1-2 seconds on gutsy but on hardy it's easily 20 seconds
[13:58] <amitk> jdahlin_: is there a bug about this?
[14:02] <jdahlin_> amitk, I tried to search on hardy/linux without finding anything
[14:02] <jdahlin_> what's the right product/source package to search on?
[14:02] <amitk> product=ubuntu, package=linux
[14:03] <amitk> jdahlin_: file a bug please
[14:03] <amitk> tjaalton: have you verified that fglrx and nvidia compiles for server flavour?
[14:04] <tjaalton> amitk: no I haven't
[14:05] <amitk> tjaalton: rtg says it wouldn't compile due to some dependencies. He'll take a stab at it today
[14:05] <tjaalton> amitk: oh cool
[15:42] <Kano> hi rtg , are you interested in a webcam driver patch for lum?
[15:43] <rtg> Kano: email it to the kernel team mailling list.
[15:46] <alejalej> hello kernel people
[15:46] <alejalej> am running Hardy
[15:47] <alejalej> very happy with the kernel change
[15:47] <Kano> http://kanotix.com/files/kernel/kernel-update-pack-generic/source/lum-stk11xx.patch
[15:47] <alejalej> no need to noapic no more, etc
[15:47] <Kano> if you like to look
[15:47] <alejalej> but I have some problems with suspend/hibernate... and specially resume
[15:47] <alejalej> do I need to file a bug first=
[15:47] <alejalej> or could you guys point me to some interesting alternative....
[15:51] <alejalej> did someone flood me out?
[16:26] <Kano> rtg: for amd64: error in debian control line 78: duplicate Conflicts
[16:27] <Kano> when compiling generic
[16:27] <rtg> Kano: hmm, I saw that on my PPA build this morning, but haven't been able to get back to it.
[16:28] <Kano> for the linux-libc-dev
[16:29] <rtg> I wonder why that just started showing up.
[16:29] <Kano> well i tried to compile it on amd64 siiiiiiiiiiiiiiiiid
[16:38] <rtg> looks like dpkg was upgraded and caught a long standing syntax error.
[16:40] <amitk> rtg: did unifying 75 and 78 fix it?
[16:40] <rtg> amitk: don't know yet. it takes a bit.
[16:48] <Kano> ubuntu/media/stk11xx/stk11xx.ko
[16:49] <Kano> at least my patches compiles the module ;)
[16:50] <amitk> Kano: you have to send an email to<EMAIL_ADDRESS>explaining _what_ the patch does.
[16:52] <Kano> it adds just this
[16:52] <Kano> svn co http://syntekdriver.svn.sourceforge.net/svnroot/syntekdriver/trunk/driver stk11xx
[16:54] <rtg> Kano: the purpose of the email list is 1) wider distribution for comments, and 2) time elasticity. Not everyone has the time to camp on IRC to find out what is going on.
[16:55] <Kano> well you are online and you have acess to git ;)
[16:56] <Kano> it is a very easy module, em8300 i still have to do...
[16:57] <Kano> or you if you like ;)
[17:03] <amitk> BenC just postponed the IRC meeting by 15mins...
[17:12] <rtg> ogasawara: when you regen your hardy-buglist page, could you put a date in the title?
[17:12] <ogasawara> rtg: sure, np
[17:13] <rtg> 'tanks
[17:14] <king_> ogasawara: how often is it updated? Is it a manual update?
[17:14] <ogasawara> king_:  updated every hour via cron job on rookery
[17:15] <BenC> I see everyone else is alive
[17:15] <BenC> smb: ping
[17:15] <ogasawara> king_: and the list is maintained in a bzr tree which gets pulled on rookery
[17:15] <smb> Ben: yup
[17:15] <BenC> good deal
[17:16] <BenC> Ok, The weekly Kernel Team meeting is now in session...agenda, as usual, is at: https://wiki.ubuntu.com/KernelTeam/Meeting
[17:17] <BenC> Let's run down the team, see what's going on
[17:17] <BenC> amitk: You're up first, how's things?
[17:17] <amitk> doing ok
[17:18] <amitk> A bunch of mobile updates for graphics drivers, dma, etc. coming up next week
[17:18] <BenC> amitk: going into hardy kernel?
[17:18] <amitk> I won't have a lot of time to do bug fixing this week
[17:19] <amitk> BenC: yes
[17:19] <BenC> Ok
[17:19] <BenC> amitk: This is all for lpia, I assume
[17:20] <amitk> yes. Everything going in is restricted to LPIA
[17:20] <amitk> it won't affect other flavours
[17:20] <BenC> good, so no need to worry much about code freezes for the rest of the dist
[17:20] <maks_> BenC: can i please remind you on an initramfs-tools sync
[17:21] <BenC> maks_: best thing is to email me, if you could please
[17:21] <BenC> my inbox acts as a todo list :)
[17:21] <rtg> also copy kernel-team mailing list.
[17:21] <maks_> which email BenC ?
[17:21] <BenC><EMAIL_ADDRESS><EMAIL_ADDRESS>[17:21] <maks_> cool
[17:22] <BenC> amitk: Thanks
[17:22] <BenC> rtg: How's the kernel looking right now for next milestone?
[17:22] <rtg> amitk is packaging the -8 ABI, which is based on <IP_ADDRESS>
[17:22] <rtg> there are a couple pof critical crashes that I need to look at as soon as its uploaded.
[17:23] <rtg> would also like to review some of the wireless issues.
[17:23] <rtg> otherwise, I think its looking OK
[17:23] <amitk> -8 will include the fixes for the vmsplice CVEs
[17:23] <rtg> yep
[17:24] <BenC> This will be the Alpha 5 kernel, right?
[17:24] <rtg> oh, and there are some possible IDE issues.
[17:24] <BenC> what happened there?
[17:24] <rtg> yes - it should be the A5 kernel.
[17:24] <rtg> Ng complained that his laptop wnet fropm sda back to hda.
[17:25] <BenC> you mean issues like regressions caused by the -8 kernel, or things that were already there?
[17:25] <rtg> someting in the -7 kernel.
[17:25] <BenC> Did someone dork around with the via IDE/PATA driver?
[17:25] <rtg> there is one commit that enables more IDE devices. perhaps that one?
[17:25] <BenC> yeah, sounds like it
[17:25] <rtg> I'll get you to reveiew it with me later.
[17:25] <BenC> we don't want to enable IDE drivers where we already have a libata-pata one
[17:26] <rtg> you are the expert there.
[17:26] <amitk> BenC: can initramfs enforce an order in which modules are tried?
[17:26] <BenC> Need to watch out when we mess with that sort of config change...could really screw up someone's system
[17:26] <amitk> ata_piix before ide_disk, for example?
[17:26] <BenC> amitk: only by blacklisting
[17:27] <amitk> BenC: unfortunate
[17:28]  * BenC pimps the udev device/driver binding paradigm, and moves on
[17:29] <BenC> rtg: Ok, thanks
[17:29] <BenC> smb: how's things coming along for you?
[17:30] <smb> So far, I work on several bugs. Most of them currently require more input or looking into them
[17:30] <smb> Did the tp_smapi addittion to lum last week
[17:31] <BenC> smb: Since you are a few weeks into things now, how are you finding the work flow and documentation?
[17:31] <smb> Generally, there are a few bugs in the crried forward section that have fixes either only in the -mm tree or not ready yet. Is it ok to leave them triaged there or can we park them
[17:32] <smb> Well, as most of us, I find Leann's buglist most usefult.
[17:32] <BenC> smb: if there's no chance of us fixing them, then marking them WontFix is proper
[17:32] <BenC> smb: it will get it out of limbo so we can move on to more important things
[17:33] <ogasawara> smb:  if you want to keep an eye on them, feel free to reassign to canonical-qa and I'll track them
[17:33] <rtg> smb: if there isn't an upstream fix by now, then its unlikely to happen in timew.
[17:34] <smb> ogasawara: Yes, I guess we did that for one and I keep an eye on the upstream report
[17:34] <BenC> The only time that isn't the case is where it's a critical bug/regression that we should put some effort into
[17:34] <rtg> like an oops.
[17:35] <BenC> well, and oops that isn't in something like netatalk :)
[17:35] <rtg> right. an oops in something interesting.
[17:35] <BenC> smb: Alright, thanks
[17:36] <BenC> king_: And fresh from your first week with us, how are things coming along?
[17:37] <king_> Ok thanks - I believe I'm up to speed .. with help I've got some code now into the repository!
[17:37] <king_> I've been looking at several bugs...
[17:37] <king_> Some look a bit more open ended than others.
[17:38] <king_> I've put a patch in for the macbook 3.1 track pad
[17:38] <king_> And I've been trying to understand why  the /proc/acpi/alarm is missing for the x86_64
[17:39] <BenC> That reminds me, we should probably revert back to sending patches to kernel-team for double-ack before commit like we used to
[17:39] <king_> I need to know how to this then.
[17:40] <BenC> This predates both you and smb, so I'll give it a quick once over
[17:40] <king_> Ok.
[17:40] <maks_> baah kernel-team is a subscriber list
[17:40] <smb> ok
[17:40] <king_> ok.
[17:40] <BenC> Any patches that we commit (this pertains mostly to the kernel), would be sent to<EMAIL_ADDRESS>[17:41] <BenC> before they are committed
[17:41] <BenC> at least two people on the team have to ACK the patch before it can be committed...assuming a kernel team person submits the patch, that means one ACK from a team member
[17:41] <smb> or pushed. we could commit locally to get a git-format-patch version
[17:42] <king_> This would be a good way of catching any dubious commits by newbies :-)
[17:42] <BenC> yeah, it's all about checks and balances :)
[17:43] <rtg> except its not a democracy.
[17:43]  * BenC puts on the iron fist
[17:43] <BenC> seriously, I'm more inclined to just put in my 2 cents where needed and let you guys make the final decision
[17:44] <king_> I'd appreciate it.. if it does not slow down workflow..
[17:44] <BenC> it seemed to work well before, but we stopped doing it since we only had 3 of us on the team, which did slow things down
[17:45] <BenC> with 5 of us, the ACK turn around should be quick, especially if you ping everyone when it's important
[17:45] <rtg> I try to stay on top of kernel-team submissions.
[17:46] <BenC> king_: ok, thanks
[17:46] <BenC> Moving on to QA bug list
[17:46] <BenC> I haven't had a chance to look at it today...is there anything serious going on there?
[17:47] <rtg> Bug #189224 is interesting
[17:47] <ubotu> Launchpad bug 189224 in linux "sunrpc causes kernel oopses on 2.6.24-5-generic" [High,Triaged] https://launchpad.net/bugs/189224
[17:47] <BenC> The carried forward section is still growing
[17:47] <smb> Which might be  cpuidle
[17:47] <ogasawara> also mathiaz reported Bug #185303
[17:47] <ubotu> Launchpad bug 185303 in linux "Kernel Oops - unable to handle kernel paging request - Hardy server i386 alpha3/alpha4 install on HP Proliant ML350 fails" [High,Triaged] https://launchpad.net/bugs/185303
[17:47] <BenC> And there's still a lot unassigned bugs
[17:48] <Kano> rtg: btw. sent a mail...
[17:49] <smb> For example https://bugs.launchpad.net/ubuntu/+bug/152187 is something  that is assigned to qa and the fix wont happen too soon
[17:49] <ubotu> Launchpad bug 152187 in linux "Serial Wacom tablet fails to return from ACPI suspend to RAM" [Unknown,In progress]
[17:49] <rtg> I should have a bit more time to work on bugs. The CVE flurry seems to have settled.
[17:50] <ogasawara> smb: I can move the qa assigned bugs off the list and track them separately
[17:50] <BenC> 189224 looks pretty damn serious
[17:50] <rtg> Benyup
[17:51] <smb> ogasawara: I think that would be good. Since this issue has to wait for the upstream fix
[17:51] <rtg> BenC: yup, even.
[17:51] <BenC> rtg: 185303 appears very similar to a vendor issue we had
[17:52] <rtg> its got some interesting wrinkles. amd64 works, i386 doesn't
[17:52] <BenC> bios related
[17:52] <BenC> although that one was fixed by a bios update...so maybe we need to track the actual problem
[17:52] <BenC> it's a regression either way
[17:53] <rtg> I think Mathiaz has checked for BIOS updates. I'll confirm.
[17:53] <rtg> He showed me this one at sprint.
[17:53] <BenC> Let's make a point to get this carried over list knocked out some how
[17:54] <BenC> those two bugs mentioned should get some priority (especially the cpuidle one)
[17:54] <smb> Ok, I try to dig further there
[17:54] <rtg> smb: get him a <IP_ADDRESS> based kernel.
[17:55] <BenC> the pci bios seems like it should be easy to debug
[17:55] <rtg> except for the fact that it chunders inside the BIOS.
[17:55] <smb> rtg: right. I read something related that vanished later
[17:58] <BenC> Alright...
[17:58] <BenC> abogani: ping
[17:58] <abogani> BenC: pong
[17:58] <abogani> Ok the thing is off-topic in this moment but I prefer clarify this point in time for next release.
[17:58] <abogani> Is it possibility to ship -rt kernel flavour in main in hardy+1?
[17:58] <abogani> There isn't CVE or Secunia advisory. It have the same local exploit of the -generic one.
[17:58] <abogani> Obviously i don't want merge -rt code into main git tree but is sufficient maintain it to a separate patchset (as usual) and release it through main repos.
[17:59] <abogani> Noteworthy is that 2.6.25 will merge other fundamental pieces from -rt patchset via Molnar's git tree (http://kerneltrap.org/node/15345).
[17:59] <abogani> Thus why we can't raise -rt to main? what i can do to achieve this goal (for hardy+1)?
[17:59] <BenC> abogani: this is something we'll need to discuss in detail at UDS
[18:00] <BenC> abogani: are you on the sponsored list?
[18:01] <abogani> Mhhh sponsored list? I don't know nothing about it... Thus I suppose no.
[18:01] <BenC> abogani: email me some notes and I'll see if we can work some way for you to be at either FOSSCamp or UDS to plead your case in person :)
[18:01] <abogani> BenC: Ok. Thanks a lot.
[18:01] <BenC> at the very least, creating a blueprint on launchpad targetted for hardy+1 is a great start
[18:02] <abogani> specifically for main inclusion?
[18:02] <BenC> yeah
[18:02] <abogani> Ok.
[18:03] <BenC> Ok, that ends the actual agenda
[18:03] <BenC> Any open items for discussion?
[18:04] <BenC> I'll take that as a no, and call the meeting to a close
[18:04] <BenC> Thanks every one!
[18:08] <tjaalton> well, there are some DRM changes in 2.6.25-rc1 that would be nice to have, like ba8bbcf6ff4650712f64c0ef61139c73898e2165
[18:08] <tjaalton> it might fix bug 189260
[18:08] <ubotu> Launchpad bug 189260 in xserver-xorg-video-intel "Backlight doesn't turn on after resume" [Medium,Confirmed] https://launchpad.net/bugs/189260
[18:08] <tjaalton> at least upstream thinks so :)
[18:23] <tjaalton> amitk: if you are doing l-r-m as well, let me know before you upload.. I'll toss you with a diff to fix bug 190347
[18:23] <ubotu> Launchpad bug 190347 in linux-restricted-modules-2.6.24 "Bad entry in menu" [Low,In progress] https://launchpad.net/bugs/190347
[18:26] <rtg> tjaalton: email it to kernel-team. I'll probably be doing the upload later today.
[18:26] <tjaalton> rtg: oh today already.. ok
[18:27] <rtg> tjaalton: actually, lrm probably won't get uploaded until tomorrow given the ABI bump.
[18:28] <tjaalton> rtg: cool, more time for me ;)
[18:29] <tseliot> tjaalton: maybe your diff can include my patch as well ;)
[18:29] <tseliot> shameless plug
[18:30] <tseliot> :-P
[18:30] <tjaalton> tseliot: hehe
[18:30] <tjaalton> actually, I'm having second thoughts about including the desktop file for nvidia-settings, since it's not a tool for a casual user, and could do more damage than good
[18:33] <tjaalton> or at least don't show it by default
[20:33] <Kano> hi, ist ubuntu.com down?
[20:36] <Kano> hmm now it seems to work again
[20:37] <Kano> rtg: did you see the mail in the ml?
[20:37] <rtg> yes
[20:37] <Kano> and where is your commit
[20:37] <rtg> busy
[20:38] <Kano> when there is a more complicated makefile with serveal flags, how to convert these?
[21:45] <Kano> rtg: do you test the kernel on amd64?
[22:38] <Kano> rtg: do you know that standard debian kernels have FB_VESA=y and FRAMEBUFFER_CONSOLE=y?
[22:40] <mjg59> Kano: That doesn't make it a sensible thing to do
[22:40] <Kano> sure without i dont get a framebuffer on amd64
[22:41] <Kano> never with a ubuntu live cd
[22:41] <mjg59> Sure you do
[22:41] <mjg59> But you'll never get one by default
[22:41] <Kano> dont know whats differnet with i386, but that problem is mainly amd64 there
[22:43] <Kano> also usplash only works with 32 bit
[22:44] <mjg59> usplash works fine with most 64 bit hardware
[22:44] <Kano> well my destiny is to have the none working examples
[22:44] <mjg59> I'm working on it, but it's not a kernel issue
[22:46] <Kano> do you own a system where it does not work
[22:46] <mjg59> No, but I know what needs to be done before it can be fixed
[22:47] <Kano> so what
[22:47] <mjg59> ?
[22:47] <Kano> tell me what you think the problem is
[22:47] <mjg59> The x86 emulation is bugged in some way
[22:48] <Kano> in usplash?
[22:49] <mjg59> Yes
[22:49] <mjg59> Well, in libx86
[22:49] <Kano> interesting that it works on some systems...
[22:50] <mjg59> Depends on the video BIOS
[22:51] <Kano> usually static vesafb is working everywhere...
[22:52] <mjg59> We can't use vesafb by default
[22:52] <Kano> vga=0 would disable it
[22:53] <mjg59> The default would have to be disabled
[22:53] <Kano> at least enabling is then easy
[22:54] <mjg59> It will already be handled properly
[22:54] <Kano> i really doubt that
[22:55] <tjaalton> mjg59: the buglist for xserver-xorg-video-nv has many potential testers for you ;)
[22:56] <mjg59> Kano: Check /usr/share/initramfs-tools/scripts/init-top/framebuffer
[22:56] <mjg59> tjaalton: Why on earth are they filed against the X driver?
[22:58] <Kano> mjg59: why dont you make fbcon static, it is modprobed anyway?
[22:58] <mjg59> Kano: So it's not loaded if the user doesn't ask for it
[22:59] <Kano> also the splash check is suboptimal
[22:59] <mjg59> ?
[23:00] <tjaalton> mjg59: lack of better knowledge perhaps
[23:00] <Kano> when you use splashy you have a splash option,but you need vesafb
[23:00] <Kano>         splash*)
[23:00] <Kano>                 FB="vga16fb";
[23:00] <mjg59> Which version are you looking at?
[23:00] <mjg59> That's not in the current code
[23:00] <Kano> etch
[23:00] <mjg59> Well, blame Debian
[23:01] <Kano> well will fetch u initramfs
[23:03] <Kano> the modprobe does not work
[23:04] <Kano> on my system
[23:04] <Kano> definitely not
[23:04] <mjg59> Working out why would be helpful
[23:04] <mjg59> Since it works here
[23:04] <Kano> well i can not send you my gfx card
[23:04] <mjg59> If the modprobe is failing, the graphics card is irrelevant
[23:06] <Kano> well sid + ubuntu are similar in that file btw
[23:06]  * mjg59 shrugs
[23:07] <Kano> just that u does not check for while read fbno desc; do if [ $(($fbno < 32)) ]; then before mknod /dev/fb${fbno} c 29 ${fbno}
[23:08] <Kano> and u uses -Qb
[23:08] <Kano> option to modprobe
[23:12] <Kano> interestingly i can use onboard vga too and get the same problem...
[23:13] <Kano> http://www.gigabyte.co.nz/Products/Motherboard/Products_Overview.aspx?ProductID=2535
[23:13] <Kano> this board
[23:57] <Kano> mjg59: the thing is: after boot vesafb is never loaded, only fbcon