[20:28] <mikehale> qq: will running a user-data script cause cloud-init to skip processing /etc/cloud/cloud.cfg?
[20:48] <smoser> mikehale, no.
[20:48] <smoser> what "processing" do you mean ?
[20:56] <mikehale> well I put some mount directives in /etc/cloud/cloud.cfg but after running `cloud-init-cfg config-mounts` the mount I expected is not setup
[20:59] <mikehale> maybe there is a guard somewhere to not do anything after the initial boot though
[21:00] <smoser> 12.04 ?
[21:00] <mikehale> 10.04 lucid, cloud-init 0.5.10
[21:00] <smoser> oh. wow.
[21:00] <smoser> old school
[21:01] <smoser> from distant memory, if this is supported.... then there is probably a '.sem' file that you'd have to remove in order to make that run again.
[21:01] <smoser> ie, it only intens to run it once er instance.
[21:01] <smoser> per instance
[21:01] <mikehale> k, thanks
[21:03] <mikehale> strafe says this was read: /var/lib/cloud/sem/config-mounts.i-nnnn
[21:03] <mikehale> s/strafe/strace/
[21:04] <mikehale> cool, removing that file allows the directives to be processed
[21:14] <smoser> mikehale, thanks for the trip down memory lane
[21:14] <smoser> :)
[21:14] <smoser> (really just kidding, if i had stuff working on 10.04, i probably wouldn't be looking to just move off it iether)
[21:59] <harlowja> woah, 0.5
[21:59] <harlowja> what existed in 0.5
[21:59] <harlowja> :-P
[22:56] <mikehale> smoser: we'd like to upgrade to the latest LTS, but it is still a relatively low priority, high risk thing for us


[07:11] <CookClean> Hi
[07:12] <CookClean> Can anybdy tel me how to load .sjar files into Tomcat?
[07:12] <CookClean> .sjar files are files generated using jarCryp
[07:16] <CookClean> please refer this link for question in detail http://stackoverflow.com/questions/15170758/adding-classloader-to-the-tomcat


[08:54] <nicoz> o/
[12:12] <Kilos> \o
[17:31] <ddstreet> o/
[17:31] <ddstreet> teward i got a decline from mapreri, so it may just be us today
[17:43] <ddstreet> ok well just me i guess :)
[17:44] <ddstreet> i'll at least run thru the mtg to clear out completed action items
[17:44] <ddstreet> #startmeeting Ubuntu Backporters
[17:44] <meetingology> Meeting started at 17:44:20 UTC.  The chair is ddstreet.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[17:44] <meetingology> Available commands: action, commands, idea, info, link, nick
[17:44] <ddstreet> #topic previous action items
[17:44] <ddstreet> #subtopic ddstreet email ubuntu-devel list to announce re-opening of backports (carried over)
[17:44] <ddstreet> done!
[17:45] <ddstreet> #link https://lists.ubuntu.com/archives/ubuntu-devel/2022-February/041827.html
[17:45] <ddstreet> #subtopic ddstreet update internal KB page with details about uploads going to 'New' instead of 'Unapproved' queue (carried over)
[17:45] <ddstreet> done!
[17:45] <ddstreet> #link https://wiki.ubuntu.com/UbuntuBackports/KnowledgeBase#Upload_Queues
[17:45] <ddstreet> #subtopic ddstreet update tooling, requestbackport, backportpackage (carried over)
[17:45] <ddstreet> not done :(
[17:45] <ddstreet> #action ddstreet update tooling, requestbackport, backportpackage (carried over)
[17:45] <meetingology> ACTION: ddstreet update tooling, requestbackport, backportpackage (carried over)
[17:46] <ddstreet> #subtopic ddstreet schedule next meeting at 12:30pm Eastern time, following USA DST schedule
[17:46] <ddstreet> done
[17:46] <ddstreet> #subtopic ddstreet make sure wiki page includes requirement to add LP:# tag in backport changelog
[17:46] <ddstreet> done
[17:46] <ddstreet> #link https://wiki.ubuntu.com/UbuntuBackports#Preparing_the_Backported_Package
[17:46] <ddstreet> #subtopic ddstreet start thread on ML to clarify wording for no-bug-required backports
[17:46] <ddstreet> #link https://lists.ubuntu.com/archives/ubuntu-backports/2022-February/022680.html
[17:46] <ddstreet> done
[17:47] <ddstreet> since nobody else is here, i'll just carryover the other action items
[17:47] <teward> sorry i am late
[17:47] <ddstreet> hello! o/
[17:47] <ddstreet> no problem
[17:47] <ddstreet> just going over previous items
[17:47] <teward> was deep in a buggy software and fixing it
[17:47] <ddstreet> #action mapreri propose text for membership process to add to KB page (carried over)
[17:47] <meetingology> ACTION: mapreri propose text for membership process to add to KB page (carried over)
[17:47] <ddstreet> #action mapreri upload (more of) all the tools (carried over, in progress)
[17:47] <meetingology> ACTION: mapreri upload (more of) all the tools (carried over, in progress)
[17:47] <ddstreet> #action mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[17:47] <meetingology> ACTION: mapreri fix lintian to not complain about ~bpo suffix (https://bugs.debian.org/1001399) (carried over)
[17:47] <ddstreet> #action (unassigned) define details on handling members/leads who are no longer participating (carried over)
[17:47] <meetingology> ACTION: (unassigned) define details on handling members/leads who are no longer participating (carried over)
[17:48] <ddstreet> #action (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
[17:48] <meetingology> ACTION: (unassigned) get DEB_VENDOR=ubuntu dch --bpo to DTRT pls (carried over)
[17:48] <ddstreet> #action (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over)
[17:48] <meetingology> ACTION: (unassigned) look at reviewer tooling such as 'queue' or other tools for reviewing/accepting/rejecting uploads, and closing the corresponding bugs (carried over)
[17:48] <ddstreet> ok that's all the previous actions
[17:48] <ddstreet> #topic discussion
[17:48] <ddstreet> i have one item on the agenda
[17:48] <ddstreet> #subtopic I (ddstreet) would like to start a discussion on a non-participating member policy
[17:48] <teward> ddstreet: given the other thing perhaps the no longer participating thing should be a TB decison
[17:48] <teward> as a matter of policy
[17:49] <teward> lol coincidence thats the topic now
[17:49] <ddstreet> mm, i'm 100% fine with the TB doing the actual member removal/addition/modification...but i'm not ok with the TB deciding membership policy for the team
[17:49] <teward> i propose we come up with something to present to the TB for their ratification
[17:50] <teward> so they can sign off, etc. but that way it gets proper review, etc.
[17:50] <ddstreet> i have no problem presenting our decision to the TB, and if they want to or need to ratify it, that's fine too
[17:50] <ddstreet> as far as i'm concerned, that step is simply an implementation detail
[17:51] <ddstreet> so i think we're in agreement on that particular part right?
[17:51] <ddstreet> just to confirm
[17:52] <ddstreet> teward you still there?
[17:52] <teward> mmmmm...
[17:52] <teward> ye typing from a phone ya impatient
[17:53] <ddstreet> ah ok
[17:53] <ddstreet> no hurry just checking :)
[17:53] <teward> i think my issue is a lack of clarity overall from a policy perspective that is apparently present at all levels - namely does a team get to decide its own policies for removals of members etc.
[17:54] <teward> can i suggest we carry over this action item and discussion to next meeting?  i want to poke a few individuals first
[17:54] <teward> get a general pulse on that core question
[17:55] <teward> i have no issue starting a discussion on how we shoukd handle inactives but with that issue being a big one on a radar far higher than ours I want to get that issue clarified at a higher level first
[17:55] <ddstreet> since this team has only the 3 of us, and generally we have no problem at all currently with lack of participation, i'm ok deferring to the next meeting...but, i really would like to make progress on this item in that meeting
[17:55] <teward> ok
[17:56] <ddstreet> i'll say that i am personally unconvinced that there can be a single policy that applies to all teams that covers what a 'non-participating member' is
[17:56] <ddstreet> and certainly not how to best handle the situation
[17:56] <ddstreet> but i think it's ok to give them 2 weeks to try to come up with a policy before we start on our own :)
[17:56] <rbasak> o/
[17:57] <ddstreet> #action ddstreet at next meeting, re-raise issue of non-participating member policy
[17:57] <meetingology> ACTION: ddstreet at next meeting, re-raise issue of non-participating member policy
[17:57] <ddstreet> rbasak looks like you have something to add to the topic?
[17:57] <rbasak> Something I was hoping to do was to ask the backporters team to ratify its responsibilities, as I had originally proposed in the ubuntu-devel@ thread during the backporter reboot discussion
[17:57] <rbasak> That's slightly related to this topic.
[17:58] <rbasak> Let me find a link
[17:58] <teward> i was just gonna ask for a link lol
[17:58] <ddstreet> sure i'm all for that, i think best to put an action item for the next meeting and/or ML discussion
[17:58] <ddstreet> if that sounds ok to everyone
[17:58] <rbasak> https://lists.ubuntu.com/archives/ubuntu-devel/2021-July/041559.html, under "Team Responsibilities"
[17:58] <rbasak> "Handle your own process reform and membership management..."
[17:59] <rbasak> So that's done, and the TB ratifies, then you'd be handling your own membership management.
[17:59] <ddstreet> no disagreement from me.
[17:59] <teward> if the TB ratifies that part i have no issues then
[17:59] <rbasak> However, given what Steve raised with the DMB, that might need further discussion with the TB because maybe that wouldn't be acceptable to them.
[18:00] <rbasak> So *if* that's done sorry
[18:01] <ddstreet> personally, i'd prefer to just assume we will get approval and make progress based on that assumption. if it turns out that assumption was wrong, things can be reevaluated later. i do not want to delay our own discussion and decision making however
[18:01] <rbasak> OTOH, maybe this team will follow the pattern of some of the other teams (SRU, archive, release) in managing their own membership, unlike the DMB which is vote-based.
[18:01] <teward> rbasak: on steves point DMB never had any say in SRU reviewers either and I think Backporters falls into that category
[18:01] <rbasak> Yeah probably
[18:01] <teward> of there is precedent to be handled independently of DMB entirely
[18:02] <rbasak> So maybe best to proceed on the assumption that my "Team responsibilities" section would be ratified by both the TB and the backporters team?
[18:02] <ddstreet> just fyi, there is an existing action item that is assigned to mapreri to "propose text for membership process to add to KB page"
[18:02] <ddstreet> so clearly, the assumption so far as been that the team will decide its own membership process
[18:03] <ddstreet> the TB of course can clarify if that assumption is wrong, but i see no reason to change anything until that clarification is made from the TB
[18:03] <teward> given the... other chaos... can we get the TB'S blessing on backporters managing our own members though?,
[18:03] <rbasak> Anyway, I was intending to send an email to the backporters list asking if that text is something you'd be willing to ratify, and then take it up with the TB if the answer was yes.
[18:03] <rbasak> But I was watching this meeting and on this topic that seemed relevant, so I thought it might be helpful to mention it now.
[18:03] <ddstreet> yes, i think it's best to carry the discussion of the specific text to ratify to the ML
[18:04] <teward> agreed
[18:04] <ddstreet> ok i can throw up an action for that then, rbasak if you want to send the email i'll assign to you? :)
[18:04] <rbasak> Assign me to send the email you mean? Sure.
[18:05] <ddstreet> #action rbasak send email to ML to clarify specific wording of team responsibilities, for proposal to TB for ratification
[18:05] <meetingology> ACTION: rbasak send email to ML to clarify specific wording of team responsibilities, for proposal to TB for ratification
[18:05] <ddstreet> hopefully i worded that well enough :)
[18:06] <rbasak> Yep, thanks
[18:06] <ddstreet> and i do still have the action added earlier to bring this topic back up next meeting, so we can review what's ahppend on the ML then
[18:06] <teward> oh robie grab me aftet tbe
[18:06] <teward> after the meeting
[18:06] <ddstreet> ok i think that topic is done for now, so aob
[18:06] <ddstreet> #topic AOB
[18:06] <ddstreet> anyhting else?
[18:06] <teward> not from me
[18:07] <ddstreet> only thing i will mention is for members (teward ;-) to be sure to check the ML, i did send a couple emails to start discussion threads, e.g. no-bug backports, etc.
[18:07] <ddstreet> no hurry though :)
[18:07] <ddstreet> ok i think we're done then, thanks all!
[18:07] <ddstreet> #endmeeting
[18:07] <meetingology> Meeting ended at 18:07:52 UTC.  Minutes at https://ubottu.com/meetingology/logs/ubuntu-meeting/2022/ubuntu-meeting.2022-02-09-17.44.moin.txt


[00:05] <Verterok> g'morning igc
[00:06] <thumper> morning
[00:07] <thumper> can I branch into the current directory?
[00:07] <thumper> for example:
[00:07] <thumper> on a server I have a directory which I have rights to
[00:07] <thumper> but the directory above is root only
[00:07] <thumper> in that directory I want to get the contents of a bzr branch
[00:07] <thumper> which was created elsewhere
[00:07] <mwhudson> bzr init, bzr pull
[00:07] <mwhudson> will probably work
[00:08] <thumper> mwhudson: ok, will try
[00:08] <mwhudson> (means you have to get the format right though)
[00:08] <thumper> sweet
[00:08] <thumper> works
[00:08] <thumper> ta
[00:08] <mwhudson> which, given sikrit insider infomation, probably means bzr init --rich-root-pack
[00:08] <thumper> it isn't
[00:08] <mwhudson> ok :)
[00:08] <thumper> but thanks anyway
[00:27] <igc> morning Verterok, how are you?
[00:27] <beuno> thumper, hi!   kick-ass blog post, btw  :)
[00:32] <Verterok> igc:
[00:32] <Verterok> I'm fine, thank you. although a bit busy (hoping to have some free time)
[00:32] <igc> busy is better than bored I always say :-)
[00:33] <Verterok> igc: good point :)
[00:33] <beuno> igc, and how are you?
[00:34] <Verterok> beuno: hi
[00:34] <igc> beuno: hi. Quite sleepy these days. The pain killers I'm on have that effect.
[00:35] <igc> otherwise, just taking each day at a time right now
[00:37] <beuno> igc, you don't seem that sleepy if I look at your work   ;)
[00:39] <igc> beuno: it's nice to hear you say that. Quantity is certainly down at the moment.
[00:39] <igc> I'm in week 2 of a 6 week treatment so ...
[00:39] <igc> hopefully I'll feel better when it's over
[00:41] <beuno> igc, I'm sure you will
[00:45] <thumper> beuno: thanks, but to be honest, abentley wrote most of it
[01:03] <mwhudson> hm
[01:03] <mwhudson> is there some way i can create a branch with a ghost on mainline?
[01:03] <mwhudson> (programming is ok)
[01:28] <igc> jam: did you see my partial review? I was wondering about that change to Merge3Merger._entries3()
[01:50] <bob2> lifeless: should that be 'http://bazaar.launchpad.net/~jameinel/%2Bjunk/pybloom/' (i.e. no bzr-)?
[02:05] <poolie> mwhudson: um, it is possible but probably complicated
[02:05] <poolie> i would start by looking for an api that will copy just one revision and not its parents
[02:05] <mwhudson> poolie: ok
[02:05] <mwhudson> don't push one of these branches to launchpad :)
[03:00] <bob2> hm, my upgrade to --gc-plain seems to not be progressing
[03:53] <bob2> hm, I lie, it is churning through it
[03:57] <jam> mwhudson: I believe there is a 'allow_lefthand_ghost=True' member that you can look for
[03:58] <jam> I think it is on set_parent_ids/trees
[03:58] <jam> igc: I did see it, I haven't fully digested it.
[03:58] <jam> I believe that True => False is *correct* though it doesn't really apply for the weave code
[03:58] <jam> just something I was trying to get around to, not quite sure how it ended up here
[04:02] <igc> jam: ok. IIUIC, the rest of the patch is benign, i.e. it doesn't seem to impact anything outside (re)merge --weave?
[04:03] <igc> that's while I highlighted that change - it has a broader impact potentially?
[04:03] <igc> s/while/why/
[04:49]  * igc lunch
[05:05] <thumper> is there an ETA for bzr-svn in the bzr ppa?
[05:33] <bob2> 85664   backup.bzr
[05:33] <bob2> 40232   .bzr/
[05:33] <bob2> that is quite awesome
[05:34] <jam> igc: well, when you get back from lunch, the next layer up does a "if changed" check, and filters them all out again, but I'm fine skipping it for now.
[06:06] <thumper> bob2: from what to what did you upgrade?
[06:07] <bob2> pack-0.92 -> bt+gc
[06:07]  * mwhudson stabs non-canonical histories
[06:12] <thumper> bob2: bt+gc??? I'm lost
[06:13] <mwhudson> thumper: btree indexes and lifeless's groupcompression thingy
[06:13] <mwhudson> (i assume)
[06:14] <thumper> ah
[06:14] <bob2> the pair of new formats lifeless posted to the list this morning
[07:19] <lifeless> bob2: :)
[07:19] <lifeless> bob2: it will be better when the fetcher knows to do inverse-topological-order
[07:59] <awmcclain> Oh no. Is there any way to undo a bzr revert?
[08:04] <matkor> awmcclain: bzr revert of uncommited changes ?  I think they are lost ...
[08:04] <awmcclain> Boo. for that.
[08:04] <awmcclain> all for doing bzr revert instead of bzr revert .
[08:05] <awmcclain> not pleased with bzr right now.
[08:06] <bob2> doesn't help now, but maybe aliasing 'revert' to 'shelve --all' might save you in the future?
[08:08] <awmcclain> yeah... i just wanted to revert one file.
[08:08] <awmcclain> so i cd'ed into the child directory
[08:08] <awmcclain> but bzr revert crawled out and did the entire tree
[08:08] <awmcclain> bad bzr! naughty!
[08:10] <asabil> awmcclain: there are backup files
[08:10] <awmcclain> oh???
[08:11] <asabil> awmcclain: just check for hidden files in your folder
[08:11] <awmcclain> okee doke
[08:11] <asabil> (ones ending with ~)
[08:11] <asabil> I think there is maybe a way to ask bzr to revert the revert :p
[08:11] <asabil> but I don't know
[08:13] <awmcclain> Well, I got it for the one file that really mattered... thank you!
[09:13] <MvG> Hi! I'm trying to move repository data from a shared repository to a dedicated repository of a single branch. I had assumed that "reconfigure --standalone" would work for this, being the opposite of "--use-shared". However I got a IncompatibleRepositories error from current bzr.dev. Trying again informs me that the tree is already standalone. How can I tell whether the conversion worked? What is the reason for this error message?
[09:16] <MvG> Steps to reproduce: bzr init-repo --rich-root-pack repo; cd repo; bzr init branch; cd branch; bzr reconfigure --standalone
[09:16] <Odd_Bloke> lifeless: I'm aiming to get to Canonical's offices sometime between 1 and 2 this afternoon.  Is that OK?
[09:24] <igc> lifeless: fyi, I'm benchmarking the group-compress stuff tonight on some repos to see how well it compresses them
[09:24]  * igc dinner
[09:27] <bob2> MvG: "bzr info" should tell you if it worked
[09:27] <Stavros> hello
[09:27] <Stavros> this is a bit offtopic, but i'd like to ask how you guys wrote your distutils script
[09:28] <MvG> bob2: bzr info tells me it did. But I worry it might have been migrated only partially. Otherwise why the error message?
[09:30] <lifeless> ogthats cool
[09:30] <lifeless> igc: thanks
[09:30] <lifeless> igc: it really needs a custom InterRepository to compress well
[09:31] <lifeless> igc: it will get about 50% I expect from an existing repo with the current inter object
[09:31] <lifeless> Odd_Bloke: thats cool
[09:31] <lifeless> MvG: sounds like you've found a bug; could you please file it in launchpad ?
[09:33] <MvG> lifeless: Sure.
[09:43] <Odd_Bloke> lifeless: Excellent. :)  Has jelmer mentioned what time he's going to be arriving?  (SUBTLE PING :D)
[09:44] <MvG> lifeless: Submitted https://bugs.launchpad.net/bzr/+bug/248932
[09:45] <lifeless> Odd_Bloke: no :)
[09:46] <lifeless> mv	thanks!
[10:55] <jaro> hello
[10:55] <jaro> now trying migration from svn to bzr
[10:55] <jaro> what tools better to use?
[10:55] <jaro> bzr fast-import?
[10:59] <jaro> anyone is here?
[11:00] <Jc2k> hi jaro
[11:00] <Jc2k> there is normally someone round who can help
[11:00] <Jc2k> i only have experience with bzr-svn, which isn't really aimed at doing migration
[11:01] <jaro> :/
[11:01] <luks> well, bzr-svn works fine for migration
[11:02] <jaro> luks: can i with bzr-svn migrate my subversion repository to bzr and i will see all changes?
[11:03] <luks> jaro: yes
[11:03] <jaro> how?
[11:03] <jaro> May by some how to?
[11:03] <jaro> link
[11:03] <jaro> ?
[11:04] <luks> install bzr-svn, run `bzr svn-import <SVN_URL>`
[11:04] <luks> or just `bzr branch <SVN_URL_OF_TRUNK>` if you want to migrate only trunk
[11:05] <luks> then you can uninstall bzr-svn and just use plain bzr
[11:05] <ignas> what is the mystical "front-end" tool that is being mentioned in http://bazaar-vcs.org/BzrFastImport ?
[11:06] <luks> ignas: http://bazaar-vcs.org/BzrFastImport/FrontEnds
[11:07] <ignas> luks: thanks
[11:09] <jaro> luks: i try bzr svn-import <URL>
[11:10] <jaro> then cd <project>
[11:10] <jaro> and there are no files
[11:10] <jaro> :(
[11:10] <luks> try `bzr info`
[11:11] <jaro> Repository branch (format: rich-root-pack)
[11:11] <jaro> Location:
[11:11] <jaro>   shared repository: .
[11:11] <jaro>   repository branch: .
[11:11] <jaro> Related branches:
[11:11] <luks> or are there no files or directories at all?
[11:12] <jaro>   parent branch: <url>
[11:12] <luks> if not, what URL did you use?
[11:13] <jaro> file:///patch/to/svn/project
[11:14] <luks> jaro: does the project have only a single branch? no trunk/branches/tags structure?
[11:14] <jaro> yes
[11:14] <luks> well, then all you need is in the directory
[11:14] <lifeless> jaro: do 'bzr checkout .' and you'll get your files
[11:14] <luks> you can use `bzr checkout .` to recreate the working tree if you want
[11:14] <luks> :)
[11:15] <jaro> but bzr checkout only get files
[11:15] <jaro> But i need history
[11:15] <luks> bzr log
[11:15] <luks> in that directory
[11:15] <ignas> or bzr vis for a nice visual history if you have gtk plugin installed
[11:18] <jaro> bzr log show my history
[11:18] <LarstiQ> hey ignas
[11:18] <jaro> So can I delete /patch/to/svn/project ?
[11:18] <ignas> LarstiQ: hi
[11:18] <jaro> And how can I see my files in /patch/to/bzr/project ?
[11:18] <jaro> To change them ?
[11:19] <luks> jaro: it's always nice to keep backups, just in case, but yes you can
[11:19] <luks> jam: bzr checkout .
[11:19] <luks> jaro:
[11:19] <luks> evil tab completion
[11:20] <lifeless> poolie: around?
[11:21] <jaro> luks: big thanx
[11:23] <matkor> what is proper way of resolivng binary file confilct ? I end up with foo and foo.moved, how to choose that foo/foo.moved is correct conflcit colvation ?
[11:28] <lifeless> matkor: that generally means foo and foo.moved were added independently; you should take the one that is in the branch closer to trunk
[11:29] <poolie> lifeless: hi, a bit
[11:29] <lifeless> poolie: can we chat about get_record_stream a bit? perhaps a quick call ?
[11:32] <igc> lilfeless: so my first group-compress test is still running after 2h30minutes
[11:33] <igc> I'm wondering if I'm doing the right thing?
[11:33] <igc> I'm doing this ...
[11:33] <igc> bzr init --gc-plain .
[11:33] <LarstiQ> igc: is there a windows vm running the testsuite yet?
[11:33] <igc> bzr pull ../normal-repo
[11:33] <matkor> lifeless: yah, but how to say to bzr: use foo/foo.moved and forget about second one ? Deleting foo.moved and bzr resolve deos not make confilct resolved ...
[11:34] <igc> lifeless: the normal repo I'm trying first is python
[11:34] <igc> hi LarstiQ
[11:34] <lifeless> matkor: does bzr st list foo.moved as unknown? if so, you probably just had foo.moved on local disk before the merge
[11:34] <LarstiQ> igc: heya :)
[11:34] <igc> LarstiQ: not to my knowledge
[11:34] <LarstiQ> igc: hmmm
[11:34] <lifeless> igc: yes, the fetch logic is O(n^2) at the moment
[11:34] <igc> I'm pretty sure jam is running on Windows these days
[11:35] <lifeless> igc: the raw compressor is better, but *shrug*
[11:35] <igc> lifeless: when n = # of revisions?
[11:35] <igc> s/when/where/
[11:36] <igc> LarstiQ: and vila was for a while as well IIRC
[11:36] <LarstiQ> igc: ok. I watched a run on markh's laptop, and it didn't look too good.
[11:37] <lifeless> igc: yeah; it caps at 20MB of raw output and resets, but it will be doing 1000's of extractions
[11:37] <lifeless> igc: I should have a better InterObject done today
[11:38] <igc> LarstiQ: as in the test suite didn't look good? or some particular bzr operations?
[11:39] <igc> lifeless: ok. VM memory use for the pull is up to 780MB fwiw
[11:39] <matkor> lifeless: Is hard to say what happend becouse other person asks me to help with that ...
[11:40] <lifeless> igc: mysql? ooo?
[11:40] <LarstiQ> igc: test failures, including not entirely deterministic ones related to test cleanup
[11:40] <igc> lilfeless: I'm planning to do those tonight but I was waiting for the python one to finish first
[11:40] <lifeless> matkor: ok. well, if bzr st shows one as unknown, just use regular 'mv' etc
[11:41] <lifeless> igc: it may well be faster to do a upgrade to --btree-plain first (or btree-rich-root etc9
[11:43] <igc> lilfeless: interesting. I did try the same thing with --btree-plain. That took 195 secs
[11:43] <igc> which is slowly than a branch (170s) but not by a lot
[11:43] <lifeless> igc: so the btree index layer won't bloat anywhere near as much as teh graphindex one
[11:43] <lifeless> igc: 'bzr upgrade --btree-plain' will be _much_ faster than a pull :)
[11:43] <igc> s/slowly/slower/
[11:55] <lifeless> igc: (upgrade --btree-plain will rewrite just the indices)
[12:45] <ignas> how do I cancel a merge?
[12:45] <awilkins> ignas: Revert
[12:45] <ignas> bzr revert seems to only revert the changes
[12:45] <ignas> i still can see the merged revisions in the pending merges list
[12:45] <lifeless> ignas: are y ou running 'bzr revert'
[12:45] <lifeless> ignas: or something more complex ?
[12:45] <ignas> "bzr revert ." ;)
[12:46] <ignas> got the hint
[12:46] <lifeless> ignas: the . tells revert not to touch pending merges :)
[12:47] <menesis> ignas: bzr revert --forget-merges
[12:47] <ignas> menesis: thanks, just plain "revert" worked too though
[12:48] <ignas> by the way - what is the correct way to resolve a tricky situation:
[12:48] <ignas> i have a release branch 2008.04
[12:48] <ignas> and trunk
[12:48] <ignas> I had a bugfix branch for small bugfixes
[12:48] <ignas> it worked fine
[12:48] <ignas> but I have managed to do bzr pull from trunk to it
[12:48] <ignas> and now if I want to merge a couple more of the bugfixes to 2008.04
[12:49] <ignas> i am getting all the new stuff from trunk that got pulled ...
[12:49] <ignas> i could -r rev1..rev2 the merge to my release branch
[12:49] <ignas> but then I will lose the history for separate commits (I think)
[12:50] <ignas> any ideas? except for picking all the separate commits from the bugfix branch (that is based on trunk now) and moving them to some other branch
[12:50] <ignas> that is based on some common ancestor of trunk and release
[12:57] <ignas> and a related question - where should I be branching my "feature that will probably go into the release and trunk" from to have nice merges later?
[12:58] <ignas> I am adding python2.5 support at the moment, and if i am branching from 2008.04 directly - I am getting release specific changes in the merge from 2.5 branch to trunk...
[12:58] <ignas> must I always branch specifically from the "branching" point of the release and trunk branches?
[13:02] <lifeless> ignas: I generally branch features from trunk, and do a cherrypick merge if needed
[13:02] <lifeless> ignas: but if you know a-priori that it will go into a release branch as well as trunk I would tend to start with the release branch
[13:04] <ignas> well - release branch has at least some release specific changes (like setting of the version for a 2008.04.02 release for example)
[13:05] <ignas> so as menesis just explained to me - bugfix branch should be branched out as early as feasible (like when the bug was first encountered/appeared in the code)
[13:05] <ignas> and features should not be merged into release branches that have been in use in general
[13:06] <lifeless> well, different folk find different things work
[13:06] <lifeless> I generally ignore history and just code to head; backporting is usually dead easy bzr-wise
[13:07] <ignas> and how do you do backporting?
[13:07] <ignas> cherry picking?
[13:13] <ignas> oh, apparently I can bzr revert some changes that were release specific, and it seems that it is "legal" to do so, so I can just skip the changes made to version.txt and to setup.py when merging from "a branch that was branched from release" to "trunk"
[13:57] <lifeless> ignas: yes, I cherry pick when needed
[14:05] <jelmer> re
[14:28] <uws> So, when is a new .pack file created?
[14:29] <uws> the sizes are really different in my repository
[14:29] <uws> I'm using a --rich-root-pack repos (that's best, right?)
[14:29] <jelmer> uws, hi
[14:29] <uws> hey jelmer
[14:30] <jelmer> uws, rich-root-pack would probably be the best choice if you don't have to worry about pre-1.0 clients
[14:30] <uws> i'm hip and up-to-date, so no worries there :)
[14:31] <jelmer> (-:
[14:31] <uws> jelmer: also, i'm cloning a svn repos using svn+http://  and it seems to open a new connection for each revision
[14:31] <uws> is that right?
[14:31]  * jelmer catches up on three days of bzr-svn highlights
[14:31] <jelmer> uws: No, that'd be a bug
[14:32] <uws> svn+http://  is ok right?
[14:32] <jelmer> though a known one if you're using particular older versions of bzr-svn
[14:32] <jelmer> yeah, svn+http:// and http:// should both work
[14:32] <uws> ii  bzr-svn                  0.4.10-2                 Bazaar plugin providing Subversion integration
[14:32] <spiv> jelmer: I'd love a fix for the find_tags stage being very slow.
[14:32]  * spiv is about to sleep
[14:32] <uws> jelmer: If i pull from the http:// one later after branching from svn+http://, will that download all revisions again?
[14:33] <jelmer> uws: No, the identity of the repository does not depend on the location
[14:33] <uws> so what does it depend on?
[14:33] <jelmer> spiv: I may have a look at that in the next two days
[14:33] <jelmer> uws: the subversion repository uuid
[14:33] <spiv> jelmer: wonderful!
[14:33]  * spiv -> sleep
[14:33] <jelmer> uws, and the path in the repository
[14:33] <uws> ah ok
[14:34] <jelmer> spiv: goodnight
[14:34] <uws> I'm cloning webkit svn ;)
[14:34] <uws> takes a LONG time
[14:34] <jelmer> ah, ok
[14:34] <jelmer> I need to do more memory use profiling
[14:34] <uws> jelmer: yeah, it leaks so I pull like 1000 revs at once
[14:35] <jelmer> siretart: do you happen to be in .uk as well?
[14:36] <uws> jelmer: it seems bzr-svn 0.4.10-2 (debian package) calls connect() to the http server quite often\
[14:36] <uws> my guess is each revision
[14:37] <jelmer> uws: That should not be the case with the 0.4 branch of bzr-svn
[14:38] <lamalex_2> Is there a howto for setting up an external branch? I'm starting a new project for work, want to use bzr, but don't want to use launchpad.
[14:38] <uws> bzr-svn is also quite cpu bound it seems
[14:38] <uws> lamalex_2: just type "bzr init" and you're done
[14:38] <jelmer> uws, some of that has changed as well
[14:38] <uws> connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("<IP_ADDRESS>")}, 16) = -1 EINPROGRESS (Operation now in progress)
[14:38] <uws> connect(11, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("<IP_ADDRESS>")}, 16) = -1 EINPROGRESS (Operation now in progress)
[14:38] <lamalex_2> uws: ... that's too easy
[14:38] <uws> jelmer: ^^ i see that every few seconds
[14:39] <lamalex_2> how do I control write access?
[14:39] <uws> lamalex_2: to a shared repository? just file system access rights, or share a shell accoutn
[14:39] <lamalex_2> ah ok
[14:39] <jelmer> uws: Yeah, so that's a known issue which is fixed in the 0.4 branch
[14:39] <lamalex_2> great thanks
[14:40] <uws> jelmer: does it affect speed seriously?
[14:40] <jelmer> uws: The reconnects probably don't matter much
[14:41] <uws> jelmer: so I shouldn't have to upgrade manually (and remove the debian package)
[14:41] <jelmer> uws: I can run a webkit import here as well with the 0.4 branch and see how fast that is
[14:41] <uws> jelmer: it's really slow :)
[14:41] <jelmer> uws, what's the URL?
[14:41] <uws> jelmer: svn+http://svn.webkit.org/repository/webkit/trunk
[14:41] <pickscrape> I can't for the life of me get authentication.conf to work :(
[14:41] <pickscrape> I want it to change the username I connect to a server using, but it always ends up connecting as me.
[14:41] <siretart> jelmer: sorry, no
[14:41] <uws> does running "bzr pack" once in a while help for speed?
[14:42] <siretart> jelmer: I'm .de
[14:42] <pickscrape> Anyone have any experience on this happening and knows what I'm doing wrong?
[14:42] <uws> pickscrape: you can use  sftp://username@host instead
[14:42] <pickscrape> uws: thanks, but I don't want to have to tell my colleagues that they have to specify the username every time they want to access the server :)
[14:42] <uws> pickscrape: is it ssh?
[14:42] <pickscrape> yes
[14:43] <uws> pickscrape: if so, you can also force it in ~/.ssh/config for that particular host
[14:43] <lamalex_2> uws: why would I use init vs init-repository?
[14:43] <uws> furthermore, urls for push/pull are remembered so it's really a one time thing
[14:43] <pickscrape> uws: Oh, thanks for that I'll look into it.
[14:43] <uws> lamalex_2: depends on whether you will have multiple branches, which will share the same "backing storage"
[14:44] <lamalex_2> what do you mean by backing storage, and is this wiki'd somewhere? I hate to waste your time if there's already an article on this
[14:45] <uws> lamalex_2: "bzr help init-repository" versus "bzr help init"
[14:46] <lamalex_2> that doesn't give me why I should use one or the other, advantages,  disadvantages, etc
[14:46] <uws> lamalex_2: branches created with "init" contain ALL history in .bzr
[14:46] <uws> so if you have two branches for the same project, most history will be there twice, resulting in unnecessary disk usage
[14:47] <uws> a repository holds all the revision data, and your branches (doesn't matter how many) just point to a specific revision,
[14:47] <lamalex_2> ah
[14:47] <uws> this results in the repository .bzr dir to be large, and the branch .bzr dirs to be really smalls (a few KB)
[14:47] <lamalex_2> so it sounds like repository is the safer choice, are there any large disadvantages?
[14:48] <uws> lamalex_2: you can't copy the branch directory using conventional means (cp, drag/drop in file browser) to other media
[14:48] <uws> lamalex_2: but you can of course still create branches outside the repo as well
[14:49] <pygi> greetings asabil
[14:49] <jam> Odd_Bloke: want some help with bug 160530?
[14:49] <asabil> hello pygi :)
[14:53] <Odd_Bloke> jam: Yeah, I haven't really looked into it a great deal, but copy-pasting the strings in the bug into PQM's queue didn't cause a problem.  So I don't know if this has been magically fixed, or...? :)
[14:55] <jam> Odd_Bloke: I couldn't tell you for sure, are you seeing stuff that uses the email library to parse the requests, rather than reading the raw string?
[15:07] <colbrac> jelmer: Working on bzr-gtk?
[15:11] <Odd_Bloke> jam: I haven't really looked into it enough, I'll look into it further later.
[15:11] <jam> Odd_Bloke: np
[15:11] <jam> Someone certainly could have cleaned up PQM's message parsing and not mentioned it
[15:12] <uws> jelmer: is it right that bzr-svn looks like it's cpu-bound?
[15:13] <uws>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
[15:13] <uws>  7210 uws       20   0  469m 442m 6700 R 43.7 44.1   7:44.93 /usr/bin/python /usr/bin/bzr pull -v -r 18500
[15:13] <uws> like that, all the time
[15:13] <uws> (also 100% btw)
[15:14] <jelmer> uws: Yeah, some bits may be CPU bound, especially in < 0.4.11
[15:14] <jelmer> colbrac: somewhat
[15:15] <colbrac> jelmer: Is that account coming through?
[15:23] <jelmer> colbrac, yep, just give me a few minutes
[15:24] <jelmer> uws, it's pretty slow here as well, but not using a lot of cpu
[15:24] <jelmer>  2497 jelmer    20   0  209m 178m 7992 S   14 11.8   8:11.88 python
[15:25] <uws> jelmer: Hmm, your 0.4 branch installs ra.so and client.so (and some other files) directly into site-packages/
[15:25] <uws> is that right?
[15:27] <uws> jelmer: Unable to load bzr-svn extensions - did you build it?
[15:27] <uws> strange, I did
[15:29] <lifeless> jelmer: http://news.launchpad.net/ppa/introducing-autoppa
[15:29] <jelmer> lifeless, blegh, ubuntu only :-( Hopefully it works on Sid :-)
[15:37] <james_w> rockstar: hi, are you still looking for me?
[15:38] <rockstar> james_w, kinda.  I've got some questions about using bzr-builddeb
[15:38] <james_w> rockstar: ah, sure, ask away
[15:40] <lifeless> jam: hi
[15:41] <rockstar> Well, I'm having an awkward time trying to find a good workflow.  I just wondered, since you probably use it on a normal basis, I wonder if you could recommend a workflow
[15:41] <rockstar> james_w, ^^
[15:41] <james_w> I don't use it that much :-)
[15:41] <james_w> what are you struggling with?
[15:42] <lamalex_2> uws: is there any apache setup or anything I need to do to make this repo accessible?
[15:44] <lamalex_2> wow no! this rules. bzr+ssh://host/path
[15:44] <jam> lifeless: hi, probably afk for a bit, my son is waking up from the morning nap, and I'll be taking him to day care in a bit
[15:44] <jam> LarstiQ: I *do* use win32 probably 75% of the time, but I *don't* run the full test suite (on either platform). I know that BzrDir.clone() is broken (BzrDir.sprout() works, which is a bit weird), but that is something that probably makes a lot of tests fail
[15:45] <jelmer> uws, hmm, it is slow
[15:45] <jelmer> uws, I'm at 800 revisions now
[15:45] <jelmer> 28k to go :-)
[15:45] <uws> jelmer: yeah, just stop it. you can branch from me later if you wish
[15:46] <uws> I'm at ~18000 already
[15:46] <jelmer> ah, ok - over how much time?
[15:46] <jam> lifeless: I would be curious to know how you did remote testing of your btree code
[15:46] <uws> ~1.5 days
[15:46] <jelmer> wow, ok
[15:46] <jam> As I'd like to put the new bloom stuff through its paces over a remote connection
[15:46] <jelmer> uws: I guess the 0.4 branch is a bit faster then
[15:46] <uws> jelmer: I couldn't get it to work
[15:46] <jam> So far, I've just finally managed to do better than no blooms on a local filesystem
[15:46] <uws> jelmer: complained about needing bzr 1.6, and it doesn't work with the 1.6b2
[15:47] <uws> complaining about make_knit_factory or something
[15:47] <jam> Not a *lot* better yet, but *better* which means they are viable :)
[15:47] <jelmer> uws: yeah, it needs bzr.dev
[15:48] <uws> jelmer: will the speed improvements be an order of magnitude?
[15:49] <jam> lifeless: oh, and until I get the 'paged bloom' code written, they won't scale to 1M+ pack files, because they will always read the full array
[15:49] <jelmer> uws, it's doing about one revision per three seconds here
[15:49] <jelmer> what sort of speed are you seeing?
[15:49] <jam> Though we could still *create* them, even if we didn't always use them yet.
[15:49] <uws> jelmer: roughly that yes
[15:49] <uws> jelmer: however I don't see that anywhere
[15:49] <uws> jelmer: only from the "strace -econnect)
[15:50] <uws> It just says "Pull phase 0/2" for a VERY long time
[15:50] <rockstar> james_w, for instance, I'm trying to package a tarball from upstream to put in my PPA.  It doesn't make sense for me to version the contents of the tarball, so I figure I version debian/
[15:50] <LarstiQ> rockstar: why, that almost sounds like a larstiq workflow ;)
[15:51] <uws> jelmer: will speed be constant when the revision number gets higher for my bzr-svn branching?
[15:51] <rockstar> At this point, what does bzr-builddeb provide over the standard debian tools?
[15:51] <jelmer> uws, yeah, that's the idea
[15:51] <uws> jelmer: Ok, I'll just let it run for the next few days then :S
[15:52] <uws> launchpad doesn't have a mirror either
[15:52] <uws> would they be interested in mine?
[15:52] <james_w> rockstar: if you only want to version debian/ then bzr-builddeb will construct the source package for you by assembling the bits in the right way. You can do this yourself, but you may find it more convenient.
[15:53] <rockstar> Where is the convenience?  That's really what I'm looking for.
[15:53] <jelmer> uws, installation of the 0.4 branch should be fixed now
[15:53]  * jelmer wonders who he has to bribe to get his gssapi patch reviewed
[15:54] <james_w> rockstar: to build the source package you need the upstream tarball unpacked, with debian/ in place. You can obviously do this by hand, but I found doing that tedious.
[15:54]  * LarstiQ takes euros and litas.
[15:55] <jelmer> LarstiQ: I can give you 200 litas I think
[15:55] <jelmer> :-P
[15:55] <jelmer> I still have some from last year, not likely to need them in the near future
[15:56] <LarstiQ> jelmer: you sir, have a deal!
[15:56] <LarstiQ> but first I'm going to bbq in the park.
[15:56] <rockstar> james_w, Ah, so you can say "download the tarball from here, build everything" ?
[15:58] <james_w> rockstar: yeah, one thing it can do is to try and get a tarball for you if you don't have one already (using apt or uscan).
[15:59] <rockstar> james_w, Ah, that's what I was looking for.
[15:59] <jelmer> LarstiQ: heh, bon appetit
[16:13] <lamalex_2> This transport does not update the working tree of: bzr+ssh://combatshadow/var/www/acetechgroup.com/systems/htdocs/systems/. See 'bzr help working-trees' for more information. -- What does that mean? Why can't I push to my repo?
[16:14] <radix> you can, it just doesn't update the working tree
[16:14] <lamalex_2> what does that mean?
[16:16] <james_w> lamalex_2: did you have a look at "bzr help working-trees"?
[16:17] <lamalex_2> so I have to run bzr update in my repo whenever I push
[16:17] <lamalex_2> that's annoying
[16:18] <james_w> lamalex_2: there are two plugins that might interest you, the first is "push-and-update", which automates "ssh wherever 'bzr update'" when you push
[16:18] <james_w> then second is "bzr-upload" that allows you to upload the working tree to a remote location, this is what web developers usually want.
[16:19] <lamalex_2> that's what I want too
[16:21] <lamalex_2> where can I get the push-and-update plugin?
[16:26] <lifeless> https://launchpad.net/bzr-push-and-update
[18:14] <Odd_Bloke> lifeless: So I've looked at your cleanup of thumper's queue-abstraction branch and it _mostly_ looks OK.  There are a couple of things that I think could be better, but it's hard to know whether it makes sense in this branch...
[18:29] <bud3030> Hi bzr  I have changed email address should i change it in bzr.conf, auth,conf, location,conf
[18:30] <Odd_Bloke> bud3030: Use 'bzr whoami <new string>' and 'bzr whoami' again to check it's correct.
[18:30] <bud3030> Odd_bloke thanks Ill give a try
[18:52] <pickscrape> Would the correct way to reverse a changeset on a branch be: bzr merge -r 8..7 . (where the revision to reverse if r8)?
[18:52] <pickscrape> s/if/is/
[18:53] <pickscrape> Actually... yes, that works. I'd accidentally done the merge the other way round, and the result makes bzr stat crash
[18:53] <pickscrape> bzr diff --stat
[18:53] <pickscrape> oops
[19:02]  * thumper wonders what bzr diff --stat does
[19:03] <pickscrape> Nothing unless you install the diffstat plugin :)
[19:03] <rockstar> Dangit, someone took my bzr-stats idea...
[19:03]  * rockstar snoozed and lost
[19:04] <pickscrape> rockstar: It's been around for ages
[19:04] <pickscrape> https://launchpad.net/bzr-diffstat
[19:04] <asabil> pickscrape: you can also simply uncommit
[19:04] <pickscrape> I recently picked it up and got it working with 1.5.
[19:04] <asabil> if you didn't publish the branch yet
[19:05] <pickscrape> asabil: no, this is a changs from a couple of revs back from HEAD that has been published. I figure it out though.
[19:05] <rockstar> pickscrape, that doesn't make me any less of a sad panda  :)
[19:05] <pickscrape> rockstar: :( One of the reasons why I've not started any projects of my own too
[19:51] <bud3030> jam how can one correct the error 13 : hook route to ubuntu machine
[19:52] <bud3030> am i log in to go privite
[20:06] <newz2000> hi, maybe this is esoteric, but it never hurts to ask...
[20:07] <newz2000> is there a plugin that will export a project as a zip file?
[20:07] <newz2000> (or some other archive)
[20:07] <beuno> newz2000, bzr export
[20:07] <beuno> it's not a plugin, it's a default command
[20:08] <newz2000> :-D
[20:08] <newz2000> that explains why it wasn't on the plugins page
[20:08] <newz2000> so I guess I'm not the only one who's wanted this feature then
[20:08] <beuno> probably not  :)
[20:09] <newz2000> ok, one more thing then...
[20:10] <newz2000> I have a workflow for some projects that includes a few steps. Is there a way to bundle these steps into one process? I like the plugin that does ssh -c bzr co .
[20:10] <newz2000> I can script it of course, just wondering if there was a hook for bzr push that would do it automatically
[20:11] <beuno> you can hook to post-tip-change, and make that run a script
[20:14] <newz2000> ok, I see this in the docs... out of curiosity, is it possible to define different actions on a per project basis?
[20:16] <beuno> hm, that's a good question
[20:16] <beuno> I don't think there's a straight forward way of doing that from bzr
[20:16] <beuno> you can probably do that on your script
[20:16] <beuno> pass on the branch nick or path
[20:17] <newz2000> At a diff job we did this with ant, so maybe I'm crossing the point of what my vcs should be doing for me
[20:19] <newz2000> beuno: thanks for the export tip... that's a big help.
[20:19] <beuno> newz2000, welcome'
[20:23] <uws> So, my bzr-svn for webkit will take a few days methinks
[20:23] <uws> there's no launchpad mirror. would they me interested in mine?
[22:00] <bkor> jelmer: could you please advise on https://bugs.launchpad.net/bugs/248119 ?
[22:54] <chadmiller> Hi all.  One of my cow-orkers is using bzr.dev of an hour ago, and gets a AttributeError exception. ...
[22:55] <Peng> chadmiller: Pastebin the traceback?
[22:55] <Peng> chadmiller: Does he have any plugins installed?
[22:56] <Peng> chadmiller: FWIW, it works for me, but I haven't tried to commit or anything.
[22:56] <chadmiller> Five lines pasted here:
[22:57] <chadmiller>   File "/usr/local/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1092, in sprout
[22:57] <chadmiller>     hardlink=hardlink)
[22:57] <chadmiller>   File "/usr/local/lib/python2.5/site-packages/bzrlib/bzrdir.py", line 1386, in create_workingtree
[22:57] <chadmiller>     return self._format.workingtree_format.initialize(
[22:57] <chadmiller> AttributeError: 'property' object has no attribute 'initialize'
[22:57] <chadmiller> That's from "bzr branch".
[22:57] <chadmiller> I have him checking that ssh is working correctly.  I've seen some weird problems caused by transport failure.
[23:35] <chadmiller> Ideas anyone?    He knows gdb, though, and Python ain't hard.
[23:37] <mwhudson> also
[23:38] <mwhudson> what exactly command is he running?
[23:38]  * mwhudson finds that his irc grammar is getting worse and worse
[23:39] <chadmiller> mwhudson: "bzr branch bzr+ssh://ourserver/branchname bn"
[23:39] <mwhudson> chadmiller: ok, can you get him to run it again with BZR_PDB=1
[23:39] <mwhudson> and then type
[23:39] <mwhudson> p self
[23:39] <mwhudson> p self._format
[23:39] <mwhudson> p self._format.workingtree_format
[23:39] <mwhudson> ?
[23:40] <chadmiller> I'll do so.  he's offline now, for sleep or something.
[23:40] <chadmiller> (Lazy Swedes!)
[23:40] <mwhudson> ok
[23:40]  * mwhudson looks to see if the problem can be seen in the code
[23:40] <mwhudson> chadmiller: oh, one more, what format is the branch hes getting in?
[23:41] <chadmiller> mwhudson: "Repository branch (format: pack-0.92)"
[23:41] <mwhudson> chadmiller: ok, ta
[23:45] <mwhudson> hm hm
[23:46] <mwhudson> i wonder if _format is the class object, when it should be an instance
[23:46] <mwhudson> hey wee, i can reproduce
[23:47] <mwhudson> which means... a rather bad miss in bzr's tests
[23:50] <thumper> mwhudson: file a critical bug
[23:50] <thumper> mwhudson: to make sure it is fixed for 1.6 release
[23:50] <mwhudson> wth
[23:50] <mwhudson> it only happened once :(
[23:51] <thumper> weird
[23:57] <mwhudson> chadmiller: fwiw, my experience suggests that if your work mate simply tries again, it will work for him :/
[23:57] <chadmiller> mwhudson: Consider this a counterexample, then.
[23:58] <mwhudson> oh good
[23:58] <mwhudson> ah hurrah, i hit it in pdb
[23:58] <Peng> Lazy import issue?


[00:29] <Unit193> 'Start in 12 hours'  Geez, who uploaded KDE again?  Thanks for the geoip-database sync.
[01:35] <valorie> Unit193: KDE is the community, LOL
[01:35] <valorie> what was re-uploaded?
[03:52] <cjwatson> Unit193: Not so much KDE, more that we're in the middle of redeploying one of the builder clouds.
[03:52] <cjwatson> I'm only noseyparkering it but it looks like it should be done soon.
[10:10] <doko> xnox: how much do you care about gcc-arm-linux-androideabi ?
[10:11] <doko> hmm, and we have u-boot-linaro depending on gcc-4.7
[10:13] <xnox> doko, i thought it should be removed, once all the reverse deps are gone... no? cause it is ubuntu only package?
[10:13] <doko> yes, I would like to see it removed
[10:18] <xnox> doko, filed RM bug for android and gcc-arm-linux-androideabi -> https://bugs.launchpad.net/ubuntu/+source/gcc-arm-linux-androideabi/+bug/1717229
[10:19] <doko> do we know about u-boot-linaro?
[10:23] <xnox> that one is from 2012, just u-boot is from 2016.03 in ubuntu, and it is 2017.09 in debian experimental
[10:23] <xnox> (2017.07 in unstable)
[10:24] <xnox> ppisati, would you at all know if we use u-boot-linaro anywhere in ubuntu still? or is our u-boot package good enough for everything / everything got upstreamed?
[10:29] <xnox> opened RM bug for u-boot-linaro
[10:29] <xnox> https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/1717232
[10:33] <xnox> doko, is reverse-depends failing to parse deps, or does gcc-5-cross and gcc-6-cross really do build-depend on binary packages from gcc-4.7-armel-cross and gcc-4.7-armhf-cross
[10:37] <doko> no, they should not
[10:37] <doko> I think I never rebuilt these cross packages after introducing newer versions, so maybe the control file still has them?
[10:42] <xnox> doko, i think that reverse-depends is simply confused.
[10:44] <xnox> hm
[10:44] <ppisati> xnox: uhm, as far as i know, we don't use u-boot-linaro anywhere
[10:45] <ogra_> i think that came from the linaro mx5 images that we used to build in 12.04
[10:45] <ogra_> long dead
[10:45] <xnox> doko, both src:gcc-4.7-armel-cross and src:gcc-7-cross build libhfgcc1-armel-cross however for some reason $ reverse-depends picked the one with lower version number, rather than higher version.
[10:54] <juliank>  rbalint: I believe unattended-upgrades.service should gain a Before=apt-daily.service, so that when shutting down, and apt-daily.service is already running, unattended-upgrades.service stops after it.
[10:55] <juliank> um, apt-daily-upgrade.service too
[10:56] <juliank> A Before=B essentially means that A is stopped after B
[10:58] <juliank> slangasek: I noticed that if we ever do an apt security update, we also have to move unattended-upgrades to security, especially if we add a versioned dep on a u-u with --download-only support; otherwise the security update would not install automatically (as u-u would not pull in the new u-u from updates)
[10:59] <juliank> for xenial / zesty
[11:01] <juliank> Or well, let's hope it does not come to that in the near future, and build in a work around in apt
[11:13] <rbalint> juliank: why do you believe that ordering is needed?
[11:14] <rbalint> juliank: AFAIK recent apt-s do only downloads in apt-daily.service thus it can be killed without any consequence
[11:14] <juliank> rbalint: See second line
[11:14] <juliank> I actually meant apt-daily-upgrade.service
[11:15] <juliank> It's unclear if it's needed, but it seems like a good idea. Locking is a bit racy in some parts still, and AFAIUI, apt-daily-upgrade does not run to completion, so if you have this set, you'd want u-u.service to run after it to complete the task?
[11:15] <juliank> Otherwise, u-u.service might run while apt-daily-upgrade is running, and fail trying to get the lock, and won't run any remaining upgrades.
[11:16] <juliank> It's relatively unlikely too happen, probably, but still seems like a good idea
[11:16] <rbalint> juliank: depending on InstallOnShutdown = true or not u-u.service or apt.*service will perform the upgrade
[11:17] <rbalint> juliank: there is no case when both can upgrade, thus there is no case for taking over
[11:18] <juliank> Let's say you have 64 updates to install.
[11:18] <juliank> apt-daily-upgrade.service is running, but you shut down. It exits after 16 updates.
[11:18] <juliank> What happens to the remaining 48 ones?
[11:19] <juliank> or do you say apt-daily-upgrade.service will not run at all when Unattended-Upgrade::InstallOnShutdown is set
[11:19] <juliank> ?
[11:19] <rbalint> u-u.service shuts down the upgrade and does not take over
[11:19] <rbalint> juliank: the service will run, but u-u stops when calling from apt's service
[11:20] <rbalint> juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade#L1535
[11:21] <juliank> aye, then it's fine
[11:21] <rbalint> juliank: https://github.com/mvo5/unattended-upgrades/blob/master/unattended-upgrade-shutdown#L134
[11:21] <juliank> sorry about the confusion
[11:21] <rbalint> juliank: no problem, this was not clear to me before diving into u-u code :-)
[11:22] <juliank> There's still some other maintenance cleanup crap done in apt-daily-upgrade.service if the options are enabled
[11:22] <rbalint> juliank: if you find something racy in u-u please report it, because i'd like to make it rock-solid
[11:23] <juliank> Well, the other stuff we do is running clean and autoclean after u-u if the options are set. But then, if you use install on shutdown, they simply are not compatible.
[11:24] <juliank> I should push guillem about the whole frontend lock to get any remaining lock race conditions fixed.
[11:26] <rbalint> juliank: from not breaking the system POV they are safe https://anonscm.debian.org/git/apt/apt.git/tree/debian/apt.systemd.daily#n507
[11:26] <juliank> indeed, that they are.
[11:26] <juliank> But don't enable them together or there will be no packages left to install on shutdown :D
[11:26] <juliank> or well, u-u will redownload them
[11:27] <rbalint> juliank:yes, it will redownload
[11:29] <rbalint> juliank: if there are still upgrade-able packages apt could keep the cache
[11:29] <juliank> rbalint: Well, that's what happens if you only use autoclean :)
[11:29] <juliank> Just don't set the option to run clean :D
[11:29]  * juliank should drop that option probably
[11:30] <juliank> Although maybe some people do really need an option to regularly delete all cached packages, who knows.
[11:30] <juliank> (like, they have a fast local mirror and don't bother with caching)
[11:32] <rbalint> juliank: by default InstallOnShutdown is false thus the default apt service works as expected with either clean or autoclean
[11:33] <juliank> true, and they are off by default too. it was mostly just a funny remark
[15:32] <doko> slangasek: your libhybris upload ftbfs
[15:33] <doko>         * malloc/malloc.c (cfree): Turn into compat symbol.
[15:33] <doko>         (__cfree): Remove alias.
[15:33] <doko>         * stdlib/stdlib.h (cfree): Remove declaration.
[15:33] <doko>         * malloc/malloc.h (cfree): Likewise.
[15:33] <doko>         * manual/memory.texi (Freeing after Malloc): Remove cfree.
[15:46] <doko> can't find the vwrite change ...
[15:58] <slangasek> doko: yes, already discussed that libhybris ftbfs with infinity on #ubuntu-release last night; and wondered if morphis__ would want to care about this
[15:59] <doko> slangasek: I stand corrected about the inclusion of -proposed. it's possible. but I think we don't want it
[16:02] <slangasek> doko: fwiw in this case I disagree; in general we always build with -proposed enabled in the main archive, and we know that there's almost nothing of relevance in -proposed right now that is both a build dependency and not targeted for release
[16:03] <doko> slangasek: sure, but we empy -proposed for the release
[16:10] <slangasek> doko: yes, but it's already pretty empty right now, compared to past releases... and I've said that we should be trying to drive -proposed to zero throughout the cycle, not just emptying it at release... so the delta in terms of ftbfs false-positives/negatives should be small here
[16:11] <doko> pretty empty? cough ...
[16:18] <cjwatson> doko: we have graphs of this stuff :-)  http://people.canonical.com/~ubuntu-archive/proposed-migration/history.html
[16:18] <cjwatson> ah, hmm, but that's only for this release
[16:19] <cjwatson> not quite the proof I was looking for
[19:30] <pitti> Laney: you restored the second cloud yesterday or today, right? are you aware of any configuration chagnes that could explain failures like<EMAIL_ADDRESS>?
[19:31] <pitti> Laney: exact same xenial cloud image as in a successful run from two days ago, same downstream packages, tests with that PR's debs work  locally
[19:36] <pitti> Laney: ah, nevermind, got it reproduced


[03:17] <Burgundavia> rob^, join the club, I did the same thing with my old gpg key
[03:45] <rob^> heh
[04:11] <nickrud> anyone working tonight?
[04:12] <Madpilot> working? not really, just passing through
[04:12] <nickrud> hi Madpilot
[04:12] <Madpilot> hi nickrud
[04:13] <nickrud> I've actually begun to have some free time recently, so I've been rebuilding some of my old docs on the wiki
[04:14] <nickrud> The thing is, I'm also not sure just where the least effort will get the most results :)
[04:14] <Madpilot> You can always visit CategoryCleanup to see the pages most in need of help
[04:15] <nickrud> That's why I picked the voodoo thing as my learning page, it was in that list. It's a long one.
[04:16] <Madpilot> the whole laptop thing is going berzerk - most of the stuff in RecentChanges is laptops... cool
[04:16] <nickrud> don't have one of those.
[04:16] <Madpilot> I've sort of "adopted" the Apache pages, and BasicCommands
[04:16] <Madpilot> no, just a desktop here too
[04:17] <nickrud> I used BasicCommands for cleaning up the aptitude page. I'm also wondering about the style guide.
[04:17] <nickrud> and, of course, doc book. Is there a good book on that?
[04:18] <nickrud> paper.
[04:18] <Madpilot> no idea, I've barely skimmed the style guide myself, and never touched docbook
[04:19] <nickrud> One thing I've picked up while dabbling in debian is, patches are welcome, and just fixes might get done
[04:19] <nickrud> It's a reasonable attitude.
[04:20] <Madpilot> O'Reilly publish a "definitive guide to Doc Book", $36 USD though
[04:20] <Madpilot> http://www.oreilly.com/catalog/docbook/index.html
[04:21] <nickrud> let's see, $26 in '00, and $36 in '05: cheap docs
[04:22] <Madpilot> OReilly isn't cheap, but they're damn good. My (few) O'Reilly books are always in use...
[04:22] <nickrud> One, on bash. It's travelled a lot :)
[04:23] <Madpilot> my O'Reilly CSS book is my web design bible...
[04:24] <nickrud> That's what you do?
[04:25] <Madpilot> not professionally
[04:25] <Madpilot> semi-pro
[04:25] <Madpilot> I maintain a couple of relative's websites, and a bunch of my own
[04:26] <Madpilot> http://www.warbard.ca/
[04:26] <nickrud> I know that place, I was there a while back. I got paid for fun.
[04:26] <Madpilot> yeah, I get paid to experiment with HTML/CSS. nice extra money
[04:27] <nickrud> back then, it was forth, believe it or don't.
[04:27] <Madpilot> cool.
[04:28] <Madpilot> maintaining my stepmother's small-business site is more like work, though. I didn't build it, and the code is really, really bad
[04:28] <Madpilot> 20+ nested tables per page, so any small change takes forever... :(
[04:29] <Madpilot> what were you programming in forth?
[04:30] <Madpilot> hey, it's Frontpage, or whatever awful Whizzy editor was used on my stepmom's store site! <gag, retch, spit>
[04:30] <nickrud> www.usmisson.org. look at that.
[04:31] <Madpilot> typo in that URL? get "no such server" here
[04:31] <nickrud> as usual
[04:31] <nickrud> www.usmission.org
[04:33] <Madpilot> wow, what a classic piece of 1997-98 web design! (sorry, but it's true!)
[04:34] <nickrud> yup
[04:34] <nickrud> you pinned it pretty well, i think.
[04:34] <Madpilot> the construction of the maps is sort of cool - absolutely-positioned divs to get the blinking gifs where they're needed
[04:34] <Madpilot> but those blinking gifs... are blinkin' awful...
[04:34] <nickrud> lol
[04:34] <Madpilot> ;)
[04:35] <nickrud> I *always* apologize when I point people at that.
[04:35] <Madpilot> heh
[04:36] <Madpilot> actually, as a method of constructing that sort of "imagemap" type thing, the absolutely positioned divs are a good idea
[04:36] <Madpilot> it just need a graphics cleanup, badly...
[04:36] <nickrud> yeah, it hasn't changed for a long time.
[04:37] <Madpilot> lots of websites around like that
[04:37] <Madpilot> great burst of enthusiasm at the start, then it gathers virtual dust
[04:37] <nickrud> It's work, I'll grant you that.
[04:38] <Madpilot> especially making graphics changes
[04:38] <nickrud> Getting that last thing right.
[04:38] <Madpilot> graphics are way, way more work than code
[04:38] <nickrud> if you mean creation, it's generally more than work, I think
[04:39] <nickrud> I use free graphics, me.
[04:40] <Madpilot> home graphics is 1/3rd artistry, 1/3 knowing your program (the GIMP or PS), and 1/3rd code work
[04:40] <nickrud> ok, it's 2/3's work :)
[04:41] <Madpilot> and 3x harder than just coding!
[04:41] <mpt> arrrrrhhhh
[04:41] <nickrud> which one?
[04:41] <mpt> http://www.usmission.org/KansasCity.html
[04:41] <Madpilot> one oddity on that mission site is the mix of divs and tables - with no need for tables at all...
[04:42] <mpt> awww, it does a fancy fade effect
[04:42] <mpt> how cute
[04:42] <Madpilot> a fancy fade effect with really, really blurry graphics
[04:42] <nickrud> excuse me, I have to go load java. be back.
[04:43] <Madpilot> and then a huge chunk of text that's actually an image - that's not cool either...
[04:43] <mpt> heh
[04:43] <mpt> Anyone remember Corel Office for Java?
[04:43] <Madpilot> Corel what for where? ;)
[04:44] <mpt> It took about 10~15 minutes to start up
[04:45] <Madpilot> full Java apps can do that on slow machines...
[04:45] <rob^> yep
[04:46] <Madpilot> we use a Java app at work - staff-side at the library - that is glacial to start, even on the new machines we've got
[04:46] <Madpilot> it's painful...
[04:47] <Madpilot> need food and drink - bbl
[04:48] <nickrud> I hope no one thinks I had anything to do with that site ;P
[04:49] <Madpilot> not your design work, then? ;)
[04:50] <nickrud> I couldn't even get the simple pages I wanted loaded onto the site, so no.
[04:51] <Madpilot> ah well
[04:51] <Madpilot> I finally talked my stepmother into letting me rebuild her business site this fall, so it'll be cleaner & faster, both to load and to update
[04:52] <nickrud> me, I talked the board into rebuilding my foundation. Now people won't trip.
[04:52] <rob^> bbs
[04:53] <nickrud> One more time increment freed :)
[04:54] <nickrud> so, I guess I'll look around the cleanup category, and see what I see.
[05:49] <rob^> grr@wget segfaulting
[09:10] <klepas> !info gaim
[09:10] <klepas> wait
[09:10] <klepas> this is not the cli is it... :-P
[09:14] <Madpilot> ubotu doesn't hang out here, try the main channel!
[05:23] <jsgotangco>  /j


[01:25] <StupidLikeAFox> Hrm, was going to make a liveUSB of 20.04, I cannot figure out what tool I used last time
[01:27] <StupidLikeAFox> what's the recomended tool and/or any clue what I may have used?
[01:28] <Bashing-om> StupidLikeAFox: What is the host operating system that you are booting ?
[01:29] <StupidLikeAFox> xubuntu 18.04lts to make a xubuntu 20.04lts liveUSB
[01:29] <StupidLikeAFox> the vanilla non-persistant sort is fine
[01:31] <Bashing-om> StupidLikeAFox: "dd": just sudo dd if=/path/to/iso of=/dev/sdX bs=4M && sync  is my goto.
[01:32] <StupidLikeAFox> should the usb stick be mounted, or unmouted?
[01:34] <Bashing-om> StupidLikeAFox:  The file system will automount the USB, then run dd - where sdX is known from ' sudo fdisk -lu' or such.
[01:35] <Bashing-om> StupidLikeAFox: dd is also known as (d)isk (d)estroyer - exercise care and caution. dd does what you tell it to do.
[01:42] <StupidLikeAFox> Bashing-om: Ah, thank ya much, that seems to have done the trick
[01:42] <StupidLikeAFox> it's probally what I used last time as well, as I don't seem to have any fancy live-media tools installed
[01:43] <StupidLikeAFox> but my memory is awful
[01:45] <Bashing-om> StupidLikeAFox: ^ guilty too as charged - short text file here beats long memory every time :P
[01:52] <StupidLikeAFox> hrm, on boot the usb complained one file error was found
[01:53] <StupidLikeAFox> and it is running /very/ poorly once it got to a desktop instead of menus
[01:53] <StupidLikeAFox> like I can barely move the mouse or interact with anything
[01:54] <StupidLikeAFox> 18.04.3 image worked fine, but couldn't see my wifi chipset (which is understandable- rather new intel wifi 6 chip)
[01:55] <StupidLikeAFox> same model and size of flash drive the other image I burnt a while back was on, all of thm started as the factory partitioning
[01:56] <StupidLikeAFox> this one does see my second ethernet chipset, but no wifi and is entirely unusable :T
[09:09] <zleap> hi
[09:11] <diogenes_> hi
[09:13] <zleap> i am trying to write an article to promote we need help with development / testing etc
[09:13] <zleap> are we planning on moving from launchpad to github ?  I get so many e-mails I am not sure if that was mentioned in relation to xubuntu or something else
[09:24] <zleap> chat later
[09:29] <bodiccea_> is there a way to permanently disable HDMI audio output ? When I do it via audio mixer, it comes back often (maybe after screen lock).
[13:28] <Aayush> Hi. I have a problem booting Xubuntu.
[13:57] <Deano59> can I use wayland on xubuntu?
[14:36] <rxom_br> good morning fellow linuxers. I'm moving from ubuntu 20.04 to xubuntu 20.04 for two main reasons: app store and tracker-miner
[14:39] <diogenes_> rxom_br, Xubuntu is an excellent choice!
[14:39] <rxom_br> I think so.
[14:39] <rxom_br> my main need is stability and free mem. I do a lot of spreadsheet editing. Any tips in order to keep the system as fast as possible?
[14:41] <diogenes_> rxom_br, disabling unneeded autostart apps ans systemd services.
[14:44] <rxom_br> tks diogenes_, will do that. since I don't own a printer at home, do you think I can disable cups, and in case I need I could reactivate it easily? (I'm pretty noob in Linux, so I feel insecure about disabling stuff)
[14:45] <diogenes_> rxom_br, of course you can disable and re-enable everything.
[14:46] <rxom_br> :-)
[15:40] <sunsetsky> Hi can someone here please help me with this? - https://ubuntuforums.org/showthread.php?t=2443376
[15:48] <diogenes_> sunsetsky, you can safely ignore the "stiky keys: notifications.
[15:49] <sunsetsky> diogenes_: ok thanks.  why are these notifications happening?
[15:52] <diogenes_> sunsetsky, some bugs somewhere.
[17:55] <mnemoc> hi, is there a repository of wallpapers included in previous releases? in 19.10 I had one of a tree reflected on the water but it disappeared when upgrading to 20.04
[17:56] <mnemoc> google isn't being helpful :-/
[17:56] <mnemoc> it looked a lot like the yggdrasil
[17:57] <diogenes_> mnemoc, if you have a 19.10 iso you could get it from there.
[17:58] <diogenes_> !wallpapers
[17:58] <diogenes_>  !wallpaper
[17:59] <mnemoc> thanks for the idea, I'll get the iso and boot it in virtualbox
[18:28] <StupidLikeAFox> I wish there was a metapackage to install support for all the stuff gparted can do
[18:28] <StupidLikeAFox> YASI
[19:05] <krytarik> mnemoc: That appears to be one of <https://xubuntu.org/news/18-04-community-wallpaper-contest-winners/>, so you could also install the 'xubuntu-community-wallpapers-bionic' package.
[19:20] <StupidLikeAFox> Anybody have tips for getting an intel wifi 6 chipset to work in 18.04.3lts?
[19:21] <StupidLikeAFox> Right now I'm briding wifi into my desktop through my laptop + ethernet
[19:23] <StupidLikeAFox> the package backport-iwlwifi-dkms seems interesting
[19:25] <StupidLikeAFox> grabbed it, I'll try restarting to see what happens when the kernel version is current
[19:28] <StupidLikeAFox> okay, that was easy
[19:39] <mnemoc> krytarik: brilliant! thanks a lot!


[22:35] <codingkoopa> Hi all - I was reading the Security Team FAQ (https://wiki.ubuntu.com/SecurityTeam/FAQ) and found it interesting the way -security and -updates work with each other.
[22:35] <codingkoopa> Would it be accurate to say that, if you remove the -updates suite/pocket from your system, you are not opting out of those updates but rather prolonging them until the next security fixes are based on them?
[23:09] <jjohansen> yes
[23:10] <jjohansen> security updates are based on the most recent update that is published
[23:10] <jjohansen> otherwise there would have to be 2 security pockets, one for release, and one for updates
[23:58] <JanC> I suppose in an extreme case removing -updates might break -security too?
[23:58] <JanC> when it depends on some update in another package...