[00:00] <cpinto> fullermd, it's not possible to push my local changes to svn if someone else committed code to the trunk
[00:00] <fullermd> If you can dig up the revid of the last change, you could probably make a diff relative to it, save it off somewhere, apply in reverse (to get back to that state), commit it, then re-apply the diff to get back to the changed state...
[00:00] <cpinto> ouch
[00:01] <cpinto> still, as i said, i committed my local changes to my local branch and when I fetched stuff from subversion it was... reverted? hence the pending merges
[00:02] <jelmer> cpinto: you can rebase before pushing
[00:02] <fullermd> Well, if I were going to work disconnected like that, I'd do it in a full branch, instead of mixing things up by doing it halfway with local commits in the checkout.
[00:02] <cpinto> yeah, I was reading about that plugin just now :-)
[00:03] <cpinto> fullermd, what do you mean?
[00:04] <fullermd> Well, when you have local commits that you 'update' into pending merges, you're basically doing the full distributed thing already, but without the cushion and tracking of having them in an explicit branch.
[00:04] <fullermd> So if you do something like that 'update' with local changes, you end up with a bunch of mixed up stuff.
[00:04] <fullermd> (should 'update' even LET you do that?  I'm not sure I'd agree with that...)
[00:06] <fullermd> The goal behind that set of commands/workflow is to try to make working central-but-disconnected as near as possible like straight-central, without introducing the bump in complexity of thinking distributed.
[00:07] <fullermd> I'm ambivalent about whether that's a succeedable goal.  Seems like something that will generally Work Just Fine, but occasionally get you twisted up worse because of the stuff it tries to hide.
[00:08] <fullermd> (I sometimes wish there was another flag like --show-ids to 'status' that would show the revids of pending merges; would make it easier to backstep in situations like that.)
[00:12] <fullermd> Of course, it's equally possible that I'm just a cranky misanthrope who should be ignored   :)
[00:12] <cpinto> damned  hardwired shell shortcut hehe
[00:12] <cpinto> anyway, i agree that update should make my changes "pending merges". but I'd like to have something to replay those merges
[00:13] <cpinto> either that or having bzr-svn merge remote changes into my local branch (which I have to commit) and after I push my stuff to the trunk not creating a revision with the stuff I originally retrieved from subversion
[00:16] <awilkins> I've been using svk for disconnected SVn work
[00:17] <awilkins> This has the secondary benefit of working well with plain SVN clients
[00:17] <awilkins> e.g. - the Eclipse SVN clients can be pointed at my SVK depot, but I can still pull / push
[00:18] <awilkins> I'm prepared to be the merging possibly isn't as good (I'm damn sure it doesn't track renames as well)
[00:20] <cpinto> awilkins, at some point i'd like to move everything onto either bzr or git. this stuff is just a minor nuisance but it's one of those minor things that build up and at some point you get tired of them
[00:21] <awilkins> cpinto: I'm most enthused by bzr so far ; I do a lot of windows development and git just isn't up to it on windows
[00:21] <cpinto> i'd say a proper workflow in bzr-svn wiki would help to avoid this stuff
[00:22] <fullermd> Wow, I can make a total mess of conflicts in a simple cases of local commits too..
[00:22]  * fullermd wanders off to create a bug report.
[00:22] <cpinto> awilkins, the reason for picking up bzr instead of git is mostly due to the fact that the old bazaar borrowed a lot from tla, which is the first dvcs i used :-)
[00:23] <cpinto> one cloud that's hanging over my head, is what will happen to bzr if canonical closes up shop
[00:23] <awilkins> Hmm, I went from Visual Sourcesafe to SVN to SVK to Monotone|git|Hg|bzr
[00:24] <awilkins> I've been trying DVCS tools because I admin a few SVN repos
[00:24] <cpinto> yeek, vss is a nightmare... ever had to recover a vss repo? :-)
[00:24] <awilkins> If canonical closes shop then people will fork bzr
[00:24] <i386> cpinto: yeah man - fuuuck
[00:24] <awilkins> cpinto: No, because you CANT recover a VSS repo
[00:24] <i386> VSS is a nightmare
[00:24] <i386> I did a VSS to Team Studio VCS conversion...
[00:25] <awilkins> The analyze tool can tell you some of the forms of damage, but it can't actually fix things
[00:25] <i386> we had to leave behind some of the version control history
[00:25] <cpinto> awilkins, not so sure of that... it seems that canonical is the single big player using bzr (well, the samba team also uses it)
[00:25] <i386> Do NOT store a 3 gb codebase in VSS
[00:25] <i386> and have 100 developers working from it...
[00:25] <awilkins> Let me fix that s/3 gb //
[00:26] <awilkins> Never use VSS for anything
[00:26] <awilkins> If VS Team VCS is even informed by the design of VSS I wouldn't touch it
[00:26] <cpinto> i386, last year I was asked to convert 3 vss repos to subversion and had to say it couldn't be done. tried everything i could remember, including using old tools to convert from vss to cvs expecting to be able to then convert cvs to svn. no dice
[00:26] <awilkins> In fact, since it's not OSS I wouldn't touch it either
[00:27] <cpinto> the MS guys we had on site said they wouldn't do it either
[00:27] <awilkins> cpinto: I've successfully converted VSS to SVN
[00:27] <i386> ha
[00:27] <i386> we had microsoft .NETs core team come to our company
[00:27] <cpinto> awilkins, really? how did you do it?
[00:28] <i386> to help us move to from 1.1 to 2.0... they told us it couldnt be done
[00:28] <awilkins> I can't recall now, it was one of the scripts on tigris.org
[00:28] <cpinto> awilkins, was it a perl tool?
[00:28] <awilkins> I think it was perl, yes
[00:28] <cpinto> awilkins: that one crashed on my repositories
[00:28] <awilkins> cvs2svn is python
[00:29] <awilkins> Ooh, they have a new one
[00:29] <awilkins> http://www.pumacode.org/projects/vss2svn
[00:29] <awilkins> pumacode ; sounds... fast and hungry
[00:30] <awilkins> And it can convert repos without installing VSS :-) that's a plus
[00:31] <cpinto> awilkins, right, that's the perl tool
[00:31] <cpinto> woops
[00:31] <awilkins> The reverse engineered thing that reads VSS repos is a new bit
[00:31] <awilkins> The version I used was somewhere around v 0.22 I think
[00:31] <cpinto> Released August 4, 2006
[00:31] <cpinto> still nothing new
[00:32] <awilkins> I used it in about 2004 I think
[00:32] <cpinto> oh well, my shrink would be glad to see i'm over it now
[00:33] <awilkins> Misery++ on the news today
[00:33] <awilkins> The north of england is flooded
[00:33] <awilkins> Heath ledger is dead
[00:34] <awilkins> The market is plumetting
[00:34] <awilkins> DOOOM!
[00:35] <awilkins> vss2svn has changes all thw way up to Nov 2007
[00:36] <awilkins> Meh "The engine of the world has been the US consumer ; now they need to save, who is going to do all the shopping?"
[00:37] <awilkins> You can just imagine the World Bank airdropping Visa cards onto the midwest
[00:54] <mtaylor> lifeless: I filed a bug about that thing earlier - #185103
[00:54] <mtaylor> about the bzr info -v producing a traceback
[00:55] <mtaylor> martin pool was starting to look in to it, but I told him you'd been working on it some already
[01:40] <ubotu> New bug: #185211 in bzr-svn "bzr commit fails on imported branch when renaming a directory with non-ASCII-name" [Undecided,New] https://launchpad.net/bugs/185211
[01:44] <bronson> Is it possible to integrate multiple svn repos using bzr?
[01:44] <bronson> I'd like to import 5 different svn repos as different subdirs in my bzr repo.
[01:44] <bronson> That way I can ensure I always have a single, consistent set of code.
[01:44] <bob2> that's fine, but they'll be no more integrated than multiple bzr branches in the same repository would be
[01:45] <bronson> Can I at least work on the branches side-by-side?
[01:45] <bronson> It isn't like I need to abandon one branch in my working copy to work on another one?
[01:46] <bob2> how do you mean "side-by-side"?  you could use "bzr switch", like you can with bzr branches.
[01:46] <bronson> I mean, I'd like to have both branches checked out simultaneously.
[01:47] <bronson> i.e. I have branch A mirrored from UpstreamSvnA, and branch B mirrored from SvnB.
[01:47] <bob2> /home/bronson/somecode/ and /home/bronson/someothercode/?
[01:47] <bronson> Yes.
[01:47] <bronson> Probably more like /home/bronson/myrepo/somecode and /home/bronson/myrepo/someothercode
[01:47] <bob2> sure, branches in the repository can be from different svn repositories
[01:47] <bob2> ah, right
[01:48] <bronson> Good to hear.
[01:48] <bronson> OK, I'll give it a shot.
[01:48] <bronson> bob2, thanks.
[01:48] <bob2> you're welcome
[02:40] <ubotu> New bug: #185224 in bzr "per-file message support into server: common config check {patch}" [Undecided,New] https://launchpad.net/bugs/185224
[03:53]  * igc lunch
[07:00] <ubotu> New bug: #185271 in bzr-gtk "empty branch causes exception for bzr viz" [Undecided,New] https://launchpad.net/bugs/185271
[07:16] <jelmer> tags eyecandy \o/
[07:16] <jelmer> http://samba.org/~jelmer/bzr/bzr-gtk-tags.png
[07:29] <mtaylor> hey all... bzr: ERROR: File exists: '/~ndb-connectors/ndb-connectors/telco-6.3/.bzr.backup': mkdir failed: unable to mkdir
[07:29] <mtaylor> oops. sorry
[07:29] <mtaylor> wrong window
[07:40] <mtaylor> HOLY CRAP. rich-root-packs is really, really fast
[08:39]  * igc dinner
[09:08] <lifeless> hi
[09:08] <lifeless> mtaylor: :)
[09:46] <ubotu> New bug: #185298 in bzr "`bzr whoami --branch<EMAIL_ADDRESS>and lightweight checkout" [Undecided,New] https://launchpad.net/bugs/185298
[10:09] <bzlm> A horse walks into a bazaar...
[10:09] <bzlm> The bazaartender says:
[10:09] <bzlm> "Why the long face?"
[10:11] <lifeless> heh
[13:04] <ushimitsudoki> Is bzr appropriate for managing your website, as in develop on local box and push to server? If so, is there a tutorial or similar available?
[13:05] <bzlm> ushimitsudoki, bzr is appropriate as a version control system for managing your website.
[13:05] <luks> bzr will help you with versioning the website, not with pushing it to the server
[13:07] <ushimitsudoki> bzlm / luks: thank you ... i'm using bzr locally alright I think for a small project, and then read that some people were using it for their websites as well - just got curious about that (it never struck me to use version control for my website before)
[13:08] <beuno> ushimitsudoki, I work at a web development company, and we use bzr through out all our websites
[13:09] <luks> bzr is fine for versioning it, but 1) it won't push the actual website files to the server (which is probably what you want), 2) it will push the branch/repository (which is probably what you don't want)
[13:10] <beuno> ushimitsudoki, what we did to overcome the problem luks mentioned is a custom PHP script that checks for the latest files modified in the commits and lets you upload them via a web interface via sftp
[13:10] <ushimitsudoki> luks: what you are saying is matching up with what I had figured, I was just wondering if I was overlooking some options there
[13:10] <ushimitsudoki> beuno: that is a good idea - a bit beyond me right now, but I grok the concept
[13:10] <Peng> You can use the push-and-update plugin.
[13:11] <luks> Peng: you still probably don't want 'bzr branch'-able data on the server
[13:11] <beuno> ushimitsudoki, push-and-update works also, you just have to be careful not to allow access to .bzr with an .htaccess rule
[13:11] <lifeless> luks: deny access to .bzr :)
[13:11] <Peng> I use .htaccess and directory permissions to block access to it.
[13:11] <ushimitsudoki> bueno / peng: I will look into the push-and-update plugin as well, sounds close to what i need
[13:14] <Stavros> is the trac-bzr plugin good?
[13:15] <lifeless> fsvo good
[13:15] <Stavros> ?
[13:15] <lifeless> it works apparently, but there are quite severe model problems in trac for working with DVCS
[13:15] <luks> "works" is probably the right word to describe it
[13:15] <Stavros> oh
[13:15] <Stavros> lifeless: such as?
[13:15] <lifeless> such as wanting a heirarcy of changed directories above branches, for the timeline
[13:16] <Stavros> oh hmm
[13:16] <Stavros> :/
[13:16] <lifeless> but different branches don't have that innately, so you have to scan all branches and synthesis this view; which is expensive. svn by its model has this
[13:16] <Stavros> i see
[13:16] <Stavros> is there anything else i could use?
[13:16] <Stavros> or do you know if trac will be changed in the future?
[13:17] <lifeless> you can use trac-bzr
[13:18] <lifeless> I'm just explainin the issues :).
[13:18] <Stavros> it's just slower?
[13:18] <Stavros> true :)
[13:18] <lifeless> you could use cart,, though it is unmaintained now
[13:18] <lifeless> or launchpad
[13:18] <Stavros> hmm nah, i'll go with trac-bzr then
[13:18] <Stavros> it's not open source :/
[13:18] <Stavros> is it this? https://launchpad.net/trac-bzr
[13:18] <lifeless> I think so ;)
[13:19] <Stavros> good, thanks :)
[13:36] <Stavros> what does bzr ci --fixes do exactly?
[13:37] <ushimitsudoki> Alright I must reveal more ignorance: I'm trying to install the aforementioned push-and-update plugin. I created a plugin dir under ~/.bazaar and read the wiki on "How to Install a plugin", but I can't find a clear download link on the push-and-update Launchpad page. I did try "bzr branch http://...bzr-push-and-update/trunk", and I got a message that said "Branched 10 revisions", but I don't know where those files are. Please h
[13:38] <Peng> Stavros: It marks the commit as fixing a bug.
[13:38] <Stavros> Peng: regardless of the tracking system used?
[13:38] <Peng> Stavros: The tracking system has to be defined somewhere.
[13:38] <Stavros> so do i do just bzr ci --fixes 12?
[13:39] <Stavros> Peng: hmm
[13:39] <Peng> Stavros: No.
[13:39] <Peng> Stavros: E.g. "--fixes lp:12345" (with the Launchpad plugin) says it fixed bug 12345 on https://launchpad.net/ .
[13:39] <ubotu> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
[13:39] <Peng> Yes, thank you, ubotu..
[13:39] <luks> Stavros: it just records that bug with URL XXX is fixed by this commit
[13:39] <luks> no other functionality
[13:39] <Stavros> Peng: i am using the trac plugin, which is supposed to have some integration
[13:40] <luks> I don't think there is a trac plugin that uses it
[13:40] <Stavros> so every developer should have the plugin installed?
[13:40] <Stavros> hmm
[13:40] <Stavros> maybe i misread then
[13:41] <luks> SVN has the advantage that it can run hooks on the server, so things like this are easy
[13:42] <luks> and since trac doesn't support external API for changing tickets, it's not that easy to do from the client side
[13:42] <bob2> ushimitsudoki: in a directory called "trunk" in the directory you ran "branch" in
[13:43] <Stavros> there's this: https://lists.ubuntu.com/archives/bazaar/2007q2/026518.html
[13:43] <luks> Stavros: what do you mean by 'this'?
[13:43] <luks> it just explains how to configure trac urls
[13:44] <Stavros> it mentions how to get trac integration
[13:44] <luks> no, how to map project:XXX to http://trac.project.org/ticket/XXX
[13:44] <Stavros> ah
[13:44] <luks> you still need a tool to read http://trac.project.org/ticket/XXX from bzr and update the ticket
[13:45] <Stavros> oh, i see
[13:45] <luks> and I'm not aware of such tool
[13:45] <Stavros> right
[13:45] <luks> I was considering writing it, though
[13:45] <luks> but that would mean I first have to install the xmlrpc trac plugin :)
[13:45] <ushimitsudoki> bob2: thank you!
[13:49] <lifeless> Stavros: 'bzr help bugs'
[13:50] <Stavros> oh, thanks
[13:50] <lifeless> (bzr help commit has a see-also of 'bugs')
[13:51] <Stavros> ah yes
[13:58] <bzlm> Peng, your nickname means "coin" in my native tongue.
[14:15] <Vercingetorigex> hi
[14:16] <Vercingetorigex> thI need help: there is a plug-in for Visual Studio of bazaar? Thanks
[14:25] <lifeless> Vercingetorigex: hi, there is such a plugin but I don't know how mature it is
[14:25] <lifeless> Vercingetorigex: google will probably find it
[14:26] <Vercingetorigex> thanks so much
[14:38] <lifeless> mtaylor: hi; yes packs are fast :)
[14:38] <mtaylor> lifeless: they make me happy
[14:48] <CardinalFang> ...fast for most verbs, anyway.
[15:39] <awilkins> How's barnsley?
[15:46] <lifeless> barnsley?
[16:11] <statik> why does bzr-gtk suddenly only have a single revision in trunk, when the version I have locally has over 400? http://codebrowse.launchpad.net/~bzr/bzr-gtk/trunk/changes
[16:11] <schierbeck> jelmer: ping
[16:12] <luks> statik: it has only a single file, named README, read it :)
[16:12] <lifeless> statik: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk/.bzr/branch/last-revision
[16:13] <lifeless> meh thats nuts
[16:13] <statik> wow that is crazy
[16:13] <lifeless> jelmer: why not just rename the branch ?
[16:14] <statik> luks: I should have read that file though, thanks for the tip :) now I can get the latest code
[16:20] <dato> or put one of those bazaar reference branches, if lp would allow doing it (eg. with sftp, I guess)
[16:20] <dato> I think that'd be the best solution?
[16:28] <statik> latest bzr.dev gives me errors trying to pull from a 1.0 smartserver
[16:28] <statik> https://bugs.edge.launchpad.net/bzr/+bug/185394
[16:28] <ubotu> Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Undecided,New]
[16:28] <statik> any other info that I should supply?
[16:30] <lifeless> statik: known defect, see the list, kthxbye
[16:30] <ubotu> New bug: #185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Undecided,New] https://launchpad.net/bugs/185394
[16:30] <statik> lifeless: ok, cool. I didn't find an open bug when I searched
[16:31] <lifeless> statik: yah, we kindof assume folk following trunk follow the list too ;)
[16:37]  * bzlm e inte i huset mer
[16:46] <ubotu> New bug: #185401 in bzr-svn "crash on checkout from SVN WC w/ unicode name" [Undecided,New] https://launchpad.net/bugs/185401
[17:23] <arkadini> whould somebody have an advice on how to split/refactor a file into a number of separate files with bzr?
[17:24] <LeoNerd> Just split it. bzr can't track movements of lines within files.
[17:25] <LeoNerd> If you're going to cut it into lots of small pieces, my suggestion may actually be add all the new pieces, then del the original
[17:25] <LeoNerd> That way you don't have a false "mv" which isn't really true
[17:27] <arkadini> no, just 1 into 2, 3 max but was hoping to preserve the history for all the "new" files...
[17:31] <lifeless> arkadini: planned feature, not there yet sorry
[17:31] <lifeless> LeoNerd: I don't think the mv is false; its not the whole story :)
[17:32] <LeoNerd> Hrm...
[17:32] <LeoNerd> But I'd prefer to in this case, ensure that a "merge" on the file definitely breaks and requires human intervention
[17:32] <LeoNerd> No chance of it accidentally succeeding where it woudl actually be wrong
[17:35] <arkadini> lifeless: fair enough, thanks
[19:13] <brink_> What is the recommended umask?
[19:14] <ernst> hi
[19:15] <ernst> just started with bazaar and am trying to setup a central repo on a ftp
[19:16] <ernst> I finished steps where I made a repo on my ftp and I checked out, and put the files from my project in my local repo.
[19:16] <ernst> but now I want to commit, which gives me this error: Append/Restart not permitted, try again
[19:16] <ernst> what can I do?
[19:17] <fullermd> Stab your FTP server.
[19:17] <ernst> with a knife you mean ... ?
[19:17] <ernst> I know it accepts APPE and RETR.. I tried those command with a command line ftp
[19:17] <fullermd> I like 1/2" rebar.  A knife could break...
[19:18] <ernst> hehe. lol
[19:18] <fullermd> But yeah, it's a pretty standard FTP failure mode.
[19:18] <fullermd> FTP is a flipping mess of a protocol.  Can use use something like SFTP instead?  That would be the easiest fix...
[19:18] <fullermd> Gaah.  "Can _you_ use".  Coffee.  Need coffee...
[19:19] <ernst> nope.. only thing I can use is plain FTP :(
[19:20] <fullermd> I think somebody once had it actually work with active FTP when it failed like that with passive; try using aftp://
[19:20] <fullermd> I can't imagine _why_ that would make a difference, but it may.
[19:20] <ernst> gonna try it now.
[19:21] <fullermd> Then take the knife to your server admin for not having sftp   :p
[19:21] <ernst> well. I can have sftp .. but it will cost me :(..
[19:22] <fullermd> What bzr version/repo format are you using?
[19:24] <ernst> I have version 1.0 and followed this steps: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#publishing-a-branch
[19:24] <fullermd> 'k, so you'd be using packs.  I wondered if maybe they might not need append, but I guess it translates to that down the stack anyway.
[19:25] <ernst> I see..
[19:26] <ernst> well I started again and am now using aftp:// instead of ftp://
[19:27] <fullermd> lifeless: ^^^  _Should_ packs be able to do without transport-layer append, and so be more FTP-friendly?
[19:27] <ernst> first time though, using something like VCN
[19:27] <brink_> Should the umask be 002?
[19:28] <fullermd> brink_: I s'pose that depends on whether you want the umask to be 002   ;)
[19:28] <brink_> It seems we get a lot of problems with permissions after changes are pushed.
[19:28] <fullermd> The umask may affect perms when you 'bzr init'; in normal operation though, bzr bases off the existing perms in the .bzr/ dir.  It may affect working-tree files that are created, I'm not sure.
[19:29] <brink_> We're getting a bit of a mutiny that wants to go back to subversion.  I want to prevent that.
[19:29] <fullermd> Mmm.  Pushing via SFTP, and getting perm problems on directories?
[19:29] <brink_> Yes.
[19:29] <brink_> I have to fix it with chmod every once and a while.
[19:29] <fullermd> OpenSSH's SFTP server doesn't allow setting setgid.
[19:29] <fullermd> It silently strips the bits.
[19:29] <brink_> Sounds evil.
[19:30] <fullermd> If you can use bzr+ssh instead, that'll work.  And probably be faster.
[19:30] <ernst> well.. aftp:// still didn't do the trick
[19:30] <fullermd> You could cron a find .bzr/ -type d -print | xargs chmod g+s with some regularity and stave it off.
[19:30] <brink_> Does bzr+ssh work well for branching too now?
[19:31] <brink_> I suppose I could, but I don't want any flakyness.
[19:31] <fullermd> It should, yeah.  There's a few quirks with branch format default and such, but it should work just fine.
[19:31] <fullermd> I don't think I've used sftp since 0.13 or so, I moved everything to bzr+ssh
[19:31] <brink_> I was wondering if the umask was one of the issues.
[19:31] <ernst> do you have another tip  I can try fullermd??
[19:32] <brink_> I've been using bzr+ssh except for branching, the sftp seems to be much faster.
[19:32] <fullermd> Nah, that's the SFTP server "helping" you.
[19:32] <fullermd> ernst: Not really, sorry   :(
[19:32] <ernst> darn.. I wanted to use Bazaar since it works with plain ftp
[19:32] <ernst> *should work* :)
[19:32] <fullermd> ernst: It comes up with some regularity; some FTP servers just don't get along well.  There's no formal spec for attributes to support or ways of passing errors, so the FTP code is pretty DWIM-y.
[19:33] <fullermd> brink_: Mmm.  Maybe you're using a shared repo, with a lot of unrelated projects/branches in it?
[19:33] <brink_> No.  It's not a shared repo.
[19:33] <fullermd> brink_: The smart server might still be doing its "send initial branch as a tarball of the repo" thing, which could end up sending a lot more data...
[19:34] <ernst> btw.. I see that bzr makes the initial file on my ftpserver.. it just won't append to it
[19:34] <fullermd> ernst: Do you know what software the server is running?
[19:34] <ernst> how do I find ou?
[19:34] <ernst> out
[19:35] <fullermd> It may give a banner you can see from a FTP client.
[19:35] <brink_> I've notice a few postings about permission problems on Linux, but not enough detail to figure out what the solution is.
[19:35] <ernst> never mind.. found it -> it's ProFTPD 1.2.10
[19:35] <fullermd> brink_: Most of them, AFAIK, end up being the "SFTP server stripping setgid" thing.
[19:35] <brink_> Can I get away with a umask of 022?
[19:36] <fullermd> Not really.  SysV filesystem semantics need the setgid on the dir to inherit the group ownership to the files under it.
[19:36] <fullermd> You could put BSD on the server   ;>
[19:36] <brink_> So what do most people do.   Set the umask to 002?
[19:37] <brink_> Actually, the main server we're using is OS X.   So it's sort of BSD.
[19:37] <brink_> We use Linux too though.
[19:37] <ndim> POSIX ACLs could work around...
[19:37] <fullermd> Hm.  I'm not sure what set of FS semantics OS X uses...
[19:37] <ndim> ...potentially.
[19:37] <brink_> I've heard ACLs could help.   I don't know how to set them up though.
[19:37] <fullermd> I don't think bzr follows the umask for repo files; it bases it off the perms of the existing files/dirs.
[19:38] <ndim> POSIX ACLs at least have an equivalent to setgid - but without needing the g+s bit.
[19:38] <fullermd> Yeah, but that probably wouldn't invoke the FS side effect of g+s.
[19:38] <brink_> I've tried setting the sticky bit.  It doesn't seem to help.
[19:38] <fullermd> Yeah, sticky wouldn't help at all.  Might hurt.
[19:39] <brink_> Is that so?  How come?
[19:39] <fullermd> Because the semantics of the sticky bit on a directory is to not allow you to delete files you don't own, regardless of whether you have +w on the dir.
[19:39] <fullermd> (hence its use on /tmp and the like)
[19:40] <brink_> Even if you're a member of the group?
[19:40] <fullermd> Group isn't relevant there.  It's all perms.
[19:41] <brink_> So what's the proper way to setup the perms?
[19:41] <fullermd> To delete a file, you need +w on the directory it's in.  Whether you get that via user, group, or other perms, doesn't matter.
[19:41] <fullermd> Well, the proper way with SysV fs semantics is g+s, so files inherit group   :)
[19:42] <brink_> Something like this?  chmod -R 2770 repo/
[19:42] <fullermd> It's just that the sftp-server doesn't get along with that.
[19:42] <fullermd> Yah.
[19:43] <brink_> And this?   chown -R  root:repogroup repo/
[19:43] <ernst> fullermd: are there any workflows with bzr that doesn't require a correct implementation of APP? ie . it only STOREs files?
[19:44] <fullermd> ernst: I don't know; I don't know the code at that level.  I presume the transport level is translating stuff to appends.
[19:44]  * fullermd nods at brink_.
[19:45] <ernst> I see..
[19:45] <fullermd> brink_: Then periodically g+s'ing directories (not files) would clean up the damage the sftp server does.
[19:45] <fullermd> brink_: But really, bzr+ssh _is_ the better answer.  If it's significantly slower, that's probably a bug.  If you can come up with some numbers on specific cases, you should probably post it to the list so we can see what we can do.
[19:46] <brink_> You believe it's only sftp that causes the damage.  Never bzr+ssh?
[19:46] <fullermd> Yeah.  It's a specific problem; sftp-server strips the g+s bit when we ask for it.
[19:47] <fullermd> bzr+ssh doesn't go through the sftp server; it runs a local 'bzr' invocation which talks to the filesystem.
[19:47] <brink_> It's possible that bzr+ssh is fast for branching now.  I haven't tried branching with bzr+ssh in some time.
[19:47] <brink_> Maybe sftp support should be disabled?
[19:48] <LeoNerd> bzr+ssh is a lot faster than sftp, in my experience
[19:48] <brink_> For pushes & pulls it's faster.   Not sure it is for branching.
[19:48] <fullermd> Actually, sftp may work OK for packs; I don't think pack repos end up creating directories very often.
[19:49] <fullermd> knit repos will until it finishes filling out the hash bucket dirs.
[19:49] <fullermd> Maybe lock dirs still suffer from it; I don't know.
[19:49] <brink_> How do I tell if I'm using packs or knits?
[19:49] <fullermd> 'bzr info'
[19:49] <brink_> Yes.  We've had lock dir issues.
[19:50] <fullermd> But really, I wish we _did_ de-emphasize sftp more.  If there are perf bugs in the SS, they should be fixed, and sftp should be a "if you can't run bzr on the server, you can still use sftp", not a default choice.
[19:51] <brink_> I'm knit format.  Is that old?  Can I upgrade it?
[19:51] <fullermd> Packs came in with 0.92, and became default in 1.0.
[19:51] <fullermd> So if you've got people using older versions, you'll need to stay with knits.  If everyone's keeping up, and is on 1.0 or 1.1, you could upgrade.
[19:52] <brink_> If I upgrade will they fail gracefully?
[19:52] <fullermd> Well, they'll fail by saying "WTF is this?  I don't know how to work with this."  That's sorta graceful.
[19:53] <brink_> That's good enough.
[19:54] <fullermd> Packs may end up slower on sftp, if you have a large history and slow connections, since they'll have to shuffle a lot of data around for repackings.
[19:54] <fullermd> I think the SS protocols already do all that server-side.
[19:55] <ubotu> New bug: #185458 in bzr "can't add files with certain unicode characters" [Undecided,New] https://launchpad.net/bugs/185458
[19:55] <ernst> @fullermd: just using bzr branche with ftp doesn't work. still APPEND errors. Time to use a USB stick instead :( or pay anothe 2 euro 50 for sftp support.
[19:55] <Peng> I have to use sftp on one large repo because the server's process Nazi always kills smart server repacks. :P :(
[19:56] <Peng> ernst: Or find a decent host? Not that that's easy.
[19:56] <fullermd> See?  Just proves my point that there's no problem that can't be solved by finding the right person, and beating the crap out of them   :]
[19:57] <ernst> yeah that's true Peng.. only prob is, I'm happy with my host when it comes to just php + mysql + http hosting
[19:57] <fullermd> So all we need is PHP bindings for bzrlib so we can write a PHP smartserver...
[19:57] <ernst> lol :)
[19:58] <brink_> My os x bazaar thinks it's version 0.18.   Is the macports version behind?
[19:59] <Peng> Well, it is behind.
[20:00] <Peng> 0.18 isn't ancient. It goes 0.18, 0.90, 0.91, 0.92, 1.0, 1.1.
[20:01] <brink_> I see that the 1.0 dmg say's it's for leopard.  I have tiger.   1.1 seems to be for tiger, but it's experimental.
[20:01] <brink_> Not sure what fink will get me.
[20:01] <brink_> Looks like fink is 0.18-1
[20:02] <brink_> Maybe I'll try the leopard one and cross my fingers.
[20:02] <fullermd> 1.1 should be fine.
[20:03] <ernst> how do I add the pgp key from the bazaar gutsy repo?
[20:04] <ernst> I'm using ubuntu gutsy
[20:08] <Peng> It says how on the website.
[20:10] <ernst> tnx. I was looking at the wrong places..
[20:12] <ernst> mm tobad . no version 1.1 out yet for ubuntu as .deb
[20:13] <mtaylor> there's the ones in the ppa
[20:13] <mtaylor> deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
[20:13] <mtaylor> deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main
[20:14] <mtaylor> ernst: ^^
[20:16] <ernst> thanx mtaylor .. that works :)
[20:16] <mtaylor> great!
[20:17]  * mtaylor really wishes that bzrtools, bzr-svn and bzr-gtk would be considered "core" plugins and released to that ppa when bzr is released
[20:17] <mtaylor> but that's just me
[20:18] <abentley> mtaylor: bzrtools is on ppa.
[20:19] <mtaylor> abentley:   bzrtools: Depends: bzr (< 1.1~) but 1.1-1~bazaar1~gutsy1 is to be installed.
[20:19] <mtaylor>   bzr-svn: Depends: bzr (< 1.0.1~) but 1.1-1~bazaar1~gutsy1 is to be installed.
[20:19] <abentley> Yeah.  It's borken, but it's there.
[20:19] <mtaylor> well yes. :)
[20:20] <mtaylor> I meant more of a process thing rather than a physical need thing.
[20:20] <abentley> Bzrtools 1.1 is on ppa, but the dependencies are messed up.
[20:20] <mtaylor> oh, fun
[20:20] <abentley> So that it wants bzr 1.0
[20:23] <ernst> fullermd, I was saying I'm getting those Append / Restart errors with bzr.. well. filezilla ftp client can 't append either. I'm gonna contact my host.. this is nonsens
[20:24] <fullermd> Nonsense?!  This is FTP!   ;p
[20:24] <ernst> hehe. well my first guess is that they disabled resume
[20:24] <fullermd> No, I think ProFTP is one of the ones that that issue is standard on.
[20:25] <fullermd> I'm flabbergasted that they want to charge more for sftp, though.
[20:25] <fullermd> After all the time I spent screwing with firewalls to try and get FTP working right, and all the gaping holes I had to open, I'd be thrilled to tears if NOBODY ever wanted to use it again and I could yank all that crap.
[20:26] <ernst> yeah I couldn't agree more.. silly thing is though, they are saying that SSH has more risks. go figure
[20:32] <Peng> But you can get those risks if you want to pay more?
[20:32] <ernst> yeah..
[20:32] <Peng> fullermd: What do you like for file servers? Just HTTP?
[20:32] <ernst> but 2 euro 50 for SSH and SFTP is too much in my opinion
[20:32] <fullermd> Well, I use NFS for file servers   ;)
[20:33] <fullermd> But yeah, file distribution, I just use HTTP.  It's simple, it's ubiquitous...
[20:33] <Peng> Har har. Ok.
[20:33] <Peng> (Isn't NFS evil?)
[20:33] <fullermd> Absolutely.
[20:33] <ernst> and everyone can get to http :)
[20:34] <fullermd> But I use it in sufficiently controlled situations that the evil is suppressed.
[20:35] <ernst> well, thanks for all the help. I'm gonna await an answer from my host
[21:15] <awmcclain> Hi all... Is the only way to get the current revision number of a file to slice up the output from bzr log FILENAME?
[21:27] <jelmer> mtaylor: I've just uploaded bzr-svn to ppa
[21:27] <mtaylor> jelmer: you are my hero
[21:27] <jelmer> I hope to also upload to ppa from now on when I do releases
[21:28] <jelmer> james_w: Is there some easier way to build for ppa than running "bzr builddeb --source --builder="dpkg-buildpackage -rfakeroot -S -sa" ?
[21:51] <mtaylor> jelmer: I just do bzr bd -S
[21:52] <mtaylor> and then I have in ~/.bazaar/builddeb.conf
[21:52] <mtaylor> [BUILDDEB]
[21:52] <mtaylor> builder = debuild
[21:52] <mtaylor> source-builder = debuild -S
[21:52] <mtaylor> quick-builder = sudo debian/rules binary
[21:52] <mtaylor> orig-dir = ..
[21:52] <mtaylor> and that works for me for ppa
[22:02] <RainCT> Hey
[22:02] <RainCT> what was the command to remove a lock?
[22:02] <jelmer> bzr break-lock
[22:03] <CardinalFang> Tee hee.
[22:05] <RainCT> jelmer: thanks :)
[22:27] <lamont> will bzr let me say 'bzr log - but only for commits that include changes to $FILE'?
[22:27] <Peng> "bzr log file"?
[22:28] <lamont> bzr: ERROR: extra argument to command log: <file>
[22:28] <lamont> win
[22:28] <lamont> otoh, if I only give it one file, it does better
[22:28] <dato> right, only one file allowed
[22:29] <Peng> Seriously?   I'm _sure_ I said it first!
[22:43] <igc> morning
[23:11] <mtaylor> abentley: so any chance of someone re-uploading bzrtools to ppa as a !bazaar2-gutsy1 release with the depends fixed?
[23:11] <mtaylor> and by ! I meant ~
[23:12] <abentley> poolie does that, and he'll be here a bit later.
[23:12] <Peng> Isn't the point of PPA that multiple people have access to it?
[23:17] <poolie> mtaylor, got it
[23:17] <poolie> Peng, yes, anyone could do it, but i probably know more about it than aaron
[23:17] <mtaylor> poolie: rock.
[23:21] <poolie> abentley, i'm off the phone, i'll be there about 11
[23:29] <Peng> Nice, "apt-get update" ran at 743 bytes/sec.


[08:04] <vmxubuntu> Hello, may I ask to receive some (x)ubuntu help in here?
[08:17] <vmxubuntu> How do I install a bootable full working (x)ubuntu OS on a usb stick that I can use on my pc to boot and work live with (x)ubuntu
[11:53] <louiml-com> hey
[15:27] <nini2> hello
[20:45] <xubuntu> ahoj


[10:08] <alkisg> cking, apw, hi, I currently have remote access to the school that had that disk issue. The exact symptoms are that disk writes start at e.g. 200 MB/sec on an HDD, and after some time, they become 2 MB/sec, without going back to 200 MB even if we leave it for hours (was suspecting temperatures). This happens on 4.4 and 4.8 (xenial), but not on 3.2 (precise) or 4.2 (trusty).  I've seen this in another case a few months ago, but I had dismissed it
[10:08] <alkisg> What I'd like to ask is, apart from `ubuntu-bug linux`, should I test or collect something else, since I won't frequently have remote access to the school?
[10:08] <alkisg> My test case is dd if=/dev/zero of=test bs=1M count=1000 conv=fdatasync; then cp -a some-20gb-folder; then dd again => and there it's slow and never gets fast again
[10:12] <cking> alkisg, so what happens if after that initial dd you sync and re-run that test?
[10:13] <alkisg> cking: it degrades gradually, e.g. starts from 200, then 190, then 100...
[10:14] <alkisg> It also happens on their SSD, it's not related to the media
[10:14] <cking> alkisg, so I guess what is happening is that initially the writes fill up the cache and so it appears to be writing fast, but as the cache gets full you get band width limited to the speed of the block device
[10:15] <alkisg> cking: echo 3 > /proc/sys/vm/drop_caches would tell me that, wouldn't it?
[10:15] <alkisg> It's an amazing difference, 200 mb/sec to 2 mb/sec, which makes the system completely unusable
[10:16] <alkisg> I don't think it's related to caching, I've never seen something similar except for those 2 cases...
[10:16] <alkisg> And, it happens only with 4.4+, not with previous kernels
[10:17] <cking> alkisg, so, lets factor out the cache and just do the dd with conv=direct and see what speed you get
[10:17] <alkisg> cking: ok, let me instruct the school to reboot with 4.8, as now it's with a trusty live cd that works fine. I can also give you reverse vnc if you like. Reporting in 2 mins...
[10:18] <apw> cking, note these are CD boots so with whatever is on the media
[10:19] <alkisg> (of course I'm dd'ing to the disk, not to RAM/overlayfs...)
[10:20]  * cking finds a fungible machine to try this out too
[10:20] <alkisg> I've tested about 100 installation so far, so this issue should be quite rare...
[10:24] <cking> alkisg, so whats the failure rate, e.g how many times have you seen it not working efficiently?
[10:25] <alkisg> cking: it 100% reproducable, what varies is that it might need 20 GB of writes before it starts to happen, or 80 GB of writes
[10:25] <cking> alkisg, I mean, of all the machines it's been installed on, how many exhibit this issue?
[10:26] <alkisg> I've only seen that issue in 2 machines. I've installed 16.04 in about 100 machines so far.
[10:26] <cking> alkisg, if you can add the machine info to the bug report than that may give some hint on what kind of common H/W issue it is related to
[10:27] <alkisg> cking: I've remote access to their xenial/4.8 installation now, freshly booted (it's not a live cd). I can give you reverse vnc if you like. Should I start with some test, or with ubuntu-bug linux?
[10:28] <cking> reporting the bug 1st would be a good start
[10:28] <alkisg> ty, doing so...
[10:44] <alkisg> https://bugs.launchpad.net/ubuntu/+source/linux-hwe/+bug/1698118
[15:23] <knowhow> good day
[15:24] <knowhow> how do i patch a kernel? with an rt patch
[15:24] <knowhow> ?
[15:25] <knowhow> i donloaded the newest rt patch
[15:25] <knowhow> and something that looked as the kernel from kernel .org
[15:25] <knowhow> in a gz format
[15:26] <knowhow> of course the thing that seemed to be the kernel isnt the kernel...it is just a source file..
[15:27] <apw> knowhow, if you want to apply a patch, that applies to a source tree
[15:27] <apw> knowhow, if you want to apply it to the ubuntu kernel, you want to get the kernel for the series on which
[15:27] <knowhow> i am not a linux expert...so here what i did
[15:27] <apw> knowhow, you intend to patch, preferably by checking out the git repo for that series
[15:28] <knowhow> i am clueless about what you just said
[15:28] <knowhow> i know what git is if that makes a difference
[15:28] <apw> knowhow, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[15:28] <apw> knowhow, you are trying to do something deeply hard, and deeply distro specific, with a very big patchset
[15:29] <apw> knowhow, you would want to have a good knowledge of the platform before even considering attempting something like that
[15:29] <knowhow> this is what i have to apply
[15:29] <knowhow> https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/
[15:30] <knowhow> it is the 4.30.rc1 way down in the list
[15:30] <knowhow> i am on ubuntu 16.04 am i am used with .deb files
[15:30] <knowhow> so what do i download from where to apply this rt patch to?
[15:31] <knowhow> beacause this:
[15:31] <knowhow> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/
[15:31] <knowhow> contains no kernel source code
[15:31] <knowhow> it is just a file in a gz format
[15:32] <knowhow> i donloaded them from graphical environment...from firefox that is
[15:32] <apw> knowhow, depends what you are trying to achieve, if you want to apply it to an ubuntu kernel, you would want to pick the ubuntu source tree git respository for 16.04 and apply it there
[15:32] <cking> knowhow, have you considered using the low-latency kernel?
[15:32] <apw> of course there is almost no way it will apply to anything other than 4.9 which is not a kernel base ubuntu picked
[15:32] <knowhow> i allready have it installed ..that came in a deb format
[15:33] <apw> you have RT installed already in deb format ?
[15:33] <knowhow> for a sound card it probably works....but i have a cnc on a parallel port
[15:33] <knowhow> no not rt
[15:33] <knowhow> low-latency but from what i hear it is not good enough
[15:34] <apw> not good enough for what
[15:34] <knowhow> and i am not going to compile linuxcnc against that...i need to build one from scratch apply rt patch to it and install it...so i can boot it with grub customizer when i need it
[15:35] <knowhow> apw...i said in the rows above...but i will repeat....linuxcnc
[15:35] <cking> knowhow, you may find using the low-latency kernel with the application running with the FIFO or RR real time scheduler with a high priority is probably more than good enough
[15:35] <apw> i think you over estimate just how much information about you and your plan i have in my head
[15:35] <knowhow> what?
[15:35] <apw> but, if you want to build an rt version of an ubuntu kernel, you need to apply that patch to the ubuntu-kernel
[15:36] <knowhow> apw are yoy some kind of inteligent AI?
[15:36] <apw> you are runnig on your system, and then build it
[15:36] <knowhow> am i talking to a real person here?
[15:36] <cking> knowhow, apw is a real person for sure
[15:36] <knowhow> ok lets start from begining
[15:36] <apw> that wiki link tells you how to get the git repositories you need to do that
[15:36] <apw> and you had better know how to apply a patch if you are going to succeed in this endevour
[15:36] <knowhow> i have the linuxcnc source...the sitee with instructions how to instaall it
[15:37] <knowhow> i reached the step where the new kernel has to be prepared...i cannot screw up the one allready installed...just in case something goes horribly wrong
[15:37] <cking> knowhow, that site states "optionally with realtime extensions", so you may not need RT
[15:38] <knowhow> i can boot from the one not touched
[15:38] <knowhow> i need it for operating the real machine...i do not need it for simulations
[15:39] <apw> "simple installation on ubuntu" if you have to build your own kernel and apply rt to make that happen it is falling far short of "simple"
[15:39] <knowhow> it will cut itself instead of the metal piece....and guys you dont want skynet in real life do you?...so help a stranger here :)
[15:40] <knowhow> i need to know what source do i download for the patch and from where?
[15:40] <apw> as i say if what you want is an ubuntu kernel with RT you need to get the kernel source git repo for your series, you need to get the nearest RT patch set, and you need to apply it
[15:40] <knowhow> i will give again the link for the patch
[15:40] <knowhow> https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/
[15:41] <knowhow> and in the list is the newest 4.9.30.rc1
[15:42] <apw> right but ubuntu doesn't have a 4.9.<anything> kernel, so if you want to have an ubuntu base you will need to apply it to 4.8 or 4.10, or use a 4.4 base with the rt for that
[15:42] <knowhow> this wwill make the kernel realtime...now i need to know which is the newest stable kernel for ubuntu that can accept this patch...and the commands to apply it safely...and then compile it
[15:42] <knowhow> and after that installing it of course...or make it a deb file for later easy use
[15:43] <apw> there seems to be 4.4 and 4.8 bases for RT so as long as you are running one of those
[15:43] <apw> i would recomment you use the latest RT for one of those
[15:43] <knowhow> right now i run 4.7...on ubuntu which gets updated...regularily
[15:43] <apw> as 16.04 was xenial and the GA kernel was 4.4, that would seem to be a lodical choice
[15:43] <apw> knowhow, then you arn't running a kernel we produce
[15:44] <apw> and you wouldn't be getting updates for 4.7 either (from us)
[15:44] <knowhow> yeah but linus....updated it and i just grabbed the newest deb there...generic...and the low latency
[15:45] <knowhow> they both work fine...but where do i get the latest stable generic source so i can apply this patch to it?
[15:46] <knowhow> i instaalled them both...and with grub customizer i can boot which one i want
[15:46] <apw> where do you get your mainline .debs now ?
[15:46] <apw> as they should be offering you some route to source in those
[15:46] <knowhow> hhold on i probably have the links somewhere
[15:46] <apw> as i am sure it is not linus who is producing .debs, he is a fedora man iirc
[15:48] <knowhow> aah no..no no....this got to be a serrious joke....is the latest stable version 4.11 ?....i checked the site two months ago and it was 4.7 or something
[15:48] <knowhow> anyway here s the link
[15:48] <knowhow> https://www.kernel.org/
[15:49] <apw> and yo got a .deb form there ?
[15:49] <knowhow> but the rt patch does not get updated that quickly so i am going to use the kernel coresponding its version
[15:50] <apw> v4.8 was released in october last year
[15:51] <apw> so if you are going to try and construct a kernel source at 4.9.30 then i would clone linus' tree, checkout v4.9 and apply the delta patch from kernel.org
[15:53] <knowhow> apw....it is seems aliens  or mr smith from matrix ate the link from which i ....
[15:54]  * cking notes one can build .debs from the kernel source using:  make deb-pkg INSTALL_MOD_STRIP=1
[15:54] <knowhow> anyway ....i just got my eyes opened with a can opener
[15:55] <knowhow> cking how do i do that ? by including ALL and imean ALL the dependencies that a ffresh install of ubuntu without internet conection?
[15:56] <knowhow> i do not find the 4.9.30 version on here
[15:56] <knowhow> https://www.kernel.org/
[15:56] <apw> knowhow, pick the URL for the patch for 4.9.32 and adjust it to say 30
[15:57] <knowhow> apw...won't that screw up shite up...the patch is intended for 4.9.30 man...i do not want to ruin my ubuntu installation
[15:58] <sforshee> knowhow: use this link - https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.30.tar.xz
[15:58] <knowhow> i do not know how to remove bad kernels yet
[15:58] <apw> knowhow, no i am saying to make the url like sforshee has said
[15:59] <knowhow> ok are you a wizard or something? how did you find that?
[15:59] <apw> he took the URL which is published there for any version on the page, and changed the version to the one you wanted
[15:59] <sforshee> right, copy the link on git.kernel.org for 4.9.32, then paste it and change the 32 to a 30
[16:00] <knowhow> but it doesnt show on the page
[16:00] <sforshee> right click the link and select the "copy" option
[16:01] <sforshee> knowhow: it seems linuxcnc has a custom distribution you can install, why aren't you just using that?
[16:01] <knowhow> well...for now i just found the source for my patch and i am going blind for a month now :|
[16:01] <sforshee> knowhow: http://linuxcnc.org/docs/2.7/html/getting-started/getting-linuxcnc.html#_installing_linuxcnc
[16:02] <sforshee> or http://linuxcnc.org/docs/2.7/html/getting-started/getting-linuxcnc.html rather
[16:02] <knowhow> sforshee....no no no my man....no bad advice there...i have a 8 core laptop ...and i want to friggin' use it
[16:03] <knowhow> i've been recommended that but i do not want to fill my house with computers
[16:03] <apw> heh that will take a few hours to build it i suspect
[16:03] <knowhow> and is old anyway
[16:04] <knowhow> apw...yeah but that is why 8 cores and 32 gigs of ram should make it just couple of hours...but after that i have it for life
[16:04] <knowhow> no?
[16:05] <knowhow> it is a dell precision m6600 whith the docking station
[16:05]  * apw tries to imagine a kernel lasting weeks ... heh
[16:06] <knowhow> when i do not operate the cnc machine i use the low latency kernel to develop the  open source sound card
[16:06] <knowhow> on low spec pcs probably lasts a day or so...
[16:07] <sforshee> knowhow: if you use that link and apply the rt patch that should get you the source tree you need, building is much much more difficult than that though if you've never done it before
[16:08] <knowhow> i have allready downloaded it and the patch too...i am going to apply it and compile it tomorow..beacause now it is evening
[16:08] <cking> sforshee, to be fair, if one slams in the nearest ubuntu config into that tree and then build with  make deb-pkg INSTALL_MOD_STRIP=1 it may just spit out the required devs
[16:08] <cking> *debs
[16:09] <sforshee> cking: only if there are not config changes needed
[16:09] <cking> sforshee, true, but one just answers the relevant questions on the config step and one is done
[16:10] <knowhow> do i need anything else to know?
[16:10] <cking> you may need several GB free to do the build
[16:10] <knowhow> the steps should be apply patch....compile kernel....and make deb file for easy install in the future
[16:11] <cking> knowhow, the make dep-pkg step will build and package the kernel in one go
[16:11] <cking> *deb-pkg
[16:11] <knowhow> cking...say what?....gigs???....what i just downloaded has 88 megs....and the patch has 300 kilos
[16:12] <knowhow> cking i allready cpied that line in a notepad file :)))
[16:13] <ivan> several gigs more like 30GB
[16:13] <cking> yeah, my last build was 28GB
[16:13] <knowhow> ckiing....i have a terabyte of sda1 and another one sda2 that means two terabytes....but...
[16:14] <knowhow> how in the name of actual f u k ....can a 88 megs and  300 kilos can take 30 gigs?
[16:14] <knowhow> i dont know...i am just asking
[16:15] <knowhow> as i mentioned...i have the space...but....nimoy would say that this is highly ilogical
[16:15] <knowhow> how can 88 megs...ok 89....can become 30 GB?
[16:16] <sforshee> knowhow: 88 megs is compressed, the source is much bigger after decompression, then all the files produced by building take up space
[16:16] <cking> knowhow, and compiled code with all the intermediate object code uses up a load of space
[16:16] <knowhow> i know it takes more space....but THAT much?
[16:17] <knowhow> i compiled files for microcontrolllers....and they take less space after compilation
[16:18] <knowhow> oh i forgot about the object code....but stil...THAT much?...
[16:18] <cking> ..and there a many modules being built = lots of code
[16:19] <knowhow> i played with c++ on win but....30 gigs...you mean my deb file is going to be 30 gigs?
[16:19] <knowhow> :|
[16:19] <ivan> no
[16:20] <cking> knowhow, no, the final deb files will be tens of MB, don't fret over the intermediate data being generated during a build, it's the final product you need to concern yourself about
[16:21] <knowhow> ooh those are going to be like a buffer in the process of compilation and after it finshes it erases that...intermediate data yeah....that was the expression
[16:21] <knowhow> i set the swap file to the size of the ram anyway for a good measure
[16:21] <knowhow> :)))
[16:22] <knowhow> that is 32 gigs
[16:22] <knowhow> it will probably never be used
[16:23] <knowhow> so do i put the gz patch in the same directory of the 88 megs file that i just downloaded?
[16:23] <knowhow> the rt one that is?
[16:23] <knowhow> cking
[16:23] <knowhow> ?
[16:25] <knowhow> well in a copy version of course just in case murphy shows up to see what i am up to?...as usual :))
[16:25] <cking> knowhow, you uncompress and untar the kernel source, cd into the kernel source then apply the patch using patch -p1 < name-of-patch-file
[16:26] <cking> if you are in luck, the patch will apply cleanly and then you can build the kernel
[16:26] <knowhow> but the gz patch has to be in the uncompressed 88 megs folder right?...well the bigger version after decompression
[16:26] <knowhow> do i need to check for build-deps or something?
[16:27] <knowhow> i allready checked for linuxcnc from the linux cnc source folder
[16:27] <knowhow> so that is prepared
[16:28] <cking> knowhow, to be clear:
[16:28] <knowhow> yes?
[16:28] <cking> uncompress the kernel source and untar it
[16:28] <knowhow> ok
[16:28] <cking> uncompress the patch, and to make things easy move it into the kernel source directory
[16:28] <knowhow> uncompress=untar
[16:28] <knowhow> what i do after that with the rt patch gz file?
[16:29] <cking> with the uncompressed patch file, apply it using patch -p1 < name-of-patch-file (what ever the name of the file is)
[16:30] <cking> if you are in luck it will apply cleanly
[16:30] <knowhow> but where the gz file needs to be for that command to be successful?...in the linux kernel source folder?...the one i just untared?
[16:30] <cking> yep, in the kernel source directory
[16:31] <knowhow> i am not to good with cli paths so i use graphic mode to copy everything in one place
[16:31] <knowhow> ok got it
[16:33] <cking> knowhow, you need some cli know-how to apply patches, get the .config sorted and to build and install the kernel for sure
[16:35] <knowhow> well after the patch is going applied well....that is the next order in line...and probably the site i got the instructions from will explain more on that part
[16:36] <knowhow> but first in row....thank you apw....for the linux 4.30 kernel source file that coresponds with my patch
[16:37] <knowhow> and then some serios thanks goes to you cking...for explaining some basic command and file ,folder placements that for the expert is trivial but for a newbie like me isnt
[16:39] <knowhow> i copied the steps of placing everything where it needs to be too...in the notepad...so i do not have to ask again the same things later
[16:40] <cking> lets hope it all works out OK :-)
[16:40] <knowhow> so big thanks for apw....cking...and the rest of the forum for the courtesy shown
[16:41] <knowhow> i hope so too...if not...i will sure come crying like a litle big baby back here again :)))
[16:41] <knowhow> if it dosnt i am not ruining a good installed kernel anyway
[16:42] <knowhow> thanks again....and i will come again for the updates about the issue
[16:44] <cking> cool
[23:38] <immu> Add new softlockup stressor, use with caution(!) ???
[23:53] <immu> how can i install Unstable updated to 4.12-rc5 on 17.04 ?????


[01:03] <mup> Bug #1906327 opened: aws-iot-greengrass snap *was temporarily gone <Snappy:New> <https://launchpad.net/bugs/1906327>
[01:12] <mup> Bug #1906327 changed: aws-iot-greengrass snap *was temporarily gone <Snappy:New> <https://launchpad.net/bugs/1906327>
[01:15] <mup> Bug #1906327 opened: aws-iot-greengrass snap *was temporarily gone <Snappy:New> <https://launchpad.net/bugs/1906327>
[07:05] <mborzecki> morning
[07:15] <mborzecki> brb, reboot for a  new kernel
[07:17] <mborzecki> re
[07:18] <mup> PR snapd#9421 closed: interfaces/utf: Add Ledger to U2F devices <Needs security review> <Created by TamtamHero> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9421>
[07:30] <mborzecki> mvo: morning
[07:30] <mvo> good morning mborzecki
[07:57] <pstolowski> mornings
[08:01] <mvo> good morning pstolowski
[08:18] <mborzecki> pstolowski: hey
[08:23] <mup> PR snapd#9722 closed: daemon: split apps and logs endpoints to api_apps.go and tests <Cleanup :broom:> <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9722>
[08:49] <pedronis> mvo: I commented on #9718
[08:49] <mup> PR #9718: secboot,devicestate: add scaffoling for "fde-reveal-key" support <Needs Samuele review> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9718>
[08:50] <pedronis> mvo: mborzecki: hi,  #9713 needs 2nd reviews/re-reviews, my fix seems to  have worked
[08:50] <mup> PR #9713: tests: sign new nested-18|20* models to allow for generic serials <Run nested> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9713>
[08:51] <pedronis> mvo: mborzecki: thanks for reviewing my daemon cleanups
[08:52] <mborzecki> pedronis: hi, i think you can force merge https://github.com/snapcore/snapd/pull/9723 when the spread jobs finish, i've restarted them but one of the tests still failed on amazon due to 408 from the store
[08:52] <mup> PR #9723: daemon: move some more api tests from daemon to daemon_test <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9723>
[08:53] <mborzecki> pedronis: and https://github.com/snapcore/snapd/pull/9719 is trivial and could use your review
[08:53] <mup> PR #9719: boot: set kernel command line in modeenv during install  <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9719>
[09:03] <pedronis> mborzecki: it's in my queue
[09:10] <mborzecki> pedronis: thanks
[09:27] <pedronis> mvo: I re-reviewed #9715 , I made a non-blocking suggestion but maybe is too complicated for now
[09:27] <mup> PR #9715: hookstate: add new HookManager.EphemeralRunHook() <Needs Samuele review> <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9715>
[09:36] <pedronis> mborzecki: I asked a question in #9719
[09:36] <mup> PR #9719: boot: set kernel command line in modeenv during install  <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9719>
[09:59] <zyga> good morning guys
[10:00] <zyga> got out of most of the planning mess and I will be back to normal on-irc working on foss-y bits tomorrow
[10:00] <zyga> I will resume snapd patches as well
[10:01] <zyga> the lat few days were sort of an internal planning sprint where I'm just always in meetings and planning
[10:04] <zyga> mvo spread has no missing deps in Debian anymore
[10:05] <zyga> coffee done and back to planning :)
[10:05] <mvo> zyga: woah! did you update it to use only pkgs that are already packaged?
[10:05] <zyga> mvo yeah, I just need to give you the package
[10:05] <mvo> zyga: let me know when you need sponsoring
[10:05] <zyga> given that I run part of my own planning now
[10:05] <zyga> I added a task group for handling debian packaging
[10:05] <zyga> so I will definitely have time for shared work
[10:06] <zyga> it's just not today, time to write down all decisions and fill in various comms systems for others to know
[10:06] <zyga> good luck and see you soon :)
[10:15] <mborzecki> pedronis: thanks, let me take a look
[10:15] <mvo> zyga: sure, no rush! see you
[10:22] <pedronis> mborzecki: what go version we have on on amazon linux?
[10:23] <mborzecki> pedronis: let me double check but iirc it was 1.11+
[10:23] <pedronis> 1.15
[10:23] <pedronis> sorry, we print nowadays
[10:23] <mborzecki> pedronis: yup that's quite likely
[10:27] <mborzecki> pedronis: centos 7 should have 1.15 too
[10:28] <mup> PR snapd#9723 closed: daemon: move some more api tests from daemon to daemon_test <Cleanup :broom:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9723>
[10:43] <mborzecki> pedronis: i've updated https://github.com/snapcore/snapd/pull/9719
[10:43] <mup> PR #9719: boot: set kernel command line in modeenv during install  <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9719>
[11:45] <pedronis> mborzecki: +1
[11:49] <mvo> thanks pedronis !
[11:49] <mvo> 9715 needs a second review, maybe pstolowski can have a look, hopefully not too long/difficult
[11:50] <pstolowski> mvo: sure, will do
[11:50] <mvo> thanks a lot!
[11:55] <mborzecki> pedronis: thanks!
[11:57] <pedronis> mvo: I commented on the cleanup: https://github.com/snapcore/snapd/pull/9715#discussion_r533353541
[11:57] <mup> PR #9715: hookstate: add new HookManager.EphemeralRunHook() <Needs Samuele review> <Squash-merge> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9715>
[11:57] <mborzecki> looks like apt hooks and snap advise is failing
[11:58] <mborzecki> (the tests i mean)
[11:58] <mvo> pedronis: excellent, I poke on this next
[11:58] <mborzecki> heh HTTP/1.0 429 Too Many Requests
[11:59] <mborzecki> when updating snap catalog
[12:16] <pstolowski> mvo: can you explain what does it mean to run hooks in ephemeral mode? maybe i'm confused by what epehemeral meant for apps & snapctl. what is the problem this is addressing?
[12:18] <pedronis> pstolowski: we want to run a hook from snapd without a change or task
[12:18] <pedronis> synchronously
[12:19] <pstolowski> pedronis: ah, i see, makes sense, thanks
[12:39] <mup> PR snapd#9724 opened: boot: observe successful command line update, provide a default  <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9724>
[14:50] <mup> PR snapd#9725 opened: bootloader: remove installableBootloader interface and methods <Cleanup :broom:> <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9725>
[15:13] <mup> Bug #1906327 changed: aws-iot-greengrass snap *was temporarily gone <Snappy:Invalid> <Snap Store Server:Incomplete by nataliabidart> <https://launchpad.net/bugs/1906327>
[15:20] <ijohnson> mborzecki: do you know if we have unit tests for snap-confine? if so where are they?
[15:21] <mborzecki> ijohnson: we have some, they're in cmd/snap-confine/*-test.c files
[15:21] <pedronis> mborzecki: I commented on #9724, some questions there
[15:21] <mup> PR #9724: boot: observe successful command line update, provide a default  <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9724>
[15:21] <ijohnson> mborzecki: ah thanks I think snap-confine-invocation-test.c is what I was looking for
[15:21] <mborzecki> ijohnson: though it's not per se the whole of snap-confine functionality covered by the test, rather some smaller individual bits
[15:21] <mborzecki> pedronis: thanks
[15:22] <pedronis> ijohnson: you asked about unit tests, there's also spread tests for it in case, under spread-tests
[15:23] <ijohnson> yeah I saw the spread tests, just wondering if we also had unit test coverage for snap-confine
[15:23] <mborzecki> w8, do we run those tests?
[15:23] <ijohnson> haaaaa
[15:24] <ijohnson> 🤦
[15:24] <ijohnson> mborzecki: uhhhh no we don't seem to run them in github actions that is
[15:25] <ijohnson> perhaps we still run them in nightly travis runs? cachio do you know if we run the spread tests in ./cmd/snap-confine/spread-tests anywhere?
[15:30] <pedronis> mmh, I don't see anything mentioning them
[15:39] <mborzecki> Before snap-confine was merged with snapd it used to have its own spread
[15:39] <mborzecki>     tests
[15:39] <mborzecki> that's from commit e3d6f6aae6bb48e585ff3de1a25277b680e736b4
[15:39] <mborzecki> https://github.com/bboozzoo/snapd/commit/e3d6f6aae6bb48e585ff3de1a25277b680e736b4
[15:41]  * cachio lunch
[15:42] <ijohnson> mborzecki: I updated #9720, could you take a look? thanks
[15:42] <mup> PR #9720: many: rename disks.FindMatching... to FindMatching...WithFsLabel and err type <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9720>
[15:47] <mborzecki> ijohnson: +1, little copy paste typo :P
[15:49] <ijohnson> thanks mborzecki !
[16:25] <mup> PR snapd#9726 opened: cmd/snap: suppress a case of spurious stdout logging from tests <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9726>
[16:47] <vidal72[m]> is it possible to persistently set some env variable for specific snap by user other than editing desktop file?
[16:50] <mup> PR snapd#9727 opened: seed: cleanup/drop some no longer valid TODOS, clarify some other points <Run nested> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9727>
[16:51] <pedronis> vidal72[m]: not atm, it would need some discussion because it kind of sidesteps/overlap with the configuration support for snaps
[17:10] <mup> PR snapd#9728 opened: Disable user creation on system-user auto-import <Created by slimjim777> <https://github.com/snapcore/snapd/pull/9728>
[17:16] <om26er> Hey my /var/lib/snapd/hostfs/ is empty, is that expected ? Also how can I check what my snap could "see" in that directory ?
[17:19] <ijohnson> om26er: /var/lib/snapd/hostfs will be empty if you are running outside of snap confinement
[17:20] <om26er> While trying to run a strict snap on Nvidia Xavier NX, my snap won't start, but if I copy my libGL* files to /var/lib/snapd/lib/gl then it starts fine.
[17:20] <ijohnson> om26er: that directory has "/" bind mounted to it when snaps run
[17:20] <ijohnson> om26er: so whatever is in "/" is what will show up in /var/lib/snapd/hostfs
[17:21] <om26er> hm, interesting. So that means the opengl interface might need some update(s) to support Yocto based environments
[17:21] <om26er> ?
[17:22] <ijohnson> well you mentioned /var/lib/snapd/lib/gl and /var/lib/snapd/hostfs
[17:22] <ijohnson>  /var/lib/snapd/hostfs should not need any changes for yocto since that's just a simple bind mount
[17:23] <ijohnson>  /var/lib/snapd/lib/gl will most likely require changes to snap-confine to do extra mounts depending on where the gl files are on the host on yocto, yes
[17:23] <om26er> is it possible that my snapd is not able to see /var/lib/snapd/hostfs, due to a bug or something ?
[17:23] <ijohnson> what do you mean that your snapd is not able to see /var/lib/snapd/hostfs ?
[17:24] <om26er> I mean't is it possible that due to a bug in snapd/confine, my snaps are not able to "access" stuff on the rootfs ?
[17:25] <ijohnson> om26er: what do you see when you run `snap run --shell <your-snap>.<an-app-in-your-snap> -c "ls -lah /var/lib/snapd/hostfs"` ?
[17:25] <om26er> root@jetson-xavier-nx-devkit:~# snap run --shell kivy-sample -c "ls -lah /var/lib/snapd/hostfs"
[17:25] <om26er> ls: cannot open directory '/var/lib/snapd/hostfs': Permission denied
[17:28] <om26er> also: on that system libGLESv2.so.2 is under /usr/lib/libGLESv2.so.2 which isn't the case on Ubuntu at least.
[17:29] <om26er> also when I run `strace`, it's not able to find this directory as well https://github.com/snapcore/snapd/blob/master/interfaces/builtin/opengl.go#L56 -- it clearly exists on the host
[17:29] <om26er> s/directory/file
[17:31] <om26er> ijohnson btw, that "permission denied" also happens on my desktop, so looks like its "expected" ?
[17:32] <ijohnson> om26er: oh yeah you will need to run a devmode snap, can you reinstall the snap in devmode
[17:32] <ijohnson> and then try that same command again
[17:33] <om26er> yeah, now it prints the directory structure
[17:34] <om26er> well in devmode, my snap starts anyways, I have been working on enable confinement though
[17:35] <mup> PR snapd#9729 opened: bootloader/lkenv: specify backup file as arg to NewEnv(), use "" as path+"bak" <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9729>
[17:35] <om26er> actually I take that back, it does't work in devmode as well unless I put the libGL* files under `/var/lib/snapd/lib/gl/`
[17:41] <om26er> btw, these are the minimal set of .so files that I copied from /usr/lib to /var/lib/snapd/lib/gl/ for the Kivy to work from a snap environment https://gist.github.com/om26er/b4aaf190f5ce3629067bd18b5ff502f2
[17:45] <mup> PR snapd#9715 closed: hookstate: add new HookManager.EphemeralRunHook() <Needs Samuele review> <Squash-merge> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9715>
[18:11] <thresh> hello.  i'm installing snapcraft in a ubuntu 20.04 docker container (RUN apt install snapcraft...), and it seems it has issues connecting to snap store while running a debian preinstall script.  It tries asking me on a TTY what to do, but there is no terminal.  How can install it without user interaction?
[18:11] <thresh> https://code.videolan.org/-/snippets/1301/raw is the log output
[18:31] <ijohnson> thresh: you shouldn't be using snapcraft as a deb package, you should be using snapcraft as a snap, there's examples of how to do this from inside a docker container on snapcraft.io/docs
[18:46] <thresh> thanks ijohnson|lunch
[18:46] <thresh> why does https://snapcraft.io/docs/build-on-docker mention FROM ubuntu:bionic as builder, but later on the Dockerfile it's using FROM ubuntu:xenial ?
[18:47] <thresh> X-Ubuntu-Series: 16 is also suspicious wrt core18...
[18:54] <cjwatson> "X-Ubuntu-Series: 16" is normal even for core18
[18:54] <cjwatson> (yes, this is a bit confusing.  It's more of an API version nowadays)
[19:11] <mup> PR snapd#9730 opened: hookstate: refactor around EphemeralRunHook <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9730>
[19:26] <mup> PR snapd#9731 opened: daemon: split out snapctl support and snap configuration support to their own api_*.go files <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9731>
[19:46] <mup> PR snapd#9726 closed: cmd/snap: suppress a case of spurious stdout logging from tests <Simple 😃> <Skip spread> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9726>
[19:51] <thresh> cjwatson, ah yeah, it's still a bit weird that it doesnt fetch core18, while says so... I've found https://github.com/snapcore/snapcraft/blob/master/docker/stable.Dockerfile which helped be to figure it out
[19:58] <thresh> thanks a lot and have a good day :)
[21:30]  * cachio afk