[00:15] <poolie> thumper: yes
[00:19] <poolie> working on ppa now
[00:20] <ubotu> New bug: #209450 in bzr "The error message for "can't find bzr on remote server" when using bzr+ssh is now scary." [Undecided,New] https://launchpad.net/bugs/209450
[00:21] <spiv> bob2: thanks
[00:23] <bob2> I was a bit suspicious of r3313, but reverting to 3312 didn't help
[00:24] <spiv> bob2: I'd probably be suspicious of 3309
[00:41] <ubotu> New bug: #209458 in bzr-loom "combine-thread doesn't result in correct tree parents" [Undecided,New] https://launchpad.net/bugs/209458
[01:06] <poolie> vila, what is ~bzr-upload-devs?
[01:49] <lifeless> There will be a short interruption to bazaar.launchpad.net and the ubuntu wiki to deploy a fix for the performance problems.
[02:47] <uniscript> how do I push a branch into a new svn: repository branch?
[02:50] <spiv> uniscript: I use "svn cp" to make the branch in the repo, then "bzr push" to that
[02:50] <uniscript> but bzr push says I have to merge
[02:50] <spiv> uniscript: there's a bzr-svn bug (https://bugs.launchpad.net/bzr-svn/+bug/203368) you can hit if you do it directly
[02:50] <ubotu> Launchpad bug 203368 in bzr-svn "svn-push a branch with no new history makes surprising commit to SVN repo" [Wishlist,Confirmed]
[02:51] <spiv> Hmm, I'm not sure why that would be.  Perhaps you did "svn cp" from a different revision of the source branch?
[02:51] <uniscript> I should explain I branched an svn: repo from repo1 but want to push up to an empty dir on repo2
[02:51] <spiv> Oh.
[02:51] <spiv> I don't know much about different SVN repositories.
[02:51] <uniscript> any suggestions on how I can achieve this?
[02:52] <spiv> Or rather, about using bzr-svn with them.
[02:52] <spiv> It's not something that SVN is really designed to support, so I'd expect bzr-svn to struggle with it too.
[02:53] <spiv> But if you mail the bazaar list, Jelmer might be able to help.
[02:54] <uniscript> does that mean I have to join another list :(
[02:55] <spiv> You could mail Jelmer directly, I guess (I think his address is in the bzr-svn README file), but I think the list is a better forum, so other people can help and/or learn from the post.
[02:56] <spiv> uniscript: you could join the list, but then set your mailman settings to disable mail delivery.   Can't find it on launchpad :(
[03:01] <ubotu> New bug: #209490 in bzr-loom "bzr-loom does not make it obvious when to use "bzr record"" [Undecided,New] https://launchpad.net/bugs/209490
[03:01] <spiv> uniscript: https://lists.ubuntu.com/mailman/listinfo/bazaar
[03:02] <spiv> uniscript: (it's linked from http://www.bazaar-vcs.org/)
[03:02] <uniscript> sorry, just being frustrated with launchpad. Never seem to be able to find what I want there
[03:03] <uniscript> the classic is: this package keeps it's bug tracking somewhere else, but doesn't say where that somewhere else is
[03:46] <awmcclain> How would I ignore a file ".foo" in every directory of my branch?
[03:48] <lifeless> bzr ignore **/.foo
[03:48] <lifeless> probably quoted: bzr ignore '**/.foo'
[03:50] <awmcclain> Thank you!
[03:53] <Verterok> lifeless: hi
[03:53] <awmcclain> If i merge a branch, does the .bzrignore file merge as well?
[03:53] <lifeless> awmcclain: yes
[03:53] <lifeless> Verterok: hi
[03:53] <awmcclain> No reason it wouldn't.
[03:53] <awmcclain> Great.
[03:54] <Verterok> lifeless: do you have time for a quick question about my patch for custom properties in log?
[03:54] <lifeless> sure
[03:54] <Verterok> I not sure what I should fix in the docstrings of the show_properties method
[03:54] <Verterok> the gmane thread is: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/38101
[03:56] <Verterok> lifeless: I already added the tests for error case and added error handling code in the show_properties method
[03:56] <awmcclain> Is "no handlers could be found for logger "bzr" a bzr message?
[03:58] <lifeless> awmcclain: its coming from pythons logging framework
[03:58] <lifeless> awmcclain: are you using the bzr frontend or some other script ?
[03:58] <awmcclain> lifeless: I'm running bzr automatically from capistrano.
[03:58] <awmcclain> Maybe I have an unmet dependency on the box?
[04:03] <lifeless> awmcclain: no sure; whats capistrano ?
[04:04] <awmcclain> lifeless: A nifty automated deployment framework. Basically I'm sshing into a minimally configured ubuntu box and running bzr up --lightweight, and I'm getting back that message (everything is working though)
[04:04] <lifeless> hmm, could be a missing thing I guess
[04:05] <lifeless> please file a bug, for extra credit with how-to-reproduce
[04:05] <awmcclain> lifeless: Okee doke. I've read on launchpad that it may be related to a lock file? Could that be?
[04:05] <lifeless> doubt it
[04:05] <awmcclain> Yeah, me too.
[04:06] <awmcclain> Sounds like a dependency thing.
[04:06] <lifeless> I'd guess race condition with the logging infrastructure setup
[04:06] <awmcclain> lemme try logging in directly
[04:06] <awmcclain> and see
[04:10] <awmcclain> lifeless: Ok, it's not a capistrano thing.
[04:11] <jamesh> lifeless: I had a bit of a play with bzr-loom.  It is quite useful, although the UI doesn't quite feel right
[04:11] <lifeless> jamesh: I saw your bug - thanks.
[04:11] <jamesh> perhaps that's just because I'm not used to it yet
[04:12] <jamesh> lifeless: is there any reason why the unrecorded loom state is in the branch rather than working tree?
[04:16] <lifeless> jamesh: yes, its branch related not tree related
[04:16] <jamesh> lifeless: I guess I'd see the last recorded loom state as being branch related, but the unrecorded state as working tree related.
[04:18] <abentley> awmcclain: Not lock file, log file.
[04:18] <abentley> You probably don't have permission to write ~/.bzr.log
[04:19] <awmcclain> abentley: Actually, I was talking about lock, as described here: https://answers.launchpad.net/bzr/+question/19988
[04:21] <awmcclain> abentley: That's exactly it. The .bzr.log file is owned by root!
[04:21] <abentley> Happy to help.
[04:21] <awmcclain> Must be because the first time I run bzr I sudo?
[04:21] <awmcclain> hrmmm
[04:22] <awmcclain> I suppose I could just touch .bzr.log before I start.
[04:22] <awmcclain> Yay!
[05:54] <Peng> jelmer: Should I back up .bazaar/subversion.conf? If it's lost, will I have to fix the branching scheme next time I pull or something? What if I keep subversion.conf but svn-cache gets deleted?
[08:21] <mdke> anyone understand this? http://pastebin.ubuntu.com/6253/
[08:23] <bob2> ubuntudoc was converted from svn
[08:23] <bob2> so needs to be branched into a "rich-root"-supporting repository
[08:23] <bob2> alas bzr co doesn't realise that
[08:24] <mdke> you mean that the downloader has got a shared repository set up there with a different format?
[08:24] <bob2> no, bzr co defaults to one that doesn't support rich-root
[08:24] <mdke> hmm.
[08:25] <mdke> is rich-root the same as "dirstate-with-subtree"?
[08:25] <mdke> that's the one we have
[08:25] <bob2> afaik the work around is "bzr init-repo --rich-root-pack ubuntu-doc ; bzr co http://launchpad-asdjfhsaldfhas/trunk ubuntu-doc/trunk" or similar
[08:25] <spiv> rich-root is a feature some formats support.
[08:26] <mdke> spiv: and dirstate-with-subtree supports it?
[08:26] <spiv> dirstate-with-subtree is one format that supports that (and also some experimental feature); rich-root-pack is the newest and best format for rich-root support.
[08:27] <mdke> is there a converting tool between the two?
[08:27] <jamesh> "bzr upgrade"?
[08:27] <bob2> bzr upgrade will convery branches
[08:27] <bob2> but that doesn't help that person
[08:27] <mdke> I tried that, it failed and trashed my branch
[08:27] <spiv> And you can generally "bzr pull" etc revisions into a compatible repository.
[08:27] <mdke> I couldn't even restore the backup
[08:28] <mdke> I should have written down the error
[08:28] <bob2> that's quite bad, since the backup is done by more or less "cp -r"
[08:28] <bob2> or was it mv
[08:29] <mdke> I wonder if I was trying to restore it to the wrong place, I had a shared repo at the time
[08:29] <spiv> bob2: there's a bug in upgrade in some situations involving shared repos
[08:29] <bob2> ah
[08:29] <mdke> double ah
[08:29] <spiv> bob2: that can leave things in a busted (but recoverable by hand) state
[08:30] <mdke> anyway, I don't think the upgrade worked
[08:30] <spiv> There's a bug report about that somewhere.  lifeless knows the full details.
[08:31] <Peng> .bzr/repository is renamed to .bzr/repository.backup or something, and there is no new .bzr/repository. It's entirely safe to just rename it back in that case.
[08:31] <mdke> I'm definitely interested in trying to convert these branches to the "official" bzr format though
[08:31] <Peng> You could've experienced another problem, of course.
[08:31] <mdke> if it's possible, i would like to do it
[08:31] <Peng> mdke: Rich roots are The Future.
[08:32] <jamesh> the problem is that they aren't The Present.
[08:32] <Peng> mdke: And converting from rich roots to non-rich roots is not supported, because that would throw away certain meta data.
[08:32] <Peng> jamesh: Heh.
[08:32] <spiv> mdke: you can do the upgrade manually, by doing "bzr init-repo --rich-root-format new-repo", and then manually "bzr branch"ing each branch from the old to the new, then renaming the repos "mv repo old-repo; mv new-repo repo".
[08:33] <mdke> what is The Present?
[08:33] <Peng> spiv: "--rich-root-pack", not "--rich-root-format"
[08:33] <Peng> mdke: Non-rich roots.
[08:33] <spiv> Peng: right, thanks.  That's what I get for typing commands direct into IRC :)
[08:33] <Peng> :)
[08:33] <mdke> I understood that the format we have now is not the best format at the present
[08:34] <Peng> Indeed.
[08:34] <spiv> (and maybe you need to do "bzr init" + "bzr pull" instead of "bzr branch" for subtree -> rich-rich, I forget)
[08:34]  * Peng shrugs.
[08:34] <Peng> I don't know that.
[08:34] <mdke> spiv: I will save those commands and give them a try later on
[08:34] <Peng> Um.
[08:34] <mdke> spiv: thanks
[08:34] <Peng> I did something like that recently.
[08:35] <mdke> I think we'd be content with trying to get up to The Present
[08:35] <spiv> (https://bugs.launchpad.net/bzr/+bug/145812 appears to be the bug I mentioned earlier, btw)
[08:35] <ubotu> Launchpad bug 145812 in bzr "Upgrade can leave a broken repository (with backup)" [Low,Triaged]
[08:35] <Peng> Right.
[08:35] <Peng> I bzr branched from dirstate-with-subtree to rich-root-pack, and it worked, but it was ridiculously slow.
[08:36] <mdke> I'm patient :)
[08:36] <Peng> Haha.
[08:37] <Peng> It took 5.5 hours for a ~1300 revision, ~200 MB repo.
[08:37] <mdke> ah, overnight then
[08:38] <Peng> That was over bzr+ssh over the Internet..
[08:38] <Peng> Doing it locally would be faster, of course.
[08:38] <Peng> But there's no way it should take nearly that long.
[08:39] <mdke> that's fine. If it's the right thing to do, I'm happy to wait :)
[08:40] <mdke> bbias
[08:44] <Peng> mdke: Going from subtrees to rich roots is safe in many situations (subtree support more features, but if they're not being used), but it's not possible to go from rich roots to non-rich roots without losing some meta data.
[08:46] <mdke> Peng: does one want to go from rich roots to non-rich roots?
[08:46] <mdke> I just want to go to the best current supported format
[08:49] <Peng> mdke: There's not much need.
[08:50] <Peng> mdke: The only problem is that the default format does not support rich roots, so users can get confusing errors when doing "bzr init-repo" and then trying to branch a rich root branch into it, and that "bzr checkout" problem.
[08:51] <mdke> Peng: could I upgrade to the "default format" instead?
[08:52] <mdke> that would still be faster than the current one, right?
[08:52] <Peng> mdke: Current one?
[08:52] <mdke> the dirstate-with-subtree format
[08:52] <Peng> mdke: Oh.
[08:53] <Peng> mdke: Like I said, you can probably go from dirstate-with-subtree to rich-root-pack, but not to a non-rich-root format.
[08:57] <Peng> Mmm, netsplit.
[08:57] <mdke> lagged out, sorry
[08:58] <mdke> last thing I have was the "isn't it a bit odd" question
[08:59] <mdke> anyway, got to go to work now. thanks all for the info
[09:02] <Peng> "isn't it a bit odd"?
[09:02] <Peng> I didn't get that.
[09:16] <ubotu> New bug: #209570 in bzr "http cannot tunnel smart protocol" [Critical,New] https://launchpad.net/bugs/209570
[09:40] <thekorn> hi, does the bzr extension for nautilus from bzr-gtk work for anyone?
[09:40] <james_w> hi thekorn
[09:40] <thekorn> hi james_w
[09:40] <james_w> I heard someone saying the other day that it didn't work for them
[09:40] <james_w> so it sounds like their may well be a regression there.
[09:41] <thekorn> hmm, the python bindings for nautilus does not seem to work at all, so there might be the problem
[09:42] <james_w> ah, you're just trying from a python console?
[09:43] <thekorn> no, within nautilus, no clue howto test it in a console-session
[09:43] <thekorn> it's bug http://bugzilla.gnome.org/show_bug.cgi?id=518824
[09:45] <james_w> thekorn: thanks, I'll open a bug in Ubuntu
[09:47] <thekorn> james_w, okay, thanks, can you please subscribe me? :)
[09:48] <james_w> done
[09:48] <james_w> do you want to use your bugcontrol powers on it?
[09:48] <james_w> https://bugs.launchpad.net/nautilus-python/+bug/209580
[09:48] <ubotu> Launchpad bug 209580 in nautilus-python "python-nautilus doesn't work with latest nautilus" [Undecided,New]
[09:51] <thekorn> james_w, yes, will set the importance to medium
[09:53] <james_w> isn't it critical for that package if it doesn't work at all, or do I misunderstand?
[09:56] <thekorn> james_w, critical for this package, but not for ubuntu, as the number of users affected by this is not that big, I think
[09:57] <james_w> ah, ok. I thought the severity was per package
[09:58] <james_w> should there be a split for the severity against the package and severity for the release?
[10:01] <thekorn> I'm not sure, maybe the gnome bug needs a higher severity,
[10:02] <james_w> it's critical I think
[10:02] <james_w> I looked again and found an existing bug for this, so I've duped it
[10:05] <thekorn> james_w, I've no clue about FFe and the related process, I will discuss this bugreport with people in #ubuntu-bugs later today
[10:06] <james_w> I don't think we need an FFe to fix this, I'm not sure though.
[10:06] <james_w> there's a workaround patch described in the bug report, we can add that to the package for the release I think
[10:07] <ubotu> New bug: #209580 in nautilus-python "python-nautilus doesn't work with latest nautilus (dup-of: 44704)" [Medium,Confirmed] https://launchpad.net/bugs/209580
[11:25] <pbor> I know I asked this before, but I can't remember how to do it... can I make  bzr diff --diff-options=-p the default for bzr diff?
[11:26] <dato> pbor: yes, with an alias
[11:26] <pbor> ah, ok
[11:26] <pbor> I thought there was some way inside bzr
[11:26] <dato> a bzr alias, not a shell alias, I mean
[11:26] <pbor> ah
[11:26]  * pbor looks that up
[11:27] <pbor> thanks dato
[11:28] <pbor> is bzr alias a plugin?
[11:28] <pbor> bzr help alias gives me an error
[11:28] <dato> nope, it's core
[11:28] <dato> but
[11:28] <dato> I don't know if you can add an alias from the command line, with a command
[11:28] <dato> I *think* you have to edit the configuration file
[11:28] <james_w> no, you can't
[11:29] <james_w> thumper proposed a patch to do that, but I don't know what happened to it
[11:29] <dato> pbor: so, like this:
[11:29] <dato> % head -n 2 ~/.bazaar/bazaar.conf
[11:29] <dato> [ALIASES]
[11:29] <dato> up = update
[11:29] <pbor> ah, ok, I can live with that :)
[11:29] <pbor> thanks
[11:29] <james_w> I think there was discussion about whether it should work like the shell builtin alias, or more like bzr in terms of command line parsing
[11:29] <frsk> Why have you aliased update? =)
[11:30] <frsk> bzr up = bzr update with aliasing it :)
[11:30] <frsk> without*
[11:30] <dato> frsk: I probably added it when the "up" alias didn't exist in core
[11:30] <dato> and didn't clean up afterwards
[11:30] <frsk> dato: Aha
[11:55] <Stavros> hello
[11:56] <Stavros> i need to pull the changes from a remote repository up to and including a tagged release, and substitute all my local working copy with that release. what is the correct command line?
[11:56] <dato> Stavros: do you have local commits_
[11:56] <dato> ?
[11:57] <Stavros> dato: no, it's a production server
[11:57] <Stavros> i may have some local edits which i want overwritten
[11:57] <dato> aha. so, `bzr revert && bzr pull -r tag:TAGNAME http://...` ?
[11:58] <Stavros> aha, that should work, let me try it
[11:58] <Stavros> do i need to do something like "revert -r"?
[11:58] <Stavros> oh wait, nm :/
[11:58] <dato> no, you don't
[11:58] <Stavros> how about pull --overwrite?
[11:59] <dato> that's for when you have local commits
[11:59] <Stavros> ah
[11:59] <Stavros> but not local working copy changes?
[11:59] <dato> nope
[11:59] <dato> those are reverted with revert
[12:00] <Stavros> hmm, it said something about conflicting tags...
[12:03] <Stavros> aw man, i'm in the front page of reddit
[12:03] <Stavros> no wonder the server is hammered
[12:05] <TFKyle> Stavros: which, learn python in 10 minutes?
[12:05] <Stavros> yeah :/
[12:08] <Stavros> so, any idea what this talk about "conflicting tags" is?
[12:08] <james_w> Stavros: there is a tag that is set to one revision in your branch and another revision in the other branch
[12:09] <james_w> or two tags with the same name on two different revisions if you like
[12:09] <Stavros> james_w: that's odd, don't tags get moved if they already exist?
[12:09] <james_w> Stavros: I think so, what does the rest of the message say?
[12:09] <Stavros> it just shows me the tag I just set
[12:09] <james_w> does it stop the pull, or just warn you?
[12:09] <Stavros> it just warns me, from what i can see
[12:09] <james_w> does it say which one was kept?
[12:10] <james_w> i.e. did it keep your tag, or use the other one?
[12:10] <Stavros> no, but apparently the server has it on a different release than on my machine
[12:10] <Stavros> that's odd
[12:10] <Stavros> i have it on 247 and the server on 246
[12:14] <Stavros> shouldn't it update the tag on pull, even though it already is on a revision on the server?
[12:15] <Stavros> hmm, --overwrite works
[12:17] <james_w> yep, it's a conflict, so you need to specify what you want to happen
[12:19] <Stavros> ah
[12:19] <Stavros> hmm, why does it not update? because i set it on the server?
[12:21] <james_w> yes, the tag points to two different places, and so bzr doesn't know which one you want.
[12:22] <Stavros> ah, so --overwrite should fix any future conflicts, yes?
[12:23] <james_w> yes, I think so, though it's not necessarily a good idea to always use --overwrite
[12:23] <james_w> why do you think you will have more conflicts?
[12:24] <Stavros> i don't really think i will, but i'm pretty sure i won't have any changes there i want to keep, so it's the safe bet
[12:24] <luks> that reminds me I should file a bug report about adding --overwrite-tags
[12:24] <Stavros> oh, that would be quite useful
[12:30] <Stavros> well, thank you all very much for your help, it works quite well now
[13:31] <uniscript> I'm wanting to copy an svn branch/tree from one repo to another where I don't have server access to the repos. I wonder if bzr-svn can help with this?
[13:31] <uniscript> I've branched the source using bzr-svn now how do I push it up to the target?
[13:35] <james_w> uniscript: bzr svn-push is probably what you want
[13:35] <james_w> uniscript: the branch doesn't exist in the second repo, correct?
[13:35] <uniscript> correct
[13:36] <uniscript> if I try svn-push it wants to merge
[13:36] <james_w> yeah, svn-push is the answer I think.
[13:36] <uniscript> I tried push --overwrite but that's not implemented yet :(
[13:38] <uniscript> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[13:39] <uniscript> the target directory exists in the repo and is empty
[13:39] <uniscript> is that a problem?
[13:42] <uniscript> testing...
[13:47] <uniscript> seems happy. So that was the problem, can't branch into an empty directory, svn-push has to create the branch dir. OK. Thanks
[14:36] <LeoNerd> Is there a way to do a push-or-pull operation..? Given two bzr branches, push updates from whichever is newer, to whichever is older? (obviously it'd break for diverged history)...
[14:52] <hmeland_> LeoNerd: No, I don't think there is such a thing.  A branch and a checkout of that branch comes close, though.
[14:53] <LeoNerd> I just wanted to put it in cron.hourly in a "foreach BRANCH in `bzr branches`; ..."   command
[15:05] <ubotu> New bug: #209688 in bzr-gtk "The branch history window should use a status bar" [Undecided,New] https://launchpad.net/bugs/209688
[15:05] <ubotu> New bug: #209689 in bzr "KeyError in transport close _file_streams while pulling into a bound branch" [Undecided,New] https://launchpad.net/bugs/209689
[16:01] <vila> bzrlib.tests.test_revisionnamespaces.TestRevisionSpec_date.test_yesterday failed
[16:01] <vila> yesterday
[16:02] <vila> err, no sometimes around 0.01 this morning
[16:02] <vila> ha ha, so funny
[16:02] <vila> Anyway, I just demonstrated that this test *is* fragile :)
[16:02] <jelmer> (-:
[16:34] <mw-home> can bzr export make python eggs from my project?
[16:36] <bob2> like bdist_egg? no.
[16:36] <bob2> there's a setuptoolsbzr thing, tho
[16:36] <mw-home> bob2: is that a bzr plugin?
[16:37] <bob2> no, a setuptools one
[17:04] <piedoggie> are there any guides on how to use bzr  to automatically increment the version number in a setup.py file
[17:07] <james_w> piedoggie: there's the version-info command that might help you
[17:07] <james_w> I think it's something like bzr version-info > _version.py and then import that in setup.py and grab the revno
[17:07] <james_w> version-info --python or something actually
[17:08] <james_w> is that what you meant?
[17:09] <piedoggie> something like that
[17:11] <piedoggie> I still need a figure out how this would affect the version number seen when you run setup
[17:11] <piedoggie> also need to figure out how to include it, generate a new one on every commit etc.
[17:11] <james_w> well setup.py is python, so you can do all this, and then pass it to the function that you call in there.
[17:12] <james_w> ah, on commit, that's different
[17:12] <james_w> you could use some sort of hook I think
[17:12] <piedoggie> my nickname is Mr. forgetful.  I can't tell you the number of times I've created new packages and then fold them up with a single commit for just the version number change
[17:12] <james_w> oh yeah, I do that all the time as well
[17:13] <LarstiQ> version-info --template might be of help
[17:13] <james_w> hi LarstiQ
[17:13] <LarstiQ> hey james_w, piedoggie
[17:14] <piedoggie> afternoon
[17:16] <piedoggie> well, I can see the auto version number update will take a bit more thing time to make it right (or least documented)
[17:16] <piedoggie> ... a bit more think time...
[17:21] <hmeland_> LeoNerd: Maybe you could do "bzr pull && bzr push;"?  I.e. try to pull from "other", and unless that fails, try to push revisions from "this" to "other".
[17:21] <LeoNerd> hmeland_: Hmmm... That might work... Though if both fail, how to tell between "sides are identical" from "sides have diverged" ?
[17:23] <hmeland_> Quick test shows that "Nothing to do" will succeed for "bzr pull", at least.
[17:24] <LeoNerd> Ah OK. :)
[17:26] <hmeland_> You can apparently also use "bzr pull -q", which will give an ERROR if the branches have diverged.
[17:27] <LeoNerd> OK. That's probably good enough then
[19:45] <abentley> jelmer: around?
[20:07] <jelmer> abentley: hi
[20:47] <abentley> jelmer: We're trying to track down what happened when you got an OOPS error yesterday
[20:47] <abentley> It looks as though you tried to register a branch with the name .bzr, but of course that doesn't make much sense.
[20:48] <jelmer> ah
[20:49] <jelmer> abentley: please ignore those
[20:49] <abentley> Well, this is an internal error.  Users really shouldn't ever get those.
[20:49] <jelmer> abentley: I mass-registered a bunch of branches
[20:50] <abentley> Oh, shell-scripting glitch?
[20:50] <jelmer> I've got a particular directory structure on my server that I relied on
[20:51] <jelmer> I've got a plugin that allows short URL access to those branches and can auto-register them
[20:51] <jelmer> It looks like it tried to register all the files in a working tree somewhere
[20:51] <abentley> Ah, okay.
[20:52] <jelmer> abentley: It would be nice to get a clearer error, but I doubt it would ever happen to a normal user.
[20:52] <abentley> Cool.
[20:55] <jelmer> It would of course also be nice if launchpad could do recursive finding of branches under a particular URL...
[21:02] <xma> 'lo
[21:02] <thumper> james_w: the alias patch has been sitting idle as I haven't written appropriate tests yet
[21:02] <xma> what should I do when I merge and something is going bad ?
[21:02] <james_w> thumper: ah, ok, thanks
[21:03] <xma> I resolved the conflict and cleared it
[21:03] <xma> but now I am stuck with "pending merges"
[21:03] <thumper> james_w: I really should get around to finishing it
[21:03] <james_w> it would be nice to have
[21:05] <xma> nobody ? :(
[21:05] <mwhudson__> xma: commit?
[21:05] <xma> hum
[21:05] <xma> what is the merge command purpose then ?
[21:05] <thumper> xma: to merge in changes
[21:06] <thumper> xma: it doesn't commit them
[21:06] <xma> really ?
[21:06] <james_w> to bring the other branch commits in, you still have to check they are merged well and then commit
[21:06] <thumper> yes, it is a feature
[21:06] <xma> oh I see :)
[21:07] <xma> will it take the commit message from the merge patch ?
[21:07] <dato> no
[21:07] <xma> ok
[21:07] <xma> I will have to generate it from my branch then
[21:13] <mdke> lifeless: around?
[21:18] <xma> are there any python-mode users around ?
[21:19] <xma> james_w: is it normal that my merge+commit added stuff not by me ?
[21:19] <xma> james_w: there were many lines touched outside of my scope
[21:19] <xma> james_w: I only modified 4 files and it seems latest commit did more than that
[21:19] <james_w> xma: they were changed in the branch you merged?
[21:20] <xma> james_w: dunno
[21:20] <xma> james_w: when I bzr status, only my files were marked as "modified"
[21:21] <xma> and now I see many lines touched in many other files in the commit
[21:21] <james_w> and then where do you see the other lines changed?
[21:21] <james_w> no files were marked as added?
[21:22] <xma> james_w: ok I think I know why :) bzr send -o mypatch was not enough
[21:22] <xma> james_w: I have to add the revision number to
[21:22] <xma> o
[21:23] <mdke> I'm interested in getting some information about the rich-root-pack format. Is it documented anywhere? Are there any obvious disadvantages to using it? Is it expected to be the default bzr format, and if so, how far away is that?
[21:23] <xma> hum no, it is not
[21:24] <james_w> mdke: non-rich root repositories don't allow you store a normal file-id for the root of a repo.
[21:24] <james_w> This means that they all have the same root id
[21:25] <james_w> this, for instance, isn't satisfactory for bzr-svn
[21:25] <mdke> I don't think that is a feature we currently use, although I suppose we might like to
[21:25] <xma> james_w: how do I know what a particular rev contains ?
[21:25] <xma> james_w: I want to see what is in the rev 3318 for instance
[21:25] <james_w> mdke: it will not be the default format, though the default format will have rich roots
[21:26] <james_w> mdke: perhaps bzr-1.4 will have a new default format with rich-roots
[21:26] <mdke> james_w: rich-root-pack will never be the default format?
[21:26] <james_w> mdke: no, but an evolution of it will
[21:27] <mdke> james_w: will an upgrade from it be supported?
[21:27] <james_w> xma: bzr log -v -r 3318
[21:27] <james_w> xma: bzr diff -c 3318
[21:27] <james_w> mdke: yes
[21:27] <xma> james_w: thank you
[21:28] <james_w> mdke: however I don't think downgrade from rich-root to non-rich-root is supported, as that would throw information away
[21:28] <mdke> sure
[21:28] <james_w> mdke: I don't think that would be part of your considerations though
[21:28] <james_w> is this for the docs?
[21:28] <mdke> ubuntu-docs
[21:28] <james_w> yeah, we've heard you're not happy with the current state of things
[21:28] <mdke> they currently use dirstate-with-subtree
[21:29] <mdke> james_w: that's not true, I'm very happy; I'm just trying to figure out what to upgrade to...
[21:29] <jelmer> mdke: they should be able to use --pack-0.92-subtree
[21:29] <jelmer> that'll at least give them packs
[21:29] <dato> and I thought it could work to -subtree too, albeit very slowly?
[21:29] <mdke> jelmer: is that better than rich-root-pack?
[21:30] <mdke> james_w: and which format to use for a potential new branch
[21:31] <james_w> mdke: ah, we have heard some complaints, but if you're happy that's great
[21:31] <xma> james_w: sorry to bother but how do I safely and cleanly get rid of a branch ?
[21:31] <jelmer> mdke: better in what sense?
[21:31] <mdke> james_w: well, not from me
[21:31] <james_w> mdke: the default will be fine.
[21:31] <mdke> james_w: hmm?
[21:32] <james_w> mdke: probably 1.4 will upgrade that to rich roots, but if you're not going to use rich-root features then there's not much point of using the format
[21:32] <james_w> mdke: you asked what to use for a new branch, I was saying the default will be fine..
[21:32] <james_w> xma: is this branch using a shared repository?
[21:32] <mdke> james_w: well, wouldn't a major reason to do so be to enable the branch to be used in a shared repository with the other branches
[21:33] <xma> james_w: yes it does
[21:33] <james_w> mdke: that's very true
[21:33] <mdke> jelmer: in any sense :) I was using the word "better" in the way that someone who doesn't know much about the subject would
[21:33] <james_w> xma: well rm -rf the branch (after making sure it is the right one, and there are no uncommitted changes, etc.)
[21:33] <james_w> however this leaves the revisions in the shared repository
[21:34] <james_w> there is currently no way to garbage collect those with a command
[21:34] <james_w> if you really want to do it the best way is to create a new repository and then branch all of the branches that you want to keep in to it.
[21:34] <xma> james_w: I want, in fact, to get rid of changes I have made onto a branch and put the branch "clean" with no modficiations pending etc.
[21:36] <xma> in short, I want to be sure all my files are at revision #
[21:37] <james_w> xma: bzr revert -r revno
[21:38] <xma> james_w: ok thank you
[21:38] <james_w> if that is not the current tip of the branch then that will still leave you with changes
[21:38] <james_w> bzr pull -r revno --overwrite .
[21:38] <james_w> will put you on a revision with no changes
[21:38] <mw-home> I want to use bzr to branch an svn repository.  I tried bzr branch svn+http://asfasd and I got an error: bzr: ERROR: Permission denied: ".": PROPFIND request failed on '/
[21:38] <mw-home> Any ideas?
[21:40] <james_w> mw-home: I assume you can "info" it with svn
[21:40] <mdke> sorry, hit the wrong button
[21:42] <mdke> james_w, jelmer - so I'm interested in upgrading to packs because I've heard it will cause good things, but I want all the branches to be the same format so they can go in a shared repository. So I'd need to upgrade the old branches as well as init the new branch with that format
[21:42] <mw-home> james_w: yeah, I can run svn info on the repo, and I don't prompted for a userID and password.
[21:42] <mdke> I haven't heard any disadvantages so far!
[21:42] <mdke> :)
[21:42] <jelmer> mdke: in that case, go for --pack-0.92-subtree if you have old branches that use --dirstate-subtree
[21:43] <mw> damn nick highliting :)
[21:43] <jelmer> mw: what os are you on?
[21:43] <mdke> jelmer: what are the reasons that --pack-0.92-subtree is better (in the general sense) than rich-root-pack? It's harder to spell
[21:44] <mw> jelmer: opensuse, why?
[21:44] <jelmer> mdke: It's impossible to upgrade from --dirstate-subtree to --rich-root-pack afaik
[21:45] <mdke> jelmer: I'm trying it by branching into a rich-root-pack shared repo, I was told that should work. it's going ok - about half way
[21:47] <jelmer> mdke: In that case, --rich-root-pack would be a better choice, indeed
[21:47] <mdke> jelmer: ok, we'll see if it works!
[21:48] <mw-home> james_w: any other ideas why bzr branch svn+http would fail on an svn repo that allows the world to read it?
[21:49] <mdke> james_w: is there somewhere I can read about the "not happy" thing - I'd like to correct it if it's on a public list
[21:51] <jelmer> mw: what version of bzr-svn?
[21:51] <james_w> mdke: no, it was just on IRC, here and Ubuntu channels. The complaint was that checkout was slow, and that the branch may not have been optimal from some things that may have happened in the past
[21:52] <james_w> but there was nothing concrete in the last part
[21:52] <mw> jelmer: sorry, i think you mean to be asking mw-home
[21:52] <mw-home> jelmer: 1.0
[21:52] <jelmer> mw: Whoops, sorry
[21:53] <jelmer> mw-home: Uhm, there is no bzr-svn 1.0 :-)
[21:53] <mw-home> jelmer: sorry.  0.47
[21:53] <mdke> james_w: ok fine - I think it's more a question of just trying to optimise things, the checkout was always going to be slow because of the size of the working tree and the downloading of the revision history
[21:53] <mw-home> 0.4.7
[21:54] <james_w> mdke: yeah, it's not optimal, I'm sure. And I'm sure people get annoyed by the delays as well.
[21:54] <mw-home> I installed bzr-svn as an ubuntu package.  Maybe I should remove that package and grab the bzr branch of the package instead?
[21:54] <jelmer> mw-home: is this a public repository>
[21:54] <jelmer> ?
[21:55] <mw-home> jelmer: yeah it is a public read-only repository.  here it is: http://svn.traceback.org/python
[21:57] <jelmer> mw-home: The repository requires authentication, e.g. "svn ls http://svn.traceback.org/python"
[21:58] <mw-home> jelmer: I don't get prompted for authentication on the /python subdir.
[21:59] <mw-home> unrelated question.  is bzr-svn/stable a tagged release of bzr?
[21:59] <mw-home> bzr-svn?
[22:01] <jelmer> mw-home: bzr-svn requires access to the root of the repository
[22:01] <mw-home> jelmer: got it.  thanks.
[22:02] <jelmer> mw-home: not sure I understand your other question
[22:02] <mw-home> my other question is, i just did a bzr branch on bzr-svn/stable.  Now I have a $HOME/.bazaar/plugins/stable directory. Do I need to rename stable to bzr_svn?
[22:04] <jelmer> you have to rename it to svn
[22:04] <mw-home> gotcha.
[22:05] <mw-home> Should that be in the README file?  I can send in a patch with that text edit if you want.
[22:05] <jelmer> I think it will tell you if you give it another name
[22:06] <jelmer> although patches (or bundles, rather) that improve the documentation are very welcome
[22:09] <lifeless> mdke: hi, will be around in one hour
[22:14] <mdke> lifeless: morning :) will try and hang around
[22:57] <mdke> jelmer: looks like it is working ok! the shared repo is 1.3GB on the new format as opposed to 1.6GB with the old one, a tidy saving
[22:58] <lifeless> mdke: hi
[22:58] <mdke> lifeless: hiya. I've been playing with converting the branches to rich-root-pack format, with the space saving as above
[23:00] <mdke> I'm still thinking of starting our intrepid branch from scratch though, just to wipe the slate clean
[23:01] <mdke> I think we have a lot of heavy stuff hanging around in the history that we don't use
[23:03] <mdke> and of course for historic record, we have it in the old branches
[23:04] <james_w> mdke: just as a heads up, if you do decide to do this then --file-ids-from will probably be what you want to do for the first add in your new branch
[23:04] <lifeless> I'm just looking at your branch now
[23:05] <james_w> hi lifeless
[23:13] <lifeless> hi james_w
[23:13] <lifeless> mdke: so I'm doing some analysis to figure out how big your branches various data items are
[23:16] <mdke> lifeless: sounds good
[23:18] <abentley> james_w: Your changes to the Revision documentation make it a lot longer and intimidating.
[23:18] <abentley> If you're going to go into that kind of detail, could you try writing it in newspaper style, putting the most important things first?
[23:20] <james_w> abentley: sure, I'll do that tomorrow
[23:20] <abentley> Thanks.
[23:30] <lifeless> abentley: IIRC someone wrote a branch stats generator
[23:30] <lifeless> abentley: do you remember it ?
[23:31] <fullermd> I vaguely remember some stats thing that listed number of commits by commiter or something like that...
[23:33] <mdke> lifeless: what's the diagnosis?
[23:33] <lifeless> mdke: still getting a clone
[23:34] <lifeless> mdke: you really should upgrade to rich-root-pack :P
[23:34] <bob2> "bad", then ;)
[23:34] <lifeless> whether or not you start over
[23:34] <mdke> lifeless: ok. Would it help for you to have access to my pc?
[23:34] <mdke> I have the branches converted to rich-root-pack there
[23:34] <lifeless> not really
[23:35] <lifeless>  its cloning inside the dc
[23:35] <mdke> ok
[23:37] <mdke> lifeless: out of interest, is it possible for me to overwrite the launchpad branches now I've got converted local branches with rich-root-pack?
[23:37] <mdke> or do I need to delete the existing ones and recreate them
[23:45] <lifeless> mdke: bzr upgrade sftp://bazaar.launchpad.net/....
[23:46] <lifeless> that will download/upload it all tho, so doing it from a dc machine is preferrable
[23:46] <lifeless> we will do a push-button upgrade for lp at some point
[23:46] <mdke> lifeless: is bzr upgrade safe to do on that? I tried it on my local branch and it broke. for the conversion I used "bzr init-repo --rich-root-pack ; bzr branch ../old-repo/branch branch"
[23:46] <mdke> I dunno if it broke because I have a shared repo or for another reason
[23:47] <james_w> mdke: what was the error?
[23:47] <mdke> james_w: I didn't make a note of it I'm afraid
[23:48] <lifeless> mdke: 'bzr reconcile sftp://....' first then
[23:48] <mdke> Ok. I'll try it after hardy is released :)
[23:51] <mdke> lifeless: I have to go to bed now. If you could leave a msg here (or more reliably, pop me an email), I'd be very grateful. Thanks for all your help
[23:51] <mdke> thanks james_w too
[23:57] <igc> morning


[05:46] <ikt> morning all
[06:06] <Noskcaj> afternoon ikt
[06:08] <ikt> what's been going on?
[06:08] <Noskcaj> Telstra finally fixed my internet, which is good. Not much else.
[06:08] <Noskcaj> you?
[06:09] <ikt> assignment due next monday
[06:09] <ikt> and work work


[00:31] <RAOF> Is anyone else having trouble booting without acpi=off after a recent update?
[03:58] <BenderUnit22> cl
[03:58] <BenderUnit22> Grr, sorry again.
[04:32] <twb> Where can I find the NetworkManager people?  I'm trying to understand how to change network without resorting to a GUI.
[04:33] <twb> #networkmanager appears to be empty.
[04:52] <persia> twb: /usr/share/doc/network-manager/README.Debian may be helpful, but there doesn't seem to be much documentation, and this isn't the right forum, even if the other is empty.  You may have luck in #ubuntu, although it tends to be difficult on the weekends.
[04:53] <twb> Thanks, I already tried both.
[04:53] <twb> I'm pestering #debian now since I know they have NM, too.
[04:53] <twb> s/have/hate/
[05:05] <\sh> twb, you should deal with dbus
[05:05] <\sh> twb, check /etc/dbus-1/even.d/*NetworkManager*
[05:06] <twb> Yeah, but I've no idea how to forge messages on- hmm, looking...
[05:06] <\sh> twb, learn dbus messaging ;)
[05:06] <twb> I'd rather not if I could avoid it :-)
[05:07]  * \sh goes to bed now
[05:08] <twb> I only have /etc/dbus-1/system.d/NetworkManager.conf
[05:08] <\sh> twb, dbus-1/event.d/ there are two daemons started..
[05:09] <\sh> twb, tab-complete against dbus- and check google for more dbus and hal knowledge
[05:10] <twb> Well, thanks
[09:31]  * Hobbsee waves
[09:32] <Mithrandir> iz Hobbsee
[09:32]  * ion_ pulses
[09:33] <Hobbsee> it iz!
[09:33]  * Hobbsee stomps on Mithrandir's feet, before he levitates
[09:34] <Mithrandir> Hobbsee: they're on top of my server, and you're not tall enough to stomp on top of that, so. :-P
[09:35]  * Hobbsee can climb!  :P
[09:35] <Mithrandir> pft
[09:35]  * Mithrandir tickles Hobbsee
[09:35]  * Hobbsee bashes Mithrandir up
[09:37] <torkel> Hey, kids, be nice to each other...
[09:37]  * Hobbsee bashes torkel up too
[09:39] <torkel> Hobbsee: go away from the computer now, and don't come back until you can behave...
[09:39] <Hobbsee> hah
[12:40] <theunixgeek> :)
[12:40] <theunixgeek> Hi. I'm writing my own implementation of a command line file copy program, and I'm faced with the problem that the number of characters in a file should be set by the user in the third argument, but setting i = argv[3] doesn't really work. http://theunixgeek.pastebin.com/m26b0e8d6
[12:41] <Seveas> theunixgeek, this is not a programming help channel
[12:41] <theunixgeek> ok.
[17:36] <rzr> http://www.vnunet.com/vnunet/news/2207369/microsoft-patents-employee
[18:53] <andrea-bs> Hello! I want to know if bug #184603 can be a valid reason to ask the Stable Release Update for grep in gutsy
[18:53] <ubotu> Launchpad bug 184603 in grep "grep -o wrong output" [Medium,Triaged] https://launchpad.net/bugs/184603
[19:24] <gladier> hey guys - im packaging something up and get this message "dpkg-checkbuilddeps: error: control file must have at least one binary package part" along with "dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting."
[19:25] <Chipzz> gladier: -> #ubuntu-motu
[19:30] <Chipzz> andrea-bs: probably a whole lot of care would have to be taken there; grep is an Essential package
[19:31] <andrea-bs> thank you Chipzz, what should I do with the bug?
[19:32] <Chipzz> andrea-bs: I'm not an ubuntu developer, but... : if an updated grep would be broken, all hell would break loose; I would guess the -o option is not *that* important, and the chances of breaking other stuff may outweigh it
[19:32] <Chipzz> but you should probably ask a real developer ;)
[19:33] <andrea-bs> ok, thanks anyhow
[19:33] <Chipzz> (otoh, the version in hardy isn't broken so chances of stuff breaking are smaller I guess)
[19:43] <saispo> anyone use a bluetooth keyboard ?


[10:53] <teddy-dbear> Morning peoples, critters and everything else
[22:20] <ChinnoDog> What Ubuntu release comes after Zesty Zapus?
[22:20] <jthan> Actually Absurd
[22:20] <jthan> jk that's a pleia2 question, probably.
[22:21] <ChinnoDog> I'm all for recycling the alphabet. Maybe with a different theme though.
[22:28] <ChinnoDog> Also, everyone refers to the releases by the adjective and rarely the noun. Might as well use one word instead.
[22:28] <jthan> Yeah true
[22:28] <jthan> The last time I actually used Ubuntu personally was 8.04
[22:28] <ChinnoDog> We could use cuts of meat. Where is my Bacon release?
[22:31] <ChinnoDog> If we do that the animal can be the adjective instead of the noun. Bobcat Bacon.
[22:57] <ChinnoDog> No really. Does anyone know what comes after Zesty? Seems like this would already be figured out by now considering Zesty release in only two months.
[23:22] <pleia2> it's a Mark Shuttleworth question, he doesn't tell us anything about release name strategy
[23:40] <ChinnoDog> I guess we'll have to depend on version numbers until then.
[23:42] <pleia2> Mark's been pretty lax about announcing release names, zapus wasn't announced until four days *after* yakkety was *released*
[23:43] <pleia2> it was not awesome for developers, had to use placeholders for z-
[23:43] <pleia2> then mad rush to replace everything once he wrote about it
[23:43] <pleia2> but these days most of the folks doing that work are Canonical employees, so *shrug*
[23:44] <jthan> I hope they used an intelligent placeholder
[23:44] <jthan> ZOME_Z_ZORD_ZERE
[23:44] <jthan> easy to sed
[23:44] <jthan> lol
[23:44] <pleia2> it really is just z- or something
[23:44] <pleia2> just the letter
[23:44] <jthan> o
[23:44] <jthan> that's not convenient.
[23:44] <pleia2> makes for a lot of busy work


[00:04] <ianorlin> argh might be a little big on me
[00:05] <pleia2> Mark Sobell is coming over to sign copies of A Practical Guide to Ubuntu Linux I got to give away up here, I just realized a few hours ago that there are 16 of them
[00:06] <pleia2> "so, about those books, hope your signing hand is ready"
[00:06] <pleia2> but hey, signed books for our jam on Sunday!
[00:07] <nhaines> \o/
[00:10] <pleia2> I thought I'd make sugar cookies (penguins!) for the jam, but my TOOMANYTHINGS alarm is going off
[00:12] <elky> glad you finally got one of those alarms :P
[00:17] <ianorlin> yeah like 14.04.2 coming out
[00:18] <pleia2> elky: haha
[02:23]  * ianorlin missed another chnace to apply for ubuntu memebership but I spent most of tuseday testings 14.04.2 images for lubuntu instead
[03:20] <pleia2> 16 books signed \o/
[03:23] <nhaines> yay!
[19:00] <pleia2> completed venue tour for the SF global jam \o/
[19:00] <pleia2> I think this will work out really well
[19:03] <nhaines> Yay!
[19:04] <pleia2> shame it hasn't exactly garnered huge attendance, but maybe a small group will be good
[19:05] <pleia2> now I just hope everyone wo signed up actually comes :)
[19:06] <nhaines> haha
[19:07] <pleia2> jono_: if you could point your minions at http://loco.ubuntu.com/events/ubuntu-california/2984-ubuntu-california-san-francisco-qa-jam/ one more time I'd appreciate it a lot :)
[19:07] <darthrobot> Title: [Ubuntu California San Francisco QA Jam | Ubuntu LoCo Team Portal]
[19:07] <pleia2> now with books signed by the authors for all attendees!
[19:07] <akk> Such a deal!
[19:20] <rww> how can there not be lots of attendees, you put it on facebook
[19:20] <nhaines> rww: not enough Meetup.
[19:21] <pleia2> rww: snort
[19:47] <pleia2> not going to leave salad prep to chance, so I ordered some lettuce, gluten free caesar dressing and croutons (served on the side, optional!) and will toss a salad together myself
[19:48] <nhaines> Needs more heirloom tomatoes.
[19:48] <pleia2> in a caesar salad?
[19:49] <pleia2> maybe parmesan on the side too
[19:49] <nhaines> Oh wait.  Well...  :)
[19:50]  * pleia2 adds shredded parm to her order
[20:10] <jono_> pleia2, you got it :-)
[20:10] <pleia2> \o/
[20:11] <pleia2> hm, how did I become unfollowing jonobacon, goofy twitter
[20:12]  * pleia2 fixes


[19:10] <bdx> sup sup
[19:11] <bdx> has anyone successfully bootstrapped an openstack provider with 2.0?


[15:57] <lolek> hi, I know that this may not be the best channel to ask for this but not sure where to go so maybe someone will have some ideas. So I'm checking the possibilities to use dropbear as a solution to allow me to unlock my server after reboot. There are some tutorials on the network but I can't find any information about how to properly configure networking for this. The thing is that I need to have vlan tag on it, any idea how to so
[15:57] <lolek> e this?
[16:39] <alkisg> lolek: this should help: https://github.com/stcz/initramfs-tools-network-hook
[16:41] <lolek> man... this is great, thank you!
[16:57] <smoser> how do people build packages ? I don't understand how bugs like https://bugs.launchpad.net/bugs/1986775 can exist.
[16:57] -ubottu:#ubuntu-server- Launchpad bug 1986775 in schroot (Ubuntu Kinetic) "schroot 1.6.12-2 incompatible with sbuild-launchpad-chroot" [High, Triaged]
[16:58] <smoser> I can justify myself not having built any packages since upgrading to Jammy, but i dont' understand how others didn't hit this earlier.  what do peopple do for package builds ?
[17:08] <ChmEarl> smoser, my pbuilder host for kinetic builds is Focal
[17:08] <patdk-lap> I haven't had any issues building packages from trusty to jammy as of last week
[17:11] <smoser> yeah.. so you wont have issues unles you're using sbuild-launchpad-chroot to maange your chroots. but, what I don't understand is why people *don't* use that. but apparently they don't.
[17:18] <patdk-lap> I rarely build binarypackages locally, normally I upload to launchpad
[17:19] <patdk-lap> only for really odd things, or testing come custom patch only I expect to make use of
[17:19] <patdk-lap> and I do all my builds inside a docker container so I don't see chroot being more helpful there
[18:07] <ahasenack> I don't use schroot, I either use a ppa, or a lxd container
[18:16] <Odd_Bloke> I ran into problems with sbuild-launchpad-chroot years ago so switched away from it, and never returned.
[18:16] <Odd_Bloke> (And now most of my package builds aren't against archive.u.c's current contents so it wouldn't work for me anyway. :p)
[18:32] <linuxperia> hi all. i have a strange network problem after i swaped the ssd with ubuntu-server from one computer to a new. ubuntu boots without any problem on the new server with the old ssd but when i try to ping a ip adress like <IP_ADDRESS> i get the error "Network Unreachable". I need somehow to reconfigure the whole network. How can i do this ? Searched on the internet but only found non working tips.
[18:33] <ahasenack> check /etc/netplan/*.yaml, see if the mac address of the old machine is in there
[18:34] <linuxperia> ahasenack: had only a install.yaml file and based on the tip i deleted all there
[18:35] <ahasenack> that's the network config what you just deleted
[18:36] <ahasenack> create a new one. If this is a server (not desktop), start with the first example from https://netplan.io/examples perhaps
[18:36] <ahasenack> that will use dhcp
[18:36] <linuxperia> okey yes is good
[18:36] <ahasenack> if you need static addressing, or something else, keep reading that examples page
[18:36] <ahasenack> one might suite you
[18:41] <linuxperia> ahasenack: yaaayy it works. thank you very much.
[18:45] <ahasenack> welcome :)
[19:24] <linuxperia> small question again. how can i set the cpu to performance in ubuntu-server ? google search suggest cpufrequtils but think this is outdated.
[19:25] <linuxperia> it the cpu guvernator set to performance should be preserved on reboots
[19:31] <sarnold> linuxperia: I think the pstate stuff is the new hotness, but it's hard to keep track of all the different tools for managing cpu performance/power .. https://www.kernel.org/doc/Documentation/cpu-freq/ has a bunch of docs but lacks any sort of guidance
[19:31] <teward> bryceh: rbasak: sarnold: nginx and 'We disable IPv6 on our servers so default config fubars automatic deployments' came up again.  This time in Debian with an Ubuntu package version reference.  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021393
[19:31] -ubottu:#ubuntu-server- Debian bug 1021393 in nginx-common "error in package nginx-common_1.18.0-6ubuntu14.2_all.deb for ubuntu 22.04 with default enabled site." [Normal, Open]
[19:31] <teward> just as a for your awareness thing
[19:31] <sarnold> linuxperia: there's probably something more useful on https://wiki.archlinux.org/title/CPU_frequency_scaling
[19:32] <teward> bryceh: rbasak: debian-devel seems to agree with our original decision that 'default config' should work for 'default Debian' and not really diverge on that.
[19:32] <teward> so we made the right call downstream here :p
[19:33] <sarnold> teward: heh, what a confusing bug report all around
[19:34] <teward> sarnold: yep, rejected because Ubuntu needs Ubuntu bugs, then they said "Well, it's not really an Ubuntu issue it's a Debian issue" and explained the same "We disable IPv6 completely" problem we had show up in Ubuntu bugs multiple times
[19:34] <teward> stil rejected because "default should work for default installations which include v4 and v6" so
[19:34] <teward> welcome to my double-pronged "no we're not changing the defaults for an end-user admin decision that can break stuff" responses xD
[19:34] <linuxperia> sarnold: tahnk you very much. will look into pstate
[19:35] <sarnold> "if you change one setting you might have to change a second setting"
[22:14] <feurig> I love how ubuntu denys responsibility for debian while completely relying on it for technical depth and correctness
[22:15]  * feurig says all the while pushing ubuntu for the same reasons