[00:04] <nacc> lol
[04:03] <SlidingHorn> where would I direct someone to ask about a possible SRU?  (see: bug in main regarding openssh)
[04:15] <guiverc> SlidingHorn, looking myself - #ubuntu-bugs comes to mind - mailing list maybe is https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad  - but is it appropriate??
[04:17] <SlidingHorn> Well, if I'm reading it correctly they patched it into Yakkety, but not Xenial yet
[04:17] <SlidingHorn> oh...wait.
[04:17]  * SlidingHorn sings alphabet to self
[04:17] <guiverc> i can't help (and i looked), mostly upstream & debian is all i saw re: xenial..  I'd ASSUME xenial is covered by debian versions mentioned; but I don't know
[05:06] <ducasse> good morning
[05:35] <lotuspsychje> good morning to all
[05:56] <lotuspsychje> uh oh nebi is in the house>...run
[06:10] <lordievader> Goos morning
[06:13] <lotuspsychje> heys lordievader
[06:14] <lordievader> Hey lotuspsychje How are you?
[06:14] <lotuspsychje> fine tnx happy almost weekend
[06:16] <lotuspsychje> you also have holiday on minday lordievader
[06:16] <lotuspsychje> *monday
[06:16] <lordievader> Long weekend :D
[06:16] <lotuspsychje> yess
[06:17] <lordievader> Yes
[06:17] <lotuspsychje> we have been to amsterdam last weekend
[06:17] <lordievader> Oh, how was it?
[06:18] <lotuspsychje> very nice, we had the best weather
[06:18] <lordievader> Yeah, the weather last week has been nice :)
[06:19] <lotuspsychje> we did van gogh museum, canal cruise, center town, shopping,bijenkorf
[06:19] <lotuspsychje> and lot of grachten :p
[06:19] <oerheks> That is where heineken is made of
[06:19] <oerheks> LoLz
[06:19] <lotuspsychje> lol
[06:20] <oerheks> and amsterdam has got famous cheese .. but i never see any cow
[06:20] <lotuspsychje> lol
[06:20] <oerheks> https://www.dropbox.com/s/jmdxyqo3197gvp6/2018ride.jpg?dl=0
[06:20] <lotuspsychje> lets c
[06:21] <lotuspsychje> oerheks: drabber split in 2?
[06:22] <oerheks> Drabber & Pien ( from mom)
[06:22] <lotuspsychje> ahhh
[06:22] <lotuspsychje> on your bakfiets.nl
[06:22] <lotuspsychje> we saw alot of those too
[06:48] <SlidingHorn> what is happening? xD
[06:51] <el> bugzie has spent the past hour making a mess in #freenode and then decided to return to #ubuntu to show off his aptitude at using vpns. it'll be messy for a while, it usually is with him.
[07:09] <SlidingHorn> not that it surprises me, but he was doing the same thing in #freenode?
[08:10] <EriC^^> morning all
[08:32] <lordievader> 👋
[11:55] <pauljw> Hi everyone
[13:01] <jink> Hi paul.
[13:07] <pauljw> hi jink :)
[13:12] <BluesKaj> Hi folks
[13:43] <pauljw> hi BluesKaj, biab... :)
[14:16] <leftyfb> gah, I did that once
[14:17] <leftyfb> at a place I worked, we had a box that we did EVERYTHING on. It was the sysadmin of boxes. I forget how, but I executed every line in the bash_history ... or at least started to
[14:17] <leftyfb> we didn't end up finding any consequences, but boy could that have been dangerous
[14:37] <pragmaticenigma> sounds like fun... I'm curios what 7.* actually removed
[15:20] <tgm4883> pragmaticenigma: just because there's a channel specifically for ubuntu-on-windows doesn't mean it's not supported in #ubuntu
[15:20] <tgm4883> just that there may be more users for that specific niche in that channel
[15:21] <pragmaticenigma> tgm4883: They were asked to change channels several times. It doesn't help a user to have multiple people tell them to move to another channel and then someone turns around and starts helping
[15:23] <tomreyn> tgm4883: are you saying that WSL should now be supported on #ubuntu? since that'd be new - so far the common POV seemed to be that it's not. but i think the ubottu factoid must have recently changed about it, too. i think it used to state that it's not supported.
[15:24] <tgm4883> pragmaticenigma: that happens all the time
[15:24] <tgm4883> tomreyn: I see no reason why it shouldn't be supported in #ubuntu
[15:24] <tgm4883> It's ubuntu branded and thus blessed (if not developed directly) by canonical
[15:24] <tomreyn> well, works about as reliable as nvidia on 18.04, i guess.
[15:24] <JimBuntu> I have no say really, but I view supporting WSDL in #ubuntu as worse than supporting non-English speaking in #ubuntu
[15:26] <JimBuntu> is WSDL covered under the listed versions in the topic? "supports Ubuntu and official flavors; versions 14.04, 16.04, 17.10, and 18.04 "
[15:26] <tomreyn> ok, i'm making things up about a recent change of the factoid: Last modified: 2017-10-18 14:59:12
[15:26] <tgm4883> JimBuntu: WSL is 16.04, so yes?
[15:26] <leftyfb> I think any server/dev activities with WSL should be supported within the OS. Any installation or hardware level or Windows integration issues should not be. WSL literally downloads the Ubuntu cloud image for the OS.
[15:27] <pragmaticenigma> My take is the cross over between doing some things with Windows and some things with WSL in CLI confusing to any new user who's actually on Ubuntu and comes to the room looking for help, and wondering why we are talking about Windows
[15:28] <leftyfb> !wsl > leftyfb
[15:28] <pragmaticenigma> If they had asked something that was easily accomplished with the WSL environment, I wouldn't have cared as much. But they didn't even know where the file was download or how to do a simple "cd" command. To me, better to move them to a more dedicated venue, then tie up others
[15:28] <JimBuntu> !wsl > JimBuntu
[15:28] <tomreyn> i remember that we had several situations where one of us spent a lot of time on trying to debug a weird issue with someonee. and then they said "oh btw. i'm using ubuntu on windows".
[15:28] <tgm4883> Literally the only thing they needed assistance with is where the C drive was mounted in Ubuntu
[15:29] <tgm4883> which would have been super simple to find out for us even for anyone not using WSL
[15:29] <JimBuntu> That seems official enough... coming from a ubot
[15:30] <leftyfb> tgm4883: that's the sort of thing I feel we shouldn't go out of our way to support since it's not an officially supported feature
[15:30] <tgm4883> leftyfb: how is it not an officially supported feature?
[15:30] <leftyfb> the problem is, when someone has a broken package like they did yesterday, which was easily fixed by someone that knows ubuntu, and they get sent to ##windows to help. How does that help anyone?
[15:31] <leftyfb> tgm4883: well, WSL seems to be lava for a lot of people here .... so something beyond what's found in a typical ubuntu server install I would assume would be where we draw the line
[15:32] <leftyfb> tgm4883: and since there's no host Windows drive mounted in a default install of ubuntu server ....
[15:32] <tgm4883> leftyfb: anything not a standard Ubuntu ISO install seems like lava for lots of people here...
[15:32] <leftyfb> again, I'd be happy to help with that regardless
[15:33] <tgm4883> leftyfb: with that regard, we stop supporting anything that isn't available in the live cd
[15:33] <leftyfb> and it's somewhat understandable in most cases .... but again, to send someone to #windows for help with a broken mysql-server install on ubuntu, that's just plain silly
[15:33] <tgm4883> leftyfb: omg, that actually happened?
[15:33] <leftyfb> yep
[15:33] <leftyfb> yesterday
[15:34] <pragmaticenigma> tgm4883: because there's a lot of bad information out there, and out dated information. Worst of all, these "helpful" articles ask users to install PPAs that include older packages that are properly maintained in the offical Ubuntu PPAs. It's a nightmare trying to untangle all that
[15:34] <tomreyn> personally i won't support WSL, because i think people should switch to linux (and that is what i want to support) and i think WSL is just another way to prevent them from doing so.
[15:34] <tgm4883> I swear I need banning powered for that reason
[15:34] <tgm4883> tomreyn: not supporting something for person reasons and sending someone away are different things
[15:35] <leftyfb> tgm4883: that wouldn't have been an easy ban for you. It was a regular who triggered !wsl which tells them to go to the channel with 9 people in it or #windows. Then we had someone from #windows come in and complain we sent someone there. I ended up helping the guy fix their packaging.
[15:35] <tomreyn> tgm4883: taht's right. so i should say that IMO #ubuntu should not support WSL, because microsoft does not support it either, nor does, to my knowledge, canonical.
[15:36] <tgm4883> tomreyn: so we only help with packages in main then?
[15:36] <leftyfb> Again, the install is just Ubuntu cloud image. I see no reason why it wouldn't be supported by Canonical.
[15:37] <tomreyn> tgm4883: with software you can install from an ubuntu OS (which in my understanding runs on the linux kernel), i'd say.
[15:37] <pragmaticenigma> tgm4883: That's what we have documentation for. That's why anything outside of that is treated like lava. Without some documentation, it's hard to know the  right questions to ask a user about what they did and how to correct it
[15:38] <pragmaticenigma> I can use the Ubuntu documentation much more readily than when someone comes in asking about how to run some program that I can't even access it's documentation because the company that made it is gone or hides the docuemntation behind a customer login
[15:38] <tgm4883> pragmaticenigma: as leftyfb has mentioned (twice), it *is* a Ubuntu install.
[15:39] <tomreyn> this may seem like a fierce discussion, but i think it's good to have it actually.
[15:39] <tgm4883> tomreyn: +1
[15:39] <leftyfb> +1
[15:40] <pragmaticenigma> And if they install packages that come from the repos that are offered by Canoncial, then that's great. But when they install PPAs that go and force updates on the user, that aren't part of the main ubuntu repos... we're stuck in limbo have not realzing that they have a kernel patch or library patch that is required by some other component that is expecting a now deprecated method or function
[15:41] <tgm4883> pragmaticenigma: when I say main. I mean "main", as in not "Universe", "Multiverse", or "Restricted"
[15:42] <tomreyn> i don't have a say in what will be supported in #uubntu and what not, but i if WSL will be supported then i won't be able to support anyone without asking "do you run WSL" anymore in the future. which adds to the questions of "so you actually run ubuntu?" and "do you run a non EOL release?",. and at some point people will need to fill a questionnaire before we can sart supporting them. ;-)
[15:42] <tgm4883> pragmaticenigma: as in, the only canonical supported repo (eg. I can purchase support and get help from canonical on this)
[15:42] <leftyfb> oh, I don't think we should limit those out. I really haven't ever seen an issue with a package because it was from universe or multiverse
[15:42] <pragmaticenigma> that's why I don't agree on supporting outside software. it's also in my experence that most of the outside software is stuff that the user is paying for support on, and they refuse to call the software vendors support line. Or the other fun one, when they come in and expect us to fix a problem they're getting paid to fix themselves
[15:42] <leftyfb> btw, inxi is from Universe and we suggest that all the time
[15:42] <tgm4883> leftyfb: you're right, we shouldn't. But that's kinda the point
[15:43] <pragmaticenigma> Universe, Mulitverse, Restricted are offered and maintained by Canoncial (at least that my knowledge) they're currated to ensure system compatibility. And they are also included by default, if only disabled by default
[15:44] <tgm4883> pragmaticenigma: yet they are not supported by Canonical
[15:44] <pragmaticenigma> tgm4883: Source of that information would be helpful for me
[15:44] <tgm4883> pragmaticenigma: you can't purchase support for packages in those, they don't get security updates
[15:44] <tgm4883> one sec
[15:44] <tgm4883> pragmaticenigma: https://help.ubuntu.com/community/Repositories/Ubuntu
[15:44] <tomreyn> there's the security team faq. but i think not everyone in canonical agrees to their strict interpretations.
[15:45] <tgm4883> Main - Canonical-supported free and open-source software.
[15:45] <tgm4883> Universe - Community-maintained free and open-source software.
[15:46] <tomreyn> https://wiki.ubuntu.com/SecurityTeam/FAQ
[15:46] <tgm4883> Or check the software sources app on any Ubuntu install. It says that right there
[15:48] <tgm4883> tomreyn: I don't see how that conflicts with anything that was said, other than main and restricted being supported by the security team
[15:48] <leftyfb> aren't we the community? :)
[15:48] <tgm4883> leftyfb: yes
[15:49] <leftyfb> I miss those LoCo days
[15:49] <tomreyn> tgm4883: i didn't mean to say it conflicts with anything that was said here.
[15:49] <tomreyn> tgm4883: is just posted the link as a second perspective on things
[15:50] <tgm4883> leftyfb: that's kinda the point. We (the community) already support many more things than are supported by canonical. WSL is a Ubuntu install, and as such should be supported in #ubuntu
[15:50] <leftyfb> I agree
[15:50] <leftyfb> to a point
[15:51] <leftyfb> asking how to install it, maybe just point at the docs
[15:51] <leftyfb> how to get Desktop working on it, no
[15:51] <pragmaticenigma> Thanks for the link tgm4883, I agree that it implies Canonical only handles main. I'm open to the others as was just said, we are the community. the community support repos are fine with me as well. I'll have to look up the requirements for a package to be added to Universe/Restricted ... as I think Canoncial does required a listing for a developer website
[15:51] <tgm4883> leftyfb: that sounds fine to me
[15:53] <tgm4883> pragmaticenigma: There are requirements, I don't believe they are from Canonical though (although it's likely that all the gate keepers for said repo are Canonical employees)
[15:53] <tgm4883> pragmaticenigma: they likely came from the technical board
[15:54] <tgm4883> https://wiki.ubuntu.com/TechnicalBoard
[15:54]  * tomreyn /invite donofrio #ubuntu
[15:58] <tomreyn> apparently i'm the only one who considered this funny. :-/
[15:59] <leftyfb> inside joke?
[16:00] <tomreyn> must be. donofrio was sharing his experience about running ubuntu on windows a lot, asked a lot of questions on it in #ubuntu, was repeatedly asked to ask them in the wsl channel instead, and then talked a lot to himself there.
[16:01] <tomreyn> so tgm4883 + leftyfb, if #ubuntu will take a softer stance wrt wsl then the factoid should maybe be updated...
[16:01] <tomreyn> or we just keep it as it is and just dont ask people to move there anymore
[16:02] <tgm4883> Does it need updated?
[16:02] <leftyfb> who makes the decision
[16:02] <tgm4883> !wsl
[16:02] <tgm4883> I think it looks fine
[16:03] <tomreyn> ## windows folks will probbal ynot appreciate it.
[16:03] <leftyfb> I feel ##windows shouldn't be lumped in with general support. That's false. #windows should only be used for installation and nothing else
[16:03] <leftyfb> Also, #ubuntu-on-windows is dead
[16:04] <tgm4883> leftyfb: I'd agree with that
[16:06] <pragmaticenigma> I'd agree to support WSL, so long as it's confied to the WSL environment. Like how to run a program/service ... that would easily traverse the Ubuntu/WSL environments. Like config files, package management, etc
[16:07] <leftyfb> bingo
[16:07] <pragmaticenigma> So in the case of NOOB... I'd go as far as helping them run the md5sum command
[16:07] <tgm4883> That seems reasonable
[16:07] <pragmaticenigma> but how to find the file they downloaded in windows... seems harder to explain...
[16:08] <pragmaticenigma> other than to offer them the "cd" command and letting them know that C: => /mnt/c
[16:08] <tgm4883> pragmaticenigma: that also seems reasonable
[16:08] <leftyfb> pragmaticenigma: rm -rf /mnt/c ? ;)
[16:08] <pragmaticenigma> lol
[16:08] <leftyfb> too soon? :)
[16:09] <pragmaticenigma> yeah... leftyfb need to burn the ISO first :-P
[16:09] <leftyfb> ah, right. good call
[16:10] <pragmaticenigma> Believe me when I say, I love to help others. Impatience is one shortcoming I don't handle well, and that honestly is why I was quick to deflect NOOB to the other channel.
[16:11] <pragmaticenigma> This conversation was great to have too... I come away with some better insight, and better ideas for how to continue being helpful, and keeping instep with everyone else
[16:12] <leftyfb> tgm4883: so again, who makes the decisions on how #ubuntu is operated? I'm all for coming away from this conversation being more helpful, but there's the possibility of upsetting others who feel we shouldn't touch WSL with a 10ft pole
[16:15] <tgm4883> leftyfb: IDK, previously I've asked in #ubuntu-ops
[16:16] <leftyfb> ok, so while this conversation was productive, at least with the few of us in agreement, it doesn't make much of a difference unless we get official buy-in from the appropriate parties
[17:17] <oerheks> i like spring
[17:17] <oerheks> .. Win10 spring Update screwed up Grub. https://www.reddit.com/r/Ubuntu/comments/8ke0vq/win10_spring_update_screwed_up_grub/
[17:19] <pragmaticenigma> screwed up? nah, I'm guessing MS made a change to their bootloader and didn't bother to check what was written to the MBR
[17:22] <pragmaticenigma> oerheks: claim is UEFI installs are fine though... odd
[17:28] <tomreyn> obviously, windows is a monotheistic religion
[17:30] <pragmaticenigma> what a pane it is too
[17:30]  * pragmaticenigma smirks
[17:31] <tomreyn> :))
[17:47] <ducasse> coming in late to this discussion, but would it be fine to answer a request for help with wsl with "sorry, i can't/won't support that, please hang around and see if someone else can"?
[17:48]  * ducasse is one of the 10ft pole crowd
[17:51] <JimBuntu> I would wait until they start being impatient, otherwise, !patience
[17:54] <ducasse> it's just that i often find myself alone for a while in #ubuntu in the mornings, was just wondering how to handle a wsl user
[17:54] <ducasse> btw, hi JimBuntu :)
[17:54] <JimBuntu> Hey there ducasse. I was surprised by the discussion. A lot to learn from it for me.
[17:56] <ducasse> yep, but i basically want nothing to do with an environment i've never even seen irl. i get that it's ubuntu in a way, but not enough for me :)
[17:57] <leftyfb> it's not "in a way" .. it IS ubuntu
[17:57] <leftyfb> it's the Ubuntu cloud image, same thing they put on all of AWS and what MAAS uses to deploy with
[17:57] <oerheks> not the desktop, but the core..
[17:57] <leftyfb> ducasse: why not help with just the OS part of it if you can? If there's a package or permission problem or the like
[17:57] <leftyfb> right
[17:57] <leftyfb> there's no desktop stuff supported on it
[17:59] <ducasse> leftyfb: possibly, but if things start getting weird i'm dropping it and walking away
[17:59] <ducasse> as in, it doesn't behave like a standard install on a linux kernel would
[18:13] <tgm4883> ducasse: I think that sounds fine, provided that was an actual issue. I would have a problem with saying "I'm not supporting you because you use WSL"
[18:57] <tomreyn> well, i may choose to say so. nothing anyone can do about my preferences. and an individual choosing not to support $something is not against the channel policies, afaik
[18:58] <leftyfb> tomreyn: sure, but there's no reason to answer with the fact that you won't support it. Just let someone else take care of it.
[19:00] <tomreyn> what is the reason not to asnwer that i won't support it then?
[19:01] <tomreyn> i mean, either seems fine to me, unless i'd build a political disucssion around it, which wouldn't beloing to #ubuntu
[19:01] <leftyfb> answering with "I won't help you" helps nobody
[19:02] <tomreyn> right, but answering "I cannot help you with WSL since I don't like to support it", this could help soemone.
[19:02] <tomreyn> that's how i do it for nvidia drivers
[19:03] <leftyfb> how does that help anyone?
[19:03] <leftyfb> it's pretty negative
[19:04] <tomreyn> hmm you think so? i just consider it a statement, an explanation, not negative it all, since it's not personally addressing the user.
[19:05] <SlidingHorn> what differences are there in a WSL ubuntu vs a normal installation?
[19:05] <tomreyn> i think this helps someone in terms of making them wonder whether their choices are good.
[19:05] <leftyfb> SlidingHorn: it's not running the linux kernel. Other than that, none
[19:05] <leftyfb> tomreyn: so the whole purpose is to impose your opinion of a product on the one asking for help with it without providing any help
[19:07] <tomreyn> leftyfb: no, the main purpose would be to at least respond something, explaining why they're not getting any help. i'd just do that if there was no one else responding.
[19:07] <leftyfb> IMO, things like that are best kept to yourself. I'm sure the person asking for help is well aware there are people in existence that do not like/prefer the product they're looking for help with and don't really care to hear there is yet another one right in front of them not willing to help them
[19:08] <tomreyn> you know it happens that people come ot the channel and ask rather specific questions about functionality which no one is really into, or no one likes to support. i think in those situations it's better to provide an explanation to the one asking than not to respond at all.
[19:08] <tomreyn> since people will just feel left out, being ignored.
[19:09] <tomreyn> and i don't like *this* to happen.
[19:09] <leftyfb> I don't see why there's all this hatred towards WSL. I think it's a great gateway solution to getting people to switch. At the very least, someone never switches completely but instead develops linux solutions for the rest of us on their windows machine.
[19:10] <leftyfb> it's a lot better than just ignoring Windows users completely
[19:10] <leftyfb> since they do make up the biggest market for us
[19:11] <tomreyn> i'm just an ubuntu user, i dont have a market. ;)
[19:11] <leftyfb> the community does
[19:14] <tomreyn> let's be positive: let's see how we get along and if you get annoyed or just think i'm doing things wrong you are welcome to point it out.
[19:18] <pragmaticenigma> I would start encouraging WSL helpees to join #ubuntu-on-windows either way... just to help build up that community too
[19:19] <leftyfb> That's not a bad idea. But we'll have to convey the idea that at the moment there's not much of a community
[19:20] <nacc> leftyfb: afaict, no one does what you're suggesting. m$ wants people to use powershell and all that stuff
[19:21] <nacc> leftyfb: but i agree with your sentiment, in principle, that if someone has an ubuntu issue, then it can be resolved in #ubuntu.
[19:21] <nacc> leftyfb: however, the moment they get to something related to the kernel, say, they are in potentially unsupported territory
[19:21] <oerheks> sudo apt install wsl-desktop ... err ... https://github.com/QMonkey/wsl-tutorial
[19:21] <nacc> as I don't believe WSL is virtualizing the cloud image properly, but I genuinely don't know
[19:21] <leftyfb> nacc: in the past 2 days, there's been exactly 2 cases of people using it for docker and to actually verify an ubuntu ISO. Neither of those have anything to do with powershell and one was actually moving to ubuntu
[19:22] <pragmaticenigma> It's not... in fact the number of hoops to enable it right now should tell the average user to just not do it
[19:22] <nacc> leftyfb: the only user who asked about wsl over the past year consistently had bastardized a desktop and requested helper repeatedly for it
[19:22] <leftyfb> nacc: I agree with not supporting the kernel part and anything not having to do with Ubuntu
[19:22] <nacc> (donofrio)
[19:23] <leftyfb> that's a bad example and one that I would agree with not supporting
[19:23] <nacc> the issue will be they will see you supporting something else and will complain (IMO)
[19:23] <nacc> but that's up to the community to resolve anyways
[19:23] <leftyfb> right
[19:24] <leftyfb> and no, it's not virtualizing the cloud image at all. It IS the cloud image running on a "linux compatible kernel interface"
[19:24] <pragmaticenigma> yeah, that is the slippery slope of this ... you cave and help one, then everyone expects the same treatment... rules or otherwise
[19:24] <leftyfb> the kernel is the only thing that's modified from the cloud image
[19:25] <leftyfb> pragmaticenigma: that can easily be managed. Just gotta define what is supported
[19:25] <leftyfb> I would say, anything within the cloud image environment, mainly userland
[19:25] <leftyfb> no installation or kernel level stuff. Certainly nothing desktop/GUI related
[19:26] <leftyfb> networking is fine as long as it's within the OS and nothing to do with whatever layers M$ is providing for it
[19:26] <leftyfb> I would even say, if the image has an ip, that's the end of networking support
[19:35] <leftyfb> it's gonna be great if that was the recovery partition for Windows lol
[19:36] <leftyfb> "hey guys, weird question, but i need to figure out what this 732 MB (windows units) partition is on my drive, from windows" I read this differently
[19:42] <daftykins> sounds like you need a tinfoil hat at the ready for that one
[19:53] <JimBuntu> as I did. I was like "windows" has it's own "units"
[20:08] <SlidingHorn> lol leftyfb


[07:51] <mup> PR snapcraft#4045 opened: Fix typo from 'unkown' to 'unknown' <Created by AristoChen> <https://github.com/snapcore/snapcraft/pull/4045>
[09:48] <mup> PR snapd#12574 closed: o/snapstate: pre-download and monitor snap for auto-refresh <Pulse> <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12574>
[10:58] <mup> PR snapd#12495 closed: o/snapstate: pre-download snaps (WIP) <Created by MiguelPires> <Closed by MiguelPires> <https://github.com/snapcore/snapd/pull/12495>
[10:58] <mup> PR snapd#12602 opened: o/snapstate: notify and monitor snap if hard check fails <Pulse> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12602>
[12:19] <mup> PR snapd#12603 opened: image,tests: add snap architecture check against model architecture for prepare-image <Created by Meulengracht> <https://github.com/snapcore/snapd/pull/12603>
[12:59] <mup> PR snapd#12601 closed: build(deps): bump golang.org/x/net from 0.0.0-20220826154423-83b083e8dc8b to 0.7.0 <dependencies> <Created by dependabot[bot]> <Closed by MiguelPires> <https://github.com/snapcore/snapd/pull/12601>
[14:49] <mup> PR snapd#12592 closed: boot: introduce parameter for optional kernel command line <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12592>
[15:16] <mup> PR snapcraft#4045 closed: Fix typo from 'unkown' to 'unknown' <Created by AristoChen> <Merged by mr-cal> <https://github.com/snapcore/snapcraft/pull/4045>
[17:30] <mup> PR snapd#12604 opened: desktop-legacy, unity7: Support for indicators activation tokens <Created by 3v1n0> <https://github.com/snapcore/snapd/pull/12604>
[19:06] <mup> PR snapd#12602 closed: o/snapstate: notify and monitor snap if hard check fails <Pulse> <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12602>
[19:11] <mup> PR snapd#12605 opened: o/configcore: add flag that will determine if a system option can be <Needs Documentation -auto-> <Run Nested -auto-> <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/12605>


[07:51] <nikolam> Hi, I have a problem recently on 22.04, on some apps I can not open folder using Ctrl+L to enter path into requester to give it to the app like in app settings.
[07:51] <nikolam> I put path wih Ctrl+L but it does not open it, 'Select' button is greyed out.
[07:53] <nikolam> When I select the path manually, clicking in requester on parent path and selecting folder manually, then it works, but not after filling path with Ctrl+L


[00:02] -kubuntu-ci:#kubuntu-devel- Project merger_kbruch build #926: FAILURE in 1 min 37 sec: https://kci.pangea.pub/job/merger_kbruch/926/
[00:02] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:02] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_messagelib build #265: FIXED in 23 min: https://kci.pangea.pub/job/artful_unstable_messagelib/265/
[00:10] -kubuntu-ci:#kubuntu-devel- Project mgmt_merger build #992: UNSTABLE in 10 min: https://kci.pangea.pub/job/mgmt_merger/992/
[00:10] -kubuntu-ci:#kubuntu-devel- Project mgmt_progenitor build #971: UNSTABLE in 10 min: https://kci.pangea.pub/job/mgmt_progenitor/971/
[00:11] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[00:11] -kubuntu-ci:#kubuntu-devel- Project artful_stable_pimcommon build #127: FIXED in 16 min: https://kci.pangea.pub/job/artful_stable_pimcommon/127/
[00:45] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_palapeli build #9: STILL UNSTABLE in 34 min: https://kci.pangea.pub/job/bionic_unstable_palapeli/9/
[00:46] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_trojita build #9: STILL UNSTABLE in 35 min: https://kci.pangea.pub/job/bionic_unstable_trojita/9/
[01:00] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_falkon build #10: STILL UNSTABLE in 48 min: https://kci.pangea.pub/job/bionic_unstable_falkon/10/
[01:00] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_sddm build #9: STILL UNSTABLE in 49 min: https://kci.pangea.pub/job/bionic_unstable_sddm/9/
[01:00] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_elisa build #9: STILL UNSTABLE in 49 min: https://kci.pangea.pub/job/bionic_unstable_elisa/9/
[01:01] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kalzium build #9: STILL UNSTABLE in 49 min: https://kci.pangea.pub/job/bionic_unstable_kalzium/9/
[01:13] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_ktp-desktop-applets build #9: STILL UNSTABLE in 1 hr 1 min: https://kci.pangea.pub/job/bionic_stable_ktp-desktop-applets/9/
[01:14] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_ark build #11: STILL UNSTABLE in 1 hr 3 min: https://kci.pangea.pub/job/bionic_stable_ark/11/
[01:15] -kubuntu-ci:#kubuntu-devel- Project bionic_stable_kstars build #11: STILL UNSTABLE in 1 hr 3 min: https://kci.pangea.pub/job/bionic_stable_kstars/11/
[01:18] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ksirk build #9: STILL UNSTABLE in 1 hr 6 min: https://kci.pangea.pub/job/bionic_unstable_ksirk/9/
[01:18] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_sddm build #59: STILL UNSTABLE in 35 min: https://kci.pangea.pub/job/artful_unstable_sddm/59/
[01:18] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_k3b build #11: STILL UNSTABLE in 1 hr 6 min: https://kci.pangea.pub/job/bionic_unstable_k3b/11/
[01:18] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kolf build #9: STILL UNSTABLE in 1 hr 7 min: https://kci.pangea.pub/job/bionic_unstable_kolf/9/
[01:18] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_ark build #9: STILL UNSTABLE in 1 hr 7 min: https://kci.pangea.pub/job/bionic_unstable_ark/9/
[01:23] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmix build #67: FAILURE in 25 min: https://kci.pangea.pub/job/artful_unstable_kmix/67/
[01:33] -kubuntu-ci:#kubuntu-devel- Project artful_stable_cantor build #59: STILL UNSTABLE in 49 min: https://kci.pangea.pub/job/artful_stable_cantor/59/
[01:34] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmix build #68: STILL FAILING in 6 min 8 sec: https://kci.pangea.pub/job/artful_unstable_kmix/68/
[01:37] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kphotoalbum build #12: STILL UNSTABLE in 37 min: https://kci.pangea.pub/job/bionic_unstable_kphotoalbum/12/
[01:38] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_ark build #164: STILL UNSTABLE in 40 min: https://kci.pangea.pub/job/artful_unstable_ark/164/
[01:38] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_kstars build #9: STILL UNSTABLE in 1 hr 26 min: https://kci.pangea.pub/job/bionic_unstable_kstars/9/
[01:38] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kstars build #212: STILL UNSTABLE in 52 min: https://kci.pangea.pub/job/artful_unstable_kstars/212/
[01:38] -kubuntu-ci:#kubuntu-devel- Project bionic_unstable_cantor build #9: STILL UNSTABLE in 40 min: https://kci.pangea.pub/job/bionic_unstable_cantor/9/
[01:38] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_k3b build #155: STILL UNSTABLE in 54 min: https://kci.pangea.pub/job/artful_unstable_k3b/155/
[01:53] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_ksirk build #76: STILL UNSTABLE in 35 min: https://kci.pangea.pub/job/artful_unstable_ksirk/76/
[01:54] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_palapeli build #123: STILL UNSTABLE in 36 min: https://kci.pangea.pub/job/artful_unstable_palapeli/123/
[02:07] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_elisa build #146: STILL UNSTABLE in 28 min: https://kci.pangea.pub/job/artful_unstable_elisa/146/
[02:07] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kphotoalbum build #144: STILL UNSTABLE in 29 min: https://kci.pangea.pub/job/artful_unstable_kphotoalbum/144/
[02:33] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:33] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kdepim-apps-libs build #83: FIXED in 26 min: https://kci.pangea.pub/job/artful_stable_kdepim-apps-libs/83/
[02:56] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[02:56] -kubuntu-ci:#kubuntu-devel- Project artful_stable_eventviews build #106: FIXED in 23 min: https://kci.pangea.pub/job/artful_stable_eventviews/106/
[04:07] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[04:07] -kubuntu-ci:#kubuntu-devel- Project artful_stable_calendarsupport build #98: FIXED in 18 min: https://kci.pangea.pub/job/artful_stable_calendarsupport/98/
[04:37] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[04:37] -kubuntu-ci:#kubuntu-devel- Project artful_stable_akonadi build #163: FIXED in 30 min: https://kci.pangea.pub/job/artful_stable_akonadi/163/
[04:39] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[04:39] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kunitconversion build #110: FIXED in 22 min: https://kci.pangea.pub/job/artful_unstable_kunitconversion/110/
[09:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1889: SUCCESS in 1 min 3 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1889/
[09:46] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1889: SUCCESS in 1 min 7 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1889/
[09:49] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1889: SUCCESS in 3 min 46 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1889/
[10:57] <BluesKaj> Hi folks
[11:55] <acheronuk> !testers
[11:56] <acheronuk> please test plasma 5.11.3 for artful in backports-landing
[11:56] <acheronuk> seems good here so far :)
[11:57] <BluesKaj> acheronuk, ok, will give 5.11.3 a shot
[12:02] <soee> :D
[12:06] <mamarley> acheronuk: I've been running it since yesterday.  It works great!
[12:06] <acheronuk> mamarley: same here :)
[12:19] <BluesKaj> yup, seems ok so far
[12:19] <BluesKaj> haven't rebooted yet tho
[12:26] <BluesKaj> plasma 5.11.3 seems fine so far
[14:35] <clivejo> grrrr
[14:35] <clivejo> kmail is broken again!
[14:41] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmail build #207: STILL FAILING in 5 min 3 sec: https://kci.pangea.pub/job/artful_unstable_kmail/207/
[14:41] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-pa build #103: STILL FAILING in 5 min 20 sec: https://kci.pangea.pub/job/artful_stable_plasma-pa/103/
[14:42] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmix build #69: STILL FAILING in 5 min 57 sec: https://kci.pangea.pub/job/artful_unstable_kmix/69/
[14:42] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_plasma-pa build #177: STILL FAILING in 5 min 55 sec: https://kci.pangea.pub/job/artful_unstable_plasma-pa/177/
[14:42] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmail build #95: STILL FAILING in 6 min 4 sec: https://kci.pangea.pub/job/artful_stable_kmail/95/
[14:44] <blaze> why?
[14:45] <clivejo> no idea!
[14:45] <clivejo> kmail being kmail I guess
[14:47] <blaze> No rule to make target 'src/org.kde.kmail.kmail.xml', needed by 'src/kontactplugin/kmail/kmailinterface.cpp'.  Stop
[14:47] <blaze> how come?
[14:48] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-desktop build #169: STILL FAILING in 12 min: https://kci.pangea.pub/job/artful_stable_plasma-desktop/169/
[14:48] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_plasma-desktop build #172: STILL FAILING in 12 min: https://kci.pangea.pub/job/artful_unstable_plasma-desktop/172/
[14:49] <clivejo> There is an email on release ML about it
[14:49] <clivejo> version of CMake or something
[14:50] <blaze> ah, custom cmake modules
[14:50] <clivejo> https://bugs.kde.org/show_bug.cgi?id=382809
[14:51] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_plasma-pa build #178: STILL FAILING in 3 min 39 sec: https://kci.pangea.pub/job/artful_unstable_plasma-pa/178/
[14:51] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-pa build #104: STILL FAILING in 4 min 35 sec: https://kci.pangea.pub/job/artful_stable_plasma-pa/104/
[14:52] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmail build #208: STILL FAILING in 5 min 39 sec: https://kci.pangea.pub/job/artful_unstable_kmail/208/
[14:52] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmail build #96: STILL FAILING in 4 min 44 sec: https://kci.pangea.pub/job/artful_stable_kmail/96/
[14:52] <clivejo> maybe it's time to upgrade my dinosaur of a system
[14:52] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_kmix build #70: STILL FAILING in 5 min 40 sec: https://kci.pangea.pub/job/artful_unstable_kmix/70/
[14:54] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[14:54] -kubuntu-ci:#kubuntu-devel- Project artful_stable_oxygen build #93: FIXED in 18 min: https://kci.pangea.pub/job/artful_stable_oxygen/93/
[14:54] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[14:54] -kubuntu-ci:#kubuntu-devel- Project artful_stable_khotkeys build #81: FIXED in 18 min: https://kci.pangea.pub/job/artful_stable_khotkeys/81/
[14:55] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[14:55] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kdeplasma-addons build #141: FIXED in 19 min: https://kci.pangea.pub/job/artful_stable_kdeplasma-addons/141/
[14:58] <mparillo> Smooth upgrade to Plasma 5.11.3. I used Discover to add back the checkmark to backports-landing, and smoothly upgraded. Then re-booted my VM and briefly tested successfully: Kinfocenter from krunner, and Dolphin, kate, System Monitor, System Settings, from the kicker Application Launcher.
[14:58] <mparillo> One brief artifact of a grey line, and when hovering over the Dolphin item in my panel, the pop-up was huge, but I could not reliably replicate either.
[15:03] <BluesKaj> mparillo, krunner no longer launches anything here and hasn't since 17.04
[15:04] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_plasma-desktop build #173: STILL FAILING in 10 min: https://kci.pangea.pub/job/artful_unstable_plasma-desktop/173/
[15:05] <BluesKaj> had to install root actions in dolphin services to edit files with root permissions
[15:11] -kubuntu-ci:#kubuntu-devel- Project artful_stable_plasma-desktop build #170: STILL FAILING in 17 min: https://kci.pangea.pub/job/artful_stable_plasma-desktop/170/
[15:14] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[15:14] -kubuntu-ci:#kubuntu-devel- Project artful_stable_kmenuedit build #116: FIXED in 19 min: https://kci.pangea.pub/job/artful_stable_kmenuedit/116/
[15:14] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_amarok build #29: STILL FAILING in 38 min: https://kci.pangea.pub/job/artful_unstable_amarok/29/
 @CliffordTheBigRedDoggie feel free to revert my last kmail commit if you want it to build ok on artful still
 In the middle of updating!
 to late then!
[15:34] -kubuntu-ci:#kubuntu-devel- Yippee, build fixed!
[15:34] -kubuntu-ci:#kubuntu-devel- Project artful_stable_powerdevil build #126: FIXED in 58 min: https://kci.pangea.pub/job/artful_stable_powerdevil/126/
 Yup
 Bionic beavers for me
[16:14] -kubuntu-ci:#kubuntu-devel- Project artful_unstable_amarok build #30: STILL FAILING in 55 min: https://kci.pangea.pub/job/artful_unstable_amarok/30/
[16:15] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » linode-01 build #1890: SUCCESS in 56 sec: https://kci.pangea.pub/job/mgmt_docker/label=linode-01/1890/
[16:15] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » master build #1890: SUCCESS in 1 min 1 sec: https://kci.pangea.pub/job/mgmt_docker/label=master/1890/
[16:18] <mparillo> BluesKaj: You mean alt-F2 does not invoke krunner, or when you start typing into krunner, and pick something (say kinfocenter), nothing happens?
[16:18] -kubuntu-ci:#kubuntu-devel- Project mgmt_docker » swy-01 build #1890: SUCCESS in 3 min 47 sec: https://kci.pangea.pub/job/mgmt_docker/label=swy-01/1890/
 Plasma 5.11.3 working fine here on Intel hw.
[16:49] <BluesKaj> Darin Miller does krunner launch files or apps on your system
[16:49] <BluesKaj> ?
[18:42] <acheronuk> BluesKaj: does on mine
[18:43] <clivejo> works on mine too
[20:03] <clivejo> acheronuk: is akonadi broken on KCI?
 no idea
[20:04] <clivejo> says Akonadia PIM service is not operational
[20:05] <clivejo> has a lovely "Details" button which does F all
 still have no idea why you try to use PIM from unstable 🙄
 I'm amazed it ever works
[20:07] <clivejo> humm
[20:07] <clivejo> db issues
[20:07] <clivejo> seems to be from I installed mysql server to try and get amarok working
[20:08] <mamarley> The dependency on MySQL is the primary reason I don't use Akonadi-based stuff or Amarok anymore.  That's what SQLite is for.
[20:30] <clivejo> grrrr
[20:30]  * clivejo kicks akonadi
[22:14] <clivejo> grrr
[22:14] <clivejo> finally got it to load
[22:35] <valorie> I'm happy to report that the latest Falkon is exceeding my expectations
[22:35] <valorie> working with myheritage site, which chrome and chromium both refuse to do
[22:35] <valorie> it might replace FF for me, at least
[22:53] <clivejo> valorie: its so fast!
[22:53] <clivejo> I can't believe how fast it is compared to other browsers
[22:54] <valorie> the scaling is a bit large for me, but I'm getting used to it
[22:55] <clivejo> do you know when there will be a release?
[23:01] <valorie> nope, have heard nothing
[23:01] <valorie> I'm using your PPA
[23:01] <valorie> <3
[23:09] <clivejo> I've upgraded to Bionic
[23:09] <clivejo> I'm mad!!
[23:09] <clivejo> mad I tell ya
[23:13] <valorie> \o/
[23:13] <valorie> so far, so good?
[23:13] <clivejo> no big changes that I can see
[23:15] <valorie> well, there is some stuff under the hood, from what I've been seeing in u-release
 @BluesKaj, Yes krunner is working fine. But I have seen quirky behavior with krunner recently but it seems to resolve itself.
[23:59] <clivejo> grrrr
[23:59] <clivejo> can't setup Kolab account in kmail


[00:00] <jelmer> lifeless: I think it comes down to two things: in order to do branch management when using a lightweight checkout you have to change directories (since the branches are in a different location, you have to "cd ../branches && bzr branch branch-foo branch-bar && cd ../wt && bzr switch branch-bar" and "bzr switch" is too slow
[00:00] <lifeless> jelmer: ok
[00:01] <lifeless> so the former - heres what I do
[00:01] <lifeless> bzr init-repo --no-trees proj
[00:01] <lifeless> cd proj
[00:01] <lifeless> bzr branch/init trunk
[00:01] <lifeless> bzr checkout --lightweight trunk working
[00:01] <lifeless> ln -s $(pwd)/working ~/.bazaar/plugins/proj
[00:02] <SamB> hmm, isn't there a "bzr switch -b" or something lately added?
[00:02] <lifeless> SamB: yes
[00:02] <lifeless> today though, I use
[00:02] <lifeless> bzr push ../new-branch; bzr switch new-branch
[00:03] <lifeless> so its not ideal, but it is pretty easy
[00:03] <SamB> not bad
[00:03] <jelmer> lifeless: ah, I hadn't considered "bzr push"
[00:03] <lifeless> jelmer: well, can also spell 'bzr branch . ../new-branch'
[00:03] <lifeless> or bzr branch ../trunk ../new-branch, if I want to be absolutely sure about provenance
[00:04] <jelmer> lifeless: but (now that we're talking about UI) I still consider this a big hassle compared to colocated branches
[00:04] <lifeless> jelmer: switch _should_ be very fast. please file bugs if its slow
[00:05] <lifeless> jelmer: typing .bzr/branches/new-branch would be equally awkward, I should think.
[00:05] <lifeless> jelmer: I think the big UI win of colocated branches isn't the colocation, its the search-path and location glue
[00:05] <lifeless> this isn't to say I don't like colocated branches/git style branches; just that I'm trying to really understand what makes things good
[00:06] <jelmer> lifeless: yeah, perhaps git style branches is a better description than colocated branches.
[00:07] <jelmer> lifeless: the setup you did is nontrivial (more than one command)
[00:07] <jelmer> lifeless: and the combined action of creating and switching to a new branch is more than one command
[00:07] <lifeless> so, we're trying to plan a better UI before making many random changes
[00:08] <lifeless> jelmer: but have you seen jam's switch -b feature?
[00:09] <jelmer> lifeless: it breaks looms :-/
[00:10] <SamB> lifeless: please contribute any tips to GitStyleBranches ;-)
[00:10] <jelmer> lifeless: but no, I hadn't. That does indeed make the second bit easier
[00:11] <lifeless> jelmer: I'll fix looms up monday
[00:11] <lifeless> I wonder if perhaps it should be in switch --new or something
[00:12] <jelmer> lifeless: Yeah, --new would probably be more intuitive to new users
[00:12] <lifeless> did it get into 1.17?
[00:12] <jelmer> lifeless: -b does remind me of the git argument, but other than that it doesn't make much sense
[00:12] <jelmer> lifeless: as far as I can tell it's only in  bzr.dev
[00:13] <jelmer> lifeless: it's not in rc1 at least
[00:15] <SamB> jelmer: well, the long name can be meaningful
[00:16] <SamB> short names are often pretty crazy, so probably won't bother people
[00:19] <lifeless> I don't think thats a good reason to use a crazy short option
[00:20] <SamB> well, it's not quite crazy either ...
[00:20] <SamB> it actually *does* do a "bzr branch" under the covers, doesn't it?
[00:20] <lifeless> bzr branch?
[00:20] <lifeless> yes
[00:21] <SamB> so how is -b a crazy short name for the flag?
[00:21] <lifeless>      branch --branch
[00:21] <lifeless> would be the long version, if -b stands for branch
[00:21] <SamB> eh?
[00:22] <SamB> I thought it was "switch" we were talking about, sorry
[00:22] <lifeless> for switch I proposed --new
[00:22] <lifeless> in a loom you probably want a new thread
[00:22] <lifeless> in a pipeline a new pipe at the current place {like looms}
[01:11] <SamB> who should I talk to about bzr-fastimport?
[01:17] <jelmer> SamB: ianc
[01:23] <SamB> hmm, is there some command-line equivalent of BZR_PDB=1 ?
[01:29] <bob2> jelmer: yes, branching into a dir inside a git repo
[01:33] <jelmer> SamB: not that I'm aware of
[01:34] <SamB> 'twould be useful for running bzr under gud, I think
[01:34] <jelmer> bob2: that's the equivalent of trying to push from bzr into git, which doesn't work yet
[01:34] <jelmer> SamB: gud?
[01:34] <SamB> jelmer: basically, s/gud/emacs/
[01:35] <SamB> gud is the bit that integrates debuggers into the UI
[01:35] <SamB> so, like, you'd see stuff in the left margin
[01:47] <bob2> jelmer: cd gitmanageddir/something/somethingelse ; bzr co /brbranch ?
[02:08] <lifeless> SamB: what do you mean command-line equivalent?
[02:15] <SamB> lifeless: I mean, an argument
[02:15] <SamB> that is, a flag
[02:15] <lifeless> no
[02:16] <SamB> for some reason M-x pdb doesn't like it if I enter an environment-variable setting before the command to run :-(
[03:04] <mtaylor> lifeless: question on MOTU process...
[03:04] <mtaylor> lifeless: there are two different processes, one for packages that are in ubuntu already, and one for ones that aren't... do packages that are auto-imported from debian but have no truly ubuntu specific package count as the former or the later?
[03:17] <lifeless> uhm
[03:18] <lifeless> there aren't really two processes
[03:18] <lifeless> or I don't know what you mean
[03:18] <lifeless> are you talking about new packages, or changes to an existing package
[03:32] <mtaylor> lifeless: well, that's the question - if the package is in but only via automatic debian import, and I want to upload a version to ubuntu - does that count as changes to an existing package, or as a new package?
[03:32] <lifeless> its a change to an existing package
[03:33] <mtaylor> ok
[03:33] <lifeless> but the process is the same
[03:33] <lifeless> which is why I don't really know what you mean
[03:33] <mtaylor> so - there was this place that said changes to existing packages shouldn't use revu, but instead should attach debdiffs to bug reports against the package
[03:35] <mtaylor> lifeless: https://wiki.ubuntu.com/SponsorshipProcess ... linked to from https://wiki.ubuntu.com/MOTU/Packages/REVU
[03:36] <lifeless> ok
[03:37] <lifeless> so uhm, I guess thts a different process
[03:37] <lifeless> but the basics: review the delta, universe-sponsors-queue, upload, are the same
[03:37] <lifeless> regardless of new package or change to existing
[03:37] <mtaylor> sure...
[03:38] <mtaylor> but my process to request review as an external-n00b-luser is quite different
[03:38] <lifeless> and in fact, REVU is meant to be replaced by lp code reviews eventually ;)
[03:38] <mtaylor> k
[05:39] <SamB> jelmer: nice, that subunit you uploaded actually works ;-)
[05:39] <SamB> I mean, not only can I use it, but dpkg stops uselessly trying to compile the code for Python 2.3 and is now *aware* that it works ;-)
[05:40] <SamB> (oddly enough, I could actually use it even before that :-)
[06:05] <jml> jelmer, http://code.mumak.net/2009/07/unittest-it-aint-broke-lets-fix-it.html
[08:10] <mrooney> Anyone know how to use the bzr pager plugin?
[08:10] <mrooney> I figured I could just install it and then a command like "bzr cdiff" would just do the right thing and go to less with more than a screen of output
[08:10] <mrooney> But apparently that isn't right.
[10:22] <Jesse1> hi
[10:22] <jelmer> hi jml
[10:22] <jelmer> hi Jesse1 I mean :-)
[10:22] <jml> jelmer, hello :)
[10:22] <jml> I'll take your greeting as it stands.
[10:22] <Jesse1> i'm new to irc
[10:22] <Jesse1> and bzr
[10:23] <Jesse1> i'm thinking of using bzr to track wikipedia entries
[10:23] <Jesse1> so as to reduce the load on wikipedia servers
[10:23] <Jesse1> but i don't know how i can manipulate the revision ids a la bzr-svn
[10:25] <Jesse1> i'm not a registered freenode user, so i'm not sure if what i said was heard at all...
[10:25] <ndurner> We hear you :-)
[10:26] <Jesse1> sweet
[10:27] <Jesse1> as i understand, bzr-svn does the rev-id manipulation at SvnBranch level, so branching from a svn repo already gets the cooked rev-id's
[10:28] <Jesse1> but what i want to do doesn't sound as complicated as that
[10:29] <Jesse1> s/what/what if/
[10:29] <Jesse1> ouch that was wrong
[10:30] <Jesse1> so i'm thinking if i can generate revision ids for wikipedia entries e.w.o/w/foo&oldid=1234
[10:30] <Jesse1> as en.wikipedia.org-foo:1234
[10:30] <Jesse1> and stuff such a revision in the repo?
[10:31] <jelmer> Jesse1: yes, but you'll probably have to do the same sort of thing as bzr-svn to do so
[10:31] <Jesse1> they subclassed bzrlib.branch.Branch
[10:31] <Jesse1> wait, "they" is actually you
[10:32] <jelmer> Jesse1: alternatively, you could create a Python script that just does an import from wikipedia into a bzr branch
[10:32] <Jesse1> a silly etiquette question: shall i prefix my messages with the intended recipient?
[10:32] <Jesse1> and how do i massage the revision ids?
[10:33] <jelmer> Jesse1: you can't change revision ids after the revision has been added, but when creating a new revision from within the bzr API you cna specify the new revision id
[10:33] <spiv> Jesse1: perhap you can generate a fast-import file of your data and import that?
[10:33]  * spiv isn't really here...
[10:34] <Jesse1> i recalled parent revisions can be changed?
[10:36] <Jesse1> jelmer: so i can specify the new revision id when creating new revision?
[10:36] <jelmer> Jesse1: parent revision ids can't be changed either
[10:36] <jelmer> Jesse1: yes, when creating a new revision you can specify the new revision id (but only from the API, this is not exposed on the command-line)
[10:36] <Jesse1> suer i understand
[10:37] <Jesse1> WorkingTree.commit() doesn't seem to have a place for revision id?
[10:39] <jelmer> Jesse1: it does, IIRC it's called "rev_id"
[10:39] <Jesse1> since bzrlib.workingtree.WorkingTree doesn't have docstring on commit()
[10:39] <Jesse1> i can only guess from the argument names
[10:39] <Jesse1> and i guess rev_id is parceled in *args?
[10:40]  * jelmer nods
[10:40] <Jesse1> what's the triple star in front of your name? (sorry i'm such a newbie)
[10:41] <jelmer> oh, it indicates an action
[10:41] <Jesse1> oic
[10:41] <Jesse1> thx
[10:42] <Jesse1> undocumented *args is eveil...
[10:43] <ronny> moin
[10:43] <Jesse1> thanks jelmer jml & spiv
[10:43] <jelmer> moin ronny
[10:43] <Jesse1> i'll look more into the docs and try
[10:44] <jml> Jesse1, I didn't do anything :)
[10:44] <Jesse1> oh really
[10:44] <Jesse1> there's never too much gracias
[10:45] <Jesse1> bye
[13:43] <Muttley> hi, I'm using bzr-svn to push my bzr branch up to the wordpress svn server and I've just realised it's trying to download the revision info for the entire repository
[13:44] <Muttley> did i screw up somewhere or is that just how it works
[13:44] <LarstiQ> fsvo download, that is how it works
[13:45] <Muttley> basically I had my bzr branch that I work in and just did: bzr push http://svn.wp-plugins.org/myplugin/trunk/
[13:45] <LarstiQ> but the revision info getting of the entire repository bzr-svn needs to do, it caches, and is pretty fast
[13:45] <LarstiQ> Muttley: which version of bzr and bzr-svn?
[13:46] <Muttley> it's windows release (don't hate me) 1.16.1
[13:46] <Muttley> not sure the plugin version
[13:46] <LarstiQ> Muttley: don't worry, we won't hate you fot using Windows.
[13:47] <LarstiQ> Muttley: `bzr plugins` will tell you, but bzr-svn is pretty strict in which versions of bzr it works with
[13:47] <Muttley> hehe, I'm actually a linux guy but I've been doing this dev in windows
[13:47] <LarstiQ> so that is probably 0.6.2
[13:47] <LarstiQ> Muttley: don't hate yourself then? ;)
[13:47] <Muttley> 0.6.3dev
[13:47] <Muttley> LarstiQ: hehe
[13:48] <LarstiQ> Muttley: I imagine the wp-plugins repository is huge? (Ie, where is bzr-svn's progress bar at?)
[13:48] <Muttley> just the wordpress plugin repository is quite big
[13:48] <Muttley> progress bar about 25%
[13:48] <Muttley> been going about an hour
[13:49] <Muttley> I'm out in asia at the moment so it's going between 5 and 10 K/sec
[13:49] <Muttley> up to 20meg so far
[13:50] <Muttley> is there anyway around it or am I just in for a long night? :)
[13:52] <LarstiQ> Muttley: could you paste the line it is showing? It has multiple phases and I'd like to be sure it is at the phase I think it is at
[13:53] <Muttley> [####/               ] http    20435KB    13KB/s | fetching svn revision info 3
[13:53] <Muttley> I think that 3 is actually more like 3xx or 3xxx
[13:53] <Muttley> just it cut of at the useful 80 char cmd promt limit
[13:54] <Muttley> my plugin trunk was created a few hours ago and was revision 136629
[13:54] <LarstiQ> ah
[13:54] <Muttley> so it could be 3xxxx that it's currently on
[13:55] <LarstiQ> Muttley: no way around this fetching svn revision info, but it is resumable, and will happen with any operation against that repository
[13:55] <LarstiQ> evening AfC
[13:55] <Muttley> ok, so if I kill it and start again tomorrow it'll at least continue from where it left off?
[13:55] <LarstiQ> Muttley: yes
[13:56] <Muttley> ok
[13:56] <Muttley> thanks
[13:56] <LarstiQ> Muttley: do you know if you have tdb or sqlite?
[13:56] <Muttley> umm, pass
[13:56] <LarstiQ> Muttley: bzr-svn grew a capability to use tdb for caching this info, which is way way faster
[13:56]  * LarstiQ wonders what the installer uses
[13:56] <LarstiQ> Muttley: ok :)
[13:57] <Muttley> yeah, I was tempted to go the whole route of grabbing the dependences and source but in the end it seemed easier to just get the all-in-one installer ;)
[13:57] <LarstiQ> aye
[13:57] <Muttley> thanks for the help
[13:57] <LarstiQ> np
[13:58]  * AfC waves to LarstiQ
[14:15] <LarstiQ> jelmer: do you know if python-tdb is available on windows?
[14:15] <jelmer> LarstiQ: No, tdb hasn't been ported to windows (yet)
[14:16] <LarstiQ> jelmer: ok, so Windows users are stuck with sqlite then
[14:16] <jelmer> LarstiQ: yep, at least for now
[14:16] <LarstiQ> k
[14:33] <alex-weej> can someone tell me how i enable nautilus integration of bzr? i have bzr-gtk installed but nothing fancy happens when i open a repo folder
[14:36] <jelmer> alex-weej: you need to have python-nautilus installed
[14:38] <alex-weej> jelmer: i do have it installed
[14:38] <alex-weej> on ubuntu 9.04 btw
[15:58] <Raim> how can I let bzr forget my lp-login? already deleted ~/.bazaar/authentication.conf, but it seems like it gets it again from somewhere else
[15:58] <james_w> Raim: ~/.bazaar/bazaar.conf
[15:59] <Raim> james_w: ah... thanks, too obvious ;)
[16:24] <thewrath> how do i checkout a specific revision from bzr
[16:25] <LarstiQ> thewrath: -r <revision>
[16:25] <thewrath> bzr -r <revision> <locationtoputitinto> ?
[16:26] <LarstiQ> -r to the bzr command
[16:26] <LarstiQ> thewrath: say, `bzr branch url/to/source -r <revision> destination`
[16:26] <LarstiQ> thewrath: could you elaborate on the task at hand a bit more?
[16:27] <thewrath> just trying to copy a certain revision to another location
[16:27] <LarstiQ> thewrath: for what purpose?
[16:27] <LarstiQ> thewrath: for say making a tarball, you'd want `bzr export`
[16:28] <thewrath> i am modifiying a joomla education build and i want to have two  locations to have the same stuff
[16:28] <thewrath> one like for hte live site and one for the dev site
[16:30] <LarstiQ> thewrath: if I interpet that correctly, your original question was for how to deploy to the live site, right?
[16:30] <thewrath> does that make ense
[16:31] <thewrath> i wanted to createe another directory with the information from a certain revision
[16:31] <thewrath> so i guess yes
[16:32] <LarstiQ> thewrath: that sounds like something I would do with the bzr-upload plugin
[16:32] <LarstiQ> thewrath: as I wouldn't do any development on the live site, only deploy
[16:36] <thewrath> right
[16:36] <thewrath> i had my dev site set up as i wanted to do for my live site so all i had to do was essentially move it over
[16:36] <LarstiQ> right
[16:36] <thewrath> wat does the bzr-upload-plugin do, does it come standard with bzr?
[16:37] <LarstiQ> it doesn't come standard with bazaar, but is easy to install (will go over that in a bit)
[16:38] <LarstiQ> thewrath: it creates the files in your working tree in a remote location, but doesn't store all the history
[16:38] <LarstiQ> thewrath: and it is smart enough to only update it with the changes
[16:38] <LarstiQ> thewrath: not the entire set of files again each time
[16:39] <LarstiQ> thewrath: it is designed to work well for deployment on web application development
[16:39] <thewrath> nbice
[16:40] <LarstiQ> thewrath: you can either run `bzr upload` manually when you want to deploy something (optionally with -r to select a specific revision)
[16:40] <LarstiQ> thewrath: or turn on automatic mode where it will upload on each commit
[16:40] <LarstiQ> thewrath: how did you install your copy of bzr?
[16:42] <thewrath> i am in windows so the msi beileve
[16:42] <thewrath> *msi installer
[16:42] <LarstiQ> ok
[16:42] <LarstiQ> thewrath: does `bzr plugins` list the upload plugin?
[16:43] <thewrath> no it does not when i run bzr plugins
[16:43] <LarstiQ> ok
[16:44]  * LarstiQ isn't too experienced with the windows installer, so let's see how it goes
[16:44] <thewrath> ok,
[16:45] <thewrath> worst comes to worst i can just reinstll it
[16:45] <LarstiQ> thewrath: `bzr --version` should have a 'Bazaar configuration' directory listed
[16:45] <LarstiQ> thewrath: sure
[16:45] <thewrath> ok yes it does along with others
[16:48] <LarstiQ> thewrath: right, so if you cd there
[16:49] <LarstiQ> thewrath: and then `bzr branch lp:bzr-upload upload`
[16:49] <LarstiQ> thewrath: you'll get a copy of the upload plugin from Launchpad
[16:49] <LarstiQ> thewrath: after which it should show up in `bzr plugins`
[16:52] <thewrath> yeap its there now
[16:54] <LarstiQ> thewrath: ok, so the usage is, for the first time, `bzr upload LOCATION`, and afterwards just `bzr upload`
[16:54] <LarstiQ> thewrath: see `bzr help plugins/upload` and `bzr help upload`
[16:54] <LarstiQ> thewrath: and/or the README file inside the plugin dir
[16:55] <thewrath> ok
[16:55] <thewrath> can i change that for each different bzr project?
[16:56] <LarstiQ> thewrath: ah right, sorry, it remembers it for a specific branch
[16:56] <LarstiQ> thewrath: so yeah, each different bzr project is independent in its upload location
[16:58] <thewrath> so each bzr init remembers its own?
[16:59] <LarstiQ> thewrath: `bzr init` is only used to start a new project, but if you mean each branch, yes
[17:00] <LarstiQ> though you should be able to configure it for multiple branches in one sweep with locations.conf
[17:04] <dvheumen> hi, I've written a "patch" (it's childishly simple, but at least to learn something about python and bzr), how should I proceed to upload it? Just add it in a message to the bug? (https://bugs.launchpad.net/bzr/+bug/84659)
[17:05] <thewrath> yea LarstiQ that is wat i meant
[17:08] <LarstiQ> dvheumen: do you intend for it to be merged? Then `bzr send`ing it to<EMAIL_ADDRESS>would be the thing to do
[17:08] <LarstiQ> dvheumen: attaching it to a bug is possible but not something we do often
[17:09] <dvheumen> LarstiQ: well it's a first for me, so I'll do what's the most common practice
[17:09] <dvheumen> LarstiQ: so if you say that bzr sending is the best, i'll do that
[17:09] <LarstiQ> dvheumen: it is
[17:09] <dvheumen> LarstiQ: okay, thanks for the info
[17:10] <LarstiQ> dvheumen: if you expect a lot of discussion, you could also send it to the mailing list with a subject prefixed with [RFC]
[17:11] <LarstiQ> but if it is childishly simple, probably not :)
[17:11] <dvheumen> LarstiQ: Well, it's basically a call to 'note' with a warning message, so I doubt it actually :D
[17:11] <dvheumen> (tagged as 'easy')
[17:11] <LarstiQ> dvheumen: good :)
[17:14] <LarstiQ> dvheumen: as a result of your `bzr send`, it should show up in https://code.launchpad.net/bzr/+activereviews
[17:14] <dvheumen> LarstiQ: ah, thanks, that's a good remark, I didn't know
[17:21] <dvheumen> LarstiQ: I'm curious, how do they match my patch with the bug report?
[17:22] <dvheumen> because I made this patch based on lp:bzr
[17:23] <LarstiQ> dvheumen: ah, maybe I should have instructed you more carefully :)
[17:24] <dvheumen> If there's some FAQ to read, just point me to it ... I don't mind ... but I have no idea of how to approach submitting a patch to bazaar/launchpad
[17:24] <dvheumen> I expected to just post the patch file with a comment in the bug report
[17:24] <dvheumen> until I heard your approach :P
[17:24] <LarstiQ> dvheumen: mention the bug in the subject, say 'add a warning for foo (#84659)'
[17:26] <alex-weej> can someone tell me how i enable nautilus integration of bzr? i have bzr-gtk installed but nothing fancy happens when i open a repo folder
[17:26] <dvheumen> okay, I'll be back in about half an hour and I'll give it a try, tnx
[17:26] <LarstiQ> alex-weej: does the README of bzr-gtk mention anything?
[17:27] <LarstiQ> dvheumen: k, see you then
[17:27] <alex-weej> LarstiQ: probably?
[17:27] <LarstiQ> alex-weej: sooo?
[17:27]  * LarstiQ doesn't use a desktop environment
[17:27] <alex-weej> hardcore
[17:27] <alex-weej> it just said i need to install python-nautilus to use nautilus integration
[17:27] <alex-weej> i already have that
[17:28] <LarstiQ> not really, I just am hopelessly ineffective in them
[17:28] <alex-weej> oh wait there is more actually, i need to symlink something to enable it
[17:28] <LarstiQ> alex-weej: right
[17:28] <alex-weej> hm, nautilus needs proper plugin management :/
[17:28] <alex-weej> thanks
[17:30] <alex-weej> LarstiQ: actually, turns out the plugin is just missing from the deb :/
[17:31] <LarstiQ> alex-weej: d'oh
[17:31] <LarstiQ> alex-weej: which deb/distro is that?
[17:31] <alex-weej> ubuntu 9.04
[17:32] <LarstiQ> ho hum
[17:32] <alex-weej> no wait, i found it! it's bundled in with the rest of the bzrlib for some reason
[17:32] <alex-weej> even though it's a nautilus plugin
[17:32] <alex-weej> :F
[17:32] <LarstiQ> alex-weej: mind filing some bugs on Ubuntu? :)
[17:33] <alex-weej> packaging error, yeah will do
[17:35] <alex-weej> nah still doesn't work, ImportError: cannot import name cmd_gannotate
[17:37] <alex-weej> i guess it has bitrotten :(
[17:40] <LarstiQ> alex-weej: that is possible. Where does it try to import gannotate from? It is, or used to be, part of bzr-gtk
[17:40] <alex-weej> bzrlib.plugins.gtk
[17:41] <jelmer> alex-weej: that's fixed in bzr-gtk trunk
[17:44] <Pilky> hey all, anyone around who's pretty well versed with how bzrlib works?
[17:45] <Pilky> I'm trying to understand how authentication works when accessing servers. I've found the code to do various commands in bzr, found the code that seems to get the password or prompt the user but I can't find the code that links the two
[17:46] <Pilky> if anyone could point me in the right direction it'd be much appreciated :)
[17:49] <LarstiQ> Pilky: have you found credential stores?
[17:50] <Pilky> yeah, I've found the stuff in config.py
[17:50] <LarstiQ> good
[17:51] <Pilky> it's more a case of I can't find where commands like push and commit etc access those
[17:52] <LarstiQ> Pilky: bzrlib/transport/
[17:54] <LarstiQ> Pilky: that is, commands don't do that, they try to connect to a location, and the underlying transport takes care of authentication
[17:55] <Pilky> right
[17:56] <Pilky> what I'm wanting to do is hijack the authentication prompt really
[17:56] <LarstiQ> Pilky: for comparison, have a look at lp:hitchhiker, which builds on bzr transports
[17:57] <Pilky> so instead of prompting for a password on the command line, I can pass in a password given to me by the user in a GUI
[17:57] <LarstiQ> Pilky: in what way? Is it just because you want to prevent a UI.. right
[17:57] <Pilky> yeah
[17:57] <LarstiQ> Pilky: look at bzrlib/ui
[17:58] <LarstiQ> Pilky: you want a UIFactory implementing get_password
[17:58] <LarstiQ> Pilky: for a comparison of _that_ you could look at qbzr for a Qt UIFactory
[17:58] <Pilky> ok cool
[17:59] <Pilky> so that would allow me to stop it from prompting the user in the UI and I can just return my own password
[17:59] <LarstiQ> Pilky: how you phrased your question at first I didn't know if I knew enough bzrlib, but I'm glad you just asked your question :)
[17:59] <Pilky> heh
[18:00] <LarstiQ> Pilky: if you so wish, though that might not be the right approach if I understand you correctly
[18:00] <LarstiQ> Pilky: it is the way to not get prompting on the cli
[18:00] <Pilky> well basically I'm building an Objective-C API
[18:00] <LarstiQ> Pilky: but if you have something more of a CredentialStore, that api would be better
[18:00] <LarstiQ> Pilky: I know :)
[18:01] <Pilky> I want to be able to get the password from the Mac's keychain
[18:01] <Pilky> authentication is the one thing that kills any project trying to tie into bzr using the CLI interface
[18:01] <LarstiQ> Pilky: bzr-svn might already do something like that
[18:01] <Pilky> well I'll have a look into bzr-svn and qbzr
[18:03] <LarstiQ> Pilky: iirc jfroy added support for keychain authentication
[18:04] <jfroy> Indeed
[18:05] <jfroy> onnnne second
[18:05] <Pilky> ah that would be useful
[18:06] <jfroy> it is :)
[18:06] <Pilky> if I can just write to keychain to set up authentication and get bzr to read from there it'd make things a LOT easier
[18:06] <jfroy> at least for bzr-svn
[18:09] <Pilky> jfroy: is it in your branch of bzr-svn or in the trunk?
[18:10] <jfroy> neither
[18:10] <Pilky> where is it then?
[18:15] <Pilky> jfroy: ?
[18:15] <jfroy> working on it :p
[18:17] <jfroy> Cleaned it up a bit, pushing to LP
[18:20] <Pilky> ah cool
[18:22] <dvheumen> hey, how can I "update" (in svn terms) to a previous revision? I've found 'revert -r #' but it leaves modifications (of newer revisions) behind.
[18:23] <jfroy> dvheumen: you can't
[18:23] <jfroy> bzr doesn't support doing that
[18:23] <jfroy> your only option is to lightweight checkout to the revision you want
[18:23] <dvheumen> hmmmm...
[18:23] <jfroy> e.g. bzr co --lightweight -r FOO some_directory
[18:23] <Pilky> dvheumen: you can try clean-tree
[18:23] <dvheumen> but I probably could do: bzr remove-tree; bzr co -r #
[18:23] <jfroy> And yes it's silly, and the bzr developers don't seem to think so
[18:23] <jfroy> dvheumen: yes, that should also work
[18:23] <dvheumen> Pilky: nothing to delete
[18:23] <Pilky> that should remove unknown files
[18:24] <Pilky> dvheumen: try bzr clean-tree --detritus
[18:25] <jfroy> Huh, hitting a ERROR: bzrlib.errors.IllegalUseOfScopeReplacer exception
[18:25] <jfroy> Pilky: hold on :p
[18:25] <Pilky> lol
[18:25] <Pilky> I swear I'm going to regret taking this project on :p
[18:25] <Pilky> at least I'm only committing a day a week to it at the moment
[18:26] <jfroy> apparently, this is bad: from bzrlib.plugins.keychain import _keychain
[18:26] <jfroy> (_keychain is an extension module in the plug-in, the plug-in itself is bzr-keychain (and the package name is keychain))
[18:26] <dvheumen> Pilky: thanks, but it's too late :P
[18:27] <Pilky> wasn't giving plugin names a bzr- prefix deprecated?
[18:29] <abeaumont> is it possible to tell bzr svn to do a branch from a certain revision (like git svn does?), without importing whole history
[18:30] <garyvdm> jfroy: if you have a project named bzr-xxx, it's directory in ~/.bazaar/plugins should just be xxx
[18:30] <jfroy> garyvdm: that's what I have
[18:30] <jfroy> I think the lazy imporer is using _foo for import foo
[18:30] <jfroy> and so dies if trying to import a module actually named _foo
[18:31] <garyvdm> jfroy: Ok - sorry - I miss understood you
[18:32] <Pilky> jfroy: you know if this works then it could simplify my code a huge amount
[18:32] <Pilky> I could do it all using NSTask and NSXML*
[18:32] <jfroy> oh it does work
[18:32] <Pilky> which also simplifies the licencing
[18:33] <jfroy> I use it all the time at work to interface with svn repositories
[18:33] <jfroy> I licensed it under BSD
[18:33] <Pilky> cool
[18:33] <jfroy> garyvdm: urg no that's not it
[18:33] <jfroy> what the heck is going on :|
[18:34] <Pilky> my issue before was I'd have to hook into bzrlib directly so I'd need to make part of my code GPL licensed, but then the developer facing API would be MIT licensed and talk to the backend via distributed objects
[18:34] <Pilky> basically, not very pretty :P
[18:34] <jfroy> Is this valid inside lazy_import.lazy_import?
[18:34] <jfroy> from bzrlib.plugins.keychain import cKeychain
[18:35] <jfroy> where the plug-in package is indeed keychain, and is named as such in the plugins directory
[18:35] <jfroy> Pilky: I don't think that's a good idea...
[18:35] <jfroy> bzr is GPL, so you should make your tool GPL as well.
[18:35] <jfroy> DOs will make things way, way more complicated
[18:35] <LarstiQ> jfroy: what is cKeychain, a class?
[18:36] <jfroy> If you use the bzr CLI, I guess it would be fine
[18:36] <jfroy> LarstiQ: an extension module in the package
[18:36] <LarstiQ> jfroy: ah
[18:36] <Pilky> jfroy: I don't want to make it GPL as I want the GUI to be MIT licenced
[18:36] <jfroy> zohar:keychain bahamut$ pwd
[18:36] <jfroy> zohar:keychain bahamut$ ls
[18:36] <jfroy> LICENSE      README       __init__.py  __init__.pyc build        cKeychain.c  cKeychain.so setup.py
[18:36] <jfroy> thanks IRC...
[18:36] <jfroy>  /Users/bahamut/.bazaar/plugins/keychain
[18:36] <Pilky> plus then my lib could be used by closed source projects
[18:36] <LarstiQ> jfroy: could you try importing bzrlib.plugins.keychain (maybe as mod_keychain or such) and working off of that?
[18:37] <jfroy> LarstiQ: sure
[18:37] <jfroy> Is there an issue with lazy import that I should be aware of (for future reference and edification)
[18:37] <LarstiQ> jfroy: a couple, they really should be written down somewhere.
[18:38]  * LarstiQ looks for it
[18:39] <LarstiQ> jfroy: from HACKING: While it is possible for ``lazy_import()`` to import members of a module when using the ``from module import member`` syntax, it is recommended to
[18:40] <LarstiQ> only use that syntax to load sub modules ``from module import submodule``.
[18:40] <LarstiQ> This is because variables and classes can frequently be used without needing a sub-member
[18:40] <jfroy> well the issue is just that importing that sub-module outright dies
[18:40] <LarstiQ> jfroy: right, which isn't mentioned
[18:41] <LarstiQ> jfroy: so I'm not aware of that being a limitation
[18:41] <LarstiQ> jfroy: can I use the keychain plugin on non-OSX?
[18:41] <jfroy> No :p
[18:42] <jfroy> I think it's a case of the stupids
[18:42] <jfroy> one moment...
[18:42] <jfroy> yup
[18:42] <jfroy> didn't refactor the module name in the C extension file >.<
[18:46] <jfroy> OK no it still dies
[18:46] <jfroy> IllegalUseOfScopeReplacer: ScopeReplacer object 'cKeychain' was used incorrectly: Object already cleaned up, did you assign it to another variable?: _factory
[18:47] <jfroy> (for from bzrlib.plugins.keychain import cKeychain)
[18:47] <LarstiQ> jfroy: that is a lazy import error
[18:48] <jfroy> doing the import in the module itself (the plug-in's __init__ module) works fine
[18:48] <jfroy> that's OK
[18:49] <jfroy> worked around ot
[18:49] <jfroy> *it
[18:49] <jfroy> def lazy_import_cKeychain():
[18:49] <jfroy>     global cKeychain
[18:49] <jfroy>     cKeychain = __import__('bzrlib.plugins.keychain.cKeychain', globals(), locals(), [], 0)
[18:49] <jfroy> :P
[18:49] <jfroy> innteresting, that seems broken too
[18:54] <LarstiQ> ahem :P
[18:54] <jfroy> did I do something stupid?
[18:54] <jfroy> :/
[18:55]  * LarstiQ has a look at the code
[18:58] <jfroy> cKeychain = __import__('cKeychain', globals(), locals(), [], 1) did the trick
[19:00] <jfroy> uh-ho
[19:00] <jfroy> converted the branch to 2a
[19:00] <jfroy> And now bzr pack is giving me bzr: ERROR: Pack '3dcf256d8340362428db62217ca32a0d' already exists in <bzrlib.repofmt.groupcompress_repo.GCRepositoryPackCollection object at 0x1018d9490>
[19:00] <LarstiQ> doesn't that mean you don't need to pack?
[19:00] <LarstiQ> scarily worded
[19:01] <Pilky> jfroy: that's your own fault for using a crappy VCS, use subversion! ;)
[19:01] <jelmer> jfroy: which version of bzr are you using?
[19:01] <jfroy> LarstiQ: does it?
[19:01] <jfroy> 1.17rc1
[19:02] <jfroy> Pilky: apologies for the delay
[19:02] <jfroy> https://launchpad.net/bzr-keychain
[19:02] <Pilky> jfroy: a short delay for the amount of time you could save me is a small price to pay ;)
[19:03] <Pilky> still trying to push?
[19:03] <jfroy> I did
[19:03] <jfroy> should be on LP
[19:03] <Pilky> ah
[19:03] <Pilky> it must not have registered it in the UI yet
[19:03] <jfroy> ah huh hold on
[19:03] <jfroy> haven't set a development focus yet
[19:04] <jfroy> there, done
[19:04] <jfroy> bzr branch lp:bzr-keychain keychain
[19:04] <jfroy> jelmer:  LarstiQ  you can grab the branch to check that pack issue if you want
[19:05] <jelmer> jfroy: this is a known bug, but I thought it had already been fixed
[19:05] <jfroy> I see
[19:05] <jelmer> jfroy: if a 2a repository is already packed then "bzr pack" will generate the exact same file
[19:05] <jelmer> jfroy: and thus you get this error
[19:05] <jfroy> gotcha
[19:06] <jelmer> jfroy: this situation should probably be special cased or something
[19:07] <jfroy> Pilky: that being said, maybe the DO approach is not so bad
[19:07] <jfroy> As bad as it is, using NSTask is even worse
[19:07] <Pilky> jfroy: your setup script doesn't seem to work
[19:08] <jfroy> the cost is launching the Python interpreter is non-trivial
[19:08] <jfroy> Pilky: oh?
[19:08] <Pilky> from: can't read /var/mail/distutils.core
[19:08] <Pilky> ./setup.py: line 27: import: command not found
[19:08] <Pilky> ./setup.py: line 29: syntax error near unexpected token `name='bzr-keychain','
[19:08] <Pilky> ./setup.py: line 29: `setup(name='bzr-keychain','
[19:08] <LarstiQ> Pilky: run it with python
[19:08] <LarstiQ> jfroy: add a hashbang ;)
[19:08] <Pilky> bah *headdesk*
[19:08]  * jfroy follows Pilky
[19:10] <jfroy> pushed >.>
[19:10] <jfroy> *ahem*
[19:11] <jfroy> Pilky: DO guidelines: 1) ONLY use async messages 2) ALWAYS wrap ANY DO message with try {} catch {}
[19:11] <jfroy> Should be fine beyond that.
[19:11] <Pilky> hmm
[19:12] <jfroy> sync messages WILL lead to deadlocks
[19:12] <jfroy> it's almost inevitable
[19:12] <jfroy> from experience
[19:12] <Pilky> yeah I was going to do everything asynchronously
[19:12] <jfroy> try {} catch {} because any DO message can throw an exception if the other end is gone for some reason (crash, etc.)
[19:13] <Pilky> I'm assuming that your plugin doesn't save to the keychain, only reads?
[19:13] <jfroy> We had amusing bugs much earlier on in [REDACTED] Leopard where mach ports would die for no reason. Caused havoc in DO apps that didn't guard properly :p
[19:13] <jfroy> it only reads, correct
[19:14] <jfroy> the credential store API in bzr doesn't have write AFAIK
[19:14] <jfroy> or does it....
[19:14] <LarstiQ> jfroy: when were you gettting cKeychain errors?
[19:14] <jfroy> LarstiQ: when lazily importing it
[19:14] <jfroy> using a "from bzrlib.plugins.keychain import cKeychain" in the lazy import list
[19:15] <jfroy> Pilky: in practice I've found this to be fine
[19:15] <Pilky> ok, so for example if I wanted to store my ssh password for launchpad I'd create an internet keychain with the url and password needed?
[19:15] <jfroy> connecting once to the svn repository using Safari or svn will add the credentials to the keychain
[19:15] <jfroy> Ah, there is *no need* for the plug-in for ssh
[19:16] <jfroy> I don't think credential stores are even queried for ssh
[19:16] <jfroy> Mac OS X since 10.5 integrates the sshkey agent with Keychain
[19:16] <jfroy> it Just Works™
[19:16] <Pilky> oh really?
[19:16] <jfroy> yup
[19:16] <jfroy> it's also lazily started by launchd
[19:16] <jfroy> (the key agent is a launchd agent, e.g. per-user session)
[19:16] <jelmer> write support to keychain/gnome keyring in bzr would be nice
[19:17] <jfroy> I don't think it's big deal, actually
[19:17] <jfroy> most people use anon http or ssh
[19:17] <jfroy> the only common case for authenticated http is bzr-svn.
[19:17] <LarstiQ> Pilky: for openssh, the thinking is that credentials are best left up to openssh not bzr
[19:18] <jfroy> IIRC ssh is special cased
[19:18] <jfroy> the credential stores are not used
[19:18]  * LarstiQ nods
[19:18] <LarstiQ> jfroy: it works when I do `bzr plugins`
[19:19] <LarstiQ> oh, but I didn't compile..
[19:19] <jfroy> it won't build on non-Mac OS X, since it uses the Keychain C API :|
[19:19] <LarstiQ> yeah
[19:21] <LarstiQ> jfroy: I would probably try 'import bzrlib.plugins.keychain.cKeychain' myself at first
[19:21] <jfroy> that probably will work, but then how do I use cKeychain
[19:22] <jfroy> If I know my Python at all, I think I'd have to use the full import name in code
[19:22] <jfroy> which is... long :|
[19:22] <LarstiQ> bzrlib.plugins.keychain.cKeychain.find_generic_password, which is indeed pretty long
[19:22] <LarstiQ> do you need to import it lazily?
[19:23] <jfroy> No, but it's always a good idea to be as lazy as possible
[19:23] <jfroy> bzr launch times are already bad as it is
[19:23] <jfroy> I worked around the issues and rolled my own lazy import with __import__
[19:23]  * LarstiQ noticed
[19:23] <jfroy> it's a small plug-in, and the C module is only used in one place, so it's acceptable
[19:23] <LarstiQ> jfroy: I'm wondering what makes it problematic though, will any C extension go wrong?
[19:26] <jfroy> dunno
[19:26] <jfroy> jelmer might have some ideas
[19:26] <jfroy> since his svn bindings used to be bundled with bzr-svn
[19:27]  * jelmer didn't really follow
[19:27] <jelmer> what's the question?
[20:11] <LarstiQ> gosh, is my upgrade of bzr.dev to 2a going slowly
[20:11] <LarstiQ> jelmer: jfroy ran into some errors with lazyimporting bzrlib.plugins.keychain.cKeychain, which is a C extension
[20:12] <LarstiQ> jelmer: so I wondered what made it problematic, did lazy importing subvertpy when it was part of bzr-svn give any trouble?
[20:14] <jelmer> LarstiQ: I don't think I ever lazy imported it
[20:15] <LarstiQ> jelmer: that calls for experimentation I guess! :)


[09:56] <mup> Bug #1479721 opened: Bulk tagging of nodes in UI <landscape> <ui> <MAAS:New> <https://launchpad.net/bugs/1479721>
[15:06] <mup> Bug #1479839 opened: MAAS deletes boot images by default if they no longer exist in simplestreams <MAAS:Triaged> <MAAS 1.8:Triaged> <https://launchpad.net/bugs/1479839>
[18:28] <daytona> hey yall, are you already aware of the PD alerts coming in? https://raxcm.pagerduty.com/incidents
[18:28] <daytona> NebOps is having issues logging in, getting Permission denied (publickey).
[18:37] <mup> Bug #1472741 changed: No way to delete images as the maas user that I can see <MAAS:Invalid> <https://launchpad.net/bugs/1472741>
[18:43] <mup> Bug #1472741 opened: No way to delete images as the maas user that I can see <MAAS:Invalid> <https://launchpad.net/bugs/1472741>
[18:49] <mup> Bug #1472741 changed: No way to delete images as the maas user that I can see <MAAS:Invalid> <https://launchpad.net/bugs/1472741>
[22:22] <mup> Bug #1479985 opened: display timestamps in user timezone (and/or relative) <MAAS:Triaged> <https://launchpad.net/bugs/1479985>
[22:34] <mup> Bug #1479995 opened: maas 1.8 will not commission AMT nodes <MAAS:New> <https://launchpad.net/bugs/1479995>
[22:58] <mup> Bug #1479995 changed: maas 1.8 will not commission AMT nodes <MAAS:New> <https://launchpad.net/bugs/1479995>