[14:08] <sobersabre> hi.
[14:08] <sobersabre> I have installed bzr on windows.
[14:08] <sobersabre> how do I run bzr explorer ?
[14:09] <sobersabre> (I understand it is a part of bzr distribution)
[14:19] <jelmer> sobersabre: it's a separate plugin
[14:26] <awilkins> The Windows distribution puts a shortcut on the desktop by default
[14:27] <awilkins> Or you can start it on the command line with `bzr explorer` , I think
[14:59] <sobersabre> awilkins: thanks!
[15:00] <sobersabre> I will try this.
[16:41] <zyga> ./bzr/branch/location makes bzr choke when an editor adds EOL to the end of that file
[16:41] <zyga> ack to fix that?
[16:47] <zyga> lifeless: ^ ?
[18:34] <DonDiego> moin
[18:35] <DonDiego> i'm using the text-checker-plugin to avoid adding tabs and trailing whitespace and similar in commits
[18:35] <DonDiego> but the pattern matching is driving me crazy
[18:35] <DonDiego> [name Makefile.am]
[18:35] <DonDiego> this appears to get ignored
[18:36] <DonDiego> below i have "[name *]" with default actions
[18:36] <DonDiego> tabs are allowed in Makefile.am but nowhere else
[18:36] <DonDiego> but the first section never appears to get triggered
[18:36] <DonDiego> any hints?
[19:00] <hsn> is there way to convert repote repo (which i dont admin) to bzr?
[19:00] <hsn> svn repo
[19:00] <zyga> hsn: yes
[19:01] <hsn> let launchpad to import it?
[19:01] <zyga> hsn: if you have a project page you can add a source branch that is imported by launchpad from one of few foreign system
[19:01] <zyga> hsn: svn and git are supported, I'm sure some others are too but I cannot remember the full list like that, I only used git personally
[19:02] <hsn> it is one way or 2 way sync
[19:02] <zyga> hsn: svn has some approval process I'm not familiar with
[19:02] <zyga> hsn: it's just a pull, one way
[19:02] <zyga> hsn: but you can use bzr to commit to a svn repo so your options are wider than just that
[19:02] <zyga> hsn: what are you trying to do?
[19:02] <hsn> need mediawiki in bzr
[19:02] <zyga> it probably is already
[19:03] <zyga> ok, so it's not
[19:03] <zyga> https://code.launchpad.net/mediawiki
[19:03] <zyga> hmm
[19:04] <zyga> it seems you have to be the owner of the project to set it up
[19:04] <zyga> hsn: you can use a local branch
[19:04] <zyga> hsn: not bound to lp in any way
[19:04] <hsn> i own one project in launchpad, i will import mediawiki there
[19:05] <zyga> hsn: don't just import mediawiki there without a good reason
[19:05] <zyga> hsn: unless your projects is mediawiki clone it does not make sense
[19:05] <zyga> hsn: you can simply get a bzr branch of mediawiki locally
[19:06] <zyga> and push it to mediawiki project in lp under your own name
[19:06] <zyga> so bzr push lp:~yourname/mediawiki/name-of-your-branch
[19:06] <zyga> you can convert the svn tree locally using bzr and bzr-svn package
[19:07] <zyga> there are docs on how to do that but I suspect that you can just simply bzr get the svn url
[19:07] <zyga> I don't know what's going to happen if you want to get all the branches, this would work for svn trunk
[19:08] <hsn> i need 17alpha branch
[19:09] <zyga> hsn: then bzr get that directly
[19:09] <zyga> hsn: if you try it and get stuck please ask again
[19:09]  * zyga goes to work in another screen
[19:44] <Tak> any thoughts on http://paste.pocoo.org/show/310950 ?
[19:45] <Tak> the odd thing is that I get that behavior when using libpython, but not at the command line or in a script
[19:46] <jelmer> hi Tak
[19:46] <Tak> hi! :-)
[19:48] <Tak> happy solstice
[19:51] <jelmer> Tak: thanks, you too :-)
[19:51] <jelmer> Tak: what happens if you try without the extensions built?
[19:52] <jelmer> I don't see what's going on, after having had a quick look
[19:52] <jelmer> Tak: In general, calling the command implementations from other code is a bad idea. Any reason for not calling branch.pull() ?
[19:52] <Tak> that's odd...locate tells me that extension only exists in my local bzrlib wc
[19:55] <Tak> mmm, I was using the lower-level api before (branch.pull)
[19:56] <lifeless> zyga: well, its not intended for editing; bzr switch will change it for you
[19:58] <jelmer> Tak: What made you switch?
[19:58] <jelmer> 'morning lifeless
[20:00] <Tak> iirc, there were some instances where the command api was doing some error handling/special-casing that I didn't want to redo by hand
[20:00] <Tak> so then I just went that way across the board
[20:16] <zyga> lifeless: yeah but bzr colo hardcodes the _absolute_ path of the tree so I had to fix it after realizing I broke it with out-of-tree mv
[20:16] <zyga> lifeless: it's a simple fix that would at the very least make the behaviour more aligned with what users might expect
[20:25] <lifeless> you can fix it with bzr switch
[20:26] <lifeless> and the bzr code as written needed absolute paths, older versions will fail if its a relative path, so we always write abs paths.
[20:27] <lifeless> zyga: I don't know if you're aware, but you can actually have \n in filenames :(
[20:33] <zyga> lifeless: then we should print the repr of the filename and still allow a newline _not_ to break this
[20:33] <zyga> lifeless: or do you think that I should not be able to mv my colocated branch  without having it explode?
[20:58] <servertood> Hello
[20:59] <servertood> Does bzr support perforce style mainline branching strategy
[20:59] <servertood> does it support it out of the box
[20:59] <zyga> servertood: what do you mean by mainline branchinc strategy?
[21:00] <servertood> well I have a team on perforce
[21:00] <maxb> servertood: You should bear in mind that most people here, myself included, will have no idea what "perforce style mainline branching strategy" is
[21:00] <zyga> servertood: I used p4 for a year and a half but I never used that term before
[21:00] <servertood> ok well the basic mainline appraoch to branching is something they document as a workflow for using perforce
[21:01] <servertood> I have a team on p4 and we want an open source scm that works the same
[21:01] <servertood> or better....
[21:01] <zyga> servertood: could you please describe the workflow?
[21:03] <servertood> one sec
[21:06] <servertood> theres a master doc
[21:06] <servertood> Im not finding it atm - heres a basic setup http://www.vaccaperna.co.uk/scm/branching.html
[21:07] <servertood> littel better http://www.perforce.com/perforce/doc.current/manuals/p4guide/06_codemgmt.html
[21:09] <servertood> ok I found it
[21:09] <servertood> http://www.perforce.com/perforce/papers/bestpractices.html
[21:10] <zyga> servertood: so which point explains the strategy you mentioned?
[21:11] <servertood> scroll down to where the heading says "mainline model"
[21:11] <zyga> o
[21:11] <zyga> so
[21:11] <zyga> one question
[21:11] <zyga> how big is your "mainline"
[21:12] <zyga> :-)
[21:12] <servertood> 250 MB?
[21:12] <zyga> checkout or entire history?
[21:12] <zyga> do you have binary files?
[21:12] <servertood> some
[21:12] <servertood> images etc
[21:13] <servertood> We are going to lose the history because its all garbage history anyway
[21:13] <servertood> the team that was using the repo all used the same user for all checkins
[21:14] <servertood> so there are alot of binaries that dont need to be there because its a mess but I would say 100MB check out might be right
[21:14] <servertood> but not a huge amount of files
[21:14] <servertood> lots of jar files etc
[21:14] <zyga> servertood: so I was in a similar situation
[21:14] <zyga> and I have the following to say as bzr user
[21:14] <zyga> 1) binaries will make you cry over bzr
[21:15] <servertood> hm
[21:15] <zyga> 2) if you switch vcs you should consider splitting the repo (say to libaries/projects/components)
[21:15] <servertood> that sucks
[21:15] <zyga> and have separate trees for that
[21:15] <servertood> whats the issue with binaries
[21:15] <servertood> just too slow
[21:15] <zyga> once you have that you can use bzr and you will be happy, p4 is actually so brain dead that bzr runs circles around it
[21:16] <zyga> they are not handled very well, the AFAIR official policy is that they are not important enough to be optimized for, if you want to version ISO files bzr will kill you
[21:16] <servertood> ok but what about stuff like images for webcontent
[21:17] <servertood> I dont want to version huge binaries
[21:17] <zyga> it _will_ work
[21:17] <servertood> right now theres some jars that may be 10 MB 50 MB stuff like that
[21:17] <zyga> but bzr assumes pretty much that you have to fit all the tree in memory
[21:17] <zyga> x2-x10
[21:17] <servertood> hm
[21:17] <zyga> depending on stuff it does and bzr version you use
[21:17] <zyga> lifeless: ^^ please bash me for talking nonsense if I do
[21:17] <zyga> anyway
[21:18] <servertood> ok that sounds a little troublesome
[21:18] <zyga> it works very well for source
[21:18] <zyga> text
[21:18] <zyga> for binaries
[21:18] <servertood> so the work around again for binaries is
[21:18] <zyga> it works but it's not the primary use case so you may get big memory usage
[21:19] <servertood> so theres no - "hey for these file extensions dont load into memory..."
[21:19] <zyga> servertood: p4 is a versioned FTP server, really
[21:19] <zyga> servertood: no, for various reasons, it's not that simple
[21:19] <servertood> so is there a workaround
[21:19] <servertood> or is the workaround dont do it at all
[21:19] <zyga> servertood: there's been many people coming in and asking for support but nobody stepped up to do it
[21:19] <zyga> servertood: there is no need for a workaround, if your files are not that big then you will not notice it
[21:20] <zyga> servertood: if you start versioning big stuff then 1) bzr was not designed to do that 2) dvcs is not a good idea 3) it will work if you have the memory
[21:20] <servertood> ok so if I have a huge lib dir say for java
[21:20] <zyga> servertood: then again, perhaps, if you already switch to a multiple-repository model you can keep something for such stuff
[21:20] <servertood> 100-200 MB of jars
[21:20] <servertood> thats going to screw me
[21:20] <zyga> servertood: do you have to version them?
[21:21] <servertood> no because Im going to switch to maven
[21:21] <zyga> and not a manifest that says which version you actually need?
[21:21] <servertood> and pull them down during the build
[21:21] <servertood> but I have to version the project as it is right now
[21:21] <zyga> servertood: I'm not in java world but versioning binaries is not a good idea, version the source and build it
[21:21] <servertood> these are dependencies
[21:21] <servertood> like I said Im going to pull them in from a remote repo during the build
[21:21] <servertood> but for now
[21:21] <zyga> I don't put my dependencies in my tree
[21:21] <servertood> I have to version what I have
[21:21] <zyga> I know java world is different
[21:22] <servertood> which is a bucket of junk
[21:22] <zyga> servertood: what you have to version is the actual _version_ of a binary, not the actual file
[21:22] <servertood> I suppose I could refactor before I import
[21:22] <servertood> maybe that makes more sense in this case
[21:22] <zyga> servertood: there is little difference to saying that I need to bundle glibc and other stuff with my C project
[21:23] <zyga> servertood: except that for Java and SVN/p4 it works (jars will execute) and works for proprietary jars
[21:23] <zyga> servertood: there are two topics here though: how to work with bzr and how to design the infrastructure around janva (which I don't know about much)
[21:24] <servertood> i can get rid of the dependent binaries
[21:24] <servertood> but over time Im going to have non devs version word docs and god knows what
[21:24] <servertood> so if this is really just for source - Im not sure its what Im looking for
[21:24] <servertood> although I have remote teams
[21:25] <servertood> initially Ill be working in non distributed client server type setup
[21:25] <zyga> servertood: if your development process produces .docs then thats another mindset incompatibility
[21:25] <servertood> does that help the performance at all?
[21:25] <zyga> servertood: we would produce source files that get built to documentatino that can be versioned/compared/merged
[21:25] <servertood> we have specifications that need to be versioned
[21:25] <servertood> they are not produced by development
[21:26] <zyga> servertood: I cannot teach you your work as you know best what is needed
[21:26] <zyga> servertood: I can only say this
[21:26] <zyga> servertood: bzr will work great for what it's designed for
[21:26] <zyga> servertood: code
[21:26] <zyga> servertood: and text
[21:26] <servertood> ok
[21:26] <zyga> servertood: if you do the transition in a smart way your overall development model will get more complex but more powerful
[21:27] <zyga> servertood: if you do it in a naive way (bzr add . && bzr ci -m "yay") then you will not get anything inherintly better than p4
[21:27] <zyga> servertood: apart from the hefty price for p4, what was it 1K/year?
[21:27] <zyga> (per seat)
[21:27] <servertood> its pricey
[21:27] <zyga> and it sucks badly
[21:27] <zyga> it's just a versioned FTP site
[21:28] <servertood> The teams I have been working on for years have no issues with it
[21:28] <zyga> they even ship pftpd, that versions files on uploads
[21:28] <servertood> But Im not an SCM expert
[21:28] <Tak> yeah, some of the guys I work with /rave/ about perforce
[21:28] <zyga> servertood: people that were always in a cage don't know how it feels outside
[21:28] <servertood> WHat I will say abvout it is
[21:29] <servertood> it never got in my way
[21:29] <zyga> servertood: eseentially each tool will work but current generation of vcses gives lots of new options that are just awesome for developers
[21:29] <servertood> Thats what Im looking for
[21:29] <zyga> I always found it buggy, slow, and mostly not different better than CVS
[21:29] <servertood> A tool that supports branching more intuitively so you can work with the tool and not be afraid of fucking up the project
[21:29] <zyga> you could go back and edit history
[21:30] <zyga> change commit messages
[21:30] <zyga> nothing was atomic
[21:30] <servertood> well Im not sure IM going to get to nirvana in this first pass
[21:30] <zyga> the GUI was just one gigantic script that often hangs if you are talking over a slow link
[21:30] <zyga> and the whole "multisite" mess is insane
[21:30] <zyga> :-)
[21:31] <servertood> I think Im going to go whole hog
[21:31] <servertood> and dump everythig in it
[21:31] <servertood> and then refactor
[21:31] <zyga> servertood: if you're open sourcing then perhaps giving people a look at the code and the layout will yield more educated answers
[21:31] <servertood> and see how the performance is
[21:31] <zyga> servertood: that's not a good idea
[21:31] <zyga> servertood: then everyone will have to get that first commit you made
[21:31] <zyga> servertood: it's not a centralized repo, you pay for the history
[21:31] <servertood> even after I refactor?
[21:31] <zyga> servertood: certainly
[21:31] <servertood> ok
[21:32] <zyga> servertood: do it the other way around
[21:32] <zyga> servertood: start adding stuff to bzr
[21:32] <zyga> servertood: while refactoring
[21:32] <zyga> servertood: and if your tools support that, break stuff up early at component boundaries
[21:33] <servertood> does bzr support allowing only access to parts of the tree to a user
[21:33] <zyga> no
[21:33] <servertood> this is a high security project
[21:33] <zyga> none dvcs does
[21:33] <zyga> it's not possible
[21:33] <zyga> if I can get anything (any revision)
[21:34] <servertood> so I have to have seperate repos for different access levels
[21:34] <zyga> yes
[21:34] <servertood> ok
[21:34] <zyga> if you can get the whole history and work offline you have to have it locally, by then no security can exist
[21:34] <servertood> right
[21:35] <servertood> so...if Im not do dist devel
[21:35] <zyga> ?
[21:35] <servertood> should I just use a centralized model
[21:35] <servertood> and not use bzr
[21:35] <zyga> ah
[21:35] <zyga> not really
[21:35] <zyga> it depends on how you define security today
[21:35] <servertood> I remember the days of clearcase when they said whatever you do
[21:35] <servertood> dont enable multisite
[21:35] <servertood> I know that this is built in out of the box now
[21:35] <zyga> I don't know how you work, do you have a team of people that can access something that other team or teams cannot?
[21:35] <zyga> ah clearcase
[21:35] <zyga> the tumor of version control
[21:35] <servertood> old days
[21:36]  * zyga shrugs
[21:36] <servertood> Well I actually
[21:36] <servertood> have to control access at the level of the developer
[21:36] <zyga> servertood: no dvcs has "mutisite", I hope you understand that
[21:36] <servertood> yes I do
[21:36] <zyga> servertood: and at the repository level?
[21:36] <zyga> servertood: developers is not what you can control in dvcs
[21:36] <servertood> well right now
[21:37] <servertood> they have code separated by env
[21:37] <zyga> servertood: you can only control the _trees_
[21:37] <servertood> so you either get access to dev or SIT or UAT or prod but thats pointless
[21:37] <servertood> I need to be able to say
[21:37] <servertood> hey a report developer
[21:37] <servertood> cannot access code that does ACH transactions
[21:37] <zyga> important question:
[21:37] <zyga> why not?
[21:38] <zyga> is it "because the code has secret sauce?"
[21:38] <servertood> I dont want them to be able to change it
[21:38] <zyga> or "because I don't want him to screw up"
[21:38] <zyga> ah
[21:38] <zyga> that's easy
[21:38] <zyga> change your model
[21:38] <zyga> have a gatekeeper
[21:38] <zyga> that reviews
[21:38] <servertood> because its a doorway to fraud
[21:38] <zyga> have branches
[21:38] <zyga> that get reviewed and merged
[21:38] <zyga> nobody but the gatekeeper can commit
[21:38] <servertood> sure I guess your right
[21:38] <zyga> so
[21:38] <servertood> its just a high security env so
[21:38] <zyga> you don't care that Joe developer got a _branch_ of Foo
[21:38] <zyga> and changed somethng that broke it
[21:39] <servertood> Actually having more eyes on the code could potentially reduce fraud
[21:39] <zyga> you just crare that he could not get his code in the "blessed" branch of Foo
[21:39] <zyga> so
[21:39] <servertood> sure
[21:39] <zyga> if you can get every part of the code accessible to everyone (or just to each emploee)
[21:39] <zyga> then you are safe
[21:39] <zyga> bzr and other dvcses will work for you
[21:39] <servertood> so they create a branch
[21:39] <servertood> do their dev
[21:39] <servertood> merge into some other branch
[21:40] <zyga> I don't know how you work
[21:40] <zyga> but again
[21:40] <servertood> but can they merge into all branches?
[21:40] <zyga> for dvcses a very common and effective model
[21:40] <zyga> is to have a reviewer
[21:40] <zyga> so I make a branch of my project trunk
[21:40] <servertood> whats stops them from merging into production
[21:40] <zyga> hack it
[21:40] <zyga> and post a merge request
[21:40] <zyga> you can put whatever security/access around a _tree_
[21:41] <zyga> so you can say that physically only that user or that grup can perform alterations in that tree (at filesystem level)
[21:41] <zyga> if you can opernsource your project
[21:41] <zyga> then launchpad will provide you an infrastructure
[21:41] <zyga> with code reviews
[21:41] <zyga> security access
[21:41] <zyga> and all the good stuff
[21:41] <zyga> teams
[21:41] <zyga> users
[21:41] <servertood> in my case that is not legal
[21:41] <zyga> and so on
[21:41] <zyga> so you cannot opensource your code as you intially said?
[21:42] <servertood> my code?
[21:42] <servertood> no I want open source tool for SCM
[21:42] <zyga> ah
[21:42] <zyga> I see
[21:42] <zyga> anyway
[21:42] <zyga> you can deploy your own infrastructure then
[21:42] <servertood> legally I cant do that
[21:42] <zyga> of have someone who will do it for you
[21:42] <servertood> sure Im building a new env
[21:42] <zyga> servertood: btw, what is your business about?
[21:42] <servertood> I really cant say
[21:43] <servertood> So if I have a release branch
[21:43] <zyga> servertood: so to go back to the topic: you can setup security, you can have a working workflow and it will be arguably better than a worflow where once you get commit access you can do anything
[21:43] <servertood> your saying I cannot prevent someone from merging into it
[21:43] <zyga> no
[21:43] <zyga> that's not what I'm saying
[21:43] <servertood> ok sry
[21:44] <zyga> bzr does not care about who is doing changes
[21:44] <zyga> neither does any other system
[21:44] <zyga> you just setup system users or other filesystel-level protection
[21:44] <servertood> ok thats cool
[21:44] <zyga> so code to /srv/bzr/something/trunk can be (for example) only changed by that user or that group
[21:44] <mkanat> zyga, servertood: There is no official policy that binaries are "not important enough to be optimized for". In fact, there are people doing work to make bzr handle them better.
[21:44] <awilkins> You exert security control on who is allowed to merge changes upstream into release branches
[21:45] <servertood> sure
[21:45] <servertood> at the filesystem level ok
[21:45] <zyga> mkanat: I remember reading about one of the bzr devs commenting that binaries are not a priority so they are not treated differently than text - that's what I meant - if that's changed then I can only be more happy
[21:46] <awilkins> I think there are "bigfile" plugins for git and mercurial that are in some kind of usable state now
[21:46] <mkanat> zyga: It hasn't changed, but there is work underway to change it.
[21:46] <zyga> mkanat: cool
[21:46] <zyga> mkanat: can I help in any way?
[21:46] <awilkins> In my experience, files up to around 100MB are alright on modern machines
[21:46] <servertood> is there a bug open on it?
[21:46] <mkanat> zyga: Yeah, very possibly.
[21:46] <servertood> how many files up to 100MB?
[21:46] <servertood> say I have a dir of 200 MB worth of binaries like 10-20MB each
[21:46] <awilkins> I have several branches that consist of around 1.5GB of text data resources in text files about 60MB or more apiece
[21:47] <awilkins> And they check out OK on a machine with 2GB of RAM
[21:47] <servertood> really
[21:47] <zyga> servertood: you might hit the memory wall when bzr repacks the data
[21:47] <mkanat> zyga: I think jbowtie is doing the work on it, you should ask him.
[21:47] <awilkins> It can get a little ... swappy at that point :-)
[21:47] <servertood> lol
[21:47] <zyga> mkanat: thanks, I'll ping him
[21:48] <zyga> AFAIR repacking crosses file boundary and just sucks the tree in
[21:48] <awilkins> On my home desktop with 6GB of RAM and a 64-bit OS it's just fine though :-0)
[21:48] <speakman> anyone running Buildbot on bzr repo?
[21:48] <zyga> then your ISO will kill a 6GB machine
[21:48] <servertood> so this slow down
[21:48] <awilkins> We have been using Maven for storing large binary build outputs in
[21:49] <awilkins> But it's not entirely well suited to that either - more to library sized JAR files
[21:49] <servertood> sure
[21:49] <servertood> Im switching to maven
[21:49] <mkanat> servertood: It's more about the size of individual files than the size of your whole repo, with bzr.
[21:49] <servertood> really
[21:49] <mkanat> servertood: It won't deal well with a 1GB binary, but it should be fine with a 100MB binary.
[21:49] <awilkins> Enough people (p4 using game developers mostly) raise the "big binaries" issue recently to make it worth looking at
[21:50] <awilkins> If you are using Maven, top tip - use Nexus, not Archiva.
[21:50] <servertood> Im sure I dont have any files near 100MB
[21:50] <awilkins> Nexus totally blows Archiva out of the water in terms of upload performance
[21:50] <zyga> mkanat: it's been my experience that repacking _will_ kill your system at that poing (having any number of 100MB files)
[21:50] <servertood> Im using Maven to build java
[21:51] <Tak> yeah, we have big binary issues as well
[21:51] <awilkins> What I'd like to see is a system that stores big non-mergy binaries on their SHA1 sum in a glorified FTP server
[21:52] <Tak> YES
[21:52] <awilkins> And you just refer to each binary you want in your build system by it's SHA1
[21:52] <zyga> awilkins: that's not going to help you without pure shallow checkouts - assuming you still want dvcs
[21:52] <awilkins> I mean, in the case of game dev, who goes with their old assets anyway?
[21:52] <zyga> awilkins: I've been considering transitioning part of a very large p4 repo to anything else
[21:52] <awilkins> You might want to build old CODE to find a bug, but who wants to go back to old ART?
[21:52] <zyga> awilkins: and that's what it ultilmately boils down to, you cannot even copy the whole history to a single computer
[21:53] <lousygarua> is there a way to download only a certain revision from a repository so i won't have to download the whole history of the project?
[21:53] <zyga> lousygarua: in bzr? yes
[21:53] <awilkins> lousygarua, Yes, you can do a shallow checkout
[21:53] <zyga> lousygarua: you can setup lighweight checkout for example
[21:53] <awilkins> ^^ or what he said
[21:53] <zyga> awilkins: lightweigh is the same as shallow?
[21:53] <zyga> I remember talks about doing history horizon but I don't know if that was implemented
[21:54] <lousygarua> zyga: hmm, ok i will read about shallow/lightweight/whatever thanks
[21:54] <zyga> so that you could see (and have) some history locally
[21:54] <zyga> lousygarua: bzr reconfigure --help
[21:54] <awilkins> Lightweight is like SVN - depends on the server
[21:54] <zyga> awilkins: yes
[21:54] <awilkins> TBH never really used shallow checkouts but I think they get used on Launchpad to save storage for user forks
[21:54] <zyga> awilkins: and if bzr could just store binaries without processing (and holding them in memory) then bzr would be a perfect VCS for anyone apart from git hardcore users and people loving to rebase (I still do, darn)
[21:55] <lousygarua> will a lightweight checkout store further revisions locally so it won't have to be SVN entirely?
[21:55] <awilkins> lousygarua, No
[21:55] <zyga> awilkins: lp uses stacked branches right? so you get same kind of data saving
[21:55] <awilkins> stacked ... I think that's sort of what I may have meant
[21:56] <zyga> awilkins: stacked is where you just have your history and go to the partent for the rest
[21:56] <zyga> awilkins: lightweight is just a working directory accessing a remote branch
[21:56] <zyga> awilkins: also lanchpad has repositories around projects to make identical revisions collapse
[21:56] <awilkins> As I say... I don't use them myself ; I mostly use bzr-svn and straight bzr with a hidden folder shared repo and lightwieght checkouts of the branches therein
[21:57] <speakman> How can I debug a plugin? How do I even check if it's run?
[21:57] <zyga> but I'm not sure if that's exactly how lp.net handles code, ask in #launchpad for that
[21:57] <zyga> speakman: print something in the module, worked for me :-)
[21:57] <zyga> speakman: also bzr plugins -v will tell you it's there
[21:58] <zyga> speakman: I had issues with putting something that cannot be imported by python (wrong name) as the plugin toplevel directory name
[21:58] <speakman> zyga: ever run buildbot with bzr?
[21:59] <zyga> speakman: no, sorry
[22:00] <zyga> servertood: if you need some non lp.net hosting then you can either use track or redmine, both are quite excellent
[22:00] <zyga> sorry trac
[22:00] <Tak> if bzr had good binary handling, it would have been the hands-down winner for new vcs at my workplace
[22:01] <zyga> Tak: I had the same problem
[22:04] <speakman> zyga: seems like there's something wrong with locations.conf
[22:05] <zyga> speakman: ?
[22:06] <maxb> < zyga> awilkins: also lanchpad has repositories around projects to make identical revisions collapse
[22:06] <maxb> No, it doesn't
[22:07] <zyga> maxb: oh, how does it work then?
[22:07] <maxb> stacked branches
[22:08] <zyga> maxb: so branches are always stacked on their parents?
[22:08] <speakman> zyga: my mistake - was prefixing config settings with a tab in locations.conf
[22:12] <speakman> okay, this plugin installs on post_commit post_push and post_change_branch_tip
[22:13] <speakman> I want it to trigger on a smartserver when new commits are pushed
[22:13] <zyga> speakman: I'm not sure how that part works or how to debug that, I cannot help you much, sorry
[22:14] <speakman> ok
[22:14] <speakman> anyone else..?
[22:14] <speakman> (the bzr --serve --inet is run as user 'bzr' and I'm editing in ~bzr/.bazaar/* )
[22:16] <speakman> the option "recurse" seems to not be working for all plugins
[22:20] <speakman> no, it's all working correctly
[22:20] <speakman> now, which hooks are trigger by bzr --serve ?
[22:21] <speakman> http://doc.bazaar.canonical.com/latest/en/user-reference/hooks-help.html#post-change-branch-tip
[22:21] <speakman> "Called in bzr client and server after a change to the tip of a branch is made. post_change_branch_tip is called with a bzrlib.branch.ChangeBranchTipParams. Note that push, pull, commit, uncommit will all trigger this hook."
[22:21] <speakman> doesn't seem so...
[22:38] <speakman> BzrBranch7(filtered-172359628:///timespot/facelift-pure/)
[22:38] <speakman> how is this suppose to match in locations.conf ?
[22:49] <speakman> Seems like the smart server need a local path resolution fix
[22:50] <speakman> BzrBranch7(filtered-172359628:///timespot/facelift-pure/)   --->    BzrBranch7(file:///srv/bzr/repo/timespot/facelift-pure/)
[23:39] <servertood> hi
[23:39] <servertood> I just setup a repo on my osx machine with notrees
[23:40] <servertood> I want to create a working copy and add files to it do I have to access the repo with sftp even tho its local
[23:42] <servertood> oh no I htink it worked at first when I referenced it on the filesystem it looked like it screwed up


[00:25] <pleia2> oh hey, you guys are experts, a fellow in an ubuntu channel is trying to argue with me that "holy crap" is not bad and wants a list of bad words/phrases he shouldn't say in ubuntu channels
[00:25] <pleia2> obviously such a list is nonsense, but I am not sure how to handle this
[00:25] <pleia2> ("family friendly" didn't work, apparently he says this in front of kids too)
[00:25] <pleia2> this user has a history of bad language, has been warned repeatedly
[00:30] <Seeker`> "whatever the channel operator deems to be bad language"
[00:30] <Seeker`> I believe that there is something in
[00:30] <Seeker`> !guidelines
[00:30] <Seeker`> that states that ops have the final say on what is/isn't appropriate
[00:31] <Seeker`> pleia2: can I ask which channel?
[00:31] <elky> pleia2, let me guess, this is mteck?
[00:32] <elky> he's come crying to me in PM
[00:32] <pleia2> elky: MTecknology in #ubuntu-us
[00:32] <pleia2> Seeker`: thank you
[00:33] <pleia2> I haven't banned him (just removed), and told him he could return if he can sort out how to conduct himself
[00:34] <pleia2> but he's having a difficult time understanding that his frequent expletives are not welcome
[00:35] <elky> pleia2, how do you expect people to express exlaimation?
[00:35] <elky> 'by golly'?
[00:37] <pleia2> I'm really not sure :)
[00:37] <pleia2> and it doesn't bug me if it's infrequent (even if I might joke about a swear jar) but this has been pretty constant, daily "WTF?!" "holy crap!" etc
[00:38] <elky> the former i can sympathise with, but the latter i just cant... there's a game called 'craps' for crying out loud.
[00:39] <pleia2> it very well might be a regional thing
[00:39] <elky> and you are in a different region of the US to him?
[00:39] <pleia2> I am not sure I would have said anything if I hadn't just spoken to him an hour before about "WTF?!"
[00:40] <pleia2> yeah, he's quite a bit further west
[00:41] <Seeker`> elky: I think the existance of a game called "craps" is probably coincidental
[00:41] <elky> Seeker`, here 'craps' means 'the runs'
[00:42] <elky> so unless people are not allowed to say various other non-s words for defecation in the channel...
[00:42] <elky> pleia2, he's trying to claim it's not daily
[00:42] <pleia2> a few times a week
[02:33]  * Pici personally doesn't have a problem with the word 'crap'
[02:37] <elky> Pici, it's not so much the word as the constant use despite being asked not to
[02:44] <Pici> elky: yes, well that would be annoying
[03:22] <tonyyarusso> elky: btw, it has always been my understanding that the game name is unrelated.  anywho..back to life
[03:23] <Flannel> It comes from the french word for toad.
[03:24] <elky> tonyyarusso, my point was the word itself is ambiguous
[03:26] <tonyyarusso> elky: Fine by me - I'm not really trying to give input on that aspect.
[03:26] <tonyyarusso> Flannel: Really?  Interesting.   I was never rude to anyone, and still am not. I am NOT supporting widnows
[04:33] <ajavid> I'm not telling anyone how to edit boot.ini
[04:33] <Flannel> No, but you need to tell them *what* to edit from it
[04:33] <ajavid> regardless of what you may think constitutes rudeness
[04:34] <ajavid> Flannel, if you go to boot.ini and you see wubi, would you remove windows?
[04:34] <Flannel> As I just said: I don't care about how you feel about windows.  Nor do the people you're helping.  If someone tried Ubuntu and chose not to keep it, for *whatever* reason, giving them the finger as they're leaving is *not* going to get them to come back.
[04:34] <ajavid> I highly doubt it.
[04:34] <ajavid> Flannel, you're a victim of your own perception
[04:34] <ajavid> there is nothing I can do about that
[04:35] <Flannel> ajavid: If you are dismissive to users like that again, you will be removed.
[04:35] <ajavid> I am/was not dismissive
[04:35] <Flannel> It reflects poorly on you, and our community.
[04:35] <ajavid> Flannel, please, look at at the past hours log
[04:35] <ajavid> Flannel, see how many people I'ved helped and how many thanks I've reciieved and how nice and courteous I've been
[04:35] <Flannel> Helping N people doesn't give you the right to be rude to 1.
[04:35] <ajavid> Flannel, kindly treat me with a bit more respect
[04:35] <Flannel> Sorry, but it doesn't work that way.
[04:36] <ajavid> Flannel, you're right, but I Was not being rude
[04:36] <ajavid> I agree, no reason/right to be rude to anyone, that is, IF i was eing rude
[04:36] <ajavid> I Wasn't (typo control-b)
[04:38] <ajavid> if they ask how to remove wubi from boot menu, and I say, edit boot.ini, its in there, and go to ##windows to find out how to edit boot.ini, there is ABSOLUTELY nothing wrong with that
[04:38] <ajavid> which is exactly what happened
[04:38] <Flannel> "Edit this file!!"   How much better would your support have been?
[04:39] <Flannel> many times moreso.
[04:39] <ajavid> it would have been better, I agree
[04:39] <ajavid> but it was fine as it was too
[04:40] <ajavid> you're point is valid, it could have been better, but it was fine
[04:40] <ajavid> there was nothing WRONG with it
[04:40] <Flannel> "edit this file" is not nearly as helpful as it ought to be.
[04:40] <ajavid> I dont' think we're going to see eye to eye on this
[04:40] <ajavid> if you feel the need to remove me, that is your perogative, feel free to do so
[04:40] <elky> Flannel, did he at least check the competence of the person first?
[04:41] <Flannel> elky: No, he just said "edit boot.ini" when someone asked about it
[04:41] <elky> eep
[04:41] <Flannel> and then said ask in ##windows
[04:41] <ajavid> no
[04:41] <ajavid> paste actual log
[04:41] <Flannel> Alright.
[04:41] <ajavid> I lost mine, I dunno exactly whatI said
[04:41] <ajavid> sorry
[04:42] <Flannel> http://paste.ubuntu.com/196778/
[04:42] <nalioth> i'm personally not seeing an issue.
[04:43] <ajavid> nalioth, neither am I, however Flannel is giving me a hard time about it,and I didn't feel that is right
[04:43] <ajavid> if you can convince me that I did make a mistake and I was rude, I will apologize to whoever
[04:43] <elky> nalioth, i am. you dont tell people to edit windows .ini files
[04:44] <Flannel> nalioth: ##windows shouldn't have to know how to deal with grub
[04:44] <ajavid> Flannel, you miss the point completely
[04:44] <Flannel> ajavid: Yes, you despise windows, I know.
[04:44] <ajavid> I sent him to ##windows to figure out HOW to edit the boot.ini file
[04:44] <Flannel> ajavid: Just *skip* the question next time
[04:44] <ajavid> as it is not a trivial as editing
[04:44] <ajavid> you  have to set soe system/hidden attributes off
[04:44] <Flannel> ajavid: And ##windows knows what to remove?
[04:45] <ajavid> I refus to support this in ubuntu
[04:45] <ajavid> i sent him to windows to find out HOW to edit boot.ini
[04:45] <Flannel> ajavid: then *dont* but don't half-ass support either.
[04:45] <elky> ajavid, then ignore it next time
[04:45] <ajavid> and I told him, the entry is in boot.ini, edit this file
[04:45] <ajavid> 10:40 <+           Flannel> ajavid: Yes, you despise windows, I know.
[04:45] <ajavid> desctruvtive, uncalled for
[04:45] <ajavid> 10:40 <+           Flannel> ajavid: Just *skip* the question next time
[04:45] <ajavid> not always
[04:45] <ajavid> I still do not think I did anything wrong
[04:46] <ajavid> 10:41 <+           Flannel> ajavid: then *dont* but don't half-ass support either.
[04:46] <elky> ajavid, you are not helping your situation at all.
[04:46] <ajavid> I have never provided half ass support
[04:46] <ajavid> I'm standing up for myself.
[04:46] <elky> ajavid, yes you have. that pastebin contains it.
[04:46] <ajavid> elky, and I agreed with hima bout it being better, however it was fine as it was
[04:46] <elky> ajavid, no it was not fine.
[04:46] <ajavid> edit boot.ini, go to windows to learn how to edit boot.ini
[04:47] <ajavid> if you edit boot ini and you you see wubi, be sure to remvoe something else, I suppose telling him exactly
[04:47] <ajavid> 20:24 < sirninja> How do I remove ubuntu as a boot option after I uninstall wubi?
[04:48] <ajavid> he did not ask how to remove it form boot.ini
[04:48] <ajavid> as my understanding goes
[04:48] <ajavid> telling him to look in boot.ini will do it for him
[04:48] <ajavid> edit boot.ini, and rmove the wubi line
[04:48] <ajavid> Flannel
[04:48] <ajavid> ss arguemtn is that I didn't mention the 2nd part
[04:48] <elky> ajavid, you dont just tell people to edit ini files.
[04:48] <ajavid> which I didn't think was neccesery
[04:48] <ajavid> as editing boo.ini implies that the wubi entry is there
[04:48] <ajavid> like I said
[04:49] <ajavid> I wasn't trying to treat him like an idot
[04:49] <elky> ajavid, you're not helping yourself at all.
[04:49] <ajavid> if you still do not see my logic or reasoning then there is littl I can do
[04:49] <ajavid> elky, and what exactly does that mean?
[04:50] <ajavid> I stand up for myself and somehow that merits a 'threat' that I'm not helping myself?
[04:50] <ajavid> what exactly is your reason for telling me this? that I'll be bannd?
[04:50] <elky> ajavid, it means that you're going around in circles, which is not helpful for yourself.
[04:51] <ajavid> apparantly, with all due respect, Flannel is a bit unreasonable right now
[04:51] <ajavid> which is why I thought that repeating myself a few times might help it sink in. I'll stop.
[04:51] <ajavid> Anyway, I do not believe I did anythign wrong.
[04:51] <elky> ajavid, and we believe you did. as it's our channel, it's our judgement that counts.
[04:52] <Flannel> ajavid: Just don't do it again, and there won't be any issues.  We already went over the cost/benefit analysis of proper support
[04:52] <ajavid> I've provied support almost everyday in #debian for the past 8-9 years. Never once have I been treated like this for trying to help someone.
[04:52] <ajavid> This is just plain wrong.
[04:52] <elky> ajavid, ubuntu is not debian.
[04:53] <ajavid> apparantly, in your self rightousness you fail to respect people in some manner
[04:53] <elky> debian lets anything fly. we dont.
[04:53] <ajavid> you shoudl be ashamed of yourself for imposing BS on people like this
[04:54] <ajavid> wow. great way to deal with issues.
[04:55] <ajavid> Really, with all due respect. Some of you maybe reasonable enough, but some are not.  I'm out.
[04:55] <elky> riddance.
[04:55] <elky> he's not even in either debian main channel that i can see
[04:56] <elky> ah, there he is
[04:59] <elky> im yet to see any support in there from him, but i have found him talking about wanting to put his *cough* in a computer...
[05:00] <elky> and how the army is what you do when you want to kill people legally...
[05:00] <elky> this is just getting worse and worse
[07:42] <Myrtti> nalioth: I think ubot3 is broken again
[08:21] <Myrtti> ubot3: ping
[08:21] <ubot3> ping yourself ;-) really the diodes all down my left side are sore
[08:22] <Myrtti> ubot3: info pidgin
[09:33] <jussio1> grumle.
[09:33] <jussio1> when did I part last?
[09:33] <Myrtti> [10:07] ~~~jussi01 [n=jussi01@ubuntu/member/jussi01] has quit [Read error: 113 (No route to host)]
[09:34] <jussio1> ok, so only 1 hour or so ago
[09:34] <jussio1> hrm
[09:34] <Myrtti> 90mins
[09:34]  * jussio1 goes to call people to sort out stuff
[12:36] <Myrtti> ubot3: info xournal
[13:01] <nalioth> is ubottu working?
[13:01] <jussi01> !test
[13:01] <jussi01> nalioth: looks that way...
[13:02] <nalioth> ubottu: info konqueror
[13:02] <nalioth> !info konqueror
[13:02] <jussi01> !info waon
[13:02] <jussi01> hehe
[13:02] <jussi01> ubot3: !info waon
[13:04] <nalioth> well, ubot3 usually only breaks when the db goes south
[13:05] <nalioth> so i'm pretty clueless
[13:05] <nalioth> ubot3: info konqueror
[13:05] <ubot3> konqueror: KDE 4's advanced file manager, web browser and document viewer. In component main, is optional.  Having a cronjob to re-start irssi was "interesting"
[13:15] <Daviey> (for clarification, it wasn't a serious suggestion..)
[13:24] <jussi01> Daviey: we have the bots on a server that we can do pretty much anything to...
[13:30] <Daviey> jussi01: sure, it was a non-serious suggestion pointing to automating the process.
[13:30] <Daviey> Wish i hadn't of said anything now :)
[13:32]  * nalioth throws Daviey out the window
[13:32]  * nalioth throws a custard afterward
[13:33]  * jussi01 bites Daviey
[13:33] <Daviey> nalioth: your custard is lumpy :(
[13:33]  * Myrtti throws a bucket of marmite
[13:34] <popey> \o/
[13:34] <elky> jussi01, well, we have the bots on numerous vpses actually
[13:34] <elky> marmite? om nom nom.
[13:34] <jussi01> hello popey
[13:34] <elky> remind me to get some cheese tomorrow so i can have marmite and cheese on crackers plzkthx
[13:35] <nalioth> elky: you prefer marmite over vegemite? or 'our mate' ?
[13:35] <elky> nalioth, indeed i do.
[13:36] <nalioth> i don't like vegemite, as it's got a higher melting point than UK marmite
[13:36] <elky> marmite is the original and definately the better
[13:39] <jussi01> vegemite is better. and elky, HOW UNAUSTRALIAN ARE YOU!!!
[13:39] <Myrtti> I want to kill authors of epiphany :-(
[13:42] <popey> vegemite is marmite for wusses
[13:42] <popey> :)
[13:42] <jussi01> popey: bite me!
[13:42] <popey> vegemite has a smoother less harsh flavour imo
[13:42]  * popey nibbles jussi01
[13:43] <elky> popey, and it's got a tackier aftertaste
[13:43] <popey> yus
[13:44] <elky> jussi01, dont make me send you a jar of promite.
[13:44] <elky> now that stuff is foul
[13:45] <jussi01> elky: yeah, well thats true
[13:47] <nalioth> i like marmite, as i can drop a spoonful in my cooking and it melts nicely - vegemite requires a higher temp to melt
[15:05] <Myrtti> nnngnghghghghghghghghghghghghghghghghghhghghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh I hate people who give lmgtfy links
[15:05] <Pici> +1
[15:06] <Myrtti> "but next time he'll know how to google it"
[15:06] <Pici> In a support channel?
[15:06] <Myrtti> yup
[15:06] <Myrtti> -fi
[15:09] <Myrtti> why do I bother? I only get bad tempered in ubuntu channels these days
[15:10] <Pici> Tell them that the answer is unacceptable
[15:13] <Myrtti> Pici: he's already protested my complain with "but next time he'll know how to google it"
[15:13] <Myrtti> I'm stumped
[15:13] <nalioth> beats the alternative google URL
[15:13] <Myrtti> ooh, now he gave the link to the first page result
[15:14] <Pici> I feel that its not good behavior for a support channel.
[15:14]  * jussio1 wonders where this is...
[15:14] <Myrtti> jussio1: the JFGI thing?
[15:14] <Myrtti> witnessed in #ubuntu-fi
[15:15] <jussio1> Myrtti: yeah, Im not in many chans if you didnt notice
[15:15] <jussio1> ooh, skype does /me :D
[15:15] <Myrtti> sure, it does replaces as well
[15:16] <Myrtti> atleast on the windows client
[15:16] <jussio1> :D
[15:16] <Myrtti> misstype something and correct it on the following line with s/client/application/
[15:21] <genii-around> Is jussi's site up and down today ? I seem to be getting a lot of disconncts
[15:21] <jussio1> genii-around: yes
[15:21] <nalioth> jussio1: I told you that random genii-disconnect script was not random enough  :P
[15:21] <jussio1> genii-around: power outages today
[15:22] <genii-around> nalioth: Bah! ;)
[15:22] <jussio1> nalioth: rofl
[15:22] <genii-around> jussio1: OK. I'll stay on Konv then for a while
[15:22] <jussio1> genii-around: Ill let you know when it comes back up.
[15:22] <genii-around> Thanks :)
[17:05] <jussio1> !ircc
[17:06] <jussio1> ooh, someone updated it already.  :)
[17:06] <Pici> jussio1: yes, the person from the factoid factory
[17:07] <jussio1> Pici: nice :d
[17:07] <Pici> I didn't touch !appeal, we should touch the wiki page it references instead.
[17:07] <jussio1> yeah
[17:07] <jussio1> someone should do that...
[17:13]  * Myrtti assigns jussi01 on the job
[17:14] <Myrtti> first rule of the internets: "do not say 'someone should do it'"
[20:33]  * Pici thinks that <also> is hackish
[20:41] <popey> vcghjkgfdcx == Samuel_AFK
[20:42] <popey> who was banned from -uk and has changed nick to evade that ban
[20:42] <popey> and changed username
[22:46] <nalioth> hmmm
[22:48]  * genii-around sips
[22:56] <genii-around> I think bazhang's connection is broken
[22:57] <nalioth> genii-around: how about the sky?  blue, dya think?
[22:59]  * genii-around looks outside to make sure
[22:59] <genii-around> Sorta grey today :)


[16:25] <OvenWerks> Eickmeyer: re: controls issue 84, did you change the desktop file name? Maybe fix the makefile to match... and I guess release again? I have already fixed the studio.service thing (before I saw this issue)  :P
[16:28] <RikMills> https://bugs.launchpad.net/ubuntu/+source/plasma-desktop/+bug/1992971
[16:28] -ubottu:#ubuntustudio-devel- Launchpad bug 1992971 in xdg-desktop-portal-kde (Ubuntu Jammy) "[SRU] tracking bug for plasma LTS 5.24.7 bugfix updates for Jammy" [Undecided, In Progress]
[16:28] <RikMills> uploaded, but in unapproved
[16:58] <Eickmeyer> OvenWerks: I haven't changed the desktop file in several releases.
[16:58] <Eickmeyer> RikMills: Awesome.
[16:59] <Eickmeyer> OvenWerks: The desktop file was changed to fix a problem with it being misrecognized as Android Studio of all things.
[17:00] <Eickmeyer> That's ancient history.
[18:37] <OvenWerks> yeah but the makefile wasn't updated to match
[18:37] <OvenWerks> Eickmeyer: ^
[18:38] <OvenWerks> What is the exact text for the desktop file these days?
[20:31] <Eickmeyer> OvenWerks: com.github.ovenwerks.studio-controls.desktop
[21:52] <OvenWerks> Eickmeyer: fixed.
[22:18] <Eickmeyer> OvenWerks: Saw the release.


[08:23] <alkisg> Hi, I'm trying to create a recipe for 2 git branches but it fails, could I have some help please? https://code.launchpad.net/~alkisg/+recipe/ltsp+debian-packaging
[08:24] <alkisg> nest-part packaging lp:~alkisg/+git/ltsp-debian debian debian disable-upstreamed-patches => this pulls the folder "debian" from branch "disable-upstreamed-patches" and puts it into a folder named "debian", right?
[08:30]  * alkisg tries removing the branch name completely, while setting it as the default in the branch options...
[08:31] <cjwatson> Looks like it *should* work.  Maybe worth trying to run git-build-recipe locally.
[08:31] <alkisg> Thank you cjwatson, will try that locally
[08:34] <alkisg> cjwatson: it worked on launchpad when I removed the branch name. The correct syntax is to put the branch name in the end, and NOT like this, right? "nest-part packaging lp:~alkisg/+git/ltsp-debian disable-upstreamed-patches debian debian"
[08:36] <alkisg> Ah, in the repository options, I also changed "Default branch", from "refs/heads/master", which was the default there but didn't exist at all, to "refs/heads/disable-upstreamed-patches"
[08:36] <alkisg> One of those 2 changes made it work...
[08:39] <cjwatson> oh yeah, "nest-part packaging lp:~alkisg/+git/ltsp-debian disable-upstreamed-patches debian debian" looks more correct
[08:39] <alkisg> cjwatson: let me find the docs link that had it wrong there...
[08:39] <cjwatson> wait, no, I do see the contradictory docs
[08:39] <cjwatson> sorry, it's been a while
[08:40] <cjwatson> yeah, branch comes last, I'm fairly sure the docs are correct
[08:40] <alkisg> https://help.launchpad.net/Packaging/SourceBuilds/Recipes#nest-part => nest-part packaging lp:~some-person/some-project debian debian master-with-packaging
[08:40] <alkisg> Ah ok
[08:40] <cjwatson> a non-existing default branch would indeed break things, as the code is at the moment
[08:41] <cjwatson> so I think your change to the default branch was what fixed it
[08:41] <alkisg> OK, I'll try to put the branch name back to the recipe, and rebuild, while having the default branch correct in the options
[08:41] <alkisg> This should verify what we assume
[08:41] <cjwatson> it doesn't have to be refs/heads/disable-upstream-patches necessarily, but it does have to exist
[08:49] <alkisg> I pushed that repository with git push, and it auto-selected a default which didn't exist...
[08:51] <cjwatson> Odd
[08:51] <alkisg> cjwatson: no, it failed to build again
[08:52] <alkisg> I only put back the "disable-upstream-patches" back in the recipe now, no other change
[08:52] <alkisg> To sum up, "nest-part packaging lp:~alkisg/+git/ltsp-debian debian debian" builds properly, and "nest-part packaging lp:~alkisg/+git/ltsp-debian debian debian disable-upstream-patches" fails
[08:53] <cjwatson> that's because you've misspelled your branch
[08:53] <alkisg> omg
[08:54] <cjwatson> disable-upstreamed-patches
[08:54] <alkisg> Very sorry, I don't know where that bad copy/paste came from
[08:58] <alkisg> Build succeeded
[08:59] <alkisg> So the only problem was, when I ran `git push` to initially create the repository, it defaulted to 'refs/heads/master', while my repository had no branch called 'master'. And going to the web interface and setting an existing one there, fixed the issue.
[08:59] <alkisg> Thank you very much
[09:07] <cjwatson> This is https://bugs.launchpad.net/git-build-recipe/+bug/1683913 BTW
[15:59] <nacc> cjwatson: if a user has used any tooling to specify their launchpad user name, is that stored anywhere currently in ~/ ? Just trying to determine if there's anything I can try to depend on to derive the LP user of the current user other than asking (or them setting it separately in their git-config)
[16:00] <cjwatson> if they've used launchpadlib then there's lp.me
[16:01] <nacc> cjwatson: which file does that get stored in? I only see cache directories under .launchpadlib
[16:01] <cjwatson> and I suppose you could try 'bzr lp-login' if it's only on a setup path
[16:01] <nacc> cjwatson: oh true, there is that
[16:01] <nacc> cjwatson: although i'd rather the git tooling didn't need to rely on bzr :)
[16:02] <nacc> on some level, i guess we're doing what `bzr lp-loging` does for the git side
[16:02] <nacc> rbasak: --^
[16:02] <nacc> *login not loging
[16:02] <cjwatson> nacc: in the launchpadlib cache it's not stored locally directly; python-keyring has credentials, and those correspond to LP database rows which identify what user they're for
[16:03] <nacc> cjwatson: ah
[16:03] <cjwatson> sure, I understand you don't want to rely on bzr, I was just thinking of it as one of a collection of heuristics you could run to try to guess
[16:03] <nacc> cjwatson: yep, absolutely
[16:03] <cjwatson> s/cache/case/ above
[16:03] <nacc> cjwatson: and in the snap it doesn't matter too much :)
[18:38] <alkisg> What's the suggested method to maintain translations from launchpad git branches? Rosetta can't yet import nor export to git, right?
[18:39] <alkisg> Should we set up a .git=>.bzr code import, and then tell rosetta to use the .bzr mirror for importing the translations, and a third bzr branch to export them?


[06:37] <BobJonkman> Sneak peek at the first Canadian Raring Ringtail Ubuntu Release Party: http://loco.ubuntu.com/events/ubuntu-ca/2325-raring-ringtail-release-party/
[06:37] <BobJonkman> Here's hoping dscassel gets the OK from the Kwartzlab board to use their space. Otherwise we'll have to set up in the vacant lot across the street.


[16:47] <apollo13> hi guys. my firefox 15.0.1+build1-0ubuntu<IP_ADDRESS> constantly crashes here on startup, wiping ~/.mozilla doesn't help -- backtrace is http://dpaste.org/AmyGX/ any hints?
[16:50] <micahg> do you have a mozilla crashid?
[16:50] <apollo13> how do I get one :)
[16:50] <micahg> when it crashes, submit the bug to mozilla?
[16:51] <apollo13> well it tells me "report submitted successfully"
[16:51] <micahg> look in ~/.mozilla/firefox/Crash Reports/ then
[16:51] <apollo13> ah
[16:52] <apollo13><PHONE_NUMBER> -- from LastCrash there
[16:52] <micahg> wiping ~/.mozilla is usually not a good idea in general (just move it out of the way if you want to test or use -P for the moment)
[16:52] <apollo13> that's what I did ;)
[16:53] <micahg> apollo13: there should be a crashid in the submited directory
[16:53] <apollo13> Crash ID: bp-73ea44fb-bf3e-4ced-8432-1672b2120912
[16:53] <apollo13> sry, wrong file *gg*
[16:57] <apollo13> https://crash-stats.mozilla.com/report/index/73ea44fb-bf3e-4ced-8432-1672b2120912 oh it's there :)
[16:58] <micahg> certainly not a topcrashes
[16:58] <micahg> *topcrasher
[16:59] <apollo13> well if it were my google foo wouldn't have failed me, so what can I do to help
[16:59] <micahg> does firefox -safe-mode help?
[16:59] <apollo13> nope
[17:10] <apollo13> micahg: normal firefox from mozilla.com doesn't crash ;)
[17:11] <micahg> hrm
[17:19] <apollo13> micahg: I am waiting for ideas :) I can fetch the source and build if you tell me what to change
[17:20] <micahg> if I only I knew what to change...
[17:22] <micahg> apollo13: mozilla 693933 seems to be the only thing in bmo related, but if the upstream build doesn't crash, maybe try our version 16 in ppa:mozillateam/firefox-next and see if that helps
[17:22] <ubot2> Mozilla bug 693933 in DOM "nsFrameSelection::GetSelection() should return nsTypedSelection" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=693933
[17:23] <apollo13> micahg: yeah I found that report too
[17:23] <micahg> the think is on lucid, we don't have anything interacting with the browser that should crash
[17:23] <apollo13> btw in the office I am on x86_64 and it doesn't crash
[17:23] <apollo13> let me try the ppa
[17:23] <apollo13> did I say that I hate ppas?
[17:23] <micahg> orly?  this is i386 only?
[17:23] <apollo13> looks like it
[17:24] <apollo13> let me compare version to be sure
[17:25] <apollo13> jupp seems so, let me find another 32 bit machine
[17:26] <apollo13> hmm not as easy as I thought, no more 32 bit machines
[17:28] <micahg> well, try the beta PPA, if that works, great
[17:28] <apollo13> yeah already downloading
[17:28] <micahg> it's only 4 weeks away from release and the crash doesn't seem to be impacting a lot of users
[17:28] <apollo13> no not great, that means I have to add it to puppet ^^
[17:28] <apollo13> haha
[17:29] <micahg> apollo13: did 15 have the same crash?
[17:29] <apollo13> 15.0?
[17:29] <apollo13> no idea
[17:29] <apollo13> I can try if you provide me a deb
[17:29] <micahg> apollo13: can you try that first?
[17:30]  * apollo13 has no idea where to find old ubuntu packages
[17:30] <micahg> apollo13: https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+build/3742855
[17:30] <apollo13> wait
[17:30] <apollo13> fuck
[17:31] <apollo13> opening that link from xchat worked in firefox
[17:31] <apollo13> just starting firefox does not work
[17:31] <micahg> lovely
[17:31] <apollo13> although, nevermind, that's the normal one from mozilla
[17:31] <apollo13> fetching 15.0 now
[17:31] <micahg> heh
[17:34] <apollo13> 15.0 works, so much for bug fixes only in minor releases :þ
[17:35] <micahg> ok, well, this is more serious then
[17:35] <micahg> the mozilla.org build is 15.0.1 as well?
[17:35] <micahg> * a little more serious
[17:35] <apollo13> is/was yes
[17:38] <apollo13> 1.16 works
[17:39] <apollo13> where is the fun in that *sigh*
[17:39] <micahg> 1.16?
[17:40] <apollo13> lol, not used to big version numbers, 16
[17:41] <micahg> apollo13: did you try reinstalling 15.0.1?
[17:41] <apollo13> this is not windows, but yes I did :(
[17:41] <apollo13> debsums reports a checksum error in omni.ja
[17:41] <apollo13> no idea if that's related (for 15.0.1 that was)
[17:42] <apollo13> let me downgrade and replace omni.ja with a workign version
[17:44] <apollo13> haha, take that
[17:45] <apollo13> I hereby inform you that your 32 bit package has a borked file in it ;)
[17:45] <apollo13> stupid /me though omni.ja wouldn#t cause issues :(
[17:46] <micahg> hrm worked for me, /me fires up vm
[17:50] <apollo13> well upload omni.ja somewhere and I test with your file and compare against the deb
[17:50] <micahg> wfm
[17:51] <apollo13> tell me your md5sum
[17:51] <micahg><PHONE_NUMBER>3de4f25214a90bb6cb8b60  /usr/lib/firefox/omni.ja
[17:52] <apollo13> ef294612adcf421465eaaf90fa741ff7  /usr/lib/firefox/omni.ja
[17:52] <apollo13> rofl
[17:52] <apollo13> ah I see my error now I guess
[17:53] <apollo13> I should have done an apt-get clean before reinstalling
[17:53] <apollo13> thx, that was it
[17:53] <apollo13> I wonder though, why does apt-get finish if data.tar.gz inside the .deb has a crc error?
[17:54] <apollo13> sry for wasting your time, but I never thought that the download was corrupt, I assumed dpkg would figure that out :/
[18:06] <micahg> it should, and dpkg has gotten better in the last few years


[00:18] <guiverc> Bashing-om, indaba summary   "Indaba means, and how they relate to Ubuntu"...  I'm having issue with tense; 'how this relates to Ubuntu'??  or not an issue?
[00:24] <Bashing-om> guiverc: Relooking ^ :D
[00:25]  * guiverc still reading..
[00:29] <Bashing-om> guiverc: Indaba - reads well to me //However the March 4 date I must correct to 5 :(
[00:30] <guiverc> thanks Bashing-om, I missed that (despite having indaba on the screen to my right which clearly shows March 5, 2023)
[00:32] <guiverc> Bashing-om, I've completed my read thru. that was all that i noted; looks good to me.
[00:33] <Bashing-om> guiverc: Not one of my stellar performances - but we got there in the end :D
[06:30] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Join us at Operator Day, hosted by Canonical at KubeCon Europe 2023 @ https://ubuntu.com//blog/operator-day-kubecon-europe-2023
[07:59] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: Join us at Everything Open 2023 in Melbourne to Learn about Open Source Technologies an... @ https://ubuntu.com//blog/everything-open-2023-in-melbourne
[12:46] -SwissBot:#ubuntu-news- ::Planet:: Ubuntu Blog: What happens in the Craft team stays in the Craft team … until today @ https://ubuntu.com//blog/what-happens-in-the-craft-team-stays-in-the-craft-team-until-today
[14:43] -SwissBot:#ubuntu-news- ::Planet:: Kubuntu General News: Kubuntu Manual 22.04.2 Release @ https://kubuntu.org/news/kubuntu-manual-22-04-2-release/
[20:26] <Bashing-om> UWN: Pulling "WIP" - No further edits are known - Will start the push sonnest :D
[20:38] <Bashing-om> UWN: M/L is away - Doing the Forums post next.
[21:00] <Bashing-om> UWN: Forums post done - Re-directs next :D
[21:31] <Bashing-om> UWN: Re-directs completed and blogged to Mastodon .
[21:58]  * guiverc smiles when I realize its 777; hopefully no typos on version nbr
[22:04] <guiverc> https://fridge.ubuntu.com/2023/03/06/ubuntu-weekly-newsletter-issue-777/
[22:12] <Bashing-om> Fridge: Spot check and no faults observed :D
[22:22] <Bashing-om> guiverc2: Yuk >>  Netsplit *.net <-> *.split quits: guiverc // will wait for ya on the other side.
[22:23] <guiverc> Bashing-om, you'll send ubuntu-news ML ?
[22:31] -SwissBot:#ubuntu-news- ::Planet:: The Fridge: Ubuntu Weekly Newsletter Issue 777 @ https://fridge.ubuntu.com/2023/03/06/ubuntu-weekly-newsletter-issue-777/
[22:35] <Bashing-om> guiverc: I did send the M/L- I do think - wont hurt to check your mail and insure It went out :P
[22:37] <guiverc> yeah it was there, I just missed it sorry (why i asked... have a head-cold I think so missing stuff I fear)
[22:37] <guiverc> uwn 777 posted to fb
[22:39] <Bashing-om> guiverc: Head cold - coming on Fall there -- these things happen :( /// clear now to wipe and reset Gdoc ?
[22:39] <guiverc> yep scrub away Bashing-om , thanks
[22:39] <Bashing-om> ^ doing .
[23:00] <Bashing-om> UWN:Issue778 kick started :D