[00:22] <KhaZ> Hrmm.  I'm trying to use 'bzr launchpad-login' and I get a crash within urllib2_wrappers.py.  Anyone not going wrong?  Am I running an inappropriate version of Python for use with bzr?  (2.5.2?)
[00:25] <Peng_> KhaZ: bzr version, and pastebin the traceback
[00:28] <KhaZ> I'm running 1.12 dev.  Let me get on that pasetbin.
[00:28] <KhaZ> *pastebin
[00:29] <KhaZ> http://pastebin.com/m38be0452
[00:30] <Peng_> KhaZ: That's a known bug. It's been discussed on the mailing list a bit.
[00:30] <KhaZ> Ah.  Is there a workaround?
[00:31] <Peng_> KhaZ: Well, you could revert to an older revision, or apply the patch on the list.
[00:31] <Peng_> KhaZ: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/52120
[00:32] <KhaZ> AH, thanks for the thread.  I'll dig around a bit.  I wonder why the patch isn't in dev?
[00:33] <Peng_> KhaZ: Cuz it only came up today.
[00:33] <KhaZ> Outrageous.  Turn around time in bzr isn't instantaneous?  I'm apalled.
[00:34] <KhaZ> ;)  Anyhow, thanks Peng_.
[01:07] <yml> hello good evening
[01:09] <yml> I have put some file on the shelve :  bzr shelve file1 file2 file3
[01:10] <yml> in order to do an automic commit
[01:11] <yml> now I would like to bring them back into my working tree
[01:13] <yml> I found that bzr unshelve do what I want but I can have several shelve I would like to know if it is possible to :  list them, name each shelf wit a meaning full name, explore their content ?
[01:51] <bob2> yml: bzr help shelve/bzr help unshelve
[02:40] <yml> bob2 I read them both but I haven't find answer to my questions
[06:32] <Peng_> jelmer: Is bzr-svn's "discovering revisions" progress bar supposed to say the progress is a negative number?
[08:38] <Lo-lan-do> Oooh, network <3
[08:39] <Peng_> ?
[08:39] <Lo-lan-do> FOSDEM wireless.
[08:40] <Peng_> Ah.
[08:40] <Lo-lan-do> Let us say it hasn't proved very reliable yesterday.
[09:02] <Lo-lan-do> LarstiQ: I pushed the current (almost empty) results of what we did yesterday at http://bzr.debian.org/bzr/users/lolando/misc/bzr-gc
[11:50] <jelmer> Peng_, Nope, that's a bug.
[12:02] <AfC> Uh
[12:02] <AfC> $ bzr info
[12:02] <AfC> Repository branch (format: 1.12-preview or 1.9)
[12:02] <AfC> ...
[12:02] <AfC> what the hell?
[12:05] <jelmer> AfC, Hi!
[12:05] <jelmer> AfC, ?
[12:06] <jelmer> AfC: What is the problem there? The fact that it mentions two formats?
[12:06] <jelmer> AfC, this is because those formats are the same except for the working tree format
[12:06] <AfC> I'm asking what's with the "or" in the statement given by `info` about the format in place in the branch. Given that it was created with --format="1.9" I have no idea what that statement means,.
[12:06] <AfC> But worse is that it sounds like Bazaar doesn't know.
[12:07] <jelmer> the problem is that if there is no working tree, there is no way to distinguish between the two formats
[12:07] <AfC> I cannot believe the core developer of a tool that purports to be a clean user experience exposed that kind of uncertainty in the UI.
[12:08] <AfC> jelmer: perhaps I could suggest that if there is no Working Tree present to not report about such things then. If it doesn't know, it doesn't know.
[12:09] <jelmer> AfC: In that case, it couldn't print a format at all if you are in a shared repository
[12:09] <jelmer> AfC, there is technically no difference between the two formats if you don't have a working tree, so I don't think there is any uncertainty here
[12:10] <jelmer> AfC, I can agree it's a bit strange, but I don't see a good way to fix this..
[12:10] <jelmer> AfC, what would you rather see?
[12:10] <jelmer> bzr could just show you one format I guess, that would be technically less accurate but less confiusing too
[12:11] <AfC> I just don't want Bazaar embarrassing itself in front of users. We made so much of the premise that bzr was a better user experience than other tools, but this is precisely the sort of thing that causes us to squander such branch equity.
[12:12] <AfC> ... such brand* equity.
[12:12] <AfC> :)
[12:28] <Peng_> Can we file that under "yes, we know bzr has too many formats" and ignore it? :D
[12:32] <LarstiQ> Jc2k: you around somewhere?
[12:34] <bialix> Peng_: what? again?
[12:35] <Peng_> bialix: It was about "bzr info" showing stuff like "Repository branch (format: 1.12-preview or 1.9)" :)
[12:35] <bialix> oh
[12:35] <bialix> wait
[12:35] <bialix> how about this:
[12:35] <bialix> Lightweight checkout (format: 1.6 or 1.6.1-rich-root or 1.9 or 1.9-rich-root or dirstate or dirstate-tags or pack-0.92 or rich-root or rich-root-pack)
[12:36] <bialix> IMO there is stil the room for dozen formats
[12:36] <Peng_> Hahaha. That's excellent. :)
[12:36] <Peng_> Too bad the subtree formats are hidden.
[12:36] <bialix> yeah
[12:38] <Peng_> I think we scared AfC away.
[12:38] <bialix> :-D
[12:38] <bialix> lol
[12:38] <LarstiQ> poor guy :)
[12:40] <Peng_> Wait a minute, why is the lightweight checkout list in that order? In order of age, that's like 5, 5, 6, 6, 1, 2, 3, 4, 3.
[12:40] <Peng_> Err, that should be 5, 5, 6, 6, 1, 2, 4, 3, 4.
[12:40] <Peng_> ...Oh, alphabetical.
[12:40]  * Peng_ bonks himself on teh head
[12:42] <bialix> we need add randomizer I guess
[12:43] <bialix> so there will be everytime something new
[12:43] <Peng_> That's a horrible, evil, excellent idea.
[12:43] <Peng_> ...It'd make blackbox tests a bit tricky though.
[12:44] <bialix> put them in a set?
[12:44] <bialix> and check the set
[12:45]  * bialix don't think there is blackbox for light checkout info
[12:45] <Peng_> Good point. It would still be slightly more complicated though.
[13:32] <Jc2k> LarstiQ: im at the front of the cross desktop room
[15:52] <Adys> This sounds stupid, but I cant find how to refetch a folder I deleted by mistake from the remote working branch
[15:53] <Adys> er, make that, refetch the folder from the remote working branch, which I deleted locally
[16:06] <Adys> right, bzr revert *
[17:23] <bialix> what is the equivalent to os.path.join in bzrlib? osutils.join?
[17:24]  * bialix found osutils messy
[17:25] <santagada> bialix: http://starship.python.net/crew/mwh/bzrlibapi/bzrlib.osutils.html
[17:25] <santagada> I think it is joinpath
[17:25] <pi_m> Hi. Can I ask you? I am new to Bazaar and I really, really can't understand one thing (yes, I have read the user guide and the user reference manual first). It is shared repository. In the texts mentioned above is written that shared repository is created after "init-repo" command. New branches could be created by "init" command executed from the shared repo. Can you tell me what the branches share and if they depend on other branches in the shared repo?
[17:26] <bialix> share history
[17:27] <pi_m> bialix: History? Do you mean the commits?
[17:27] <nevans> yep.  all of the commits are stored in the shared repo.  so if two branches have the same commits, then they won't be duplicated
[17:28] <nevans> it becomes a little bit more obvious if you sneak a peek into the .bzr directories.
[17:28] <bialix> yep
[17:29] <nevans> normally, a branch's .bzr dir will contain a branch, checkout, and repository subdirs
[17:29] <nevans> for a standalone branch, that is.
[17:29] <santagada> in the end the result is the same as the common working of svn I think
[17:29] <santagada> is you copy files around it will not copy history
[17:29] <santagada> copy/branch
[17:30] <pi_m> nevans: So it is good to have a shared repo if you have some branches that have some common code (uh)?
[17:30] <santagada> pi_m: only if they share the same commits
[17:30] <nevans> pi_m: common history.  I use shared repos whenever I expect to work on many branches of the same project.
[17:31] <santagada> pi_m: which is the usual thing when you work on branches
[17:31] <bialix> santagada: joinpath -> Undocumented :-P
[17:31] <bialix> I guess pathjoin actually is right
[17:31] <nevans> actually, I've got a single shared repo for all of my work projects... even though some of them don't share commits.  it's just simpler than having a shared repo per project.
[17:31] <pi_m> santagada: Yes. So placing the different project's branches to shared repo has no sense, I think...
[17:31] <santagada> bialix: at least you know the name :D
[17:32] <bialix> problem is: there are 2 functions: joinpath and pathjoin
[17:32] <santagada> pi_m: it doesn't help... but it is not a performance problem either (i'm guessing here)
[17:32] <nevans> pi_m: if you look into a branch's .bzr (under a shared repo), you'll only see branch and checkout dirs.  and the shared repo's .bzr will contain the repository.
[17:33] <nevans> and if you run du on any .bzr dir, you'll see that the repo dir is always the largest.
[17:34] <bialix> santagada: pathjoin = os.path.join
[17:34] <bialix> :-P
[17:34]  * bialix anyway thinks osutils.py is messy
[17:34] <santagada> bialix: thanks... i'm also trying to learn the bzr api
[17:35] <nevans> pi_m: so if you have 5 branches that are fairly similar (and most branches within a project are), and their working trees take ~20MB, and their repos each take ~100MB, then it would take ~600MB to store them without a shared-repo, and ~200MB with a shared repo
[17:35]  * bialix using this api for several years and anyway it's messy
[17:36] <nevans> and since there's less disk usage, certain operations will also run more quickly with a shared repo (e.g. bzr branch)
[17:37] <pi_m> Thank you, your advices were very useful!
[17:40] <KhaZ> Can I ask why there is an osutils versus using the os.path stuff?
[17:45] <bialix> KhaZ: cross-platform support
[17:46] <santagada> let's just be franc that os.path.join is cross platform
[17:46] <santagada> what is diffente on osutils? stat?
[17:48] <KhaZ> Aye, I thought os.path.join *is* cross platform.  Although I do realize that a lot of stuff in Python wraps it nicely but doesn't necessarily yield the same results..
[17:49] <bialix> the difference is: osutils try to canonicalize the path after transformation to one standard
[17:50] <bialix> always / as path separator, even on windows
[17:50] <bialix> fix drive letter for windows and some other small details
[17:50] <KhaZ> Ah, gotcha.  Hrmm.  I'm sure the patch I submitted'll be rejected based on that alone. ;)
[17:50] <bialix> what?
[17:51] <KhaZ> Heh, just that I ended up using os.path and stuff directly in the patch I submitted w/RFC.
[17:52] <bialix> don't worry, you'll get detailed review and precise hints what to use instead
[17:52]  * bialix son't remember all gory details
[17:53] <bialix> s/son't/don't/
[17:55] <KhaZ> Just be gentle. ;)
[17:59] <bialix> sorry
[18:33] <Phill> Hey guys, I'm confused on how to use bzr, what should I be doing... (bzr add, commit, and then push?) or should I have done merge? It's a two person project, and now we seemingly messed it up with conflicts in some auto-gen files. I'm thoroughly confused.
[18:38] <bialix> if the files auto-generated you'd probably better re-generate them?
[18:38] <Phill> I can't seem to do that?
[18:38] <bialix> I don't understand
[18:39] <Phill> Well, I don't know why, but it seems bzr thinks there was a conflict and put it's TREE, MERGE etc things into the file.
[18:39] <Phill> The file was created once... I don't think it should've ever changed, so I don't know why Bzr says it changed, here, one second, let me look at it's diff.
[18:39] <bialix> do you know how to solve 3-way merge conflicts?
[18:39] <Phill> Nope!
[18:40] <Phill> I don't know how to solve 2-way merge conflicts :)
[18:40] <Phill> Ignorance ain't bliss.
[18:40] <bialix> read `bzr help conflicts` first, please
[18:40] <Phill> Aight.
[18:41] <bialix> you're interested in text conflicts section
[18:42] <Phill> Yeah, reading that now.
[18:42] <Phill> I think, I can actually auto-gen this file, but not the others, let's give the auto-gen a shot.
[18:43] <bialix> yep
[18:49] <Phill> Ok, so, it just to make sure I have this clear, it sticks two files into each other if it doesn't know what to do?
[18:49] <Phill> Like, the earlier revision, and then the later one?
[18:50] <bialix> no
[18:50] <bialix> it tries to be intelligent and combine common parts together
[18:50] <Phill> Then why does it look like the same xml document twice over?
[18:50] <bialix> if you have 2 files entirely in conflict there is different line-endings perhaps
[18:51] <Phill> Mmm.
[18:51] <bialix> check .THIS and .OTHER in binary mode
[18:51] <Phill> I just deleted the second one and hope it works ;-) (That's bad practice!)
[18:51] <bialix> you can repeat merge ;-)
[18:51] <bialix> `bzr resolve` will delete this junk automatically
[18:52] <Phill> Ok, so I'm taking it my usual, "Bzr add, commit, pull" isn't the way to do stuff?
[18:52] <Phill> Not pull, push I mean.
[18:52] <Phill> bzr add, commit, push
[18:53] <Phill> I always thought push and merge were the same thing...
[18:56] <Phill> bialix: Or let me rephrase, I Thought pushing merged as well - automatically,  take it as a no?
[18:56] <bialix> no
[18:57] <bialix> you should get 'branches are diverged' error -- then you need to merge locally and then push again
[18:57] <Phill> They weren't diverged (I assume, I never got that error), it was 20-21 21-22, etc. Basically, I worked on it, then my friend did, we just kept our code base in sync...
[18:58] <Phill> He worked at home, I worked at school, so - that's why we never merged.
[18:59] <bialix> you're pull when you need get his changes
[18:59] <Phill> Yep, that's what I did.
[18:59] <bialix> and push when you need to publish your changes
[18:59] <Phill> and then I pushed when I had changes.
[18:59] <bialix> so?
[18:59] <Phill> Why the conflicts?
[19:00] <bialix> you did pull?
[19:00] <Phill> Yep.
[19:00] <bialix> you had uncommitted changes in your branch
[19:00] <Phill> Yeah, About to say that.
[19:00] <Phill> And then I pulled.
[19:00] <Phill> = Errors.
[19:00] <Phill> Right?
[19:01] <Phill> Should I always commit before pulling then?
[19:01] <bialix> bzr did merge for you because you had uncommitted changes
[19:01] <Phill> Then merge before pushing?
[19:01] <Phill> Ahh, that's nice of it.
[19:01] <bialix> you'd better have 2 branches
[19:01] <bialix> 1 branch is exact mirror of remote
[19:01] <bialix> 2nd branch for your own work
[19:02] <bialix> you did pull only in 1st branch
[19:02] <Phill> I didn't even know I had two branches.
[19:02] <bialix> no
[19:02] <bialix> sorry
[19:02] <bialix> may be my English is not ideal
[19:02] <Phill> Nah; not your fault, I don't know what I'm doing. (That's my fault) :)
[19:02] <bialix> will be better if you create 2 branches to work on
[19:02] <Phill> Yeah.
[19:03] <Phill> and then merge them, right?
[19:03] <bialix> if they are diverged -- yes merge
[19:03] <Phill> Yeah.
[19:03] <bialix> if not diverged -- just pull from 1 to 2
[19:03] <Phill> Yeah.
[19:03] <Phill> Diverged means, mismatched revision numbers - right?
[19:03] <bialix> you can do `bzr merge --pull` and bzr selects appropriate action to you
[19:04] <bialix> not exactly numbers
[19:04] <bialix> say you have revision 20, and your friend too
[19:04] <bialix> your branches are full mirror of each other
[19:05] <bialix> then you change say file foo.txt and commit
[19:05] <bialix> but in the same time your friend change file bar.txt and also commit
[19:05] <bialix> you both will have revision 21, but they are different
[19:05] <Phill> so, I should do bzr merge -pull from now on? So it just does whatevers right for us?
[19:06] <bialix> ok?
[19:06] <Phill> bzr merge --pull
[19:06] <Phill> Yeah, that's cool.
[19:06] <Phill> I get it now :)
[19:06] <bialix> yes, it's safe choice
[19:06] <bialix> you can create alias
[19:06] <Phill> Boy do I need that one then ;-)
[19:07]  * bialix is not boy
[19:07] <Phill> Er, figure of speech.
[19:07] <bialix> creating alias will save you typing this everytime
[19:07] <bialix> check `bzr alias -h` for details
[19:08] <Phill> I don't have alias?
[19:09] <Phill> bzr alias -h bzr: ERROR: unknown command "alias"
[19:09] <bialix> bzr version
[19:10] <bialix> what is your bzr version?
[19:10] <Phill> Bazaar (bzr) 1.3.1
[19:10] <Phill> I take it, that that is old.
[19:10] <bialix> very old
[19:10] <Phill> :)
[19:10] <Phill> I probably got it from the repo long ago.
[19:10] <bialix> you'd better upgrade
[19:10] <Phill> Yep, yep.
[19:10] <Phill> Haha.
[19:10] <bialix> I bet you're on Ubuntu
[19:10] <Phill> Haha.
[19:11] <bialix> no?
[19:11] <Phill> Wow, Ubuntu is going to be what Windows was to the world. "Oh, you're on "UBUNTU".
[19:11] <Phill> Yeah I am.
[19:11] <bialix> I'm on Windows
[19:11] <bialix> hehe
[19:11] <Phill> I never upgraded the newest version of Ubuntu, I don't really care for it - waiting for 9.10 (I think) in April.
[19:12] <bialix> read instructions on how to update bzr at bazaar-vcs.org
[19:12] <Phill> And I think I installed this through a .deb package so it doesn't auto-update. =/
[19:12] <Phill> I can't uninstall/reinstall newest?
[19:12] <bialix> go to Download page, look for Ubuntu and read instructions
[19:12] <Phill> kk
[19:13] <bialix> you should be able to aapt-get
[19:13] <Phill> Oh cool, it has it's own apt server.
[19:14] <Phill> Didn't know this.
[19:18] <bialix> many people don't know
[19:19] <Phill> I don't get it... bzr is worked on by conical - why don't they just put it in the main repo branch?
[19:19] <Phill> Bazaar (bzr) 1.11
[19:19] <Phill> Now what?
[19:20] <bialix> where?
[19:20] <Phill> Huh? That's what my up-to-date bzr is.
[19:20] <Phill> 1.11, rather than whatever it use to be.
[19:20] <bialix> now `bzr alias` will work :-)
[19:21] <Phill> Cool.
[19:21] <bialix> :-D
[19:22] <Phill> Ok, so if I do bzr resolve, it delete the >>TREE stuff, right?
[19:23] <bialix> yep
[19:23] <bialix> np
[19:23] <bialix> no
[19:23] <bialix> sorry
[19:24] <Phill> Confused, what?
[19:24] <bialix> you need to resolve conflict (with meld e.g.) and then run `bzr resolve`
[19:24] <Phill> meld?
[19:25] <bialix> if the file has no '<<<< >>>>' markers then .THIS .BASE .OTHER files will be deleted
[19:25] <Phill> Yeah, it's just a properties file that I don't care about, so I removed the <<<< markers and called it a day. ;-)
[19:25] <Phill> Probably not a good thing, but whatever.
[19:26] <Phill> Ok, here's a good one.
[19:26] <Phill> Text conflict in pangea/nbproject/genfiles.properties
[19:26] <Phill> That file doesn't exist?
[19:27] <Phill> Found out why, I deleted it, my bad. Nevermind.
[19:30] <Phill> Ok, so all my conflicts are gone, thanks to ya' :) Though, here's what I need help with, sorta? It'll take a second to type it down - ready?
[19:31] <Phill> I've branched from revision 20 (the last one that worked) and pulled to 21, and then fixed the conflicts. The latest revision however is 23.
[19:32] <Phill> How can I merge with 22-23?
[19:37] <bialix> brrr
[19:37] <bialix> again
[19:37] <bialix> bzr commit your current state
[19:38] <Phill> Did so
[19:38] <bialix> then bzr merge
[19:38] <Phill> I did...
[19:38] <Phill> bzr merge --pull
[19:38] <bialix> so?
[19:38] <bialix> bzr st
[19:38] <Phill> actually, I did bzr merge --pull -r 22
[19:38] <Phill> I don't want rev 23 atm.
[19:38] <Phill> Two conflits.
[19:38] <Phill> Conflicts*
[19:38] <bialix> resolve them
[19:39] <bialix> then commit
[19:39] <Phill> Ok, this is a different conflict though.
[19:39] <Phill> Conflict adding file pangea/build/classes/pangea/resources/New Folder.
[19:42] <Phill> The other thing is I have "PangeaVIew.class" to PangeaView$39.class, (Using Netbeans) but I think these files were from bzr. Do I need them?
[19:42] <Phill> Nevermind, I answered my own question, Yes I do need them.
[19:56] <Phill> bialix: Ok, so - here's one more thing I want to know how to do, remove stuff from bzr version control.
[19:56] <Phill> I have a lot of junk classes and old images I no longer want bzr to keep track of, in fact, I wanted them deleted.
[19:56] <Phill> What do I do?
[19:59] <bialix> either just delete them
[19:59] <bialix> or use bzr remove
[20:00] <bialix> with bzr remove you have fine grained control, read `bzr remove -h`
[20:00] <Phill> I used bzr remove.
[20:01] <Phill> Deleting them made bzr just throw them back up when I pull again.
[20:01] <bialix> delete + commit
[20:01] <bialix> but `bzr remove` is better way
[20:01] <Phill> Mmk.
[20:01] <bialix> "explicit"
[20:01] <Phill> Off hand, what's the better thing about it?
[20:02] <bialix> explicit is better than implicit
[20:02] <bialix> just don't forget commit
[20:03] <bialix> Phill: try this `python -c "import this"` :-D
[20:04] <Phill> I've learned not to use commands that I don't know, but hey, you can try rm -r /
[20:04]  * bialix on Windows
[20:04] <Phill> Oh right.
[20:04] <Phill> Darn.
[20:04] <bialix> :-P
[20:04] <Phill> Open up fdisk and figure out how to nuke your cdrive, I'm to lazy. ;-P
[20:05] <bialix> format c:
[20:05] <bialix> it's easy
[20:05] <Phill> Yeah, I've since forgotten 90% of the commands that aren't related to the Cisco IOS.
[20:05] <Phill> It's a bummer.
[20:05] <bialix> ok
[20:07] <Phill> Ok, now this is the last thing, bzr alias?
[20:08] <thumper> morning
[20:08] <bialix> just remembered: if you like the risk in life, try to run format c: drive
[20:08] <Phill> Thumper?
[20:08] <thumper> Phill: I may have missed some context, but aliases aren't exactly new
[20:08] <Phill> Oh no, I think I recognized you from another form.
[20:08] <Phill> forum*
[20:08] <bialix> Phill: last thing for what?
[20:08] <bialix> thumper: hi
[20:09] <Phill> Thumper: Ever been on the Firefox support forums?
[20:09] <thumper> Phill: no
[20:09] <Phill> Thumper: Wrong thumper then.
[20:09] <bialix> no, he's right thumer
[20:10] <thumper> Phill: just different :)
[20:10] <Phill> Ahh.
[20:11] <Phill> What's a good alias for bzr merge --pull ...
[20:11] <bialix> maybe: get-the-new-stuff
[20:11] <bialix> ;-)
[20:12] <Phill> Mmm.
[20:12] <Phill> get-new
[20:12] <Phill> OR, sync.
[20:12] <bialix> not bad
[20:12] <Phill> get-sync
[20:12] <bialix> actually I think "sync" is good
[20:13] <Phill> yep
[20:13] <Phill> and the command was "merge --pull" right?
[20:13] <bialix> right
[20:13] <Phill> Neeto.
[20:13] <Phill> That's not a word.
[20:14] <bialix> не то?
[20:14] <bialix> or не это?
[20:14] <Phill> I don't know?
[20:15] <Phill> Ok, so, when I push back up, I can just run bzr push right?
[20:15] <bialix> never mind
[20:15] <Phill> Or should I do "bzr merge --push" ?
[20:15] <bialix> yes
[20:15] <bialix> no
[20:15] <Phill> ok
[20:15] <bialix> merge is when you get the new stuff
[20:16] <bialix> you can't do merge for remote server
[20:16] <bialix> just push
[20:17] <Phill> Oh ok.
[20:17] <Phill> Well thanks.
[20:17] <Phill> Any other cool things you could teach me about launchpad and bzr? lol
[20:18] <bialix> tomorrow
[20:19] <Phill> haha
[20:19] <Phill> sure ;-)
[20:25] <lifeless> Adys: just revert foldername
[20:25] <lifeless> Adys: or if you want to revert everything, just 'revert'
[20:53] <tro> did anyone end up volunteering for that editor thing kfogel proposed on the ml?
[20:57] <Stavros> hello
[20:57] <Stavros> i tried to do bzr shelve and bzr is crapping out now
[20:57] <Stavros> i have 1.11
[21:03] <garyvdm> Stavros: crapping out -> how? Can you pastebin a traceback?
[21:03] <Stavros> it's not crashing, but bzr shelve tells me that it can't acquire a lock and then does strange stuff like telling me to break a lock before telling me again it can't acquire another
[21:04] <Stavros> bzr: ERROR: Could not acquire lock "repo/.bzr/checkout/dirstate"
[21:04] <garyvdm> It should tell you who created the lock that is blocking you.
[21:04] <Stavros> i'm the only user
[21:04] <tro> Stavros: are you using windows?
[21:04] <Stavros> yes
[21:05] <tro> i think you may be using the new shelf (shelf2) which doesn't work with windows yet
[21:05] <Stavros> oh
[21:05] <Stavros> hmm
[21:05] <Stavros> shouldn't it print something, then? :/
[21:05] <tro> there's probably a way to use shelf1. maybe someone else knows?
[21:05] <Stavros> it's okay, i just wanted to shelve one file, so i committed it, but the errors were odd
[21:06] <tro> i'm still using an older version of bzr, so i don't know what the solution is, sorry :/
[21:06] <Stavros> ah, thanks anyway
[21:15] <thumper> you could alias shelve to shelf1 (if that is the command)
[21:16]  * thumper wonders why the new shelve doesn't work with windows
[21:16]  * thumper looks at abentley
[21:16] <thumper> abentley: should the new shelve have problems with windows?
[21:17] <bialix> 1.12 should work fine
[21:17] <bialix> jam fixed it
[21:49] <garyvdm> Hi bialix
[21:50] <bialix> Hi Gary
[21:50] <bialix> I've edited NEWS
[21:50] <bialix> you'd better look at it with fresh eye
[21:50] <garyvdm> Ok - will do
[21:50] <bialix> because difftools is not mandatory thing
[21:51] <bialix> as you said
[21:51] <bialix> Do you have specific question to me?
[21:51] <garyvdm> I've been trying to build a deb - but I got frustrated - move on to more intresting things.
[21:51] <garyvdm> I'm looking at how I can use igc's revno-cache plugin to improve qlog's startup performance
[21:51] <bialix> ouch
[21:52] <bialix> garyvdm, we can skip the deb, I guess
[21:52] <bialix> at least people don't poke us everyday
[21:52] <bialix> as they are do about bzrtools
[21:52] <bialix> ;-)
[21:52] <garyvdm> And the deb can come after the release - hopefully shortly
[21:53] <bialix> garyvdm: about revno-cache
[21:53] <garyvdm> If we use revno-cache - we would have to stop showing the children in the revision plane
[21:53] <bialix> igc told me it's working mostly as revno->revid map today
[21:54] <garyvdm> because you have to walk the whole tree to find the children.
[21:54] <bialix> um? sorry, can you explain
[21:54] <garyvdm> In the bottom plane of qlog - we show parent and children for the selected revisions
[21:54] <garyvdm> *revision
[21:54] <bialix> yes
[21:55] <bialix> we show both revno and revid
[21:55] <garyvdm> To find the parents - you just have to make one call to the graph
[21:55] <bialix> I think it should simplify walking through the history
[21:56] <garyvdm> but to find the children - you have to load the parents for every revisions.
[21:56] <garyvdm> Right now - we have to do that anyway to create merge_sorted_revisions
[21:57] <kfogel> tro: no, but people have been writing the scenarios, and I've been using them to help with, e.g., http://www.emacswiki.org/emacs-en/EmacsBzrSwitchover
[21:57] <bialix> wait, I'm running qlog to follow you
[21:57] <kfogel> tro: I suspect I'll just end up editing them myself
[21:57] <kfogel> tro: unless... you're volunteering to help? :)-
[21:57] <kfogel> :-)
[21:57] <garyvdm> revno-cache caches merge_sorted_revisions
[21:58] <garyvdm> I can do all the other functionality just from the data from merge_sorted_revisions - with out loading the whole graph
[21:58]  * bialix ran qlog with LANG=C and sees now what garyvdm means
[21:59] <garyvdm> except displaying children
[21:59] <bialix> this is qreat idea
[21:59] <garyvdm> qreat - intentional mistake?
[21:59] <bialix> no, by Freud
[21:59] <garyvdm> ha ha
[21:59] <bialix> so
[22:00] <bialix> we'll lose the ability to find branched history?
[22:01] <bialix> I can't say I'm use the parent/children links too much
[22:01] <garyvdm> No - qlog will be able to do everything it currently does, except display children in the revision plane.
[22:01] <bialix> so I'm probably even did not notice if they disappear
[22:01] <garyvdm> And only load the parent for the revisions that are diaplayed
[22:02] <bialix> garyvdm: I mean no more click on children will go to that revision
[22:02] <garyvdm> Yes
[22:02] <bialix> may be it's better to post this as rfc to qbzr ml. if luks won't object -- I'll be fine
[22:03] <garyvdm> Ok - WIll do
[22:03] <bialix> in theory we can load this data lazily in the background after main history has loaded?
[22:03] <garyvdm> Yes - we can do that to
[22:04] <bialix> how we'll behave without revno-cache?
[22:04] <garyvdm> Good idea
[22:04] <garyvdm> Same as before
[22:04] <bialix> I like it
[22:04] <bialix> qbzr reuse many goodness already exisiting in bzr world
[22:04] <garyvdm> And it will only do this if you are loading 1 branch.
[22:05] <bialix> btw Gary, I'd like to discuss with you dichotomy with 1/several branches
[22:05] <garyvdm> If you are loading more than 1 branch - It will have to load everythin.
[22:05] <bialix> ah
[22:05]  * garyvdm looks up the meaning of dichotomy
[22:05] <jelmer> Jc2k, I fixed dpush into git on the train, it's working now :-)
[22:06] <bialix> garyvdm: I want to add more actions to context menu
[22:06] <garyvdm> ok
[22:06] <bialix> like tags, push, merge
[22:06] <garyvdm> revert
[22:07] <bialix> but those actions should know the branch
[22:07] <bialix> I need either allow actions for 1 branch mode
[22:07] <poolie> lifeless: why did you approve johnf for bzr-beta-ppa?
[22:08] <bialix> garyvdm: or to have the proper way detect/select branch in multi mode
[22:08] <garyvdm> It's easy to get from a revision to a branch/repository
[22:08] <bialix> garyvdm: this is also related to bug about taga on multibranches
[22:08] <bialix> s/taga/tags/
[22:08] <garyvdm> but a revision may have more than one branch.
[22:09] <bialix> this is *the* problem
[22:09] <bialix> can you suggest easy way to detect if qlog started in multibranch mode?
[22:10] <garyvdm> My re-factored branch is much better at this.
[22:10] <bialix> IIRC t should landed shortly
[22:10] <garyvdm> len(log_list.graph_provider.branches)
[22:11] <garyvdm> Yes - I'll land it after we release 0.9.7
[22:11] <bialix> poolie: hi, plans about 1.12 is the same? we need to release QBzr in sync with bzr
[22:11] <poolie> bialix: still planning to do rc1 tomorrow my time and final friday
[22:11] <poolie> synchronized release would be nice
[22:12] <bialix> garyvdm did very good job to support new progress bar
[22:12] <bialix> he's our release manager for 0.9.7 :-)
[22:12]  * garyvdm is nervous
[22:12] <poolie> ah great :)
[22:13] <bialix> poolie: your time is about?
[22:13] <poolie> utc+11
[22:13] <poolie> ie it's monday morning now
[22:13] <garyvdm> Down under?
[22:13] <bialix> garyvdm: ?
[22:14] <garyvdm> Slang for  Australia/New Zeeland
[22:14] <bialix> ah
[22:14] <garyvdm> reference to it's position on the world map
[22:15] <bialix> garyvdm: I think you can release it anytime soon
[22:15] <bialix> even tonight, if you like
[22:15] <garyvdm> Ok
[22:15] <bialix> I'll be there couple of hours, coding scmproj
[22:16] <bialix> so you can ping me if needed
[22:16] <garyvdm> Thanks
[22:16] <bialix> I'm usually simply follow the instruction
[22:20] <lifeless> poolie: because he's going to help keep the ppa up to date?
[22:37] <garyvdm> bialix: Should I mention updated translations in NEWS.txt?
[22:38] <bialix> garyvdm: I never do this, only new ones
[22:38] <garyvdm> Ok
[22:38] <bialix> the list of updated could be loong sometimes
[22:40] <poolie> lifeless: is he?
[22:40] <garyvdm> poolie: do you think this will land before 1.12? http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C20090126072506.GA30864%40steerpike.home.puzzling.org%3E
[22:41] <garyvdm> It causes a bug in qbzr.
[22:41] <poolie> lifeless: ok i see your reply to jam about that
[22:41] <poolie> did he suggest it offline?
[22:42] <poolie> i'm just asking because people seem to randomly request to join groups all the time
[22:42] <lifeless> poolie: yes, he chatted here on friday about that; he packages stuff elsewhere in Debian format (I don't recall if he's a DD offhand), etc
[22:42] <poolie> because of poor ui i guess
[22:42] <poolie> great
[22:42] <lifeless> poolie: so, randoms I would have declined :P
[22:42] <poolie> also iwbn if the 'request to join' let people specify a rationale
[22:42] <poolie> i realize he's not very random
[22:45] <poolie> lifeless: ah, bug 4976
[22:50] <garyvdm> ls
[22:50] <lifeless> abentley: if you could review http://bundlebuggy.aaronbentley.com/project/bzr/request/%3C1233892193.12070.112.camel%40lifeless-64%3E that would be lovely
[22:50] <lifeless> abentley: its a shelve/treetransform bug and I'm on shaky ground there
[22:52] <bialix> poolie: can you help gary?
[22:53]  * poolie looks
[22:54] <poolie> garyvdm, bialix: i approved it (enthusiastically :-) so we need to poke spiv
[22:54] <poolie> i think vila's approach is a bit better, of hooking in at the socket level
[22:54] <poolie> but we can unify them later
[22:54] <garyvdm> Actualy - I'm hoping it's not going to land :-(
[22:54] <garyvdm> >	It causes a bug in qbzr.
[22:55] <poolie> oh i see
[22:55] <poolie> i thought you meant lack of it causes a bug
[22:55] <Jc2k> jelmer: awesome!
[22:56] <lifeless> garyvdm: whats the bug
[22:57] <garyvdm> Bug 325924
[22:57] <poolie> srsly
[22:58] <poolie> that exception should be shot
[23:00] <bialix> garyvdm: it affects on;y qlog?
[23:00] <bialix> only
[23:01] <garyvdm> In theroy no - but in pratice - I have not seen it any where else
[23:01] <garyvdm> Let me do some testing
[23:02] <spiv> garyvdm: I find it odd that the traffic-smart branch would cause that.
[23:02] <spiv> Unless it's because of some side-effect like the GUI blocking without it?
[23:03] <lifeless> spiv: or not blocking
[23:03] <lifeless> garyvdm: does qbzr use threads, or is it synchronous?
[23:03] <garyvdm> synchronous
[23:04] <garyvdm> It's really a bug with qbzr - not that branch
[23:04] <garyvdm> When we get notified of transport activity - we do a processEvents()
[23:05] <garyvdm> Which would allow more than 1 simultaneous request.
[23:07] <bialix> garyvdm: what's there before?
[23:08] <bialix> maybe we need temporarily disable monitoring of transport activity in qbzr?
[23:12] <spiv> garyvdm: ah, in that case I'd expect vila's patch for HTTP traffic reporting would cause the same issue with bzr+http://
[23:13] <lifeless> garyvdm: so processEvents handles an aritrary amount of user input ?
[23:13] <garyvdm> spiv: I'm not sure - I don't know the transport code to well.
[23:14] <garyvdm> spiv: It will happen with any transport that does not allow concurrent requests, and reports traffic.
[23:15] <lifeless> we have a sync api to transport
[23:15] <lifeless> garyvdm: can you not call processEvents?
[23:16] <garyvdm> lifeless: Then it won't display the transport activity
[23:17] <garyvdm> lifeless: processEvents is normally called in the event loop, but you can also call it during long running processes to keep the ui responsive.
[23:18] <garyvdm> http://doc.trolltech.com/3.2/qeventloop.html#processEvents
[23:18] <garyvdm> Newer version: http://doc.trolltech.com/4.0/qeventloop.html#processEvents
[23:22] <bialix> garyvdm: but I see you've disabled user input. this is not enough?
[23:22] <garyvdm> Was just about to give some detail on that - just a sec
[23:22]  * bialix waits
[23:23] <garyvdm> That fixes that bug in 99% of cases
[23:24] <garyvdm> In qlog: when you click on a rev - we set a timer to load the delta to show that changed files.
[23:25] <bialix> yes
[23:25] <garyvdm> That timer may get called from a processEvents called during notify_transport_activity
[23:25] <bialix> got it
[23:27] <bialix> imo we have hidden problem there
[23:27] <bialix> even for concurent transports
[23:28] <bialix> as a quick fix we can use some flag at qlog instance to prevent loading delta untill we finishing with main request
[23:28] <garyvdm> bialix: What's that?
[23:29] <garyvdm> (hidden problem)
[23:29] <bialix> we don't have a way to reuse connection?
[23:29] <garyvdm> bialix: We do reuse connections
[23:30] <bialix> but anyway we got the error
[23:31] <bialix> I think simple queue may help as you wrote in bug report
[23:31] <bialix> but it'snot quick fix
[23:33] <bialix> we talk about log.py update_revision_delta?
[23:33] <garyvdm> Yes
[23:33] <bialix> and uifactory?
[23:34] <garyvdm> With my patch to not allow user event - it very difficult to reproduce.
[23:34] <garyvdm> Yes
[23:35] <bialix> mmm
[23:35] <poolie> (out for a little bit)
[23:36] <garyvdm> http://pastebin.com/d26b9c3b1
[23:38] <garyvdm> bialix: log.py update_revision_delta is the only place I've been able to reproduce it.
[23:39]  * bialix looks
[23:39] <garyvdm> bialix: How about - in update_revision_delta - try... execpt TooManyConcurrentRequests reschedule the timer
[23:40] <garyvdm> as a quick fix.
[23:40] <bialix> but the traceback actually points to logmodel
[23:40] <garyvdm> Ahhhh
[23:41] <bialix> i'm thinking about using simple lock
[23:41] <bialix> and if the lock is acquired -- then reshedule the timer
[23:42] <bialix> this will affects any transport
[23:42] <bialix> ?
[23:42] <garyvdm> Yes- as a quick fix
[23:42] <bialix> thread.Lock
[23:43] <bialix> from std lib
[23:43] <garyvdm> That won't work
[23:43] <bialix> ?
[23:43] <garyvdm> Here is a different traceback from my .bzr.log: http://pastebin.com/d7d18c473
[23:44] <garyvdm> bialix: we are not using threading.
[23:44] <garyvdm> A simple is_loading_revisions will do though.
[23:45] <bialix> IMO this lock should not require real threading
[23:45] <bialix> ok, fine
[23:46] <bialix> re 2nd traceback: yep, i guess it's 50%-50% effect
[23:47] <bialix> anyway we disable input
[23:47] <mwhudson> hm
[23:47] <garyvdm> Long term fix - have a queue - re-enable input
[23:47] <mwhudson> i remember bzr has some knob you can twiddle wrt decorators like @needs_read_lock
[23:48] <mwhudson> do you get fast or pretty ones by default?
[23:48] <lifeless> fast by default I beleve
[23:49] <mwhudson> oh goof
[23:49] <mwhudson> good!
[23:51] <garyvdm> mwhudson: All the requests that qbzr make allready have read_locks. It unfortunately does not prevent TooManyConcurrentRequests
[23:51] <bialix> garyvdm: agree. we can live with current situation for a while
[23:51] <garyvdm> Anyway - we don't want to prevent the request - we want to make it happen later.
[23:53]  * bialix mutters: although for local branch we can avoid locking
[23:53] <mwhudson> garyvdm: i'm worrying about my own problems, not yours :)
[23:53]  * bialix out of good ideas
[23:54] <garyvdm> bialix: Not necessary to not lock for local - because local does not report transport.
[23:54] <garyvdm> mwhudson: oh!
[23:55] <bialix> garyvdm: it's a bit late for me. sometimes morning is smarter than evening. don't worry too much about 1% bug tonight
[23:55] <garyvdm> I'm a night owl... I'm sure I can put a quick fix in.
[23:56]  * garyvdm ignores irc for a while.
[23:56]  * bialix too, but he needs to sleep sometimes
[23:56] <bialix> garyvdm: bye


[07:36] <slyon> Hey! Could somebody with the powers please re-trigger the netplan/focal test on ppc64el, arm64 & amd64 https://autopkgtest.ubuntu.com/packages/netplan.io/focal/ppc64el ? It failed for flaky tests... was successful before in bileto.
[11:22] <Laney> slyon: pretty much all of the autopkgtests are failing for me now when trying a test run locally in qemu... do you know why?
[11:23] <slyon> Laney: not sure... let me re-try that locally as well. I verified that all were working before the upload.
[11:24] <Laney> I'll try to re-run one arch on focal
[11:26] <slyon> thank you
[11:53] <Laney> seems to be working, so I did the others
[11:53] <Laney> no idea why qemu isn't working properly :(
[12:11] <cpaelzer> slyon: what is your commandline to get qemu autopkgtest runners?
[12:11] <cpaelzer> ... -- qemu --qemu-options='-cpu host' --ram-size=1536 --cpus 2 ~/work/autopkgtest-groovy-amd64.img
[12:11] <cpaelzer> would be my tail that I use for these most of the time
[12:13] <slyon> Laney: cpaelzer: qemu is doing good for me so far, it's still in the middle of the test, but all tests passed up to now. I do not have any special commandline, just using "-- qemu ./autopkgtest-focal-amd64.img"
[12:15] <Laney> like that but without --cpus 2
[12:15] <Laney> autopkgtest --timeout-copy=6000 --apt-pocket=proposed=src:netplan.io netplan.io -- qemu --ram-size=1592 autopkgtest-focal-amd64.img
[12:16] <Laney> pretty much everything broke, way more than did in the runs that failed on autopkgtest.u.c so I don't even
[12:17] <Laney> https://paste.ubuntu.com/p/8hQwp8wk8G/ for example
[12:17] <Laney> but running that without the --apt-pocket=proposed=src:netplan.io was mostly good https://paste.ubuntu.com/p/Ym5QhHHsJ9/
[12:23] <slyon> That's interesting... I can reproduce it if I use --apt-pocket=proposed=src:netplan.io (instead of using the source dsc). I need to look into that
[12:24] <slashd> rbasak: could you please reject my 'sosreport' upload in bionic ? I need to arrange a few things and will re-upload later.
[12:25] <slashd> re: LP: #1892275 ^
[12:37] <rbasak> slashd: sure
[12:37] <slashd> rbasak: thanks
[13:51] <xnox> dpkg-genchanges: error: cannot fstat file ../linux-firmware-raspi2_1.20200902-0ubuntu2_amd64.buildinfo: No such file or directory
[13:51] <xnox> dpkg-buildpackage: error: dpkg-genchanges subprocess returned exit status 25
[13:52] <xnox> anybody had this before, whilst building source build of the package only?
[14:00] <jchittum> LocustusOfBorg: i updated lp:1895862 with more information. I took the path of using the pre-installed virtualbox-guest-utils module. However, attempting an upgrade or install will fail. This will end up breaking anyone using the vagrant-vboxguest plugin or that installs an update via automation (such as Ansible)
[15:24] <cousteau> Hi, I had to rebuild and install package `git`.  Now `apt policy git` shows two candidates: 1:2.25.1-1ubuntu3 500 (the one from repos) and 1:2.25.1-1ubuntu3 100 (the one I installed).  Now, if I `apt-get install git`, for some reason it thinks the one from repos is more modern than the custom one I built and installed, and reinstalls the one from repos
[15:24] <cousteau> I have no idea what those 500 and 100 mean
[15:25] <cousteau> (on an unrelated note, git with GnuTLS doesn't work on my company network)
[15:35] <cjwatson> You should change the version if you rebuild it locally
[15:35] <cjwatson> Increase it very slightly, e.g. 1:2.25.1-1ubuntu3+local1
[15:47] <cousteau> cjwatson: I suspected that.  After some research, apparently the 500 is a pin priority established by apt_preferences(5)
[15:47] <cjwatson> It's possible to adjust pinning, but much easier to change the version
[15:47] <cousteau> Now let's see how easy it is to change the version number.  Guess it's a matter of touching the DEBIAN file
[15:47] <cjwatson> Just requires sticking a new entry at the top of debian/changelog
[15:47] <cjwatson> Do not ever touch DEBIAN (all-caps) manually
[15:48] <cjwatson> You modify packaging metadata by editing things under debian/ (all lower case) in the source package
[15:48] <cousteau> Or the... whatever file that later generates the DEBIAN
[15:48]  * cousteau followed a tutorial mostly blindly and didn't have much idea what he was doing
[15:49] <cjwatson> Any tutorial that advises touching DEBIAN/ (all-caps) should be cast into the sea and replaced with some other tutorial :)
[15:49] <cjwatson> It's a good filtering mechanism
[15:50] <cousteau> Yeah sorry.  I just remembered there was a DEBIAN file or folder so I mentioned that
[15:50] <cjwatson> Yeah, it's an internal detail used by dpkg when assembling the control.tar part of the binary package
[15:51] <cousteau> In fact this tutorial said to edit debian/control and never mentioned the all caps version
[15:51] <cjwatson> Oh good
[15:51] <cjwatson> But debian/changelog for changing the version
[15:51] <cjwatson> There's a fairly precise format.  The "dch" tool will help
[15:53] <realtime-neil> If Ubiquity doesn't support preseed keys for the `base-installer` component (https://wiki.ubuntu.com/UbiquityAutomation), then how do I tell it which kernel to install? Equivalently, what is the Ubiquity way to do `base-installer/kernel/image`?
[15:53] <cousteau> cjwatson: https://devopscube.com/gnutls-handshake-failed-aws-codecommit/ the tutorial, in case you're curious :)
[15:56] <cjwatson> Yeah, I would generally recommend sbuild instead to keep your main system clean, but that's not wrong
[15:56] <cjwatson> Mostly
[15:57] <cjwatson> But it indeed omits changing the version, which is wrong :)
[16:00] <cjwatson> realtime-neil: I'm several years out of date, but generally speaking ubiquity doesn't have configuration for this sort of thing because it's designed to copy a squashfs instead - you give it a different kernel by preparing a replacement squashfs that contains that kernel
[16:00] <realtime-neil> cjwatson: that's incredibly helpful. How can I edit the documentation to this effect?
[16:03] <paride> hi Laney, did you have a chance to look at the broken xenial migrations? Is there a LP project where it's sensible to file a bug against for this?
[16:05] <Laney> paride: A bit, but I didn't get to the end yet with the sprint and stuff, sorry about that
[16:07] <Laney> you can file it on the 'britney' project
[16:32] <paride> Laney, https://bugs.launchpad.net/britney/+bug/1898907
[16:32] <Laney> merci
[16:40] <cjwatson> realtime-neil: Sorry, I'm too far out of the loop to know where would be best to edit - I used to work on this stuff but not for >5y
[16:41] <realtime-neil> cjwatson: no worries; I'll keep looking around
[19:43] <mwhudson> fwiw subiquity's squashfs doesn't have a kernel in it, but it doesn't really have a sensible hook for letting you change which kernel to install


[10:41] <zxmpi> mmmm, hot porridge
[10:41] <daftykins> :D
[10:44] <daftykins> oh dear there's a bit of sunlight entering the room, showing me all the dust on my monitors + desk again ;)
[11:00]  * zxmpi laughs in irish gloomy cloud cover
[11:02] <zxmpi> it's 11am and i might need to turn on lights it's that dark
[18:48] <zxmpi> mmmm, hot mug of tea


[01:16] <pleia2> most of our planet articles this week are... people arguing about what planet articles should be, fail :)
[01:16] <pleia2> anyway, shipped off to summary writers
[01:16] <pleia2> and condensed all those posts into a single spot because it's too much
[01:24] <jose> :P


[03:35] <lotuspsychje> good morning to all
[06:12] <lordievader> Good morning
[06:25] <ducasse> good morning
[06:26] <Bashing-om> ducasse: Day crew is on ,, us night guys can now retire :)
[06:28] <ducasse> hiya Bashing-om - how have you been? all going well?
[06:39] <Bashing-om> ducasse: Well enough :) .. support has gotten real slow .
[06:42] <ducasse> Bashing-om: no major challenges? well, in a way that's good, i guess.
[06:44] <Bashing-om> and ' nuff again for this session ,, outta here :P
[07:31] <lordievader> Hey ducasse
[07:34] <ducasse> morning lordievader - how are you doing?
[07:34] <lordievader> Doing good here :)
[08:17] <Allie`> morning all
[08:27] <lordievader> 👋
[09:55] <Allie`> y'know what, as much as i strongly oppose some of the ubuntu design decisions... i'm so glad we have a certified hardware program/etc, that's why i'm still here
[10:00] <guiverc> :) @ bot Allie`
[10:00] <Allie`> c:
[14:05] <BluesKaj> Howdy folks
[14:09] <daftykins> hey \o
[14:10] <daftykins> all well in diet america? :)
[14:10] <hggdh> morning
[14:11] <daftykins> o/
[14:11] <hggdh> daftykins: diet America keeps on dieting, and getting, ah, larger
[14:12] <daftykins> just a joke name for Canada :D
[14:16] <BluesKaj> Hey ducass, daftykins, hggdh, well we're more Trump like in ontario, Rob Ford's (former coke snorting mayor of Torornto) brother Doug just won a landslide victory in the Ontario elections ...a promise them everything so called conservative
[14:17] <daftykins> ah so that's who he is, my friend in Hamilton was mentioning voting yesterday
[14:18] <BluesKaj> oop sToronto :-) ...
[14:21] <BluesKaj> yup, I didn't vote his party ..he has no experience in politics on that level, he was a Toronto city councillor before running for the conservative party's leadership, but hemanaged to win that by too many cnadidates splitting the vote
[14:22] <BluesKaj> now we have newbie running the show ...circus is more like it
[14:23] <sonicwind> join the club :-)
[14:24] <BluesKaj> yeah,  goinf downhill fast
[14:28] <BluesKaj> ducasse: , bought a new audio receiver on amazon, supposedly has great sound, not too expensive and enough power for this living room https://usa.denon.com/us/product/hometheater/receivers/avrs540bt
[16:31] <ducasse> BluesKaj: cool, congrats - denon makes good stuff
[16:36] <BluesKaj> ducasse:  yeah, my 13 yr old Harman Kardon still sounds good but I can fix some clunky switching problems between audio and video sources an d still have decent sound
[16:37] <BluesKaj> with the Denon
[16:38] <BluesKaj> the HK will be a bedroom system now
[16:41] <ducasse> you already have speakers for the bedroom system?
[16:42] <daftykins> :D
[16:42] <daftykins> i wish i could get rid of the idle buzz on my bedroom NAD
[16:43] <daftykins> it happens even with speakers detached, so must be the transformer
[16:43] <ducasse> \o daftykins - how's you?
[16:43] <daftykins> pretty good thanks! lazy day today as i'm mostly waiting on other peoples actions to progress some work
[16:43] <daftykins> just plugged in my old das keyboard for a test :>
[16:43] <daftykins> how's things your end?
[16:45] <ducasse> my laptop keyboard is on the fritz - one more reason to consider an upgrade. thinking of buying a refurbished thinkpad.
[16:46] <daftykins> ah yes you mentioned finding the local reseller, sounds like a plan
[16:46] <ducasse> other than that luna and me are good :)
[16:47] <daftykins> i'm still waiting on a client deciding what to do about a system that's failing
[16:47] <daftykins> fools continue to use it despite knowing it's at deaths door
[16:52] <ducasse> i should do something about my fileserver as well, but money
[17:07] <BluesKaj> ducasse yes i have a pair  home built pilips speakers from the 80's and they still sound good
[17:07] <BluesKaj> philips rather
[17:14] <BluesKaj> daftykins:  got one of those led lampa nearby the NAD, those can cause weird noises in audio equipment
[17:15] <BluesKaj> lamps
[17:21] <lotuspsychje> good evening to all
[17:21] <BluesKaj> hey lotuspsychje
[17:22] <lotuspsychje> hey BluesKaj all good on your side?
[17:22] <BluesKaj> yeah, surviving :-)
[17:23] <lotuspsychje> great, weekend here
[17:24] <daftykins> BluesKaj: nah, does it with the speakers disconnected too
[17:24] <lotuspsychje> hey daftykins
[17:24] <daftykins> hmm i think i was going to test it next at another house just to rule out the mains supply
[17:24] <daftykins> hi lotus :) all good in the hood? :)
[17:24] <lotuspsychje> yeah all good here thank you
[17:24] <BluesKaj> yeah so far the weather's nice , lotuspsychjenice
[17:25] <BluesKaj> oops
[17:25] <lotuspsychje> BluesKaj: they predict 'tropical heat' on our side this weekend
[17:25] <BluesKaj> heh, phat phingers missed the back space
[17:26] <BluesKaj> whoa , not fun for you, gonna be 24 and sunny here
[17:26] <EriC^> hey guys
[17:26] <lotuspsychje> yoyo EriC^
[17:27] <EriC^> :D
[17:28] <BluesKaj> hey EriC^
[17:28] <nacc> lotuspsychje: ah it's nice when IntelCore is /ignore'd
[17:28] <BluesKaj> think I'l go back outside and finish trimming ...BBL
[17:29] <lotuspsychje> BluesKaj: have fun
[17:30] <lotuspsychje> nacc: that guy keeps on returning with weird stuff :p
[17:30] <nacc> lotuspsychje: yes, i think they are a troll.
[17:31] <EriC^> hey BluesKaj
[17:32] <lotuspsychje> nacc: lol at they
[17:47] <BluesKaj> well, got roped into setting up a gazebo .looks like I'll be gone for the duration...take care
[17:48] <daftykins> hehehe
[18:47] <EriC^> !ping
[19:03] <lotuspsychje> new factoid
[19:03] <lotuspsychje> !netplan
[19:10] <blackflow> a factoid about snaps would be useful too.
[19:12] <daftykins> pretty sure i'd seen one
[19:12] <lotuspsychje> !snappy
[19:14] <lotuspsychje> blackflow: you can request ideas to factoids if you like
[19:14] <blackflow> yah but snappy ain't it snaps, it's a distro.
[19:15] <daftykins> might be another one, search the db
[19:15] <lotuspsychje> blackflow: how would you describe a snap factoid?
[19:16] <blackflow> lotuspsychje: "Snaps are containerised software packages similar to flatpaks or appimage. For more info, see https://snapcraft.io"
[19:16] <lotuspsychje> good idea
[19:16] <daftykins> comparing to alternatives isn't an explanation though
[19:16] <lotuspsychje> you know howto request?
[19:17] <daftykins> the best descriptions are free from existing examples
[19:17] <blackflow> daftykins: but gives people an idea. "containerized software packages" is the base explanation, imho.
[19:17] <daftykins> "Snaps are images of software including all of a programs dependencies needed to run, avoiding the hassles of incompatible libraries on a host. For more info go to..."
[19:18] <blackflow> "images of software". what's that :)
[19:18] <blackflow> photos?
[19:18] <lotuspsychje> lol
[19:18] <daftykins> hehe, a fair point, but i think you can see what i'm getting at too
[19:18] <daftykins> an ideal would probably be neither of ours
[19:19] <lotuspsychje> blackflow: /query ubottu and !snap is your-description-here
[19:19] <lotuspsychje> blackflow: when found as good idea, the ops will add it
[19:20] <blackflow> lotuspsychje: done, thanks.
[19:20] <lotuspsychje> tnx you
[19:20] <daftykins> now sit back whilst they remain pending for 6 months
[19:20] <daftykins> \o/
[19:20] <lotuspsychje> lol
[19:21] <lotuspsychje> they added/changed some good stuff lately daftykins
[19:21] <daftykins> \o/
[19:37] <lotuspsychje> nite nite all
[19:37] <lotuspsychje> see you another timezone


[08:46] <Mamarok> taking this here: any reason why our Frameworks is still at 5.68.0?
[08:47] <RikMills> Mamarok: what release? in the archive or backports PPA?
[08:47] <Mamarok> plain 20.04
[08:48] <RikMills> we can't update frameworks in the archive as it introduces new features
[08:48] <Mamarok> I haven't reactivated the backports yet
[08:49] <RikMills> backports PPA will get frameworks 5.70 sometime soon, when I fix the animation speed issue it would cause
[08:50] <RikMills> 5.70 only landed in 20.10 release pocket last night, and we skipped 5.69
[08:51] <Mamarok> ok
[08:52] <Mamarok> that monitor position issue I posted earlier in #plasma is bugging me, can't reproduce this, the only time I had a monitor behaving erratically was when it was connected to a docking station
[08:52] <RikMills> I missed that
[08:52]  * RikMills looks
[08:53] <Mamarok> https://forum.kde.org/viewtopic.php?f=17&t=165932
[08:54] <Mamarok> I installed 20.04 on my old wor laptopp now, which has its primary screen on the left, the other one has its primary on the right, no issues
[08:54] <Mamarok> even same brand of monitor
[08:54] <Mamarok> work* laptop*
[08:57] <RikMills> hmmm.


[01:13] <Eickmeyer[m]> OvenWrks: Did you hear from Mauro about joining the Ubuntu Summit? Do you think you'd be able to go?
 "OvenWrks: Did you hear from..." <-  OvenWrks: it would be great to have you there.
[21:04] <RuthCheesleysheh> Made a few changes to these pages just to make them more readable:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/03b8beaccf0eba3401ddcdcd9f90b2b62d075ebc)
[21:07] <Eickmeyer[m]> Ruth Cheesley (she/her): To be honest, that has always confused me as well. As far as I know, help.ubuntu.com has always been just general community-contributed help pages, whereas wiki.ubuntu.com is official documentation and developer information, but I'm not 100% sure.
[21:07] <RuthCheesleysheh> OK - there did seem to be quite some duplication
[21:08] <RuthCheesleysheh> Just wanted to make sure I understood what should live where!
[21:08] <Eickmeyer[m]> Thomas Ward: Do you have any better explanation than I?
[21:08] <Eickmeyer[m]> (that's assuming he answers)
[21:08] <Eickmeyer[m]> Maybe Simon Quigley Might have a better answer.
[21:09] <arraybolt3[m]> (Just popping in to say distrho-ports progress is continuing - I think I'm almost to under 5000 entries in the progress file.)
[21:10] <Eickmeyer[m]> arraybolt3: Awesome! Yeah, it's... a marathon, not a sprint. Glad you have the time to do it, I know I was busy mixing a live stream this morning. I get called-in to do those from time-to-time.
[21:10] <arraybolt3[m]> The thing is HUGE! Thankfully, once it's done once, a git diff should show how it changes and allow future updates to be much easier.
[21:11] <Eickmeyer[m]> arraybolt3: Yeah, but you should have push access, so don't worry about diffing it. I'll look at your commit and make changes if necessary. It's a collaborative effort more than a review effort at this point.
[21:12] <Eickmeyer[m]> Unless you're doing the diff for your own benefit.
[21:12] <Eickmeyer[m]> Ruth Cheesley (she/her): It's a Sunday, so don't be surprised if we don't get better clarification on that today. I know there's historical context, but I'm fuzzy on the details.
[21:13] <Eickmeyer[m]> Ruth Cheesley (she/her): BTW, the readability is awesome, and thanks for doing the updates! It's fallen behind. Documentation is *so hard* to keep up on!
[21:14] <RuthCheesleysheh> Oh no rush at all. I don't have huge amounts of time so I'm just popping in and doing things as and when I have a bit of time free 🙂
[21:14] <Eickmeyer[m]> I couldn't ask for more!
[21:39] <tsimonq2> > <@rcheesley:matrix.org> Made a few changes to these pages just to make them more readable:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/e9d1ab941762e092ff962f14a6b45b7b158c1c2c)
[21:39] <tsimonq2> That's at least how I remember it
[22:16] <RuthCheesleysheh> Well, I managed to yoink a list of all the pages under wiki. and help. in the Ubuntu Studio section using the sub-pages lists, which I've dumped here: https://docs.google.com/spreadsheets/d/1aKz2rJVfasq1Drvg8urk9_5NdsQSjkdsMopgcUHqu2I/edit?usp=sharing .. can't seem to crawl it with link checker but that might be something server side blocking it being crawled I guess. So at least that's a rough outline of what's actually
[22:16] <RuthCheesleysheh> there
[22:18] <RuthCheesleysheh> The parts which are unlinked are due to probably the most un-user-friendly resource on the planet: https://wiki.ubuntu.com/UbuntuStudio/SubPages
[22:18] <RuthCheesleysheh> 🤣
[22:19] <Eickmeyer[m]> Ruth Cheesley (she/her): Awesome. Obviously some of that is useful, some of it isn't, and some of it is merely historical. It'd be nice to weed-out the stuff that's unnecessary.
[22:19] <RuthCheesleysheh> had to do a bit of jigging around to get them out into a column from an epic long list of three-space-separated slugs
[22:19] <Eickmeyer[m]> I've been doing release notes via the website for the past few releases as it's WordPress, so it's vastly more intuitive and quicker to use than the wiki, hence no new release notes there.
[22:20] <RuthCheesleysheh> Yeah I totally agree. Must be a million times easier!
[22:20] <Eickmeyer[m]> Basically WYSIWYG.
[22:21] <RuthCheesleysheh> Will have a think during the week how best to organise it all visually
[22:21] <Eickmeyer[m]> I can see the Blueprints pieces going away, and a few other deprecated pieces getting deleted.
[22:22] <Eickmeyer[m]> Sounds good.
[22:22] <RuthCheesleysheh> Not sure if you've come across it before but https://diataxis.fr/ can be helpful in organising documentation so folks know where to go to find what they are looking for
[22:22] <Eickmeyer[m]> One of my predecessors was obsessed with documenting everything to the point of duplicating documentation found elsewhere.
[22:23] <RuthCheesleysheh> May not be appropriate here, but it's been quite useful a few other projects I know of
[22:23] <RuthCheesleysheh> Document all the things! hehe
[22:24] <Eickmeyer[m]> I mean, writing manuals for applications we include that already have their own manuals? Knothx.
[22:24] <RuthCheesleysheh> Ah, yeah, that's just a bit of a waste of volunteers time. Single source of truth and all that.
[22:25] <Eickmeyer[m]> Exactly.
[22:25] <Eickmeyer[m]> Now, there are some docs we have that I even still refer to from time to time, like the one on creating a debdiff. I haven't found one like it anywhere else.
[22:26] <Eickmeyer[m]> I think it's somewhere under seed maintenance or something like that.
[22:26] <RuthCheesleysheh> I have started throwing stuff like that into my Obsidian notes .. just so I can find it quicker!
[22:28] <Eickmeyer[m]> Yeah, I usually just bookmark it and sync it everywhere.
 "Thomas Ward: Do you have any..." <- hmm?
[22:57] <Eickmeyer[m]> Thomas Ward: Oh, it was about the wikis, and the difference between wiki.ubuntu.com and help.ubuntu.com.
[23:00] <ThomasWard[m]> ah.  thats an issue that has been escalated to the CC so for now i dont have an answer.
[23:11] <ErichEickmeyer[m> @teward001 See DMs in Telegram
[23:40] <krytarik> Eickmeyer[m]: You can reply to the "dead link to checksums" person now if you wish, I just went through the whole 22.04 release notes page and fixed things I noticed there including that, which btw wasn't dead because of the point release but because it linked to a self-invented MD256SUMS file. XD
[23:43] <Eickmeyer[m]> krytarik: self-invented? Ew.
[23:45] <krytarik> Yeah, apparently you mixed and matched between the old MD5 and the now sole SHA256 at the time of the original release. >_<
[23:52] <Eickmeyer[m]> Oh crap.
[23:53] <Eickmeyer[m]> That's what I get for copy-pasting and editing.