[17:43] <harmw> if someone sees RaginBajin tell him to ping me
[17:43] <harmw> i've got a freebsd pkg for him to test


[03:17] <micahg> I seem to have an issue with debian/.gitattributes being removed on a no change rebuild (even without clean), it has no diff, so it'll be sync'd right over anyways, I would think this is ok, but wanted to bounce it off someone
[03:18] <ScottK> Don't see how it matters since we aren't using git.
[03:19] <micahg> right, ok, thanks
[03:19] <micahg> that should be it for the libgsoap transition, yay
[06:38] <dholbach> good morning


[21:31] <YamakasY_> hey guys!
[21:31] <YamakasY_> I heard this channel is great for preseed questions :)
[21:32] <YamakasY_> ok, I'm adding a puppet repo using my preseed file but puppet 2.7 is installed from the ubuntu repo and not the 3.4 one from the puppet labs repo
[21:33] <YamakasY_> this is what I do: http://pastebin.com/jQDw3XMk
[21:43] <cjwatson> (I only have about 30 seconds before I have to run off to stop children destroying the universe.)  Do you also have an apt-setup/local0/...?  apt-setup will count from 0, and stop at the first one that doesn't exist.
[21:43] <cjwatson> If you don't have a local0, rename this one.
[21:43] <cjwatson> If that isn't it then I'd need to see an installer syslog.
[21:43] <cjwatson> (gone)
[22:26] <YamakasY_> cjwatson: yes did that :) now I read it here :)
[22:27] <YamakasY_> cjwatson: that works, but it's not going to be installed on 12.04 because of a unmet dependency... on a 12.04 lts I need to to do a dist-upgrade to get it installed
[22:28] <cjwatson> "d-i pkgsel/upgrade select full-upgrade" might be worth trying then
[22:35] <YamakasY_> cjwatson: just add it under those lines ?
[22:35] <cjwatson> Position doesn't matter
[22:36] <cjwatson> Preseed files are declarative - they're basically setting a bunch of database entries
[22:36] <cjwatson> Order within embedded scripts obviously matters, but not otherwise
[22:39] <YamakasY_> cjwatson: ah ok, thanks, restarting the install now
[22:39] <YamakasY_> cjwatson: I get my lines always proper :)
[22:44] <YamakasY_> cjwatson: going well so far :)
[22:56] <YamakasY_> cjwatson: nope, hangs again
[23:00] <YamakasY_> cjwatson: shouldn't it install the base packages first and than do a d-i pkgsel/upgrade select full-upgrade ?
[23:22] <YamakasY_> lol, preparing maanpages... maan is moon here ;
[23:23] <YamakasY_> cjwatson: nope, not going to work
[23:39] <YamakasY_> damn this is annoying
[23:46] <YamakasY_> shengyao: he!


[01:01] <Bashing-om> Thunderstorm .. me be gone down for the count .
[06:07] <ducasse> morning all!
[11:33] <BluesKaj> Hiyas all
[11:34] <ducasse> wb BluesKaj :)
[11:36] <BluesKaj> Hi ducasse
[11:37] <ducasse> everything well in your corner of the world?
[11:44] <ducasse> daftykins: you around, or still across the pond?
[11:46] <BluesKaj> he's still marked away
[11:47] <ducasse> didn't see that, sorry
[11:49] <BluesKaj> wow, suddenly bigtime cpu usage on FF
[11:49] <ducasse> BluesKaj: what os are you running on your rpi? i need to fix some stuff on mine, so i'm looking for a good base to work with.
[11:50] <BluesKaj> dunno which is worse FF with or without adblockers
[11:50] <ducasse> have you tried privoxy instead?
[11:53] <BluesKaj> ducasse, I'm running a modded raspbian-jessie, rather than their xfce/ldxe combo desktop, I'm using lxde exclusively.Also i moved  root dir to a fast 3.0 USB stick, which makes it much faster
[11:55] <ducasse> i can imagine, sd card isn't too quick. i mostly just need a good base for kodi, but want to also add a few other things for convenience.
[11:57] <BluesKaj> that way the sd card only has to boot the system, since my first one died after 8-9 formats trying out different OSs ...lot's od uders are now using ubuntu mate with root on usb
[11:57] <BluesKaj> of users
[11:59] <BluesKaj> thinking of switching to ubuntu-mate, but ai like the lxde deskrop, and kodi runs fine on my setup as an app
[12:04] <ducasse> i was thinking of setting kodi up to run as the wm, as most of the other stuff i want are just things i can handle via ssh. i'll look at both raspbian and ubuntu mate, though.
[12:10] <BluesKaj> ok ,, yakkety has some ppa packages that need testing ...bbiab
[13:10] <JanC> I don't think Kodi can run as a WM?
[13:19] <ducasse> JanC: iirc it can, i think that's how several of these media player distros are set up. there even used to be an entry in /usr/share/xsessions for it, don't know if that's still there.
[13:19] <ducasse> (i know it doesn't actually function as a wm, i was talking about autologin to an x session that just runs kodi fullscreen on startup)
[13:21] <JanC> right, that wouldn't make it a "WM", but more like a graphical shell or something
[13:22] <ducasse> i know, just bad choice of words.
[13:24] <BluesKaj> was looking into i3 tiling yesterday, but I'm too much of a gui user to bother with that
[13:24] <JanC> tiling is a form of GUI?
[13:24] <BluesKaj> I didn't say that
[13:24] <ducasse> i3 is really nice, especially on multi-monitor systems.
[13:25] <BluesKaj> it's mostly shells placed evenly on your screen depending on haow many you enable at any one time
[13:26] <JanC> ?
[13:26] <JanC> it works for all windows, not just shells...
[13:27] <BluesKaj> well I didn't see anything but shells in the exampleson the i3 site
[13:27] <ducasse> BluesKaj: unlike some tiling wms, i3 can also 'float' windows, and does so automatically for dialogs and such.
[13:29] <BluesKaj> at first i thought it would be neat, but still prefer switching with activities on xenial and yaketty or virtual desktops on trusty
[13:30] <JanC> https://i3wm.org/screenshots/i3-10.png ?
[13:31] <BluesKaj> what's with ? on every post, JanC?
[13:32] <ducasse> BluesKaj: you might like awesome, it can tag windows and create workspaces with all windows with a certain tag on the fly. i dislike the way most desktops handle multiple screens, personally.
[13:32] <JanC> it's a question mark, BluesKaj
[13:34] <BluesKaj> ducasse, well, I liked the virtual desktops on kde/plasma4 , but after 15.04 and plasma5 the devs regressed that feature without a blink and shoved activities down our throats, a much clunkier methos in my view
[13:34] <BluesKaj> method
[13:35] <BluesKaj> JanC, I'm surprised you didn't use one there :-)
[13:38] <ducasse> i've never really looked much at kde, so i can't comment. i like i3, though, lightweight and flexible. the people in #i3 are very helpful to those who rtfm :)
[13:38] <BluesKaj> ducasse, too bad they called it "awesome", such an overused word for all kinds non-awsome things these days
[13:38] <ducasse> ...and horrible to google :-/
[13:39] <BluesKaj> I'll bet
[13:41] <ducasse> what i didn't like about awesome was lua, but i understand why some people see it as a major feature. i don't want to learn a new language just for my wm, though.
[13:50] <BluesKaj> well, being a basic home user makes it unnecessary for me to run more "advanced" WMs etc, since i don't feel the need for them ...testing dev OSs can be difficult enough without adding unneeded apps to the mix :-)
[13:51] <ducasse> i view desktop environments as "adding unneeded apps to the mix" :)
[13:57] <BluesKaj> well, that's your choice, mine's just different, that's my view
[13:58] <ducasse> absolutely :) people's workflows are so individual, i'm happy there are so many choices available.
[14:04] <BluesKaj> I don't have a "workflow", mostly I just muck about :-)
[14:04] <ducasse> :)
[14:05] <ducasse> btw, virtual desktops on kde4 - was that workspaces as most wms implement them or something different?
[14:06] <BluesKaj> well, they could be workspaces if set up that way
[14:08] <BluesKaj> basically they just ordinary numbered desktops which can have different backgrounds and as many apps per as one wishes
[14:10] <ducasse> pretty much what other desktops/wms do. and this is missing from plasma?
[14:10] <BluesKaj> it's been deleted in plasma5
[14:12] <ducasse> odd, i'd think it's a pretty basic feature...
[14:14] <BluesKaj> according to the devs, it's a complex setup that wasn't renewed
[14:17] <ducasse> well, their choice i guess. earlier today there was a guy in #i3 who was running kde plasma, but with i3 instead of kwin. interesting setup.
[14:22]  * BluesKaj nods
[14:26] <ducasse> !info linux-image-generic yakkety
[14:26] <ubot5`> linux-image-generic (source: linux-meta): Generic Linux kernel image. In component main, is optional. Version <IP_ADDRESS>36.37 (yakkety), package size 2 kB, installed size 12 kB


[03:52] <govatent> test
[03:53] <maxolasersquad_h> success
[03:53] <govatent> My friend just loaded some new osx irc client on my computer. *ducks*
[03:54] <maxolasersquad_h> Have you played with Mac ports yet?
[03:54] <maxolasersquad_h> I don't know a lot about it, but it brings a lot of Linux/Unix apps to Mac.
[03:54] <maxolasersquad_h> brew is another cool toy.  It's scripts to download, patch, and compile lots of popular Unix apps.
[03:54] <govatent> i am loading it. although i honestly won't be using it much. i really do plan on loading ubuntu on this
[03:55] <govatent> I just have been busy and my friend is showing me all the cool osx toys i can use. i think tomorrow being holiday ill load ubuntu. it took me about 10 mins total to upgrade my hard drive. most the time was spent looking inside the case at how cool it was :P
[03:56] <maxolasersquad_h> irssi is available on OSX as well.
[03:56] <govatent> yea i saw
[03:56] <govatent> i was going to load it
[03:56] <govatent> i spent most of my day working.
[03:56] <govatent> this is the first time today i am sitting down to actually just relax on my pc
[03:57] <govatent> i def will load irssi
[03:57] <govatent> this lime chat thing is interesting though
[07:56] <govatent> itnet7: ping
[08:10] <bluebomber> I do not accept those terms.
[08:10] <bluebomber> Therefore my words may not be logged.
[23:42] <bluebomber> Happy Thanksgiving, Florida LoCo!


[00:00] <jelmer> yep
[00:00] <lifeless> jelmer: can you document what you need from the hook? I can likely do the bzr side trivially
[00:01] <jelmer> https://bugs.launchpad.net/bzr/+bug/186422
[00:01] <ubotu> Launchpad bug 186422 in bzr "Ability to modify the tree from a pre-commit hook" [Wishlist,Triaged]
[00:02] <lifeless> is in-python sufficient
[00:02] <jelmer> the summary should probably be changed to "Add a start-commit hook"
[00:02] <jelmer> lifeless: yes
[00:03] <lifeless> k
[00:10] <lucasvo> hi
[00:10] <lucasvo> I'm having issues with bzr. It doesn't want to work if locales isn't set correctly...
[00:10] <lucasvo> see: http://paste.ubuntu-nl.org/57277/
[00:10] <lifeless> thats correct; you can set LANG=C etc if you have really broken locales on your machine
[00:11] <lifeless> but to get the correct i18n filename we need locale information
[00:11] <jelmer> shouldn't it be "locale en_US.UTF-8" rather than "locale enUS.UTF-8" ?
[00:11] <lucasvo> lifeless: I am using gnome terminal with an ssh session
[00:12] <lucasvo> if I set  encoding to western in gnome terminal it works
[00:12] <lucasvo> I usually have it on utf-8
[00:12] <lifeless> jelmer: yeah, I think so
[00:12] <lifeless> lucasvo: as long as its set to a valid locale bzr will work fine
[00:12] <lucasvo> so that is not a bug.
[00:13] <lifeless> lucasvo: we have to recreate the files you commit, with their names, on different operating systems
[00:13] <lifeless> lucasvo: some (mac os X) require unicode paths.
[00:13] <lifeless> lucasvo: so we have to know the actual unicode path of each file we read from disk
[00:14] <lucasvo> ok
[00:14] <LaserJock> would it be possible to get bzr-svn in the bzr LP PPA?
[00:14] <lifeless> lucasvo: and to do that we need to know if you are using 8859-{1,3,...} or utf8 or utf16 or utf7 or whatever
[00:14] <jelmer> LaserJock: it's already there
[00:15] <lifeless> lucasvo: so yes, it is a _requirement_ that your locale be set up accurately for bzr to work. if its complaining, you have a bug in your locale setup.
[00:15] <LaserJock> jelmer: you sure? I don't have it here
[00:15] <jelmer> a traceback shouldn't be necessary for this error though
[00:16] <LaserJock> jelmer: ah, I see the problem, there is a version in -backports that overrides the one in the PPA
[00:16] <jelmer> LaserJock: Yes, it's only in feistry, gutsy and hardy though
[00:16] <lifeless> jelmer: its being thrown from python's core
[00:17] <lifeless> jelmer: we could catch and pretty it up I guess
[00:17] <LaserJock> jelmer: gutsy-packports has 0.4.7-1~gutsy1 and the PPA has 0.4.6-1~bazaar1~gutsy1
[00:17] <lucasvo> ok, well, I gotta move over to the ubuntu channel and try my luck there. Thanks for the help guys.
[00:18] <LaserJock> dang, even if you put in 0.4.7 it'd be a lower version than -backports :/
[00:20] <jelmer> LaserJock: what exactly is so problematic about that? in the end, you have the latest version
[00:20] <jelmer> lifeless: yeah, that would make sen
[00:20] <jelmer> se
[00:20] <LaserJock> umm, because I either can't upgrade bzr or I have to remove bzr-svn
[00:21] <LaserJock> not sure why bzr-svn has such a tight dependency, but I'm assuming the maintainer knew what they were doing
[00:21] <jelmer> LaserJock: bzr-svn gets very easily broken by bzr API changes
[00:21] <LaserJock> fun
[00:21] <LaserJock> so right now I'm not updating bzr/bzr-tools so I don't remove bzr-svn
[00:22] <jelmer> LaserJock: ah, that bit is unrelated to the packaging
[00:22] <jelmer> I simply haven't released bzr-svn 0.4.8 compatible with bzr 1.2 yet
[00:22] <lifeless> tsk tsk
[00:22] <lifeless> :)
[00:22] <LaserJock> ah
[00:23]  * LaserJock tries to resist a "that's why git is nice" comment ;-)
[00:23] <LaserJock> but instead I'll wait patiently
[00:29] <LaserJock> although, I'm using bzr-svn because it seems a lot better than git-svn
[00:30] <LaserJock> so I should just hold my tongue
[00:38] <jelmer> Sorry for not being quicker with this
[00:38] <jelmer> Although I don't see why it would be an immediate problem
[00:40] <jelmer> LaserJock: git-svn doesn't have the same level of integration that bzr-svn has so it doesn't use the same range of the API
[00:41] <jelmer> LaserJock: if we would make the dependencies of bzr-svn less tight bzr-svn would probably break every other upgrade of bzr
[00:42] <LaserJock> jelmer: right, I figured it must be something similar
[00:42] <LaserJock> I just wondered if it was a known thing as I've been unable to upgrade bzr for something like a week or so
[00:42] <LaserJock> but it seems that really gutsy-backports is more to blame
[00:43] <jelmer> LaserJock: why?
[00:44] <LaserJock> because -backports has 0.4.7
[00:44] <LaserJock> I was thinking that the bzr PPA didn't have bzr-svn in it
[00:44] <jelmer> yes, but what's problematic about backports having 0.4.7?
[00:44] <lifeless> is 0.4.7 released ?
[00:45] <jelmer> yes
[00:45] <jelmer> 0.4.7 is compatible with bzr 1.1
[00:45] <lifeless> LaserJock: actually I think aptitude is to blame; if bzr's ppa has a matching bzr-svn, aptitude should be able to resolve to install that over backports; unless you've got pinning set
[00:45] <jelmer> lifeless: ppa doesn't have a more recent version than backports
[00:45] <lifeless> jelmer: I know that
[00:45] <LaserJock> jelmer: it's just that it means I'm getting bzr from bzr PPA but not bzr-svn
[00:46] <lifeless> jelmer: I didn't say more recent; I said matching.
[00:46] <jelmer> lifeless: There is no matching bzr-svn for the latest bzr in PPA
[00:46] <lifeless> jelmer: there we go :)
[00:46] <lifeless> LaserJock: so its really just that bzr-svn has not recently this week yet
[00:47] <jelmer> lifeless: Right, but I fail to see how LaserJock is blaming that on backports rather than on me :-)
[00:47] <LaserJock> well, I'm just saying it's nice to get the whole set from the same repo
[00:47] <LaserJock> rather than bits from one and bits from another
[00:48] <LaserJock> but of course, in this case, I guess I'd be in the same situation even if I didn't have -backports
[00:51] <jelmer> the version of bzr-svn in backports is newer
[00:51] <jelmer> ~bzr comes after ~backports
[00:52] <jelmer> hmm, no that's not right..
[00:52]  * jelmer gets some sleep before he says more stupid things
[00:52] <LaserJock> -backports uses ~gutsy
[00:52] <LaserJock> wasn't stupid
[00:52] <LaserJock> versioning sucks ;-)
[01:03]  * lifeless waits for 11K unit tests.
[01:03] <lifeless> poolie: if you are touching logging again; I would like to remove logging to disk entirely for tests. Its pointless to write a log when we can introspect it in python; less disk io is good.
[02:10] <ubotu> New bug: #195282 in bzr-loom "new revision spec needed - below:" [High,Triaged] https://launchpad.net/bugs/195282
[02:13] <lifeless> bob2: ping
[02:14] <bob2> hi
[02:15] <lifeless> hows your nicer-error patch coming? I just got forcibly reminded of it :)
[02:26] <poolie> lifeless: i'm not at present but will try to remember that
[02:31] <poolie> lifeless: quick call sometime
[02:31]  * igc food
[02:31] <lifeless> poolie: sure; now ?
[02:31] <poolie> sure
[02:32] <lifeless> please find my house phone for me
[02:32] <poolie> lol
[02:33] <lifeless> damn charge
[02:35] <fullermd> Holy crud.
[02:35] <fullermd> I just watched that talk Bryan Cantrill did at Google about dtrace.  That's insane how deep it gets its fingers into python.
[02:43] <keir> so, is loom headed for core? seems like incredibly useful functionality, and is something the other systems don't do as well.
[03:12] <lifeless> keir: well, I think it will get smoothly integrated; I don't know that it belongs in core
[03:12] <lifeless> bob2: hows your nicer-error patch coming? I just got forcibly reminded of it :)
[03:12] <poolie> thumper: hi?
[03:16] <bob2> lifeless: updating tests.blackbox atm
[03:17] <lifeless> bob2: cool
[03:18] <bob2> lifeless: ooi, is the arg ordering of assertEqual('literal', var) deliberate?
[03:18] <lifeless> bob2: our convention is expected, actual
[03:18] <lifeless> so 'literal' is what we want.
[03:18] <bob2> lifeless: right
[03:35] <thumper> poolie: hi
[05:17] <lifeless> bbiab, late lunch time
[06:59] <lifeless> spiv: ping
[07:00] <lifeless> spiv: is urlutils.escape(user_supplied_url) the right way to get a ascii url ?
[07:09] <jml> did 1.2 change things about when Branches let go of http connections?
[07:11] <lifeless> it shouldn't have; why ?
[07:11] <lifeless> you may be seeing pycurl vs non pycurl ?
[07:13] <jml> maybe
[07:13] <jml> there's no pycurl in the stack
[07:13] <lifeless> what are you seeing happen ?
[07:14] <jml> lifeless: the test suite is complaining about how there are sockets in the garbage after certain of our tests that do stuff with http
[07:14] <lifeless> interesting
[07:14] <lifeless> you may have found a bug I guess?
[07:14] <jml> specifically, a socket._fileobject
[07:14] <lifeless> I'd need to look closely in the log; you can do that:O - look for stuff from vila
[07:22] <jml> it's possible that we're holding on to a reference too long or that the gc is doing something stupid
[07:22] <lifeless> try a gc collect?
[07:23] <jml> or both
[07:23] <jml> my money's on both
[07:23] <jml> s/the gc/the calls to the gc/
[07:23] <lifeless> one thing that is likely is that persistent connections are better
[07:23] <lifeless> that is, that we won't drop them after every call, I'm sure vila was working on that
[07:28] <lifeless> yay:
[07:28] <lifeless>  du -sh ../thallow/
[07:28] <lifeless> 72K     ../thallow/
[07:30] <lifeless> thats a shallow branch
[07:40] <lifeless> wow slow though
[07:40] <lifeless> 1m24 to create over sftp
[08:31]  * igc dinner
[08:33] <lifeless> ok, bzr push is whackily slow ; that or too much data.
[08:46] <lifeless> ah link fuggage
[09:01] <ubotu> New bug: #195360 in bzr "bzrtools 1.2 in feisty ppa: broken depends on bzr" [Undecided,New] https://launchpad.net/bugs/195360
[09:26] <lifeless> muhahaha it works: ~/source/baz/shallow-branch/bzr log -r -1 http://people.ubuntu.com/~robertc/test-shallow/3
[09:26] <lifeless> using http://people.ubuntu.com/~robertc/baz2.0/shallow-branch
[09:29]  * bob2 branches
[09:39] <bob2> oh that's what all the stackable thing was about
[09:39] <jrydberg_> hi guys
[09:49] <lifeless> bob2: extremely small branches
[09:54] <lifeless> http://people.ubuntu.com/~robertc/test-shallow/4 has a commit in it
[09:54] <lifeless> total repo size - 56K
[09:54] <lifeless>  du -sh public_html/test-shallow/4/.bzr/repository
[09:54] <lifeless> 56K     public_html/test-shallow/4/.bzr/repository
[09:55] <lifeless> bob2: ^
[10:18] <bob2> that's quite cool
[10:18] <Prodoc> Good mornin'
[10:19] <Prodoc> I'm trying to install the Bazaar Eclipse plugin using the following instructions: http://bazaar-vcs.org/BzrEclipse/Installation
[10:21] <Prodoc> After selecting the latest version it will try to download the plugin but I get an error that an exception occurred downloading the .jar file
[10:21] <bob2> lifeless: is that bluesky or 1.3 material?
[10:21] <Prodoc> it's only after a couple of retry's that it appears to work
[10:21] <Prodoc> is this a known issue?
[10:23] <lifeless> bob2: 1.3 I hope
[10:36] <mrflip> Hello, I am just moving over to bzr.  Here is my question.  I'm working on a website, and the project is the main dir site/ with subdirectories srcassets/ (original copies of graphics, etc), meta/ (design notes), utils/ (tools), web/ (the actual site).
[10:36] <mrflip> When I deploy, I want to only push site/web/ to the server, which was easy with svn
[10:36] <mrflip> how do I do this with bzr?
[10:40] <bob2> bzr split would let you split that dir into it's own branch
[10:40] <bob2> or you could just not import the others into bzr
[10:40] <bob2> but bzr doesn't generally work like svn, where each dir is a nested checkout
[10:43] <mrflip> (reading about bzr split now)...  I definitely need all of those dirs versioned... and I need to have (somehow or another) site/* on my dev machine and only web/ on the server.
[10:57] <mrflip> so I think I have to move web/ into its own repos, which I can live with... it's tiny compared to srcassets, which I can't afford to pull each time I deploy.
[10:57] <mrflip> Thanks for the help bob2
[10:58] <bob2> doesn't have to be it's own repository, just branch
[10:58] <bob2> well, depending on how you do it I guess
[11:25] <ubotu> New bug: #195397 in bzr "Bazaar does not follow the Freedesktop XDG Base Directory Specification" [Undecided,New] https://launchpad.net/bugs/195397
[13:59] <adwi2> jelmer: Could the ability of bzr to use a SVN repository be used to create a branch that used a SVN repository that one could push back into another SVN repository with bzr-svn?
[14:04] <jelmer> awilkins: Yes
[14:04] <jelmer> it wouldn't create a copy of the original svn branch in the other svn repository though
[14:05] <jelmer> at least, it won't look like a copy to svn
[14:05] <jelmer> it will look like one to bzr
[14:05] <awilkins> jelmer: What I essentially want is what SVK does but using bzr, I suppose
[14:06] <awilkins> I have an Eclipse ticket plugin that syncs to SVN
[14:06] <awilkins> But I'm rapidly leaning toward BZR for the other version control aspects of this project because the branch / merge requirements are rigourous and I'm probably going to end up re-inventing merge tracking if I stick to SVN
[14:07] <awilkins> Alas, the ticket plugin is closed-source (what a dumbass I was to recommend that one...)_
[14:07] <awilkins> And doesn't use the geenric Eclipse team sync, as far as I can tell.
[14:08] <awilkins> Ah, I shall just have to experiment.
[14:08] <awilkins> I shall be using BZR for dev and testing just because it's so much faster than SVN :-)
[14:08] <awilkins> It'll save me more time tha it'll take to re-roll things in SVN if I have to.
[14:43] <jelmer> re
[14:43] <jelmer> awilkins: yes, bzr-svn is usable in a svk-like style
[14:44] <jelmer> that's what it was originally designed for
[14:49] <xif> is branching and merging with Bazaar less of a headache than it is with Subversion?
[14:50] <edreamleo> Hello All, this is Edward Ream from the Leo editor
[14:51] <Peng> xif: Yes.
[14:52] <Peng> xif: Any modern VCS, including bzr, tracks which revisions have already been merged.
[14:52] <Peng> xif: Of course, that makes cherrypicking a pain in most of them...
[14:53] <edreamleo> Is this the place to ask total newbie questions?
[14:53] <jdong> edreamleo: any bzr related question :)
[14:53] <Peng> edreamleo: Sure.
[14:53] <jdong> or any question you'd want a bzr related answer to :D
[14:53] <edreamleo> ;-)
[14:53] <edreamleo> First, let me say I'm excited about moving Leo to bzr.
[14:54] <edreamleo> It will enable much closer cooperation between Leo and IPython.
[14:54] <edreamleo> I have been able to get bzr working on XP...
[14:54] <edreamleo> But am having trouble connecting on Linux
[14:54] <xif> Peng: if I plan to do lots of branching and merging, would you recommend Bazaar or anything else?
[14:55] <edreamleo> I suspect the problem is easily fixed, but I have no idea how to fix it.
[14:55] <jdong> xif: I'd definitely recommend some distributed VCS with a 3-way merge algorithm. bzr's defnitely nice for it but it's not the only one
[14:55] <jdong> edreamleo: can you describe more what kind of trouble you're having when connecting?
[14:55] <edreamleo> Sure.
[14:56] <Peng> xif: Sure, I'd recommend bzr or anything else that's not cvs or svn. :P
[14:56] <edreamleo> I have pull defined as a bzr alias. One moment while I look it up...
[14:56] <xif> jdong: yeah, I'm still contemplating whether I want hg, darcs, or bzr
[14:57] <jdong> xif: well I think between those 3, the answer all of us in #bzr will give you is obvious ;-)
[14:57] <xif> from what I've seen, hg has better performance, bzr has more features
[14:57] <jdong> xif: I don't think that's entirely true anymore
[14:57] <xif> ("seen" = "read in online reviews" :-)
[14:57] <jdong> xif: recent versions of bzr come quite close in performance, storage size, etc
[14:57] <jdong> xif: it is true that older versions of bzr have horrendous performance compared to hg
[14:58] <xif> right, before you rewrote some of the Python modules in Pyrex
[14:58] <xif> yeah, I think I'll check bzr out first
[14:58] <Peng> And made other improvements.
[14:58] <xif> Peng: such as?
[14:58] <jdong> xif: and changed on-disk storage format, etc
[14:58] <xif> oh, right.
[14:58] <Peng> xif: General improvement of the code?
[14:58] <xif> now your storage format is git-like I hear.
[14:58] <Peng> Sorta, yeah.
[14:59] <jdong> xif: there's far too many performance tweaks for us to list one by one short of reproducing the changelogs
[14:59] <Peng> For me, it's really a toss-up between bzr and hg, but I haven't used anything else (other than svn).
[14:59] <xif> not sure how darcs fits in the comparison, doesn't look like it can compete with hg or bzr on either performance or features.
[15:00] <jdong> yeah, my unbiased toss-up would be between bzr, hg, and git
[15:00] <Peng> I haven't looked into git much.
[15:00] <xif> Peng: aren't there features you miss on hg vs. bzr or vice-versa?
[15:00] <edreamleo> Ooops.  pull is not an alias
[15:00] <Peng> xif: Yeah.
[15:00] <jdong> xif: bzr's vast array of plugins... seems like there's more of them than for hg
[15:00] <xif> I prefer hg and bzr (or even darcs) because Python and Haskell are nice languages.
[15:01] <jdong> xif: also, hg is horrible without its smart server IMO
[15:01] <jdong> xif: which is a problem if you don't have the access to install hg on the remote system
[15:01] <Peng> Indeed.
[15:01] <jdong> bzr's non-smart-server performance is quite good with packs
[15:02] <xif> jdong: so if I want to stay lightweight (e.g. using the VCS to manage my own project) bzr might be a better choice?
[15:02] <Peng> And even if the performance was poorer, at least it supports dumb servers fully.
[15:02] <edreamleo> Ok, now I remember, I did a bzr co, not a bzr pull
[15:02] <Peng> (Well, it is poor*er*, just not that much worse.)
[15:02] <edreamleo> co *is* an alias
[15:02] <Peng> If I was smarter, I'd work on SFTP support for hg...
[15:02] <jdong> xif: I'd believe so.
[15:03] <jdong> Peng: last time I tried dumb HTTP, it didn't work well either
[15:03] <xif> OK, thanks.
[15:03] <jdong> Peng: and the response I got upstream was "well it's outdated, set up a CGI"
[15:03] <Peng> jdong: Heh.
[15:03] <Peng> jdong: I didn't know it was outdated.
[15:03] <Peng> jdong: I don't know how good it is now.
[15:04] <Peng> jdong: I've always had the impression that it doesn't get quite enough love, but I don't know whether it's still good enough.
[15:04] <jdong> Peng: well apparently thy are considering oldhttp to be obsolete
[15:04] <edreamleo> co is defined as co=checkout<EMAIL_ADDRESS>[15:04] <edreamleo> now when I do a bzr co I get a Python traceback
[15:04] <LeoNerd> Who keeps highlighting me? :P
[15:04] <jdong> Peng: but I was surprised that they do not support SFTP
[15:05] <Peng> edreamleo: "co" is a builtin alias.
[15:05] <edreamleo> Oh!
[15:05] <Peng> edreamleo: (for "checkout")
[15:05] <Peng> jdong: I asked once, and mpm mentioned that he wouldn't want to add a dependency on Paramiko or whatever.
[15:05] <edreamleo> Right, that's what I was trying to do :-)
[15:06] <edreamleo> Trust a newbie to find the ways to crash a program.
[15:06] <Peng> :)
[15:06] <edreamleo> Ok, let me pick another name for co and see what happens...
[15:06] <Peng> edreamleo: Are you using bzr 1.2? If not, upgrade; if so, file a bug.
[15:06] <Peng> edreamleo: You shouldn't need to co the same branch so often that you need an alias for it...
[15:07] <jdong> edreamleo: also, why is the alias necessary? Do you really checkout that branch enough times that you don't want to type it out?
[15:07] <jdong> Peng: we're trampling over each other :D
[15:07] <edreamleo> I'm using bzr 0.90.0
[15:08] <jdong> edreamleo: I highly recommend upgrading to the latest
[15:08] <edreamleo> Iirc I used apt-get (or maybe the synaptic package manage) to get the latest version
[15:08] <jdong> edreamleo: what distribution?
[15:08] <edreamleo> Ubuntu, Gutsy Gibbon
[15:09] <jdong> edreamleo: you can either (1) enable backports, or (2) use the bzr PPA
[15:09] <jdong> although I'm the maintainer of backports, I recommend #2
[15:09] <edreamleo> What's the bzr PPA?
[15:09] <jdong> I've got hundreds of requests for updates and I can't keep backports as up to date as fast as the bzr PPA
[15:09] <Peng> edreamleo: Bzr's official apt repo thingamabob. https://launchpad.net/~bzr/+archive
[15:09] <jdong> edreamleo: it's an APT repository maintained by the bzr developers
[15:10] <Peng> (Though they do have a habit of screwing up bzrtools's dependencies... :P )
[15:10] <jdong> edreamleo: it contains the latest bzr packages, plus minus a few days ;-)
[15:10] <jdong> Peng: hehe well I'm guilty of doing the same
[15:10] <Peng> I'm hungry.
[15:10] <jdong> backports is currently on bzr 1.1, though I do intend on updating to bzr 1.2 once Hardy's entire stack is ready
[15:11] <jdong> but backports gives you other cool new packages too ;-)
[15:12] <edreamleo> Ok, I see bzr-1.2.-1~bazaar2~gutsy1 at the url you gave.
[15:12] <edreamleo> Are there installation instructions?
[15:12] <jdong> edreamleo: the page should have such instructions
[15:13] <jdong> edreamleo: pick Gutsy from the dropdown....
[15:13] <jdong> edreamleo: add the "deb" line to Software Sources Manager in system->admin
[15:13] <jdong> the deb-src line is optional
[15:17] <edreamleo> I did system->admin->software soucrces...
[15:18] <edreamleo> Now I see a dialog, with 5 tabs...
[15:18] <edreamleo> What's the "deb" line?
[15:18] <jdong> elmo: click Third Party Software, then Add
[15:19] <jdong> grr wrong person
[15:19] <jdong> he doesn't need to know how to add sources lines... :)
[15:19] <edreamleo> Heh, heh,
[15:19] <jdong> in the dialog that pops up, type deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
[15:22] <edreamleo> djong: ok, that seemed to work.
[15:22] <edreamleo> Do I do an apt-get now?  If so, what would I do exactly?
[15:24] <edreamleo> Never mind, the latest version now shows up in the package manager.  Doing an update now.
[15:24] <jdong> edreamleo: you can pop up update manager or synaptic, check and apply for new updates
[15:29] <edreamleo> Ok, we have progress...
[15:29] <edreamleo> Now we have bzr 1.2.0
[15:30] <edreamleo> And now bzr co (still with the confusing co alias) doesn't crash, it says...
[15:30] <jdong> edreamleo: run bzr reconcile and bzr upgrade on your existing branches to bring them to the new faster packs format
[15:30] <edreamleo> ssh: connect to host bazaar.launchpad prt 22: connection refused
[15:31] <edreamleo> Ok.  bzr reconcile and bzr upgrade made what seem like happy sounds.
[15:32] <jdong> edreamleo: bazaar.launchpad.net
[15:32] <jdong> unless you're one of those lucky people on the .net domain :D
[15:34] <edreamle1> Drat: something weird happened to gaim.
[15:36] <edreamle1> gdong: I'll check the url and change the co alias to something else...
[15:36] <jdong> edreamleo: yeah the URL is the only problem I see
[15:41] <Peng> Also, again, why are you checking out the same thing so often that you need an alias?
[15:42] <dato> Peng: bzr provides the alias
[15:43] <edreamle1> Peng: my memory isn't the best, so I like to leave bread crumbs around wherever possible.
[15:43] <edreamle1> Success: the bad url was the problem
[15:43] <jdong> edreamleo: you'd probably want to alias your branch location as a branch
[15:43] <jdong> rather than alias the entire co command to one branch
[15:43] <edreamle1> Btw, bzr co worked just fine, even with co as an alias
[15:43] <jdong> edreamleo: after the initial checkout, you never have to type the branch URL again
[15:43] <jdong> just "bzr up, bzr commit, bzr log" all work inside the branch
[15:44] <jdong> so I don't see the point of making the co=checkout branch alias.
[15:44] <edreamle1> jdong: you must be right :-)
[15:45] <edreamle1> jdong: but what if I wanted to check out another sandbox?  Wouldn't I need to know the url?
[15:46] <Peng> Is it possbile to checkout or branch a checkout?
[15:47] <jdong> Peng: yes
[15:47] <jdong> edreamle1: indeed, but you can branch from your existing checkout
[15:47] <jdong> edreamle1: or type "bzr info" inside the branch to figure out what URL it was from
[15:47] <edreamle1> jdong: Thanks for these tips.
[15:47] <edreamle1> Clearly, I don't understand bzr branches yet...
[15:49] <edreamle1> Anyway, many thanks for your help.  I'm unstuck.
[18:00] <Odd_Bloke> Does anyone know anything about http://article.gmane.org/gmane.emacs.devel/89117 ?
[18:02] <Peng> Odd_Bloke: No. It's been confirmed as true, but there's still no information.
[18:03] <Peng> Odd_Bloke: Ask Mark Shuttleworth or poolie?
[18:03]  * Peng shrugs.
[18:03] <Peng> Ok.
[18:03] <Odd_Bloke> OK, it's the confirmation that I was looking for.
[18:04] <Odd_Bloke> Peng: Thanks. :)
[18:04] <Peng> The confirmation isn't very useful when I have no idea what it *means*.
[18:05] <Peng> RMS is replacing poolie as lead developer? Mark Shuttleworth paid them $10,000 to get "GNU" stamped on bzr?
[18:05] <Peng> Of course, I could do research and see what exactly it usually means, but I'm busy reading about Star Trek.
[18:06] <abentley> Peng: It means nothing in terms of personnel.  It means that GNU will endorse bzr, use it for their own projects, and update Savannah to support it.
[18:07] <Toksyuryel> awesome!
[18:07] <Peng> Right. It's just marketing.
[18:07] <Peng> I forgot.
[18:07] <abentley> It does mean that there are certain rules we must follow.  I forget the details at the moment.
[18:07] <Toksyuryel> yay bzr ^_^
[18:07] <Peng> You said that earlier. :P
[18:08] <Toksyuryel> What does it mean with regards to launchpad?
[18:08] <abentley> Well, if you're gonna get snotty, I don't have to say anything...
[18:08] <johnny> Toksyuryel, nothing afaics
[18:09] <Odd_Bloke> The list of things that have to be complied with is at http://www.gnu.org/prep/maintain/
[18:09] <Peng> I'm only being a tiny bit snotty.
[18:09] <Peng> And that's non-sarcastic.
[18:09] <Peng> I completely forgot that you explained it earlier.
[18:10] <Peng> Odd_Bloke: Yikes, 100K of ASCII?
[18:10] <diocles> Odd_Bloke: There's also the GNU Coding Standards, and maybe a few other documents.
[18:11] <Toksyuryel> it's not really fair to call it "just marketing", I think that bzr being endorsed by GNU is a pretty damn big deal
[18:13]  * Toksyuryel thinks that it shows just how good bzr is, that they would choose it over other things out there :) it also grants a lot of additional credibility to the project
[18:13] <diocles> Peng: http://www.gnu.org/help/evaluation.html#whatmeans would seem to answer your questions, but I realise Star Trek is important.
[18:15] <Toksyuryel> Stargate is better~ *hides*
[18:15] <Peng> Toksyuryel: What about Firefly?
[18:15] <johnny> they're all dumb :)
[18:15] <abentley> I'm not aware of any direct effects on Launchpad, though it does turn Savannah into a Launchpad competitor.
[18:15] <johnny> that should solve it..
[18:15] <johnny> barely..
[18:15] <johnny> a very very poor one
[18:15] <Toksyuryel> I never watched firefly, I heard good things about it though
[18:16] <Toksyuryel> abentley: my concern is more related to the issue of the fact it's not a free/open project (yet)
[18:16] <Peng> Toksyuryel: Same here. I'm afraid that whenever I do finally watch it, it won't live up to my expectations thanks to the hype. :\
[18:16] <johnny> Toksyuryel, has no effect on bzr
[18:16] <Peng> diocles: Thanks. I have 550 tabs open!
[18:17] <Toksyuryel> mmkay
[18:17] <johnny> launchpad is the only reason i'm considering using bzr seriously
[18:17] <johnny> which is upsetting, since it's not free
[18:17] <Toksyuryel> there's a lot of great things about bzr completely unrelated to launchpad...
[18:17] <johnny> like?
[18:18] <diocles> johnny: What are you comparing bzr with?
[18:18]  * Toksyuryel personally considers it to be the best vcs of them all, period ^_^
[18:18] <Peng> The GNU documents mentions using an @gnu.org address for bugs, and hosting on gnu.org. What is bzr going to do?
[18:18] <johnny> i mean above and beyond git,mtn,hg
[18:18] <johnny> Peng, the docs mention that
[18:18] <johnny> there's notice you put on there
[18:19] <Toksyuryel> bzr is way way better than git and hg. not sure what mtn is but bzr is probably better than that too :)
[18:19] <johnny> how so?
[18:19] <johnny> how is it better than git or hg?
[18:19] <johnny> other than being much easier to use than git :)
[18:19] <Peng> Toksyuryel: Monotone.
[18:19] <johnny> hg is not really in my consideration tho
[18:19] <Toksyuryel> there are documents on the website that do a way better job explaining than I ever could
[18:19] <Peng> Toksyuryel: Kinda inspired git and hg, but not very popular. Slow.
[18:19] <johnny> i've read them Toksyuryel
[18:19] <Toksyuryel> eww, ok, bzr is definitely better than that XD
[18:20] <Peng> Toksyuryel: Gaim/Pidgin used it, last I checked.
[18:20] <johnny> and i wasn't convinced
[18:20] <Toksyuryel> well I was
[18:20] <Peng> johnny: Why not hg?
[18:20] <johnny> bzr has launchpad, hg doesn't bzr has the potential to be tested across 1000s of projects
[18:20]  * Toksyuryel is even considering using it to version his entire system, but thinks he may need a bigger hard drive for that
[18:20] <johnny> hg has a few, and moz..
[18:21] <johnny> but bzr will always have the edge due to launchpad
[18:21] <Peng> Toksyuryel: Don't do that.
[18:21] <johnny> since it mirrors everything in bzr
[18:21] <Peng> Toksyuryel: I do; it sucks.
[18:21] <johnny> Toksyuryel, bzr doesn't handle privs
[18:21] <johnny> at least not last i heard..
[18:21] <Toksyuryel> ohh
[18:21] <Toksyuryel> yeah that could be tricky...
[18:21] <Peng> Oh, that's true.
[18:22] <johnny> you need seperate sfotware
[18:22] <diocles> johnny: The other advantage over git might be Windows support. But that never bothered me.
[18:22] <james_w> johnny: there will hopefully be a plugin to handle that at some point.
[18:22] <Peng> None of the popular VCSes handle more than the exec bit.
[18:22] <johnny> yes
[18:22] <Peng> I don't version my whole system, just my homedir.
[18:22] <johnny> Pe is correct
[18:22] <Peng> And I'm reducing that today.
[18:22] <james_w> for now you can check out etckeeper, which there is a bzr plugin for.
[18:22] <johnny> err Peng is correct
[18:22]  * Toksyuryel has never considered windows support to be a feature, rather finds it to distract people from the features that matter
[18:23] <johnny> i'm concerned about windows support
[18:23] <johnny> but git is mostly used by the hardc0re
[18:23] <johnny> and the speedsfreaks
[18:23] <Peng> Toksyuryel: (Especially since Windows support is a rough spot in both bzr and hg; at least case-insensitive file system stuff. Cough.)
[18:23] <diocles> I use git.
[18:23] <Toksyuryel> don't the benchmarks say bzr is faster than git?
[18:23] <johnny> no
[18:23] <johnny> try mirring the kernel and proving it
[18:23] <johnny> with full changes
[18:23] <Toksyuryel> dependant on the size of the project of course; they are working on that part :)
[18:23] <johnny> or moz for that matter
[18:24]  * diocles tries to work out whether he's "hardc0re" or a "speedsfreak".
[18:24] <johnny> Toksyuryel, i know what they are working on :)
[18:24] <johnny> i really really like in mtn how revisions are not dependent on a branch
[18:24] <johnny> a branch is just a cert on a revision
[18:24] <Toksyuryel> Peng: I find windows support to be a waste of time and resources that could better be spent improving the software =/
[18:24] <johnny> Toksyuryel, you're wrong
[18:24] <johnny> more devs come because of windows
[18:25] <johnny> and even more users come
[18:25] <Toksyuryel> they should switch to a real OS =/
[18:25] <johnny> and that is?
[18:25] <johnny> does it run autocad? or photoshop? :)
[18:25] <johnny> this is sad for me to have to say this :(
[18:25] <johnny> but it's true
[18:25] <Toksyuryel> that's not the fault of the OS
[18:26] <johnny> sure, but the OS doesn't mean much if it can't run apps
[18:26] <Toksyuryel> and photoshop is easily replaced besides
[18:26] <johnny> no it isn't
[18:26] <jdong> Toksyuryel: no it's not...
[18:26] <johnny> google is spending alot of money on wine support now tho
[18:26] <Toksyuryel> GIMP, inkscape, probably some other stuff out there too
[18:26] <johnny> nope
[18:26] <johnny> they are all weak
[18:26] <jdong> Toksyuryel: you've got to be kidding
[18:26] <Odd_Bloke> Guys, arguing about why people should switch from Windows in #bzr is kinda OT...
[18:26]  * Toksyuryel stops then
[18:26] <jdong> Toksyuryel: that's like saying gwbasic roughly replaces C
[18:27] <jdong> but at any rate, if you don't care about Windows, then windows support is not something to look at in your VCS of choice :)
[18:27] <johnny> i've used linux only on the desktop for 5 years now Toksyuryel .. and even i can't say those apps have proper replacements :)
[18:28] <jdong> likewise. I've used Linux for a few years and developed on it for a few less than that
[18:28] <jdong> I can say FOR ME I've found Linux replacements
[18:29] <jdong> but I can't say for every application there is a Linux replacement
[18:29] <diocles> Tut, tut, it's GNU/Linux. Don't you know bzr is a GNU project now?
[18:29] <jdong> that's completely nonsense
[18:29] <jdong> diocles: no it's not, I use a BSD userland ;-)
[18:29] <Peng> Who needs Photoshop; I can write JPEG by hand. With a magnet, up hill in the snow all three ways.
[18:29] <johnny> lol
[18:29] <diocles> jdong: I bet you don't. :)
[18:29] <jdong> diocles: how do you know? :)
[18:29] <johnny> it is possible tho
[18:30] <johnny> or the opposite ..
[18:30] <diocles> jdong: Because Ubuntu doesn't have a BSD port.
[18:30] <jdong> diocles: and that's where you start assuming :)
[18:31] <jdong> but ANYWAY, still OT :)
[18:31] <johnny> unless bzr won't run on that combination.. :)
[18:31] <jdong> johnny: A few of us here have independently got bzr running on IronPython
[18:31] <Toksyuryel> bzr ought to run on any POSIX-compliant system... I think
[18:32] <jdong> Toksyuryel: more than that :)
[18:32]  * jdong feels sorry for all the bzr devs who will be reading this scrollback
[18:33] <johnny> jdong, but then the boycottnovell guys will come after you !
[18:33] <johnny> lol
[18:34] <abentley> johnny: Bzr handles only the execute bit, not other privs.
[18:34] <johnny> abentley, i know :)
[18:34] <abentley> Oh, I thought you didn't because of how you phrased it.
[18:35] <johnny> supporting windows is difficult for sure :(
[18:35] <Toksyuryel> hmmm... The requested URL /bzr.1.2/en/release-notes/NEWS.html was not found on this server.
[18:37] <abentley> johnny: In most DVCses, branches link to revisions, and the revisions themselves are not tied to any particular branch.
[18:38] <johnny> maybe it's not as exposed in bzr in the docs then
[18:38] <johnny> i read over the user guide , and that other one
[18:40] <james_w> Toksyuryel: there is a missing symlink, someone reported it to the list already, but it doesn't seem to have been added yet
[18:40] <Toksyuryel> ok
[19:07] <Vadi> I'm trying to 'push' a branch online, but I get an 'Not a branch:' error. Is there some specific setup I need to have on my local folder or something?
[19:08] <Odd_Bloke> Vadi: What cmmand are you running?
[19:09] <Vadi> "bzr push<EMAIL_ADDRESS>[19:10] <Odd_Bloke> Vadi: That suggests that you're not in the branch when running the command.
[19:10] <Vadi> Ahah. Now what exactly does that mean? I'm in a folder on my laptop, that I want to upload the contents of on the branch (new to this)
[19:12] <Odd_Bloke> Vadi: OK, you'll need to use 'bzr init' to create an initially empty branch.
[19:12] <Odd_Bloke> Then you'll want to use 'bzr add' to add all of the files in the directory to the branch.
[19:12] <Odd_Bloke> s/branch/working tree/
[19:13] <Odd_Bloke> Then you'll want to commit the changes in your working tree (i.e. everything) to a revision of the branch, using 'bzr commit -m "Initial import."'
[19:14] <Odd_Bloke> The part in "s is the commit message, which will show up in the log of the branch.
[19:16] <Vadi> Where do I specify the branch I want to commit to?
[19:16] <Vadi> I got the bzr init'd and add'd
[19:19] <Vadi> Ahah, okay. I think I got it.
[19:20] <Vadi> I got a exceptions.AssertionError :(
[19:23] <abentley> Vadi: please copy the traceback into a pastebin
[19:23] <abentley> ubotu: paste
[19:23] <ubotu> pastebin is a service to post multiple-lines texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the channel topic)
[19:24] <Vadi> abentley - here you go: http://paste.ubuntu-nl.org/57363/
[19:24] <Vadi> I might have screwed up my ssh key, I'm not entirely sure.
[19:25] <abentley> I was just about to suggest doing sftp manually.
[19:25] <abentley> Just to make sure it's set up properly.
[19:25] <abentley> Also, you might consider upgrading to 1.2
[19:26] <Vadi> How? To both suggestions..
[19:26] <Vadi> I'm on Ubuntu 7.10.
[19:28] <jdong> # Implementation. Implement your chosen code design in Java. You might find that you want to make changes to your design. You are free to do this, but should record the changes so it is clear what the original design was and what changes you made to it.
[19:28] <jdong> # --> Test. Run the staff test suite using the test framework provided. If your program fails any of the tests, correct the problem, and rerun the test suite. Create at least three additional test cases of your own, that demonstrate the robustness of your Multipart implementation.
[19:28] <jdong> oops
[19:28] <jdong> stupid paste button
[19:29] <jdong> I meant to paste https://launchpad.net/~bzr/+archive
[19:34] <lifeless> moin
[19:35] <abentley> Vadi: for the first: "$ sftp<EMAIL_ADDRESS>[19:36] <abentley> For the second, http://bazaar-vcs.org/DistroDownloads
[20:27] <awilkins> Random offtopic question : recommend a home office colour laser (scanner optional)
[20:36] <lifeless> no idea
[20:41] <ubotu> New bug: #195560 in bzr "version-info {clean} doesn't work" [Undecided,New] https://launchpad.net/bugs/195560
[21:18] <blueyed> wow... "bzr revert" after "bzr add" deletes files?? 8/
[21:20] <LaserJock> revert says "go back" so yeah
[21:20] <blueyed> well.. "only" the symlinks..
[21:20] <blueyed> LaserJock: nah.. I wanted to undo the add.. not delete files that were already there...
[21:20] <LaserJock> hmm
[21:21] <mwhudson> there should be backup files .~1~ or whatever
[21:21] <blueyed> bug 87548
[21:21] <ubotu> Launchpad bug 87548 in bzr "bzr add and revert on symlink deletes symlink" [Undecided,Invalid] https://launchpad.net/bugs/87548
[21:21] <blueyed> mwhudson: nope.. /etc/alternatives is now nearly empty..
[21:21] <mwhudson> LaserJock: i finally started the openbabel import btw
[21:21] <mwhudson> blueyed: oops!
[21:22] <lifeless> blueyed: this is the difference between 'undo' and 'revert' - undo needs to know exactly what sequence of things has occured
[21:22] <LaserJock> mwhudson: awesome, thanks
[21:22] <lifeless> blueyed: revert just puts them back the way they were
[21:22] <lifeless> you undo an action, and revert to a state
[21:23] <blueyed> lifeless: the way they were? e.g. /etc/rc?.d/ wasn't empty before "add". but it's after "revert".
[21:23] <blueyed> I just did "bzr init; bzr add;", thought "well, add some ignores first", so "bzr revert" and oooops..
[21:24] <blueyed> lifeless: there's no "good" undo, is there?
[21:26] <lifeless> blueyed: no we don't have an undo, I'm not aware of a vcs that has one - its actually quite unwieldy. Anyhow, that said - I think its a bug that we didn't make backup files called .~1~ of each symlink
[21:26] <lifeless> blueyed: (unless we did ?)
[21:27] <blueyed> lifeless: no.. also not for empty directories like ".common/vim/.svn/props/"
[21:27] <blueyed> so, where's my backup of "/etc"? :/
[21:28] <dato> lifeless: uh, if `bzr add regularfile; bzr revert` does not remove/rename regularfile, why would it not behave the same for symlinks?
[21:28] <blueyed> dato: exactly my thinking.. (including empty dirs)
[21:28] <Vad1> abentley: Hiya
[21:30] <abentley> Vad1: Hi.
[21:31]  * abentley is inclined to fix revert so that it always deletes files, thus not leading people down the garden path.
[21:31] <shagbag> lifeless, I'm running the command: bzr co http://bazaar.launchpad.net/~awn-extras/awn-extras/trunk awn-extras-bzr -r 347
[21:31] <shagbag> and it's taking a LONG time to 'transfer'
[21:32] <Vad1> abentley: I'm still having that error with bzr. Do you know if there's a .deb of the 1.2 version? I'm running 0.9 right now.
[21:33] <abentley> Yes, there is.  Did you see the link I posted?
[21:33] <Vad1> No, but it somehow was opened in firefox already. I was wondering if I was dilusional
[21:33] <Vad1> Whew.
[21:34] <Vad1> (how did you do that though?)
[21:36] <dato> abentley: so how does one undo an add before commit? rm?
[21:36] <Vad1> A bit better this time, but still not quite there: http://paste.ubuntu-nl.org/57373/
[21:36] <abentley> dato: Yes.
[21:37] <lifeless> blueyed: there isn't one, because revert was doing what it is designed to do. That said,  I think we can provide more of a safety net
[21:37] <abentley> Although, I call it "remove", because it's not the same thing as rm.
[21:37] <blueyed> abentley: and how would you undo an "add"?
[21:37] <lifeless> abentley: we can define merge-hashes for links and dirs too
[21:37] <abentley> blueyed: see above.
[21:37] <lifeless> shagbag: its in knit format, knit format is slow.
[21:37] <abentley> lifeless: Not for dirs.
[21:37] <Vad1> I did paste the public ssh key in my ubuntu profile. Not sure what can be wrong - but then again, I couldn't find clear instructions on how to do all of this either.
[21:38] <lifeless> blueyed: 'bzr rm --keep --new'
[21:38] <blueyed> ah.. I see..
[21:38] <lifeless> abentley: yes, we can - sha1('\x00'.join(sort(child.name for child in dir._children)))
[21:39] <blueyed> but I expect "rm" to be more bad to my data than "revert"..
[21:39] <ryanakca> Is it possible to commit in someone's name (other than going sudo -u jsmith bzr commit -m "ponies") ?
[21:39] <abentley> blueyed: So call it "remove" instead.  both work.
[21:39] <lifeless> ryanakca: sure, long as they are not expecting gpg signed commits ;)
[21:39] <lifeless> ryanakca: also see --author IIRC
[21:40] <blueyed> for me, the previous state is "unknown" for those symlinks, empty dirs (and files) in general.
[21:40] <ryanakca> lifeless: okies, thanks :)
[21:40] <lifeless> yes, --author
[21:40] <lifeless> to commit
[21:40] <abentley> lifeless: I don't think that's a clear indicator of whether the directory was automatically created.
[21:41] <lifeless> abentley: merge-hashes records the hash value of a file that we write to disk, IIRC ?
[21:42] <lifeless> abentley: so if we create a directory with 'foo' 'bar' and 'baz', we can look at disk and see that it actually has 'foo', 'bar', 'baz', 'baz.pyc' and conclude that its been altered since.
[21:43] <abentley> Technically, yes.  But the connotation is that the content was generated automatically, not subject to user info.  For example, even though shelf rewrites files, it doesn't update merge-hashes.
[21:43] <blueyed> lifeless: so it's at least a bug that there are no ~1~ files, yes?
[21:44] <lifeless> blueyed: I think its arguable that that is the case.
[21:44] <lifeless> abentley: got you
[21:45] <Vad1> What does a "Permission denied (publickey)." in bazaar mean? It
[21:45] <Vad1> It's not exactly unique, so google doesn't help
[21:46] <lifeless> Vad1: thats being reported by ssh, not bzr
[21:46] <TFKyle> Vad1: if it's while pushing/pulling to sftp it's likely that the other end requires ssh public key authentication and bzr/your ssh client didn't provide any (or you didn't get your passphrase right possibly)
[21:46] <shagbag> lifeless: thanks.  the command worked tonight (unlike last night).  I'm trying the
[21:47] <shagbag> lifeless: thanks, it's downloaded (unlike last night) and compiling now.
[21:47] <Vad1> TFKyle: Okay, how can I do it without the keys?
[21:47] <Vad1> TFKyle: I can't find clear instructions that work anywhere for uploading. The ones I'm going by right now are here (http://ddaa.net/blog/launchpad/bzr-hosting)
[21:48] <lifeless> shagbag: contact the branch owner and get them to upgrade with bzr 1.0 or newer
[21:48] <TFKyle> Vad1: you'd have to configure the server to accept things other than public keys, with openssh have a look at /etc/ssh/ssshd_config
[21:48] <lifeless> shagbag: it will massively improve performance
[21:48] <Odd_Bloke> Vad1: If you're trying to upload to Lauchpad, you need to have an SSH key set up.
[21:49] <TFKyle> but yeah, with lp you need a public key
[21:49] <Vad1> Okay, I do have one in my profile in launchpad
[21:49] <Vad1> Do I need one on my laptop too or?
[21:49] <Odd_Bloke> Vad1: When you create a public key, it generates a private key and a public key.  You should have uploaded the public key.
[21:50] <Odd_Bloke> Vad1: If you haven't created one on your laptop yet, then yes.
[21:50] <Vad1> Right, I uploaded the public key
[21:50] <Vad1> What to do with the private one?
[21:50] <LaserJock> it should be in ~/.ssh/
[21:50] <Odd_Bloke> Vad1: It should have been generated in the correct place, IIRC.
[21:50] <Vad1> Any specific file name?
[21:51] <Vad1> I did it on my server :/
[21:51] <LaserJock> I have a id_dsa in ~/.ssh/
[21:51] <LaserJock> if you have that you can scp that over
[21:53] <blueyed> Wouldn't it be possible to detect a "revert" before any commit, so that no files would get deleted? (I've read in bug 193980 that the problem only is too less information to have "proper" "undo")
[21:53] <ubotu> Launchpad bug 193980 in bzr "revert after add destroy my working tree" [Undecided,New] https://launchpad.net/bugs/193980
[22:00] <ubotu> New bug: #195578 in bzr ""bzr revert" does not backup symlinks and empty directories" [Undecided,New] https://launchpad.net/bugs/195578
[22:29] <igc> morning
[22:30] <lifeless> hi
[22:35] <lifeless> abentley: ping
[22:35] <abentley> lifeless: pong
[22:35] <lifeless> whats a good test to crib from that works with public locations?
[22:36] <lifeless> I want bzr push --shallow to default to looking for the parent branches public location
[22:36] <abentley> Maybe a merge directive test?
[22:37] <lifeless> k I'll look thanks
[22:40] <igc> lifeless: I'm wondering whether we ought to put an upper bound on the auto-repacking
[22:40] <lifeless> igc: we should fix the bugs marked 'pack'
[22:40] <igc> in my OOo import, the repack of 10 10,000 packs has been going for 14 hours now
[22:41] <igc> and in still stage 2/5
[22:41] <lifeless> igc: you are at 100K revisions?
[22:41] <igc> yup
[22:41] <igc> there's 300,000+ just in trunk
[22:41] <igc> the full rpeo is closer to 500,000
[22:42] <igc> I wondering whether 10,000 packs is big enough and beyond that we should only manually pack
[22:44] <lifeless> so, thats very slow. We should fix it being slow
[22:44] <lifeless> igc: with 10 packs you have 10 times the latency problem of 1 pack.
[22:45] <lifeless> igc: please get a lsprof of it.
[22:45] <lifeless> igc: hint: you can cp -a the repository while pack is active
[22:45] <lifeless> igc: then you can break lock and run 'pack' manually to lsprof it
[22:45] <igc> ok
[22:46] <lifeless> igc: so I don't think number of things to rearrange is the issue; because - its exponential backoff
[22:46] <lifeless> igc: the new pack this 10x10K operation creates will not be altered again at all by bzr during your import
[22:47] <lifeless> igc: clearly though we have a performance problem in the pack logic and we should fix that
[22:48] <igc> and memory pressure as well
[22:48] <igc> I think it's lack of memory (4G) that is causing the issue
[22:48] <igc> but 4G isn't 'lack of memory'
[22:48] <lifeless> so
[22:48] <lifeless> pack streams data
[22:49] <lifeless> it holds two things: the index, and an individual delta in memory at a time
[22:49] <lifeless> it uses a readv interface; a bug there would cause very high memory pressure
[22:50] <lifeless> and it buffers writes crudely; a bug there could lead to high memory pressure if you have many big deltas
[22:50] <lifeless> (but many small deltas will be fine)
[22:50] <lifeless> it could be the index builder
[22:51] <igc> thanks for the info
[22:51] <lifeless> it could be the memory pressure of the index
[22:51] <igc> I'll go digging later today
[22:51] <lifeless> so yeah - backup the repo before it completes so that we can reproduce it
[22:51] <igc> shall do so now
[22:51] <lifeless> and get a basic handle on whats wrong and I'll help fix that
[22:52] <igc> ok
[22:52] <foom> does bzr write out profile data even if you interrupt an operation, these days?
[22:52] <lifeless> for instance we may need to start tape-sorting the index we are creating incrementally with very large index sizes
[22:52] <lifeless> foom: maybe; ctrl-\ + a little prodding will let you finish early though :)
[23:07] <lifeless> is there a way to do optional strings on an option?
[23:07] <lifeless>  --reference=bar, with --reference when given defaulting to something e.g. auto:// ?
[23:08] <lifeless> I'd like to not have two options (--shallow and --reference=url)
[23:12] <poolie> lifeless: i see your point but i think it's bad style
[23:12] <spiv> lifeless: hmm, I don't think so.  How would that disambiguate between "--reference unrelated_argument" and "--reference bar"?
[23:12] <poolie> confusing when people say --option SOMETHING
[23:12] <lifeless> yeah
[23:13] <poolie> wot he said
[23:13] <lifeless> this has already occured to me
[23:13] <lifeless> but I still thought I'd ask
[23:41] <Prodoc> I accidentally added some folders I didn't want to track using 'bzr add' (windows xp), now when I try to remove those folders using 'bzr remove <folder name>' I get an error message: 'bzr: ERROR: Can't safely remove modified or unknown files:', can someone explain what's going on here? Is this a bug or should I exclude the folders in a different way?
[23:44] <lifeless> bzr rm --new --keep
[23:45] <Prodoc> --new?
[23:47] <lifeless> bzr help rm
[23:48] <Prodoc> heh, of course, thank. I'm ashamed to admit that I'm too much used to GUI's :-$
[23:49] <Prodoc> it worked, cheers lifeless
[23:57] <lifeless> poolie: np


[02:18] <mwhudson> is there a package in the archive that uses symbol versions that is less complicated than glibc?
[02:20] <sarnold> mwhudson: if I've understand what you want correctly, the apparmor source package provides a libapparmor: http://bazaar.launchpad.net/~apparmor-dev/apparmor/master/view/head:/libraries/libapparmor/src/libapparmor.map
[02:20] <mwhudson> ah yeah, that seems to be what i mean
[02:20] <mwhudson> thanks
[02:20] <sarnold> I can't promise it's perfect but it's probably esaier than glibc :)
[02:21] <mwhudson> is the format documented somewhere?
[02:22] <mwhudson> man ld says "see VERSION for more" or something
[02:22] <mwhudson> but i don't see where it means
[02:26] <mwhudson> ah it all seems to be in http://www.akkadia.org/drepper/dsohowto.pdf
[02:26] <mwhudson> some light reading for when insomnia is a problem
[02:26] <sarnold> heh I was just wondering if that'd be the best source :/
[02:27] <sarnold> I thought forsure I'd seen something "more official", but can't find what I was thinking of.
[02:28] <infinity> mwhudson: I would have recommended zlib, but apparmor seems like a decent example too.
[02:30] <infinity> mwhudson: Also, for docs: apt-get install binutils-doc && info ld
[02:31] <infinity> mwhudson: Section 3.9 is VERSION.
[02:31] <mwhudson> omg info
[02:31] <sarnold> ha! I forgot info loads manpages if youdon't have the info pages loaded.
[02:32] <sarnold> I checked there for VERSION but .. of course didn't have the binutils-docs loaded.
[02:32] <infinity> Yeah, an annoying misfeature.
[02:32] <sarnold> one of many.
[02:33] <infinity> I imagine info makes sense to emacs users, to me it's always been vile.
[02:33] <sarnold> next time I find an emacs user I'll ask :)
[02:34] <sarnold> (I wonder if 'vile' can make info less terrible?)
[02:34] <infinity> Oh, wow, vile - VI Like Emacs - vi work-alike
[02:34] <infinity> WHY IS THAT A THING?
[02:35] <sarnold> I ran that on dos back in the day :)
[02:36] <infinity> sarnold: Telemate's built-in editor was all the editor I ever needed on DOS.
[02:37] <sarnold> infinity: haha :)
[02:37] <infinity> Given that DOS only existed to play video games and run Telemate to dial into my UNIX shells at the university...
[02:38] <jrwren> i heard pinfo is a nicer info reader
[02:39] <infinity> Huh.  This youtube video is basically my early teens: https://www.youtube.com/watch?v=nOx9fLBJO1w
[02:40] <infinity> Except that I wasn't a scrub with [UNREGISTERED] flashing in the corner.
[02:42] <mwhudson> oh, so the man page thing is a poor translation from texinfo or whatever
[02:44] <sarnold> I thought there was a nice gui info viewer, like xman, but I can't find the thing now
[02:45] <jrwren> xinfo?
[02:46] <infinity> There's tkinfo, but I wouldn't call it "nice".
[02:47] <infinity> pinfo is definitely nicer than the GNU client, though.
[02:48] <infinity> curses based, and kinda usable by normal humans.
[02:48] <sarnold> maybe it was tkinfo I was thikning of. I would have sworn just xaw widgets but maybe it was tk..
[02:50] <mwhudson> pinfo is like pouring a nicer kind of vinegar in your eye
[02:50] <infinity> Arguably, the sanest modern info viewer would be a web browser frontend for the rendered and some info2html magic.
[02:50] <infinity> s/rendered/renderer/
[02:54] <sarnold> and if we're really lucky, we'd burn the info backend once the conversion was done once :)
[02:55] <infinity> sarnold: Well, much like LaTeX, the info format isn't a terrible way to write/maintain documentation, it's just that you need to render it sanely to read it.
[02:55] <infinity> sarnold: In the case of LaTeX, rendering it sanely is entirely the point, for info, that's been a WIP for 20 years. :P
[02:55] <sarnold> hahaha
[02:59] <infinity> sarnold: But, given than no modern OS is complete without about 20 HTML rendering engines, and info node cross-referencing should map 1:1 with hyperlinking, conceptually, I figure it wouldn't be rocket surgery to build an info browser into, say, yelp.
[03:00] <infinity> sarnold: Or build an info browsing local web service that you could hit from any browser.
[03:00] <infinity> I'd actually be surprised if someone hasn't done the latter, and I just can't find it.
[03:00] <sarnold> I never liked the fact that the information was broken into multiple pages; I always liked manpages putting all the information in one simple pager
[03:00] <sarnold> I'm pretty sure I've run one of those info-to-html servers before :)
[03:01] <infinity> Yeah, I tend to prefer manpages too, but whenever I'm using a GNU tool, I have to suffer the pain of info.
[03:01] <infinity> And, to be fair, for some it would be amazingly unwieldly to have one giant manpage.
[03:01] <infinity> The glibc docs come to mind.
[04:35] <pitti> slangasek: in ubuntu we already have a split upstart-sysv binary; I meant if that will go into Debian as well, to have the same binary package layout in both
[04:36] <pitti> Good morning
[05:16] <slangasek> pitti: it probably should at some point, but again, not something I'm committing any time to right now
[05:16] <pitti> slangasek: ack; I was just wondering
[06:40] <dholbach> good morning
[06:49] <mitya57> infinity, I think yelp already has an info browser
[07:32] <Noskcaj> sil2100, Are we ok to sync libgit2-glib and gitg? The only delta is -glib's breaks on gitg < 3.15
[07:38] <sil2100> Noskcaj: I would say it should be fine to sync it
[07:38] <Noskcaj> ok, can you sync them or should i file sync bugs?
[07:42] <sil2100> I'll try doing that today, but it might slide a bit since I still have a few other things to finish up :)
[07:44] <Odd_Bloke> I don't think I've ever used info; perhaps this explains some of my past confusion. :p
[08:28] <pitti> arges, bdmurray: I'd appreciate if you could process bug 1450009 soon -- this fixes a regression in the previous round of postgresql updates
[08:28] <pitti> arges, bdmurray: erk, I meant bug 1461425 (just a formality, postgresql has an MRE)
[08:28] <seb128> pitti, wrong bug number? ;-)
[08:28] <seb128> hehe
[08:28] <pitti> seb128: -ETOOMANYTABS
[08:29] <seb128> seems like pitti has systemd autofingers nowadays :p
[08:29] <pitti> seb128: yeah, I cannot even write the word <tries very hard> "system" any more :)
[08:29] <seb128> :-)
[09:58] <Silentlord> hi, i want an email to contact someone regards application reviewing
[10:12] <pete-woods> hi, I seem to be unable to modify bugs on the indicator-network source package (which I maintain / develop)
[10:12] <pete-woods> https://launchpad.net/ubuntu/+source/indicator-network
[10:12] <pete-woods> can someone tell me how to become a member of "Ubuntu Developers
[10:14] <pete-woods> (you'd think I'd already be a member, given I'm employed by Canonical) :p
[10:17] <cjwatson> Ubuntu Developers relates to direct upload access and is a community process, not a Canonical process
[10:17] <highvoltage> hey pete-woods, http://fridge.ubuntu.com/2011/01/27/becoming-an-ubuntu-developer-a-short-guide/ is slightly dated but still mostly good
[10:17] <cjwatson> https://wiki.ubuntu.com/UbuntuDevelopers
[10:17] <cjwatson> But there are other ways to get what you want: https://wiki.ubuntu.com/UbuntuBugControl
[10:19] <pete-woods> cjwatson: thanks. I think that's more what I'm after :)
[10:19] <pete-woods> highvoltage: seems like I don't want to actually become an "ubuntu developer"
[10:23] <larsu> pete-woods: someone needs to set the maintainer of that project to indicator-applet-developers
[10:23] <larsu> which is what all the other indicator projects have
[10:23] <pete-woods> larsu: that sounds like a more sensible value to me
[10:25] <larsu> pete-woods: wait, you are already in ~pspmteam, so this should work
[10:25] <larsu> ah my bad. You want to be able to change *ubuntu* bugs
[10:25] <pete-woods> larsu: the others (source packages here) look to be maintained my Ubuntu Desktop
[10:25] <pete-woods> yeah
[10:25] <pete-woods> we're supposed to have all our bugs on the source package now
[10:26] <larsu> right, you won't get into ubuntu desktop
[10:26] <pete-woods> indeed
[10:26] <larsu> UbuntuBugControl is what you want
[10:26] <pete-woods> cool
[10:26] <pete-woods> I just need to get a
[10:26] <larsu> it's fairly easy to join if you're a developer
[10:26] <pete-woods> "showcase of my best 5 bug triages"
[10:26] <pete-woods> I'm not sure I've done much other than merge branches to fix bugs, though
[10:29] <pete-woods> kinda feels like my whole team "unity api team" should be in the bug control group
[10:29] <pete-woods> instead of us each having to apply manually
[10:40] <pete-woods> oh, it says to contact jcastro if you are an upstream developer? does that mean I don't have to go through the full application process?
[11:12] <rbasak> pete-woods: you can have a team membership to the bug control group: https://wiki.ubuntu.com/UbuntuBugControl#Requirements_for_Teams
[11:12] <rbasak> The Canonical Server Team has one.
[11:45] <pitti> rbasak: thanks for pinging the biosdevname bug!
[11:54] <rbasak> pitti: no problem. Sorry I hadn't followed up on this before.
[11:55] <rbasak> pitti: I've also asked internally to see if we can find a Dell contact.
[11:55] <rbasak> (well, delegated that to my manager at least)
[11:55] <pitti> rbasak: cool, thanks
[12:01] <pete-woods> rbasak: yeah, I think I'll have to put in an application for one :)
[12:17] <rbasak> Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right?
[12:22] <jcastro> pete-woods: just have someone from your team send me a mail and I'll add you today
[12:22] <jcastro> that page is mostly for 3rd party developers who have a package in universe or something and want to triage their own bugs
[12:24] <pete-woods> jcastro: okay, cool, will send you a mail now :)
[12:29] <LocutusOfBorg1> doko, ping :)
[12:29] <LocutusOfBorg1> I hope you read there, I would like to know if it is ok for you to upload casablanca with CXX=g++5 in unstable (the ABI problem)
[13:06] <rbasak> Any reason to continue maintaining an upstart job in the Ubuntu delta for squid3? I can drop it now, right?
[13:07] <seb128> rbasak, slangasek or pitti might help you there, unsure if we still want to support booting with upstart
[13:08] <caribou> Q: Would adding an upstart job to an existing package in trusty acceptable for an SRU ?
[13:42] <caribou> rbasak: I'm facing the same upstart question in Wily wrt my Trusty SRU question
[13:42] <caribou> rbasak: I need to add an upstart job for kdump-tools for Trusty but should I also worry about adding it to Wily, as Wily uses the systemd service
[13:43] <caribou> In short, do we consider Wily + upstart a supported option ?
[14:02] <pitti> rbasak: I think we should still keep upstart working until at least 16.04 LTS
[14:02] <pitti> rbasak: now, if squid3 has an init.d script which essentially does the same as the upstart job, it's fine to drop
[14:02] <pitti> rbasak: but if it does ubuntu specific things, we should keep it (or adjust the init.d script instead)
[14:04] <rbasak> pitti: it has an init.d script from Debian and we were previously adding the upstart job. There'd the odd reported bug with the upstart script and so I think the init.d script is of higher quality. So I'll just drop the upstart job - thanks.
[14:04] <pitti> rbasak: ack
[14:28] <slangasek> rbasak: no, for 15.04 and beyond I don't think there's any reason to carry a delta for an upstart job.  it's reasonable and appropriate to submit that upstart job for upstream inclusion in Debian, though, where upstart is still an option
[14:42] <hallyn> infinity: hi - any newer thoughts on bug 1454862 ?
[14:55] <infinity> hallyn: I'm not big on thinking in the morning, but I'll get back to you.
[15:15] <hallyn> thx
[15:48] <infinity> pitti: Can you confirm for me that all new ddebs are coming via the librarian and if I flatten a buildd (thus losing public_html), we won't lose anything?
[15:51] <cjwatson> infinity: ddebs.u.c has had its direct buildd retrieval switched off for at least a couple of weeks now
[15:54] <pitti> infinity: yes, I disabled all the apache polling
[15:55] <pitti> I should actually commit that, thanks for the reminder
[15:55] <infinity> cjwatson, pitti: Excellent.  Then, in the name of d-i testing, today might finally be the day the arm64 buildds get reinstalled with a distro kernel.
[15:55] <cjwatson> Just in time to replace them with Moonshot </not-really>
[15:55] <infinity> cjwatson: Yeah, I noted the same irony.
[15:56] <infinity> cjwatson: But realistically, I'm sure these Mustangs will be in service for a couple/few more months still, unless we really get our ducks in a row.
[15:56] <cjwatson> Yeah
[15:57] <infinity> They've treated us remarkably well.  I kinda want one in my house.
[15:57] <infinity> After we squished the worst issues, they've since been clocking uptime in the months, and the only interruptions for the last year have been DC power maintenance.
[15:57] <cjwatson> Let's hope the distro kernel isn't worse.  Is this for page size changes?
[15:58] <pitti> arges: what was wrong with the utopic/vivid postgresql-9.4?
[15:58] <pitti> arges: I'll sync wily from unstable once it hits, but that won't happen until Friday or so
[15:58] <infinity> cjwatson: No.  Mostly, it's cause I need to test trusty's d-i, but it's also just an excuse to be running our own code, get SRU updates, etc.
[15:58] <infinity> cjwatson: But it might also fix some longstanding bugs, like hangs in the gdb testsuite, etc.
[15:58] <cjwatson> Fair enough
[15:59] <infinity> cjwatson: I also have a sneaking suspicion that the combination of new firmware and new kernel might fix the abysmal I/O and suddenly make those buildds quite a bit speedier.  But that's hard to know for sure without trying.
[16:01] <cjwatson> Try one or two at a time, I guess
[16:01] <infinity> cjwatson: Yeah, I'm only killing one today.  See how it holds up under load, then I can do the other 4.
[16:01]  * cjwatson nods
[16:19] <pitti> arges: https://launchpad.net/ubuntu/+source/postgresql-9.3/9.3.8-0ubuntu0.4.04 -> erk, version typo
[16:19] <pitti> arges: should have been 14.04; but it doesn't matter actually, there's no other release with 9.3, so *shrug*
[16:21] <infinity> pitti: 4.04, though?  Well done on inventing a release before warty.
[16:21] <pitti> infinity: right, it's the 404 release -- not found :)
[16:21] <infinity> :)
[16:22] <infinity> pitti: And now I realize that Mark missed a great opportunity to use HTTP responses as version numbers instead of using dates.
[16:22] <infinity> Those release would have been self-naming too.
[16:24] <infinity> Might have even been vaguely appropriate for the first release (100) to be "continue".
[16:30] <arges> pitti: yikes sorry about that
[16:45] <pitti> arges: no worries
[16:45] <pitti> arges: oh, you were able to re-accept the old utopic package? I thought that wouldn't work
[16:46] <pitti> arges: anyway, if it works, we can reject the 14.04.1 package from the queue, and otherwise use that
[16:46] <pitti> arges: thanks!
[16:47] <pitti> arges: nevermind, I mis-looked
[17:02] <arges> ah pitti's gone
[18:45] <menace> Hi, i want to use /etc/cron.daily/apt to download the current/new debian packages. but i only want to install them from the local cache at boot or shutdown. is this possible with unattended-upgrades. I'm not sure if the modes/variables for /etc/cron.daily/apt and unattended-upgrade are the same, so both would only download OR download and install in one step, but i want to have it in two separate steps...


[05:14] <chesedo> Morning all, it has been a long time
[12:36] <chesedo> superfly: what happened to everyone?
[15:06] <superfly> chesedo: I'm not sure.
[15:06] <superfly> I changed timezones, so it's difficult for me to hang around with everyone else. Kilos pops in from time to time, but again, that's usually when I'm not yet awake.


[22:02] <Ashiren> happy Caturday
[22:02] <Ashiren> :3 https://img-9gag-fun.9cache.com/photo/ad84B0j_460swp.webp