 Given that there are only ~430 people in the Kubuntu forums and if  contrasted against the 1000's of Kubuntu downloads, I would say skip IRC. As for torrents (and IRC's), anyone savvy enough to employ such tool are typically savvy enough to install either as needed.
 Sorry, wrong thread...
[08:06] <Mcklaren> hi
[10:47] <Alabalistic> well well well. Big thanks to all Devs and contributers to kde, The best desktop ever.
[12:30] <BluesKaj> Hi all
[12:43] <BluesKaj> !anti-virus
[12:44] <BluesKaj> !antivirus
[13:12] <jabberwock> Curious if Linux has a firewall GUI like that (something "spy") macos program. I've never been curious until now
[13:16] <BluesKaj> jabberwock, no GUI that I know of, but there are cli based apps like clamav
[13:17] <jabberwock> Little Snitch!
[13:18] <jabberwock> Not spy
[13:18] <jabberwock> BluesKaj: Seems totally possible though, using one of those dialog GUI frontends
[13:18] <jabberwock> a project to add to the never-ending queue lol
[13:19] <BluesKaj> there isn't a lot of call for a GUI IME
[13:19] <jabberwock> TIL: Enabling USB power sharing in the BIOS seems to cause random system freezes
[13:20] <jabberwock> BluesKaj: Makes sense. Most linux folks seem more adept with such things
[13:21] <BluesKaj> most linux users learn to use the cli to some degree
[13:29] <jabberwock> BluesKaj: TBH I wouldn't mind something like LittleSnitch within environments like KDE - where things are reaching out constantly. Also to help me note which apps contact which endpoints
[13:30] <jabberwock> At the end of the day I just ran the whole thing through burpsuite. That's what helped me pin down Korganizer not sending auth headers for icloud sync
[13:31] <BluesKaj> jabberwock, try sudo netstat -tapen
[13:32] <BluesKaj> for endpoints
[13:35] <jabberwock> lol: https://www.linuxquestions.org/questions/linux-newbie-8/column-width-for-netstat-top-etc-260211/
[13:35] <jabberwock> some day we're going to have to give all of these tools like netstat, htop, etc. json output
[17:41] <jabberwock> I can DoS myself by entering nfs://<IP_ADDRESS> as a network stream in VLC.  Quick question - is it the same with kubuntu as with ubuntu - when the first point release of 22.04 comes out, i will be prompted to upgrade to it from 20.04?
[19:12] <kdeguy> anyone?
[20:01] <mparillo> Yes, AIUI, LTS to LTS upgrades are only triggered after the .1 is out.
[20:02] <valorie> not always immediately tho
[20:03] <valorie> at least once they stopped a few days to fix a severe .1 bug
[20:10] <gatekeeper137> Hy everyone (sorry for my english)
[20:10] <gatekeeper137> In my version LibreOffice <IP_ADDRESS>, in print dialog there is no tab "Page layout", what is the issue?


[20:57] <Fantu> hi, there is a strange thing in launchpad, the latest package build successfull in my launchpad seems still not published: https://launchpad.net/~fantonifabio/+archive/ubuntu/ubuntu-fixes/+packages
[21:41] <Fantu> problem is now solved, thanks
[21:55] <wgrant> Fantu: One of our servers had a hardware fault a few hours ago, sorry about that.
[21:56] <Fantu> np, thanks for reply
[21:58] <teward> wgrant: how long do package publications happen in the PPAs again?
[22:05] <wgrant> teward: It's still catching up, but I don't imagine it will be more than another hour.
[22:06] <teward> wgrant: ok.  i was hoping it wasn't a breakage in the system that resulted in ANOTHER hardware fail, but meh


[00:24] <Bashing-om> WIKI575 up for acceptance - is this what we present to the world ?
[00:52] <krytarik> Bashing-om: Ugh, there are weird space characters (some of them follow a normal one, making it double) in front of "GNOME 3.32", "year naming", "Sean finishes", and "links for download"  Also, while looking for those, I've spotted "naming some of the those who helped" - where "the" should be dropped.
[00:55] <Bashing-om> krytarik: Called myself checking for those spaces :( Glad you caight them .. will correct.
[00:55] <krytarik> And "FLISOL  · sede Los Polvorines" in the LoCo events list got an actual normal double space, and we could fix that too - but I figured they've just written it like that on the event itself.
[01:01] <krytarik> guiverc: Have you got a non-breaking space in your keyboard layout by chance? >_>
[01:03] <guiverc> krytarik, don't know what one is (US keyboards only), but I do find the mouse does strange things on occasion for me which seem to weird things (strange chars on occasion; or the page does strange things..)
[01:11] <krytarik> "This release is widely covered, - new features and fixes are preeminent - the following is a collection of articles selected by our editors" - oh, and while I've noticed this departure from the usual wording last time when I looked at the Google Doc, I'd have to look up what "preeminent" means in this context, but at least I think we should fix the funky punctuation there, maybe by just ...
[01:11] <krytarik> ... puttting it in commas instead.
[01:12] <krytarik> And didn't it use to say "was widely covered" rather than "is", either?
[01:15] <Bashing-om> krytarik: "was widely covered" - yes .. but our directive is to use present tense this I did change.
[01:17] <krytarik> Also, I didn't mention yet, but I saw that my recommendation on the section to only link third-party posts and not also those of the various flavors, has been ignored - but I'm fine with that as long as everybody agrees that it's ok to stuff up the list a little like that.
[01:19] <krytarik> Bashing-om: Well, that might be correct for summaries, but I think the usual delay between the articles being posted and the UWN issue covering them, warrants the use of past tense there.
[01:21] <Bashing-om> krytarik: You th man :) .. will change to was .
[01:27] <krytarik> Bashing-om: Oh, and please cut the 19.04 Updates to just those after it was released.
[01:28] <Bashing-om> krytarik: Ouch .. did not notice that :( will cut.
[01:32] <krytarik> Bashing-om: That'd start with the two 'distro-info-data' entries quite at the end of the list then.  Makes sense enough! >_>
[01:38] <Bashing-om> krytarik: Looking .. in the meantime I now get "Unknown user" at https://lists.canonical.com/archives/<release>-changes . What gives now ?
[01:39] <krytarik> Maybe because that's canonical.com instead?
[01:44] <Bashing-om> krytarik: Could be :) .. naybe mousepad had gone wild on me ,, I play with the URL and see what I can come up with. thanks !
[01:47] <krytarik> Bashing-om: I just clicked the provided links on the list btw. >_<
[01:48] <Bashing-om> krytarik: I did not know the double distro-info-data as a delimeter.
[01:48] <krytarik> Me neither until then.
[01:50] <krytarik> That is, I just clicked the links on various items in the list to narrow it down.
[02:07] <guiverc> no issues with read thru of https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue575
[02:14] <Bashing-om> guiverc: :) 2 down one to go .. Wild_Man ? have you looked ?
[02:36] <Wild_Man> Bashing-om, have you already made the changes mentioned above/
[02:36] <Wild_Man> ?
[02:39] <Bashing-om> Wild_Man: So far as I know we are up to date with all suggested changes.
[02:39] <Wild_Man> Bashing-om, Looking now
[02:50] <Wild_Man> Bashing-om, looks good to me
[02:50] <Bashing-om> Wild_Man: Great - What is is what will be :P
[06:47] -SwissBot:#ubuntu-news- ::Planet:: Jono Bacon: Open Source Won’t Save A Subpar Product @ https://www.jonobacon.com/2019/04/21/open-source-wont-save-a-subpar-product/
[12:35] -SwissBot:#ubuntu-news- ::Planet:: Kubuntu General News: Trusty 14.04 LTS end of life, and end of Kubuntu support for Xenial 16.04 LTS @ https://kubuntu.org/news/trusty-14-04-lts-end-of-life-and-end-of-kubuntu-support-for-xenial-16-04-lts/
[14:02] -SwissBot:#ubuntu-news- ::Softpedia:: Ubuntu MATE 19.04 Brings Improved Out of Box Nvidia GPU Experience for Gamers @ https://news.softpedia.com/news/ubuntu-mate-19-04-brings-improved-out-of-box-nvidia-gpu-experience-for-gamers-525751.shtml (by Marius Nestor)
[15:25] -SwissBot:#ubuntu-news- ::Softpedia:: Xubuntu 19.04 Drops Support for 32-Bit Systems, Ships with Xfce 4.13.3 Desktop @ https://news.softpedia.com/news/xubuntu-19-04-drops-support-for-32-bit-images-ships-with-xfce-4-13-3-desktop-525752.shtml (by Marius Nestor)
[16:06] -SwissBot:#ubuntu-news- ::OMG!Ubuntu:: Ataris VCS Delayed Until December, Like Anyone Even Cares At This Point… @ https://www.omgubuntu.co.uk/?p=141251 (by Joey Sneddon)
[17:59] -SwissBot:#ubuntu-news- ::Planet:: Erich Eickmeyer: Gearing Up for Linux Fest Northwest 2019! @ https://ericheickmeyer.com/2019/04/22/gearing-up-for-linux-fest-northwest-2019/
[19:41] -SwissBot:#ubuntu-news- ::Softpedia:: Ubuntu Kylin 19.04 Adds a New Visual Experience, Latest WPS Office Suite @ https://news.softpedia.com/news/ubuntu-kylin-19-04-adds-a-new-visual-experience-latest-wps-office-suite-525754.shtml (by Marius Nestor)
[20:01] <Bashing-om> M/L is away ,,, doing the forum post next.
[20:25] <Bashing-om> Wild_Man: Eyes on ? Got an issue posting to the forum :(
[20:54] -SwissBot:#ubuntu-news- ::Softpedia:: Kubuntu 19.04 Ships with KDE Plasma 5.15 Desktop, Experimental Wayland Session @ https://news.softpedia.com/news/kubuntu-19-04-ships-with-kde-plasma-5-15-desktop-experimental-wayland-session-525755.shtml (by Marius Nestor)
[21:01] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Studio: Ubuntu Studio at Linux Fest Northwest 2019 @ https://ubuntustudio.org/2019/04/ubuntu-studio-at-linux-fest-northwest-2019/
[21:10] <Wild_Man> Bashing-om, I will try to post to the forum
[21:25] <Wild_Man> Bashing-om, It is not working right for me either it is messing up the 18.10 updates and curtailing the rest as you said
[21:26] <Wild_Man> I think I will try to post a new one myself and see what happens
[21:33] <Wild_Man> Bashing-om, I suspect it is just to long and we may have to split it into to posts, I do not know of that having to be done before but I think that is the case, I ask for admin input
[21:34] <Bashing-om> Wild_Man: My thought is to make a comment and reduce the content.
[21:35] <Wild_Man> We may have to, I am waiting for an admin to respond
[21:35] <Wild_Man> Bashing-om, when I posted the 18.10 updates the formatting is messed up as well
[21:35] <Wild_Man> I just copied and pasted so it should be correct
[21:37] <Bashing-om> Wild_Man: yup - we run out of buffer .. and the final [/LIST] is cut off .. all I know to do is cut the contents down to size.
[21:38] <Wild_Man> Bashing-om, I think that is what we will have to do, what are you thinking add a comment to see the updates for 18.10 go to the wiki page?
[21:40] <Bashing-om> Wild_Man: cut in between the 18.04 and 18.10 updates " ----cut to reduce content -----" . Say the first and last 10 items in each left ?
[21:42] <Wild_Man> Bashing-om, however you want to do it is okay with me, krytarik thoughts?
[21:43] <krytarik> Well, you guys have managed to do it before, wonder what's different now?
[21:45] <krytarik> If you can't make it work this time though, then of course I'd also be fine with cutting the section in some way and linking to the wiki instead.
[21:45] <Wild_Man> I believe it is a different issue, I think there is a character limit for a post and I believe we reached it, the other issue is about security and I got around it by leaving some out then editing to add it later
[21:45] <krytarik> Ah, ok.
[21:47] <Wild_Man> krytarik, where do you think we should cut it off at the 18.10 updates the put a comment to see the wiki for a complete lit of updates
[21:48] <Wild_Man> list
[21:49] <krytarik> Could also cut on the releases that are the least relevant by now if it reduces the size enough - thinking of 14.04 and 16.04
[21:49] <Wild_Man> krytarik, other then linking to the wiki, only other thing we can do is split the letter into two posts, I have seen tutorials split into several posts and I believe this is the reason
[21:51] <Wild_Man> guiverc, I can do the fridge today if you want me too
[21:52] <krytarik> Well, as I've mentioned the last time this issue came up, I don't think the update lists are so interesting to most anyway - so I'd rather cut than split if necessary.
[21:52] <Wild_Man> That is my thought too, I think it would look bad split
[21:53] <krytarik> Just make sure to link properly.
[21:54] <Wild_Man> Bashing-om, just go ahead and cut out the 18.10 updates and add a link to the wiki that goes directly to the updates
[21:54] <Wild_Man> I will start on the fridge
[22:16] <Wild_Man> guiverc, ready for 2nd
[22:16] <Wild_Man> krytarik, I would be okay with the forum publishing to be like the fridge
[22:20] <krytarik> Yeah, we've talked about this option the last time too, but I think we figured the forums is different because the UWN has its own section there and so is another place where (usually) the full issue can be read.
[22:21] <Wild_Man> Maybe but I know even with the full issue being on the forum I still always go to the wiki I like it better not sure that is true of everyone
[22:22] <Wild_Man> krytarik, do you want to be my 2nd?
[22:22] <guiverc> Wild_Man, looks great - 2nd
[22:23] <Wild_Man> Thanks guiverc, you want me to do social media too?
[22:23] <guiverc> yes please..
[22:24] <Wild_Man> Here it is http://fridge.ubuntu.com/2019/04/22/ubuntu-weekly-newsletter-issue-575/
[22:24] <Wild_Man> Okay
[22:28] <Wild_Man> Done
[22:34] <Wild_Man> Bashing-om, you want me to fix the links where they are clickable?
[22:35] <guiverc> thanks Wild_Man :)
[22:35] <guiverc> thanks for all your effort Bashing-om
[22:36] <Wild_Man> Your welcome guiverc
[22:41] <Bashing-om> Wild_Man: Yeah ,., my thinking is not doing too well ! for makeing up a proper link.
[22:42] <Bashing-om> guiverc: Only thanks to you we get this done :P
[22:42] <guiverc> :)
[22:46] -SwissBot:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 575 @ http://fridge.ubuntu.com/2019/04/22/ubuntu-weekly-newsletter-issue-575/
[22:49] <Wild_Man> Bashing-om, you can click edit in the post and see the format now that I have changed it
[22:50] <Bashing-om> Wild_Man: Doing the looking :)
[22:50] <Wild_Man> krytarik, when you say to make the link correctly you meant it should go to the updates section right? I do not know how to make it do that
[22:50] <Wild_Man> I guess I would just add update 18.10 to the link?
[22:51] <krytarik> Wild_Man: Just copy the respective link from the sidebar on the wiki page.
[22:52] <Wild_Man> krytarik, Thanks
[22:53] <krytarik> And I'd introduce the link with a proper wording, and then just put the bare link after a colon.
[22:56] <Wild_Man> The links work correctly,  Bashing-om you want to reword it?
[22:58] <Bashing-om> Wild_Man: krytarik :: Like " dies to excessove content these are abridged, The complete lest is here: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue575#Ubuntu_18.04_Updates " ??
[22:58] <Bashing-om> due*
[22:59] <Wild_Man> Something like that is okay with me
[23:00] <Wild_Man> I have to fix my wife something to eat now
[23:08] <Bashing-om> re-directs are done also :)
[23:19] <Wild_Man> Thanks Bashing-om
[23:30] <Bashing-om> Wild_Man: guiverc :: Clear to wipe Gdoc ? and we start UWN576 ?
[23:30] <Wild_Man> Yes Bashing-om
[23:31] <guiverc> concur.
[23:31] <Bashing-om> wipeing :)


[09:56] <doko_> infinity, cjwatson, jibel: please help python2.7 into trusty. the failing ntdb package is new, and the test wrong :-/
[10:04] <jibel> doko_, results forced.
[10:19] <doko_> thanks, filed an issue in debian
[14:36] <knome> anybody who can approve blueprints for trusty around? i don't want to flood the channel with details (again), so please ping me
[21:13] <xnox> knome: send an email to ubuntu-release mailing list, and appropriate people with powers will do that.
[21:15] <knome> xnox, cheers, will do that
[22:52] <xnox> infinity: please demote udisks src+bins to universe
[22:54] <knome> xnox, mail sent. :)


[00:53] <maxb> Hi, where do I register a vote for PLEASE PLEASE PUT THE WINDOW BUTTONS BACK! :-)  (Assuming this is where the change originated?)
[01:01] <DanRabbit1> maxb: the change originated from very high up and I'm afraid this is no amount of voting that can sway the decision
[01:02] <maxb> *sigh*
[01:04] <maxb> Having major UI decisions forcibly thrust upon you is becoming a distressing trend in Ubuntu
[01:05] <DanRabbit1> maxb: You should try out it first. You might actually like it. I've had my buttons on the left for a couple years now and I would never go back :)
[01:07] <maxb> I don't see the point in trying to retrain my brain on something that isn't even a change in functionality, just moving it around
[01:09] <DanRabbit1> eh, in your opinion
[01:10] <DanRabbit1> Psychologically, the left side of the screen is supposed to be more of a "comfort zone"
[01:10] <maxb> !
[01:10] <maxb> o...... kay
[01:11] <DanRabbit1> Also, this means that window controls will never be under Notify-OSD bubbles
[01:11] <DanRabbit1> well, I shouldn't say never.
[01:11] <DanRabbit1> but less likely
[01:11] <maxb> Yes. well. I use notification-daemon :-/
[01:11] <DanRabbit1> hehe, well then you are obviously capable of modifying your system ;)
[01:12] <DanRabbit1> it sounds harsh, but if you don't like it, there's tons of distros out there. That is what choosing a distro is about. Finding one that fits you the best.
[01:12] <maxb> Anyway, is there a mailing list where this sort of change gets announced? (specifically, announced, rather than high-volume UI discussion)
[01:13] <DanRabbit1> I don't believe this was discussed with the community if that's what you are asking
[01:13] <DanRabbit1> it was something that just happened one day internally
[01:13] <maxb> Well, even if it wasn't discussed, it would have been nice for it to have been announced as it happened
[01:14] <DanRabbit1> maxb: Jono is the perfect person to ask about it ;)
[01:15] <jono> maxb, just switch them back
[01:15] <jono> it is a gconf key
[01:16] <maxb> jono: Is there a mailing list where radical UI designs issuing forth from Canonical get announced, such that people running the development release can get some warning and background on the change, rather than just being surprised by an update one day?
[01:16] <jono> maxb, every ubuntu release has surprises
[01:16] <jono> but the ayatana list is the best place to ask
[01:18] <maxb> Doesn't it make more sense to publish a brief statement why something's being done, rather than having people come asking?
[01:19] <DanRabbit1> hehe, I think they would have to hire someone full time just to write a book rationalizing every change made from release to release ;)
[01:21] <bratsche> DanRabbit1: I disagree that no amount of voting/bitching can sway the decision. :)
[01:21] <maxb> Not every change. Just the ones that are quite obviously going to be controversial
[01:22] <maxb> Really, what annoys me the most is that it's been done without providing a configuration UI. *I* can happily fiddle with gconf. My mother/father/brother can not.
[01:23] <bratsche> Hey jono, how's it going dude?
[03:09] <DanRabbit1> bratsche: well AFAIK it was Mark who made the call ;)
[16:01] <jcastro> seb128: is it indicator-application bug day for you?
[16:01] <jcastro> \o/
[16:02] <seb128> jcastro, yes ;-)
[16:02] <seb128> jcastro, helping my ayatana friends to see clearly what they should look at for lucid
[16:03] <jcastro> cool
[16:03] <jpetersen> I will be back in an hour
[20:36] <Nafai> HI guys
[20:36] <Nafai> Sorry I haven't been online, been a really bad allergy day
[20:36] <ryanprior> Hey Nafai.
[20:42] <jpetersen> Hey Nafai
[20:42] <Nafai> Hi jpetersen, ryanprior
[21:36] <seb128> tedg, bug #530429
[21:36] <ubot4> Launchpad bug 530429 in indicator-applet (Ubuntu) (and 1 other project) "invalid cast from `GtkStatusIcon' to `GtkWidget' (affects: 2)" [Undecided,New] https://launchpad.net/bugs/530429
[21:36] <seb128> do you think those warnings are coming from indicator-applet?
[21:38] <seb128> jcastro, bug #535267
[21:38] <ubot4> Launchpad bug 535267 in indicator-applet (Ubuntu) (and 1 other project) "Application indicator menu is not updated when new devices are added (affects: 1)" [Undecided,New] https://launchpad.net/bugs/535267
[21:38] <seb128> was there an another bug update issues already somewhere?
[21:39] <jcastro> seb128: running an irc session, I'll check later
[21:39] <seb128> jcastro, ok no hurry
[21:39] <jcastro> jpetersen or nafai might know
[21:39] <tedg> seb128: They could be in libappindicator.
[21:39] <tedg> I wish there was a line number.
[21:39] <tedg> Oh, wait.  That's fixed.
[21:40] <seb128> tedg, I rebuilt without the libindicator change and it's not there
[21:40] <seb128> the warning
[21:40] <seb128> tedg, what is fixed?
[21:40] <seb128> the warning or the update? ;-)
[21:40] <tedg> seb128: The warning.
[21:40] <seb128> where ?
[21:40] <tedg> seb128: I want to give credit, but I don't remember who fixed it... I think it was chriscoulson.
[21:40] <seb128> hum right, I don't get it in lucid now
[21:42] <seb128> tedg,
[21:42] <seb128> "      Use gtk_status_icon_set_visible to hide the status icon. GtkStatusIcon is not derived from GtkWidget, so gtk_widget_hide doesn't work
[21:42] <seb128> "
[21:42] <seb128> that one?
[21:42] <seb128> tedg, it was chrisccoulson indeed, thanks
[21:42] <tedg> seb128: Yup, that one.
[21:44] <seb128> Nafai, hey
[21:44] <seb128> Nafai, bug #535267, do you know if that's a duplicate and from which bug?
[21:44] <ubot4> Launchpad bug 535267 in indicator-applet (Ubuntu) (and 1 other project) "Application indicator menu is not updated when new devices are added (affects: 1)" [Undecided,New] https://launchpad.net/bugs/535267
[21:45] <Nafai> seb128: Let me check
[21:45] <seb128> Nafai, thanks
[21:47] <Nafai> It's related to an earlier bug, thought it was fixed, but it could very well be new
[21:47] <seb128> Nafai, can I assign it to you to investigate?
[21:47] <Nafai> sure thing
[21:47] <seb128> thanks
[21:50] <Nafai> This actually sounds like another bug that will be fixed with jpetersen's patch that I think will be rolled out tomorrow with the latest indicator release, I'll check it against the code in bzr
[21:51] <seb128> Nafai, thanks
[21:51] <seb128> tedg, bug #534854, does that speak to you?
[21:52] <ubot4> Launchpad bug 534854 in indicator-applet (Ubuntu) "indicator-applet logs 'GTK not updated' to disk every 30 seconds (affects: 2)" [Undecided,New] https://launchpad.net/bugs/534854
[21:53] <tedg> seb128: Yes, that's a dbusmenu bug.
[21:53] <seb128> tedg, ok, should I assign it to you?
[21:54] <tedg> seb128: yes
[21:54] <seb128> tedg, in which cases does it happen?
[21:54] <seb128> tedg, thanks
[21:55] <tedg> seb128: I think that it's something to do with dbusmenu-gtk looking for a property update before being realized.  It's a race condition that is fortunately ending in a warning :)
[21:56] <seb128> tedg, ok
[21:56] <seb128> tedg, sorry for all the ping today but I think we are almost done looking through the list
[21:56] <seb128> then I will let you work quietly on fixing on those isses for lucid ;-)
[21:56] <tedg> seb128: Heh, no worried.  Thank you for going through them!
[21:57] <tedg> worries
[21:57] <seb128> tedg, np
[21:57] <seb128> tedg, I guess you have a bug about the spacing for indicators?
[21:57] <tedg> seb128: Yes, I think kwwii has fixed it in the theme.
[21:59] <seb128> tedg, oh, right, he fixed it in the default theme but not the light one
[21:59] <seb128> tedg, I will chase him tomorrow ;-)
[22:00] <Nafai> bbiab, but I will investigate these things today
[22:01] <seb128> Nafai, see you later
[22:06] <seb128> tedg, btw
[22:06] <seb128> http://launchpadlibrarian.net/40652260/buildlog_ubuntu-lucid-i386.libindicate_0.3.5-0ubuntu4_FAILEDTOBUILD.txt.gz
[22:06] <seb128> tedg, libindicate still failed to build with your change + the build-depends
[22:08]  * tedg looking
[22:13] <tedg> Uhg, okay.  It needs a lib path.
[22:15] <seb128> right
[22:15] <seb128> it's probably working for you or me because we have a system libindicate installed
[22:16] <seb128> but it should have a -L$(srcdirsomething)
[22:17] <seb128> tedg, what does the indicator ordering? there is a bug saying that applications should go on the left of the sound indicator
[22:17] <seb128> has the order been speced?
[22:17] <tedg> seb128: Yes, it should be in -L$(top_builddir)/libindicate/.libs
[22:18] <tedg> seb128: Yes it has.  And it's in trunk... need to do a release of indicator-applet.
[22:18] <seb128> tedg, good ;-)
[22:19] <seb128> I see, revision 343
[22:39] <jcastro> seb128: lp #535267 looks like a regression
[22:39] <ubot4> Launchpad bug 535267 in indicator-application (Ubuntu) (and 1 other project) "Application indicator menu is not updated when new devices are added (affects: 1)" [Medium,Confirmed] https://launchpad.net/bugs/535267
[22:40] <jcastro> I think that was the problem he was having before
[22:40] <seb128> jcastro, Nafai replied since
[22:40] <jcastro> oh ok
[22:41] <seb128> jcastro, he said that jpeterson's recent change might fix it
[22:41] <seb128> jcastro, he will test that later and update the bug
[22:41] <seb128> jcastro, but thanks ;-)
[22:43] <jcastro> well, while he's in there he can check on the icons
[22:43] <seb128> tedg, bah I don't get it, there is several crash in standard GError use
[22:43] <jcastro> seb128: we wanted to remove the arrow thing and the prefs icon right? So the menu doesn't look all messed up?
[22:43] <seb128> jcastro, that's not a gnome-bluetooth bug but the indicator not respecting the show_icon flag for stock items
[22:44] <jcastro> oh
[22:44] <seb128> jcastro, we agree there is no change required to the app patch there
[22:44] <jcastro> are we fixing that for lucid?
[22:44] <seb128> I guess so
[22:44] <jcastro> in the indicator I mean
[22:44] <seb128> I'm building a list of milestoned issues for dx work, I will put it there
[22:45] <jcastro> <3
[22:45] <tedg> seb128: Yeah, I've seen a couple that have done that.  I'm not clear on why.  I think it's something with dbus setting errors.  Is that what you're seeing?
[22:46] <seb128> tedg, yes
[22:46] <seb128> chrisccoulson might know about that?
[22:46] <seb128> code is basically
[22:46] <seb128> dbus_g_proxy_new_for_name_owner(priv->bus,...&error);
[22:46] <seb128> 	if (error != NULL) {
[22:46] <seb128> 		g_error("Unable to get the proxy to DBus: %s", error->message);
[22:46] <seb128> with error init to NULL before being used as it should
[22:46] <seb128> and it crashes in the g_error call
[22:46] <tedg> I think dbus must be doing a double free somewhere.  I've looked and not found it though :(
[22:46] <seb128> doesn't make sense to me
[22:47] <tedg> dbus-glib.
[22:47] <seb128> will be tricky to debug I guess
[22:48] <chrisccoulson> hi
[22:48] <chrisccoulson> i saw my name mentioned ;)
[22:48] <seb128> hey chrisccoulson
[22:48] <seb128> chrisccoulson, you know quite some things about dbus so I was wondering if you saw bugs like this before
[22:50] <chrisccoulson> where is that code from?
[22:51] <seb128> chrisccoulson, one bug is bug #532965
[22:51] <ubot4> Launchpad bug 532965 in libindicator (Ubuntu) "indicator-applet-session crashed with signal 5 in g_type_create_instance() (affects: 1)" [Medium,New] https://launchpad.net/bugs/532965
[22:51] <seb128> libindicator
[22:51] <seb128> bzr get lp:libindicator
[22:51] <seb128> editor libindicator/indicator-service-manager.c
[22:51] <seb128> line 189
[22:52] <seb128> but I just ran into a similar but in indicator-messages
[22:52] <seb128> bug #522855
[22:52] <ubot4> Launchpad bug 522855 in indicator-applet (Ubuntu) "indicator-applet crashed with signal 5 in indicator_object_get_entries() (affects: 4) (dups: 3)" [Medium,New] https://launchpad.net/bugs/522855
[22:52] <seb128> so I'm wondering what the heck is happening with dbus and GErrors
[22:55] <seb128> chrisccoulson, don't feel like you have to look at that, I was just wondering if you have seen similar bugs before
[22:55] <seb128> I know you discussed some dbusish issues with james_w
[22:55] <chrisccoulson> i'll have a quick look and see if i can spot something
[22:55] <seb128> chrisccoulson, thanks
[22:56] <seb128> hum
[22:56] <seb128> there is a new dbus-glib bug fix version in debian
[22:56] <seb128> I'm wondering if we should get that in lucid
[22:57] <seb128> hum
[22:57] <seb128> chrisccoulson, tedg: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541632
[22:57] <ubot4> Debian bug 541632 in libdbus-glib-1-2 "libdbus-glib-1-2: wonky results from dbus_g_proxy_call" [Normal,Fixed]
[22:58] <seb128> similar issue?
[22:59] <chrisccoulson> i remember looking at that when i looked at what looked like a similar issue, but it ended up being something different
[22:59] <chrisccoulson> but it could be that issue
[22:59] <seb128> we should get 0.84 in ;-)
[22:59] <seb128> I'm pondering just doing the sync now
[23:00] <tedg> Yeah, that seems likely to be the issue.
[23:00]  * tedg sucks at switch statments which probably why he missed it.  Seriously, it's a coding weakness, I always slow down when writing them.
[23:02] <seb128> chrisccoulson, tedg: ok thanks, I will sync dbus-glib 0.84 from debian and close those bugs with a "reopen if you get the issue again after upgrade"


[23:05] <doko> so gnutls is coupled with bind9 and linux; removed netexpect, trying to get filezilla done


[01:55] <mgz> OOPS-2062AZ5 too late at night...
[01:57] <mgz> Fourth time lucky, I wonder if putting "lp:" on the start of the prerequisite branch upset anything...
[01:58] <lifeless> mgz: bugs.launchpad.net/launchpad-project/+bugs?field.tag=timeout
[01:58] <mgz> 77 results being the relevent thing? :)
[01:59] <lifeless> no, there is one for +merge-proposal in there ;)
[02:00] <mgz> bug 629087 looks likely.
[02:00] <lifeless> yeah thats the one
[02:00]  * mgz metoos
[04:00] <poolie> hi mgz, scottk
[04:07] <ScottK> hello poolie.
[04:07] <ScottK> poolie: It's gone midnight, so I'm about to go to bed, but what's up?
[04:07] <poolie> just saying hi
[04:07] <poolie> thanks for the suggestion
[04:07] <poolie> about out of date branches
[04:07] <ScottK> Ah.  OK.
[04:08] <ScottK> Hello back poolie.
[04:26] <AuroraBorealis> heya.
[04:28] <AuroraBorealis> how do i tell what gets called when you pass commands to bzr? like, bzr add, checkout, merge, etc
[04:29] <lifeless> AuroraBorealis: do you mean what python functions run?
[04:29] <AuroraBorealis> yeah
[04:29] <AuroraBorealis> i see the Command class and that you have to register
[04:29] <AuroraBorealis> said commands but i dunno where that gets done o.o
[04:29] <lifeless> for plugins during the plugins __init__
[04:30] <lifeless> for core commands by being in builtins.py
[04:30] <lifeless> or whatever the file is called :)
[04:32] <AuroraBorealis> ah, thank you =)
[05:29] <AuroraBorealis> oh gee.
[06:18] <vila> hi all !
[06:20] <AuroraBorealis> hi...
[06:20] <AuroraBorealis> where does the InventoryEntry object store its 'kind' variable?
[06:21] <AuroraBorealis> i keep seeing it referenced but i never see it created, its not created in __init__ and ctrl+f shows its not created anywhere else in inventory.py..
[06:25] <AuroraBorealis> never mind i'm stupid, its in the subclasses. although said methods are calling that variable in the super class so they would throw errors if you called said method on the superclass o.o
[08:30] <ChrisCauser> Hi Everyone, quick question. I'm reading up a lot about why you shouldn't push a feature branch directly upstream. I was just wondering if there was a way to enforce non changing id numbers so the people I work with don't accidentally do this
[08:31] <poolie> ChrisCauser: yes, set append_revisions_only
[08:31] <ChrisCauser> Brilliant. Many thanks
[08:38] <poolie> vila, so if you look at jam's recent get_parent_map work
[08:38] <poolie> i think there's a constant in it which he did some empirical work to change
[08:38] <vila> yup
[08:38] <poolie> i think i suggested it could be configurable and he opted not to
[08:38] <vila> indeed
[08:38] <vila> for backport reasons
[08:38] <poolie> mm
[08:39] <vila> which is tangential but could become a concern if we never use new features by fearing backport issues, but that's not the main point here
[08:39] <poolie> so, i don't think going back and changing it to be configurable, which would potentially close 832061, would be especially useful in itself
[08:40] <vila> I trust jam's work on setting the "best" value here, but that doesn't mean that for some setups this value will be far from optimal
[08:40] <poolie> sure
[08:40] <vila> if we can't try new values, we'll never know
[08:41] <vila> and if the code evolves and the best value is not the best anymore, we'll never know either
[08:41] <jam> poolie: I also didn't want to introduce yet-another-read of something that doesn't-really-need-to-be-set
[08:41] <poolie> right
[08:42] <vila> and if this constant turns out to be easily tweaked based on some (for the sake of the example) branch history property, we can't tweak either
[08:42] <poolie> so, basically
[08:42] <vila> jam: right, that's a performance issue
[08:42] <poolie> i like bugs that correspond to actual problems and where you can tell whether they're fixed or not
[08:43] <poolie> if you find a way to tweak that constant, or to dynamically configure it to make things faster, that's great
[08:43] <vila> well, not being able to diagnose whether a constant is good or bad *is* the problem I'm referring to
[08:43] <jam> vila: so if it was something like "disable it completely" I would consider a config item. If it is just tweaking it, it really depends on how much effect it could have.
[08:43] <jam> Since my experiments said "very little" outside of edge cases
[08:44] <poolie> so, being able to change a thing when we don't have any actual reason to think we want to change it is Low
[08:44] <poolie> there are a lot more important bugs than that
[08:44] <vila> well, I won't ask you to extend your experiments to lp hosted code...
[08:44] <jam> vila: so in *this particular* case, I did a fair amount of analysis and testing (a couple days at least) to know that the setting was not going to be very optimizable. I don't know that it applies in every case
[08:44] <jam> vila: that was tested on lp hosted code
[08:45] <vila> *all* lp hosted code
[08:45] <jam> vila: I don't think we really care about the perf on lp:bzrtools as long as it is reasonable, and I tested against lp:gcc-linaro lp:mysql and lp:emacs
[08:45] <poolie> so, vila, if you had a good reason to suspect that by further tweaking we could get a big improvement, i'd say go for it
[08:45] <jam> I suppose I could do lp:launchpad
[08:45] <jam> but I did try to do different types of histories, etc.
[08:45] <poolie> but that doesn't seem to be where we are
[08:46] <jam> Yes, this experiment could be done again in a year, etc. But honestly, unless someone is going to spend the time analyzing the results, it won't help much.
[08:46] <vila> poolie: it's not about *me* it's about anybody willing to try with its *own* know code
[08:46] <jam> And if they are doing that, they don't need a config setting
[08:46] <vila> what do they need then ? Modifying the code ?
[08:46] <jam> vila: sure, or a plugin that modifies the constant, or ...
[08:46] <poolie> so if someone is going to tune this, it's probably pretty easy for them to make it configurable at that point
[08:46] <jam> in the end, you need to write a script
[08:47] <jam> and that can fairly easily get at what you need
[08:47] <vila> or just a fix for bug #491196...
[08:47] <poolie> i think adding a command-line option is possibly the thing that would help them most
[08:47] <poolie> right, i would say that is far in advance of going back and making every thing configurable
[08:47] <poolie> i think too, many things that could be tuned don't want to be tuned by just changing an integer
[08:47] <poolie> but possibly changing the algorithm, which is beyond what this can do
[08:48] <vila> right, changing algorithms is better done via hooks
[08:48] <vila> but hooks can also be configured
[08:48] <poolie> or experimenting with an actual patch
[08:48] <jam> vila: or you can write a plugin...
[08:48] <jam> or monkey patch, or.
[08:49] <jam> honestly, if someone wants to experiment with the code, I really don't see a huge difference from them playing with the *code*
[08:49] <vila> jam: or set a command-line option, which one is the easiest for someone wanting to experiment without knowing the code base ?
[08:49] <jam> vila: someone who wants to tweak this is going to need to know a whole lot more than a command line option
[08:49] <jam> note *this*
[08:49] <jam> Some other things would be good with a command line/environment var
[08:50] <poolie> vila, a command line option would be great
[08:50] <poolie> very nice for interactively testing config related stuff, aside from anything else.
[08:51] <jam> vila: I agree that having a config item that can be set from a command line (env var, argument passed) is the easiest way to play with bulk behavior.
[08:51] <jam> In this case, I think it is YAGNI.
[08:51] <jam> You also want to avoid doing the whole fetch
[08:51] <jam> so you need to hack the code anyway
[08:51] <poolie> vila do you see what i mean about prefering 'know you're done when' bugs?
[08:51] <jam> otherwise the 1-5min startup time is lost in the 30min transferring 600MB of data.
[08:52] <poolie> vila do you see what i mean about prefering 'know you're done when' bugs, and why this isn't really one at the moment
[08:54] <vila> poolie: yes, but we disagree on "it's done" :)
[08:55] <poolie> when would it be done?
[08:55] <vila> we had many cases in the past where one setting (let's just say 'encoding') wasn't properly found (for whatever reasons) and users were blocked because there was no way to override this setting
[08:56] <poolie> yup
[08:56] <poolie> i would certainly agree with that
[08:57] <poolie> in fact i think i have filed a bug about that particular case, or at least someone has
[08:57] <vila> If we can associate that kind of setting with a *config* setting, we can at least say: 'Look, we'll fix that in the latest stable series, in the mean time, just set it to x in this context)
[08:58] <vila> I argue that whatever setting (constant or not) should be a config setting to cover these cases and I'd call it done when the know ones are
[08:58] <poolie> yep
[08:58] <poolie> if it names some specific things that aren't configurable but should be i'd be totally fine with the bug
[08:59] <poolie> (bit questionable whether to have one bug or several but the simplest thing would be to start with one)
[08:59] <poolie> perhaps better to fix the bugs that are already filed though
[08:59] <vila> :)
[08:59] <poolie> some of them, like fsenc, are nontrivial to change
[09:00] <jam> vila: we've had code bugs in the past that we couldn't fix in the stable release. If we could write some python config values we could say "write this config and it will fix the bug for now".
[09:00] <jam> oh, that is a plugin...
[09:00] <jam> I'll agree that 'config' seems a little better than a plugin.
[09:00] <jam> meaning "lighter for the user"
[09:00] <vila> and doesn't require python knowledge
[09:01] <vila> I argue that it it was that easy to write a plugin we'll have far more of them today
[09:01] <jam> vila: but does require to know the config value to set
[09:01] <jam> and if we have to give them something to use
[09:01] <jam> we can give them the plugin
[09:02] <vila> I'm not saying plugins are bad and should never be written, I'm saying that too few people can write them or even install them
[09:02] <poolie> ok...
[09:02] <vila> jam: look at bug #320593 and tell me how long the proposed plugin will work
[09:02] <vila> shudder
[09:03] <jam> vila: I'm arguing that the set.difference() between set(users_can_set_a_config_we_recommend).difference(set(users_that_can_install_a_plugin_we_recommend_on_a_bug)) is small
[09:03] <vila> jam: look at bug #302593 and tell me how long the proposed plugin will work
[09:04] <poolie> jam, could you review or maybe finish off https://code.launchpad.net/~spiv/bzr/faster-stacked-tree-build/+merge/70381 some time?
[09:04] <jam> vila: longer than writing a config item for it
[09:04] <jam> poolie: it is in my "in progress" queue
[09:04] <jam> so yes
[09:04] <poolie> cool thanks
[09:05] <vila> jam: huh ? Turning a constant into a config item should be a one-liner (if you exclude the help which you need to write anyway)
[09:05] <jam> vila: "Reading options for a branch from locations.conf fails with bzr+ssh "
[09:05] <jam> are you sure you were on the right bug?
[09:05] <poolie> vila, so
[09:05] <poolie> let's see if i understand
[09:05] <poolie> you think that generally speaking we should have configs-with-defaults rather than magic numbers
[09:06] <vila> jam: https://bugs.launchpad.net/bzr/+bug/302593/+attachment/1157814/+files/fixLocationConfigForBzrSsh.py
[09:06] <vila> poolie: yes
[09:06] <poolie> i agree with that, though i'd have some concern about the scalability of documentation if it includes lots of stuff most people should never change
[09:06] <poolie> some of them should perhaps be debug flags with values
[09:06] <jam> vila: but you could never fix that with a config change
[09:06] <vila> poolie: which is bug #746993
[09:06] <poolie> iiuc you also think we should go back and look for all things that could potentially be config options and change them
[09:06] <jam> so yes, the plugin is fragile, it works until you can upgrade to a newer release which has the bug fixed
[09:07] <jam> and the failure is so large in scope that it is completely outside of "tweaking a config item"
[09:07] <poolie> well, it goes beyond that, into perhaps having an 'internal' or 'hidden' class of options
[09:07] <poolie> i don't think that's worth doing until there's actually a motivation to change them
[09:07] <jam> poolie, vila: We've also falling into the trap in the past of having configurable settings that people can tweak, but not providing a good default.
[09:08] <jam> because we stop at "ok, they can configure it"
[09:08] <poolie> that's a risk too
[09:08] <jam> and defaults really do matter
[09:08] <vila> know risk
[09:08] <vila> known risk, but I'm talking about the other end of the spectrum where there is *no* way to change it
[09:09] <jam> vila: I feel we got a bit off on the wrong foot, though. I agree that *in general* I'd rather have something exposed to the user easily in case something goes wrong.
[09:09] <jam> This particular case, the reward / benefit was not high enough.
[09:09] <jam> When we have properly cached configs, that may change.
[09:09] <poolie> cool
[09:09] <vila> jam: pfew, thanks
[09:09] <jam> vila: note that I was clear all along that *this case* was how I handled it.
[09:10] <vila> jam: right, I never said you did wrong given the existing code base 1
[09:11] <vila> I'm saying many problems we encountered *could* be far easier to address
[09:11] <vila> poolie: yes, this may not be the first thing to work on *today* but I'd like us to keep it in mind and not punting every time
[09:12] <poolie> ok, i just read https://bugs.launchpad.net/bzr/+bugs?field.tag=config
[09:12] <vila> poolie: in that respect, I feel that 'low' is pretty close to 'wontfix'
[09:12] <poolie> i think the ones that are High are plausibly high
[09:13] <vila> well, those are the ones I filed yesterday (except for the first one), I didn't touch the others but I took them into account when writing the devnotes/configuration.txt
[09:14] <jam> vila: the flip side of the argument is that you've spent a fair amount of time reworking the config stuff, which still isn't quite enough of a change, vs just fixing the bugs we run into that could have been easier with a better config system.
[09:14] <jam> (limited human time and all that)
[09:14] <jam> I really like where you are pushing config
[09:14] <jam> I'm not sure if it was the optimal use of time
[09:15] <poolie> jam, yeah, that's why i'm looking at that list
[09:16] <poolie> perhaps vila can finish up the High bugs there and any that naturally fall out from doing it and then move on for a bit
[09:16] <poolie> perhaps to udd
[09:16] <vila> jam: my counter-argument to that is that I didn't spent that much CPU time on it considering the results and that we are now with two designs in flight and that is already a concern
[09:17] <jam> vila: sure, I certainly think it has been started, it is in flight, we need a clear landing for it
[09:17] <jam> as poolie said, a clear "it is done"
[09:17] <jam> but I think you're at a point it can be ratcheted down
[09:18] <jam> rather than a primary focus. Perhaps not
[09:18] <vila> well, it's certainly not the only thing I'm working on and I fail to see which of the ~10 mps landed in the last 15 days is not on the cirtical path
[09:20] <poolie> so, in <http://people.canonical.com/~mbp/kanban/vila-kanban.html> (which may be lossy)
[09:21] <poolie> i see 7 for the last month, and 3 are config related (of which 1 is my fdatasync bug, and fairly serious) and 4 are test suite failures
[09:21] <vila> poolie: yup, definitely lossy because  I didn't file bugs I was fixing (at the some time slicing the features doesn't match filing bugs in my mind but I can change that (which I started yesterday))
[09:26] <poolie> anyhow, i think john and i are just keen to have config infrastructure and also to get your help on other things
[09:42] <jam> vila: poke about https://code.launchpad.net/~vila/bzr/missing-stacks/+merge/71918
[09:42] <jam> You said "Remote branches ignore bazaar.conf and locations.conf" care to clarify?
[09:43] <jam> it sounds dangerously wrong
[09:43] <jam> as locations.conf is provided as a way to *override* settings in branch.conf for remote items.
[09:43] <jam> remote branches
[09:46] <soren> Hi. I'm hoping someone can help me decipher this error message:
[09:46] <soren> bzr: ERROR: Parent not accessible given base "bzr+ssh://bazaar.launchpad.net/%2Bbranch/nova/" and relative path "../../../~soren/nova/trunk/"
[09:46] <soren> It's in response to "bzr lp-propose-merge -m 'something'"
[09:46] <soren> http://paste.ubuntu.com/673669/ is my ~/.bazaar/locations.conf
[09:47] <soren> And I have *no* clue what ../../../~soren/nova/trunk/ is.
[09:53] <soren> Oh. It's from Launchpad.
[09:53] <soren> :-$
[09:57] <poolie> hi
[09:57] <vila> "it sounds dangerously wrong", see revno 5999, I'm not introducing that
[09:57] <poolie> oh, so i think your parent_branch config setting is wonky
[09:58] <vila> jam: "it sounds dangerously wrong", see revno 5999, I'm not introducing that
[09:58] <poolie> hm, or, which branch are you trying to propose?
[09:58] <vila> jam: I'm just formalizing the existing code
[09:58] <poolie> soren, basically what's happening is that bzr is trying to infer which branch you intend to merge into, and getting an apparently impossible path
[09:58] <soren> poolie: Can you try this, please:
[09:58] <soren> poolie: bzr info lp:nova
[09:58] <jam> vila: that was *only* for reading *just* branch.conf to get the stacking location
[09:58] <soren> Just for shits and giggles.
[09:58] <jam> not *all* settings
[09:59] <jam> if that's what you've done, great.
[09:59] <soren> poolie: ...because I get that error doing that as well. ~soren/nova/trunk is something that only ever existed on Launchpad.
[09:59] <soren> poolie: Hang on, I'll post the .bzr.log.
[09:59] <jam> (we no longer support using locations.conf to override a stacked location, but we still support it for everything else)
[09:59] <vila> jam: it's not used yet but the plan is to use it only for this case if that's possible
[10:00] <vila> jam: and neither do we for default_stacking_on if I understand correctly
[10:00] <soren> poolie: http://paste.openstack.org/show/2269/
[10:00] <jam> vila: I think you're right about default_stacking_on but I have limited experience with it.
[10:00] <soren> poolie: It seems to get the ~soren/nova/trunk bit back from lp (no clue why, though) and tries to make sense of it locally.
[10:00] <soren> poolie: Or rather, ../../../~soren/nova/trunk which makes even less sense to me.
[10:01] <vila> jam: but thanks for the poke, I'll double-check (now that you mentioned it, I may have fall into a trap with that)
[10:01] <soren> poolie: This happens even if I explicitly specify the target branch.
[10:01] <poolie> vila, can he fix this with bzr config to update the branch conf?
[10:02] <vila> jam: which in retrospect was my main concern with revno 5999 (even if I didn't make a funny face at the time ;)
[10:02] <soren> poolie: ..and with an empty locations.conf as well, apparently.
[10:02] <vila> poolie: in theory yes, in practice there may be bugs with remote branches
[10:02] <vila> ... they should be filed and fixed of course ;)
[10:03] <poolie> soren, did you perhaps rename this branch from something else to be the trunk?
[10:03] <jam> soren: it is a setting in .bzr/branch/branch.conf which is saying that the "parent" branch is ../../../~soren/...
[10:03] <jam> I'm not sure why we need the parent
[10:03] <jam> ah, lp-propose is failing
[10:03] <jam> because it is trying to auto-detect what branch you want to target
[10:03] <poolie> yes, that's what i said :)
[10:04] <soren> jam: .bzr/branch/branch.conf:  http://paste.ubuntu.com/673676/
[10:04] <jam> poolie: yeah, your statements were intermixed around when I was chatting with vila, so I missed bits
[10:04] <jam> silly conversation threading
[10:04] <poolie> soren i think 'bzr config -d lp:nova --remove parent_location' should fix it
[10:04] <soren> poolie: Nope.
[10:04] <soren> poolie: I haven't referred to anything as trunk in over a year.
[10:04] <jam> soren: it is the remote one that is probably the issues
[10:04] <jam> issue
[10:05] <soren> I'm happy to try it, but:
[10:05] <soren> http://paste.ubuntu.com/673682/
[10:05] <vila> I suspect we have been propagating parent_location from local to remote branches in the past (and we may still do so)
[10:05] <jam> soren: the small issue is that launchpad changed how you access branches, from always being 3-parts (~user/project/branch) to sometimes just +branch/project
[10:05] <soren> There's no reference to anything called trunk.
[10:05] <jam> soren: the issue is lp:nova
[10:05] <soren> ~soren/nova/trunk was abandonded well over a year ago.
[10:05] <soren> jam: Oh.
[10:06] <jam> soren: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/.bzr/branch/branch.conf
[10:06] <soren> jam: That makes even less sense to me:
[10:06]  * vila pesters about not being able to decipher  /+branch-id/362222
[10:06] <soren> http://paste.ubuntu.com/673683/
[10:06] <soren> jam: Oh, dear.
[10:06] <soren> jam: That is so wrong.
[10:06] <jam> soren: I'm guessing you created the branch by branching from soren all those years ago
[10:07] <soren> jam: Yes, that's entirely likely.
[10:07] <jam> soren: what version of bzr are you using?
[10:07] <soren> Now?
[10:07] <soren> Bazaar (bzr) 2.4.0
[10:08] <jam> soren: bzr config -d lp:nova "parent_location="
[10:08] <soren> I can't.
[10:08] <jam> should get rid of that setting
[10:08] <soren> I'm not ~hudson-openstack.
[10:08] <jam> ugh
[10:08] <soren> ...but I guess I could become him.
[10:08] <jam> soren: we can get a sys-admin to do it if you can't
[10:08] <jam> but it takes a while
[10:08]  * soren does so while whistling innocently.
[10:09] <poolie> you're asking a sysadmin?
[10:09] <vila> I think he's becoming ~hudson-openstack and can't answer from there ;)
[10:10] <jam> poolie: soren is doing it himself
[10:10] <jam> well, at least for now
[10:10] <poolie> oh, really
[10:10] <jam> if he comes back saying it doesn't work, i'll contact a losa
[10:10] <jam> poolie: it sounds like ~hudson-openstack is a bot
[10:10] <jam> (hudson and all that)
[10:10] <poolie> yeah
[10:12]  * vila scratches head...
[10:12] <soren> I'm battling this right now: Unable to copy ownership from "/var/lib/jenkins/.bazaar" to "/var/lib/jenkins/.bazaar/locations.conf". You may want to set it manually.
[10:12] <soren> GImme a minute.
[10:13] <vila> launchpad redirects lp:nova to https://code.launchpad.net/~hudson-openstack/nova/trunk but 'bzr config -d<xx>' doen't give the same result
[10:13] <soren> What does this mean for me?
[10:14] <soren> uark!
[10:14] <soren> http://paste.ubuntu.com/673691/
[10:14] <soren> That can't be good.
[10:15] <poolie> vila ^^ ?
[10:15] <soren> lp-propose-merge does seem to be happier, though.
[10:16] <vila> poolie: wow, that is so wrong, lp urls are not even supposed to be supported... 'lp:novalp:nova' ... is wrong too but
[10:17] <vila> and bug #832653 filed anyway
[10:18] <vila> soren: what's your 'bzr config' output in the branch you ran lp-propose ?
[10:19] <soren> vila: http://paste.ubuntu.com/673692/
[10:21] <jam> soren: still looks wrong here: http://bazaar.launchpad.net/~hudson-openstack/nova/trunk/.bzr/branch/branch.conf
[10:21] <soren> Yes, ti does.
[10:21] <soren> it, even.
[10:21] <vila> soren: so you're not under /home/soren/src/openstack/nova ?
[10:22] <soren> vila: I am.
[10:22] <soren> vila: Oh, sorry.
[10:22] <vila> meh
[10:22] <vila> ha
[10:22] <jam> soren: sftp bazaar.launchpad.net ; cd ~hudson-openstack/nova/trunk/.bzr/branch; rm branch.conf
[10:22] <soren> 10:02 < soren> poolie: ..and with an empty locations.conf as well, apparently.
[10:22] <soren> vila: I cleared out locations.conf to see if that was causing it.
[10:22] <vila> ha, ok, empty locations.conf was the missing bit
[10:23] <jam> soren: though you can continue helping vila debug remote config issues if you want.
[10:23] <vila> soren: keep in mind that locations.conf *overrides* branch.conf (but seem to act as a default value provider)
[10:23] <soren> vila: Wow, really?
[10:23] <soren> That's... wow.
[10:23] <soren> Ok.
[10:24] <soren> Is that by design?
[10:24] <jam> soren: Users have access to locations.conf
[10:24] <jam> but may not have access to branch.conf
[10:24] <soren> How can they not have access to branch.conf?
[10:24] <jam> soren: You can't write to *my* branch.conf
[10:24] <jam> though you may read it when branching from me
[10:24] <jam> so locations.conf was designed as a way to override settings for your personal use
[10:25] <jam> but also grew globs
[10:25] <vila> soren: see bug #832046
[10:25] <jam> which meant that it started providing defaults as well as overrides
[10:25] <soren> Fascinating.
[10:25] <jam> which makes things messy
[10:25] <jam> you need 3 layers, basically
[10:25] <soren> Defaults, branch, overrides.
[10:25] <jam> defaults get overridden by branch local config gets overriden by user specified overriedss
[10:25] <soren> Right.
[10:26] <soren> That lp:novalp:nova thing... Is that going to cause troupble?
[10:26] <soren> Or trouble?
[10:26] <vila> tyops welcome ;)
[10:27] <fullermd> Rule 1: You always need 1 level more than you have.  Rule 2: The cognitive load limit is always 1 level less than you have    :p
[10:27] <soren> vila: "tyops"?
[10:27] <soren> vila: Oh. typos :)
[10:27] <vila> well, I would be surprised if it applies to lp:nova urls anyway since urls are supposed to be translated already when dealing with locations.conf
[10:27] <soren> vila: orly?
[10:28] <vila> soren: yeah, I do less tyops once I invoked the tyop god
[10:28] <vila> only
[10:28] <vila> but it doesn't work everytime
[10:28] <fullermd> Well, maybe this time dog will simile on you.
[10:31] <vila> fullermd: smile ?
[10:32] <poolie> pqm might be having trouble?
[10:32] <poolie> i've asked the sysadmins
[10:34] <vila> jam: wow, you sent https://code.launchpad.net/~vila/bzr/824513-fadatasync-options/+merge/72454 to pqm *after* I did (lp is misleading, I did the send after the push)
[10:34] <vila> jam: still I didn't get any answer, did you ?
[10:35] <jam> vila: I was trying to submit one of mine, I just read the proposal wrong and submitted yours
[10:35] <vila> poolie: blackbox.test_branch.TestBranch.test_branch_broken_pack FAIL is spurious, dunno if we have a bug for that though
[10:35] <jelmer> we do
[10:35] <poolie> yes it's broken; will be fixed soon
[10:35] <poolie> o/ jelmer
[10:35] <jelmer> hey poolie :)
[10:35] <vila> jam: ha, ok, still did you get an answer or is indeed pqm borken, ha right
[10:36] <vila> jelmer: hey !
[10:36] <poolie> can you guys re-feed them if necessary when the paper jam is cleared?
[10:36] <jam> vila: I didn't get any response and the web page is "0 scripts" for me
[10:36] <jam> poolie: certainly
[10:36] <vila> jam: ok, same here
[10:36] <jam> want us to resubmit your "trivial" as well?
[10:37] <poolie> yes thanks, i have two or three approved
[10:37] <poolie> i have 10 assigned bugs and i think all but one or two are blocked
[10:40] <jam> poolie: in what channel did you ask the sysadmins? (Just trying to follow the thread)
[10:42] <jelmer> jam: #is
[10:44] <poolie> #is
[10:55] <jam> poolie, jelmer: Are we doing the udd standup in 5 min?
[10:55] <poolie> no, it's on holiday for augest
[10:55] <poolie> *august
[10:55] <jam> ah, ok
[10:55] <poolie> afaik
[11:10] <mgz> afternoon all.
[11:12]  * jelmer waves to mgz
[11:19] <vila> mgz: _o/
[11:21] <poolie> hi mgz
[11:21]  * poolie fixes a package import, yay
[11:28] <poolie> hm, bug 832052 is interesting, if it was hit on 2.4.0
[11:28] <poolie> which should have fdatasync on
[11:49] <jelmer> Riddell: thanks for backporting that i18n fix!
[11:49] <Riddell> jelmer: the rt got a reply so we should have access to PQM's 2.4 now
[11:50] <jelmer> Riddell: that was quick
[13:05] <mgz> jam: ping
[13:05] <jam> hi mgz, I was wondering when you would show up
[13:05] <mgz> ha, we were both waiting for each other to say something first?
[13:05] <jam> I guess so
[13:16] <Riddell> anybody object if I just turn on translations for the bzr project in launchpad?  I don't see a reason why not
[13:16] <vila> Riddell: +1 (I thought it has been done :-/)
[13:17] <jelmer> Riddell: go for it
[13:17] <vila> Riddell: what series will be impacted ?
[13:17] <Riddell> that's the next question, do we want to point people at 2.4 or trunk
[13:17] <jelmer> Riddell: perhaps have it export to a different branch rather than directly to trunk
[13:18] <jelmer> Riddell: does 2.4 have enough support for translations for translations to actually be usable?
[13:18] <vila> Riddell: if there is a way to point to trunk-only first that will allow us to debug the fallouts
[13:19] <Riddell> jelmer: yes, for most of the command help text
[13:19] <vila> jelmer: only command helps IIRC, so testable but not that useful
[13:19] <jelmer> I'd prefer targetting trunk in that case; we don't know what other fallout there may be from translations
[13:30] <Riddell> jelmer: what's your worry about exporting to trunk?
[13:41] <jelmer> Riddell: worried about a bot committing directly to one of our branches (and perhaps conflicts with pqm)
[13:43] <Riddell> yep
[13:44] <Riddell> lp:bzr-translations-export ?
[13:45] <Riddell> I wonder who should own it
[13:45] <Riddell> ~bzr-core I guess
[13:56] <jelmer> Riddell: does it have to be a new project?
[13:56] <Riddell> jelmer: no, I've set it to lp:~bzr-core/bzr/bzr-translations-export
[13:57] <jelmer> Riddell: cool
[14:48] <RenatoSilva> is there a lp plugin command for listing all branches of a project or your junk?
[14:49] <jelmer> RenatoSilva: I believe someone wrote one, but I'm not sure where you can find it
[14:49] <RenatoSilva> well, in the lp plugin, no?
[14:50] <RenatoSilva> a separate lp plugin? ok
[14:51] <jelmer> RenatoSilva: there isn't anything in the standard lp plugin
[14:51] <jelmer> though I think it would be an appropriate place for it
[14:53] <RenatoSilva> ok thanks jelmer
[15:08] <vila> jelmer: on jubany, there are uncommitted changes to plugins/builddeb and we miss 41 revisions from  lp:builddeb
[15:08] <vila> jelmer: shouldn't we at least update a bit ?
[15:08] <jelmer> vila: I have to admit, I've never looked at the bzr-builddeb on jubany
[15:08] <jelmer> what are the uncommitted changes?
[15:09] <vila> jelmer: (the uncommitted changes comment out installing the debian changelog merge hook)
[15:10] <jelmer> that sounds reasonable
[15:10] <vila> jelmer: and the revno on jubany is 566 (607 on trunk)
[15:10] <vila> jelmer: what ? Not installing the hook ?
[15:10] <jelmer> with regard to updating, I think it's a good idea but it would probably need some testing with current udd
[15:10] <jelmer> vila: yeah, the previous hook didn't very wekll
[15:10] <jelmer> *well
[15:11] <vila> work well , got that ;)
[15:12] <vila> weird, I thought spiv was happy with it... I should have miss some episodes
[15:12] <vila> jelmer: what kind of testing ?
[15:12] <jelmer> vila: Spiv added a new changelog merge hook
[15:12] <jelmer> vila: but I'm pretty sure that was after r566
[15:13] <vila> jelmer: ha ! So it may be worth re-trying the new one right ?
[15:13] <vila> jelmer: yeah, looks like revno 596
[15:15] <jelmer> vila: some internal APIs in bzr-builddeb have changed that udd might rely on
[15:16] <vila> hmm
[15:25] <jam> jelmer, vila: Didn't we switch to the system installed versions? Or was that for python-debian?
[15:25] <vila> python-debian
[15:26] <vila> jelmer: devscripts is not installed on jubany but you said 'Add dependency on devscripts >= 2.10.59, required now that 'dch --
[15:26] <vila>     package' is used. LP: #783122' does that apply to jubany ?
[15:28] <vila> ha, crap
[15:28] <vila> jelmer: by internals API you meant DistributionBranch ?
[15:30] <jelmer> vila: that would apply for the changelog merger
[15:31] <jelmer> vila: though I'm surprised the changelog merger matters at all for jubany - where is that used?
[15:31] <jelmer> vila: yep
[15:32] <vila> the devscripts dep you mean ? It seems to require dpkg-dev instead but that one is installed
[15:33] <vila> jelmer: so for DistributionBranch, udd doesn't use kwargs so an update is probably required and also probably in lock-step with bzr-builddeb update :-/
[15:34] <vila> ok, harder than I thought, I'll file a bug
[15:43] <vila> bug #833097
[18:37] <gdoubleu> I'm seeing odd behavior trying to push to an svn repo: I make a change, commit it, and the dpush.  A commit gets recorded in the svn repo but it is empty, and my working tree returns to the state prior to the commit (i.e. bzr st/diff shows the file/change I had previously committed).  Any ideas?
[18:38] <gdoubleu> this is with bzr 2.4.0 and bzr-svn 1.1.0dev
[18:38] <gdoubleu> I tried a fresh branch of the svn repo, but seeing the same behavior
[18:40] <jelmer> gdoubleu: this is bug 826946
[18:41] <gdoubleu> ah, I searched for push and missed this one
[18:41] <jelmer> gdoubleu: are you using http as well?>
[18:41] <gdoubleu> well, https
[18:43] <jelmer> this is actually the bug that is blocking the 1.1.0 release
[18:46] <gdoubleu> jelmer, is there a previous, working version of bzr-svn that's still compatible with bzr 2.4.0?
[18:53] <jelmer> gdoubleu: one of the earlier snapshots of lp:bzr-svn, but I'm not sure which one
[19:33] <gdoubleu> jelmer, fwiw using bzr-svn at revspec date:2011-07-01 works here
[19:55] <yofel> hey, is there are reason why bzr dailydeb substitutes {date} while fetching the source from bzr? Thanks to that it downloads the source every day I run it even if I already fetched the source already
[19:56] <jelmer> yofel: not sure I follow - if you don't want the date in there, why not use e.g. {revno} ?
[19:58] <yofel> jelmer: no, I want the date in there. What I wonder is why if I have '2+git{date}+r{revno}-{revno:packaging}' as version in the recipe. bzr dailydeb makes a stacked branch in like 'work/kdelibs-2+git20110824+r{revno}-{revno:packaging}' when building
[19:58] <yofel> why doesn't it leave {date} unsubstituted?
[19:59] <yofel> like that I need to fetch the branch every day
[19:59] <jelmer> yofel: it rebuilds if the version changes
[19:59] <jelmer> yofel: and the date changes every day :)
[20:00] <jelmer> it sounds like you want {revdate}, which is the latest bzr-builder that hasn't yet been deployed to lp
[20:00] <yofel> jelmer: this is running bzr builder by hand - not on launchpad
[20:00] <yofel> since I still need to upload some by hand
[20:00] <jelmer> https://bugs.launchpad.net/bzr-builder/+bug/793072
[20:01] <yofel> well, revdate would probably help - if it doesn't substitute it at branch time
[20:01] <jelmer> yofel: are you running 0.7.1?
[20:02] <yofel> hm, no, my server is on natty - so 0.6. Did that get fixed?
[20:04] <jelmer> yofel: no, {date} is still generated at branch construction time
[20:05] <jelmer> s/generated/expanded/
[20:05] <jelmer> yofel: on launchpad these directories always get discarded so it doesn't really matter
[20:06] <jelmer> yofel: you're welcome to file a bug, and I'll see how hard it is to fix
[20:06] <yofel> ok, I've got plenty of bandwidth myself, so it's not serious. Was just wondering why I have to download a few hundred MBs every day if I already have the branches on disk
[20:07] <jelmer> yofel: have you considered running it inside of a shared repository?
[20:08] <yofel> what's a shared repository? ^^
[20:09] <jelmer> yofel: http://wiki.bazaar.canonical.com/SharedRepositoryTutorial
[20:09] <yofel> k, thanks for the pointer
[22:31] <poolie> hi all
[22:32] <jelmer> poolie!
[22:33] <poolie> hi there
[22:41] <poolie> that is good news about mrevell