 (Photo, 1280x575) https://i.imgur.com/O8uSkPw.jpg hello, which one is showing my ram usage ?
 @devikri [<reply to image>], Does RSS show the use of RAM?
[04:29] <guiverc> devikri, what tool are you using?
 @guiverc [<guiverc> devikri, what tool are you using?], lxtask
[04:30] <guiverc> okay, sorry I should probably have guessed that..
[04:32]  * guiverc doesn't have a 18.04/LXDE system running; so having to look up details online
 I usually use htop, and this is my first time using lxtask
[04:34] <guiverc> I was hoping to find out what RSS stood for, I can't find the answer on lxde.org
 oke thx guivere
[04:40] <guiverc> even the source code refers to it as RSS; I could only guess sorry
[04:42] <guiverc> RSS usually means Resident Set Size in posix/unix ... but I can't confirm sorry   (memory allocated to a process and is in ram)
 @guiverc [<guiverc> RSS usually means Resident Set Size in posix/unix ... but I can't conf …], at least this helps 😁😁😁 thx
[04:45] <guiverc> :)
[16:10] <n-iCe> I sold my laptop, so I need t bring back to life my old one
[16:11] <n-iCe> will lubunutu run in 1GB ram?
[16:12] <n-iCe> Genuine Intel(R) CPU T2400 @ 1.83GHz
 Is there any utility to switch between amd and intel graphics on Ubuntu ?
[16:49] <diogenes_> The_LoudSpeaker, try DRI_PRIME=1 your app
 Okay. But I was looking for a gui to enable/disable the amd card. Like nvdia. Nvdia provides a good gui.
[17:06] <diogenes_> it's disabled by default and it's enabled by  DRI_PRIME=1, other than that, your bios might provide the settings which card to enable/disable.
[18:34] <pythonesia> ping
[21:26] <upupbb-user1> hello which version is more lightweight, lubuntu or xubuntu?
[21:31] <wxl> upupbb-user1: the "l" in lubuntu stands for it, soooooo
[21:32] <upupbb-user1> so lubuntu
[21:32] <upupbb-user1> I'm downloading, thing my hardware is really old.
[21:32] <wxl> 64 bit at least?
[21:32] <upupbb-user1> no :(
[21:33] <upupbb-user1> Genuine Intel(R) CPU T2400 @ 1.83GHz 1GB RAM HDD 80GB
[21:33] <wxl> oh yeah well that's a problem
[21:33] <upupbb-user1> No candidate?
[21:33] <wxl> at least looking into the long term
[21:33] <guiverc> Lubuntu 18.04 LTS works with x86 (i386/686); supported until 2021-April
[21:33] <wxl> for now, 18.04 will do the trick, but you won't be able to go any further
[21:33] <wxl> ^ what he said
[21:34] <upupbb-user1> I see
[21:34] <upupbb-user1> Any more lightweight distro you guys recommend?
[21:34]  * wxl shrugs
[21:35] <guiverc> Xubuntu is another choice; again supported until 2021-April.  It's only slightly heavier
[21:35] <upupbb-user1> but I mean more lightweight than lubuntu,  I have read about slitaz, puppy, bohdi
 you will have same problem with all *buntu for 32 bit suport.
[21:36] <guiverc> The only other choice in my mind would be pure debian.
[21:36] <wxl> oh my i'd avoid puppy like the plague
[21:36] <wxl> bodhi is an ubuntu derivative afaik so it will suffer the same problem
[21:37] <wxl> maybe arch?
[21:37] <wxl> nope, sorry
[21:37] <guiverc> I tested Lubuntu up to 19.04 using a single-core pentium M 1gb box from ~15 years ago.  Lubuntu is pretty good
[21:37] <wxl> there's a "community derivative" arch linux 32 but i'm not sure what that means
[21:38] <wxl> https://archlinux32.org/
[21:38] <wxl> of course arch is not "easy" per se
 arch is almost a white page, you need to install everything you want/need.
[21:40] <wxl> right
[21:40] <wxl> which means you can keep it really slim, but it also means it's not easy


[00:39] <jrwren> greg-g: ever get straus yogurt?
[00:40] <jrwren> i found some in SLC grocery and I saw it is from petoluma and ZOMG is it tangy!
[03:39] <greg-g> jrwren: yeah, straus is a good dairy here :)
[13:14] <cmaloney> morning
[13:19] <rick_h_> morning
[13:45] <waldo323> good morning
[13:46] <waldo323> was I wrong about today being the release day for 18.04? I don't see mention of it at ubuntu.com
[13:49] <rick_h_> I think it's supposed to be today
[13:49] <rick_h_> did they announce a delay?
[13:51] <waldo323> I don't see any announcement, I do see an announcement from a 3rd party which points to the downloads page which hasn't been updated yet.  so maybe it is scheduled to be released at some time today later than now
[13:52] <rick_h_> yea
[13:53] <rick_h_> global company means as long as it's 26th somewhere lol
[13:58] <waldo323> :)
[13:58] <waldo323> works for me
[13:59] <cmaloney> I still haven't put up the release party on the loco directory
[13:59]  * cmaloney is a bad contact
[13:59] <cmaloney> but I do have stuff for the release party so yay!
[14:00] <waldo323> Michael W Lucas came to mug this month and gave a talk about ZFS and a secret project he worked on to create a real book with humor added for april 1 on the standard UNIX editor: ed
[14:01] <waldo323> ZFS: https://youtu.be/x9A0dX2WqW8
[14:01] <waldo323> discussion of how the Ed book came to be and a teaser intro: https://youtu.be/cnB_Ds8Q-q4
[14:25] <dzho> oh, heh
[14:26] <dzho> I was following a little bit about that book on the fediverse
[14:26] <dzho> v. funny
[14:33] <waldo323> yeah, I've read a little bit of the book and it had me chuckling so I look forward to reading the rest
[14:34] <dzho> last I saw there was this whole schtick about doing an ed(1) conference
[14:36] <waldo323> heh nice
[18:01] <Scary_Guy> no one does a release party like OpenBSD :p
[18:02] <Scary_Guy> the theme of this Ubuntu release should be Gnomes
[21:05] <jrwren> add-apt-repository does -u by default now.  whooo hooo!
[22:26] <waldo323> yeah i saw that :)


[07:00] <Unit193> Happy (late) Thanksgiving to all!
[14:15] <yano> likewise!
[14:15] <yano> i hope everyone has a great weekend!
[14:15] <yano> and hopefully doesn't have to work


[03:53] <guiverc> Ginalo, you didn't mention release, but its open source so why not look? https://packages.ubuntu.com/hirsute/ubuntustudio-installer and https://packages.ubuntu.com/hirsute/all/ubuntustudio-installer/filelist
[04:37] <Ginalo> Oh right that makes sense. I don't know why that didn't hit me
[16:28] <blvckrvbvt> #coffee


[04:18] <salambander> has anyone solved this problem? http://ubuntuforums.org/showthread.php?t=1339264&page=2
[04:19] <micahg> salambander: check in #ubuntu, this is the bug triage channel
[09:51] <monkill> now install air blue theme final last desktop 9.10
[09:51] <monkill> ?
[09:52] <monkill> help me
[10:04] <etali1> Monkill, you may find more help in #ubuntu - that's where people tend to go for support.  This channel is for bug triaging.
[10:05] <monkill> ok
[19:02] <cjohnston> wishlist Bug #500310 please
[19:02] <ubot4> Launchpad bug 500310 in purple-plugin-pack "Update purple-plugin-pack to 2.6.1" [Undecided,New] https://launchpad.net/bugs/500310
[19:07] <micahg> cjohnston: done
[19:08] <cjohnston> thanks micahg
[19:12] <cjohnston> wishlist bug #500296
[19:12] <ubot4> Launchpad bug 500296 in tcc "tcc: a new upstream version (0.9.25) is available that support x86_64" [Undecided,New] https://launchpad.net/bugs/500296
[19:14] <micahg> cjohnston: done
[19:27] <cjohnston> Bug #500131 is this a bug for ubuntu, for the theme creator or pidgin?
[19:27] <ubot4> Launchpad bug 500131 in pidgin "gmail buddies are too wide" [Undecided,New] https://launchpad.net/bugs/500131
[19:29] <cjohnston> wishlist bug 500120
[19:29] <ubot4> Launchpad bug 500120 in ekiga "needs update to 3.20" [Undecided,New] https://launchpad.net/bugs/500120
[19:29] <micahg> cjohnston: 500120 done
[19:30] <cjohnston> :-)
[19:30] <micahg> cjohnston: as for the pidgin bug, I'd ask in the pidgin IRC channel
[19:30] <micahg> if they say it's their bug, upstream it, otherwise, invalid and tell the user to report to the author of the theme
[19:33] <cjohnston> wishlist Bug #500053
[19:33] <ubot4> Launchpad bug 500053 in indicator-session "indicator applet session should also work on lxpanel" [Undecided,New] https://launchpad.net/bugs/500053
[19:33] <cjohnston> keepin ya busy micahg.. hehe
[19:34] <cjohnston> and bug 500070
[19:34] <ubot4> Launchpad bug 500070 in multisync0.90 "Sync multisync0.90 0.92.0~svn355-2 (universe) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/500070
[19:35] <cjohnston> bug 500045
[19:35] <ubot4> Launchpad bug 500045 in libsvm "Please sync libsvm (2.90-1) with Debian testing" [Undecided,New] https://launchpad.net/bugs/500045
[19:35] <cjohnston> lol
[19:35] <cjohnston> too bad i cant wishlist
[19:36] <micahg> cjohnston: you can apply for bug control if you think you're ready
[19:36] <micahg> done on both
[19:36] <cjohnston> should i finish mentoring first?
[19:36] <micahg> cjohnston: yeah, I guess so, you can talk to your mentor about whether or not you're ready
[19:42] <cjohnston> bug 500039 wishlist
[19:42] <ubot4> Launchpad bug 500039 in intel-gpu-tools "Please sync intel-gpu-tools (1.0.2-1) with Debian Testing" [Undecided,New] https://launchpad.net/bugs/500039
[19:43] <cjohnston> bug 500025
[19:43] <ubot4> Launchpad bug 500025 in ubuntu "[Packaging request] Ailurus" [Undecided,New] https://launchpad.net/bugs/500025
[19:46] <cjohnston> bug 500023 - i guess mark as fix released?
[19:46] <ubot4> Launchpad bug 500023 in software-center "daily-ppa hasn't built anything in more than 12 weeks" [Undecided,New] https://launchpad.net/bugs/500023
[19:48] <micahg> cjohnston: done
[19:48] <cjohnston> wishlist 499992
[19:48] <cjohnston> wishlist bug 499992
[19:48] <ubot4> Launchpad bug 499992 in gnome-terminal "Update gnome-terminal to 2.29.1" [Undecided,New] https://launchpad.net/bugs/499992
[19:49] <micahg> cjohnston: done
[19:50] <cjohnston> micahg: on bug 500023 - the op says its fixed..
[19:50] <ubot4> Launchpad bug 500023 in software-center "daily-ppa hasn't built anything in more than 12 weeks" [Undecided,New] https://launchpad.net/bugs/500023
[19:50] <micahg> cjohnston: no, the user fixed it in a branch under their LP user
[19:50] <cjohnston> o
[19:50] <micahg> cjohnston: so maybe triaged
[19:50] <cjohnston> gotcha.. so the fix still needs to be imported
[19:51]  * cjohnston cant do triaged
[19:52] <micahg> cjohnston: done
[19:53] <cjohnston> ;-)
[19:53] <micahg> cjohnston: battery's about to die, I might be back later
[19:54] <cjohnston> okie.. have a good one.. Merry Christmas
[19:55] <cjohnston> wishlist bug 499988
[19:55] <ubot4> Launchpad bug 499988 in libapache2-mod-fcgid "New upstream version available" [Undecided,New] https://launchpad.net/bugs/499988
[20:14] <LimCore> hi, I try to debug alsa sound problem
[20:14] <hggdh> cjohnston: done
[20:15] <LimCore> game using alsa hangs and looses sound.  How to debug it more
[20:18] <etali> LimCore: you'd be best off asking for help in  #ubuntu - this channel is for triaging rather than support.
[20:18] <LimCore> I ment to /debug/ the problem, for the bugreport
[20:19] <hggdh> LimCore: you have had the debugging sound wiki pointed to you already, have you not?
[20:19] <LimCore> which one?
[20:19] <hggdh> https://wiki.ubuntu.com/DebuggingSoundProblems
[20:31] <LimCore> hggdh: so far installing libsdl1.2debian-pulseaudio seems to help. Perhaps it should be installed by default?
[20:36] <hggdh> LimCore: depends on a series of factors. Please add this finding to the bug comments
[21:42] <cjohnston> wishlist Bug #500416
[21:42] <ubot4> Launchpad bug 500416 in referencer "sync referencer (1.1.6-1) from Debian testing or unstable" [Undecided,New] https://launchpad.net/bugs/500416
[21:47] <micahg>  cjohnston: done
[21:48] <cjohnston> thanks
[23:37] <cjohnston> bug #500045 wishlist
[23:37] <ubot4> Launchpad bug 500045 in libsvm "Please sync libsvm (2.90-1) with Debian testing" [Undecided,New] https://launchpad.net/bugs/500045
[23:42] <mrand> done
[23:42] <cjohnston> :-)
[23:44] <cjohnston> mrand: bug 500437 what package should that be reported againts?
[23:44] <ubot4> Launchpad bug 500437 in ubuntu "package linux-image-2.6.31-15-generic 2.6.31-15.50 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zur?ck" [Undecided,New] https://launchpad.net/bugs/500437
[23:44] <cjohnston> against
[23:47] <mrand> From what I can read, I suppose kernel, but it is difficult for me to decipher for certain.
[23:47] <mrand> Dinner time.  bbl


[00:00] <jelmer> groo_: It hasn't changed recently - see the bzr bug report for details: https://bugs.launchpad.net/bzr/+bug/402814
[00:37] <poolie> good morning
[00:49] <groo_> jelmer: tks for info :)
[00:58] <spiv> Good morning.
[01:06] <poolie> hi spiv, jelmer
[01:15] <maxb> hrm
[01:16] <maxb> bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: Cannot add revision(s) to repository: missing text keys: [('dulwich/____init____.py', 'git-v1:f60d0a17de087f21708f7f32115b7cc957d51a1a'), ....
[01:16] <maxb> in our dulwich-daily recipe
[01:16]  * maxb suspects the damaged divergence of pushed and dpushed dulwich
[01:47] <TJNII> I've set up bzr as a centralized vcs successfully.  Now I would like to set up a directory that gets updated every time something is committed to the central repo, so that it always the newest and shiniest bits.  This directory will be read only, so merging should not come in to play.  Is a hook script the best way to do this, or can loggerhead do this better?  I'm mainly wondering what documentation to read at this stage.
[01:51] <spiv> TJNII: loggerhead is a web UI for viewing bzr branches
[01:52] <spiv> It looks like http://bazaar.launchpad.net/+branch/bzr
[01:52] <TJNII> Okay, so that's a no, then.
[01:53] <TJNII> Thanks for the example, though.  I was wondering what it looked like.
[01:56] <poolie> TJNII: there is a push-and-update plugin that might be what you want
[01:56] <TJNII> poolie: But that needs to be installed for each client, yes?
[01:57] <maxb> although, that relies on the person pushing to use it
[01:57] <maxb> I think a hook would make the most sense here
[01:57] <poolie> yes
[01:57] <TJNII> Requiring all users to run it isn't really feasable.... Is there a sound argument against a hook?
[01:57] <poolie> a server side hook to do this would be good
[01:57] <TJNII> Okay, that's what I thought.
[01:57] <poolie> there probably is such a hook
[01:57] <TJNII> Thanks for the confirmation.
[01:57] <poolie> post_tip_change
[01:57] <poolie> but i don't know if there is something that hooks into it that will update the tree
[01:57] <maxb> although a hook will only fire if the push is over a smart transport
[01:57] <poolie> if you know python it should not be hard to run
[01:58] <poolie> there is that too
[01:58] <poolie> another option is to just set up a cron job to update the working tree
[01:59] <TJNII> Which transports would not be considered "smart"?
[02:00] <maxb> Ones which do not rely on there even being a copy of Bazaar installed on the server
[02:01] <spiv> TJNII: http://doc.bazaar.canonical.com/plugins/en/automirror-plugin.html might be close enough.
[02:01] <spiv> TJNII: pushing over bzr+ssh is "smart", i.e. runs bzr on the server.  Pushing over sftp isn't.
[02:02] <maxb> bzr+ssh is smart. http will try to use smart bzr+http if available, otherwise fall back to dumb http. sftp is dumb file operations
[02:02] <spiv> The automirror plugin is at least an example of using the post_change_branch_tip hook.
[02:02] <TJNII> maxb: How does that work in a centralized configuration without bzr?  I thought bazaar did not maintain a usable tree that could be accessed directly due to logistical reasons at the core repo?
[02:02] <TJNII> By "usable" I mean "directly accessable"
[02:03] <TJNII> My verbage was not to good, there.
[02:03] <maxb> directly accessible by a human using basic file tools isn't the same as accessible using Bazaar remotely
[02:04] <TJNII> Oh, so the remote bazaar modifies the .bzr directory?
[02:04] <spiv> TJNII: is your central repo written to via bzr+ssh?
[02:05] <TJNII> spiv: Right now, yes.  I think I can maintain that, though I haven't played with the Windows end yet.
[02:05] <spiv> Ok, that works well then.
[02:06] <spiv> Because bzr+ssh means bzr is running on the server, and the client is merely asking the server's bzr to make changes rather than writing to .bzr itself.  So you just need to install the hook on the server, and it will be run.
[02:07] <TJNII> Aah, I understand.
[02:07] <spiv> I'd try the automirror plugin first, I think it's pretty close to what you want.
[02:08] <TJNII> Gotcha, thanks.
[02:31] <poolie> jelmer, are you still here?
[02:31] <poolie> what do you think of bug 758758 vs bug 681582?
[06:23] <spiv> poolie: do you know anything about “AssertionError: NoWhoami not raised” test failures on lp:bzr/2.3?
[06:23] <poolie> hi spiv
[06:23] <poolie> there is a bug open for it
[06:24] <spiv> Hmm, do you have the number handy?  A search didn't find it for me.
[06:25] <spiv> I'm a bit puzzled about how it passed PQM, perhaps there's a test isolation problem?
[06:25] <poolie> spiv it is a test isolation thing
[06:25] <poolie> specifically the heuristic of having /etc/mailname probably works on your laptop but not on pqm
[06:26] <poolie> https://code.launchpad.net/~mbp/bzr/751824-whoami-test-failures-2.3/+merge/56503
[06:26] <poolie> is supposed to have fixed it
[06:26] <spiv> But isn't merged to 2.3?
[06:28] <poolie> ah ha
[06:28] <poolie> was meant to go in to 2.3 but did not
[06:28]  * spiv wonders where his ssh agent went
[06:32]  * spiv wonders where the environment variables pointing to the perfectly good ssh agent went
[06:33] <poolie> https://code.launchpad.net/~mbp/bzr/751824-whoami-test-failures-2.3/+merge/57436
[06:33] <poolie> the diff to 2.3 looks reasonable so i'll send it
[06:34] <spiv> poolie: if it's the same fix already approved & merged for lp:bzr then I approve without even looking at it :)
[06:34] <spiv> Thanks!
[06:35] <spiv> For bonus points, do you think gnome-session is a reasonable package to file a bug against if my new terminal instances started by Ctrl-Alt-T (but not Ctrl-Shift-N from an existing terminal!) are lacking environment gnome-sessiony variables?
[06:35] <poolie> and, ah, https://bugs.launchpad.net/launchpad/+bug/676769
[06:36] <poolie> filed by you :)
[06:36] <poolie> spiv i'd guess that was a gnome-terminal bug
[06:36] <poolie> that's surprising
[06:36]  * spiv hmms
[06:36] <poolie> it seems like it would have to try hard to break it
[06:37] <spiv> Huh, yes, maybe g-t
[06:37] <spiv> Using Alt-F2 to run xterm inherits the vars ok
[06:37]  * spiv wonders what the Ctrl-Alt-T shortcut does exactly.
[06:39] <spiv> Hmm, part of the “Gnome compatibility plugin” in ccsm
[06:43] <poolie> wow
[06:43] <poolie> ok, i sent that to pqm
[06:44] <poolie> spiv i might go out for a bit, as i have some calls tonight
[06:44] <poolie> should be back about 5
[06:44] <spiv> Ok, see you later
[07:35] <maxb> mm yay it's beta time again, watch the ~bzr/beta ppa become a nightmare of uninstallability
[07:40] <maxb> jelmer: I want a bzrtools snapshot in ~bzr/beta for installability, are you interested in having it in experimental too (i.e. should I prepare it on the alioth experimental branch?)
[08:21] <spiv> losa ping: http://pqm.bazaar-vcs.org/ is giving 503 Service Temporarily Unavailable.  Is that a known issue?
[08:22] <spm> hrm. not by me.
[08:24] <spm> spiv: iz back; had crashed
[08:28] <spiv> spm: thanks!
[08:28] <spiv> And apparently poolie's patch for 2.3 didn't land.  Hmm.
[08:30] <spm> I call cause and effect. poolie's patch is clearly evil and crashed the pqm ui.
[08:31] <poolie> maxb: what happens around beta time?
[08:31] <poolie> bzr betas?
[08:32] <maxb> the usual api compatibility versioning nonsense mess
[08:33] <poolie> because of bzr changes?
[08:33] <poolie> oh, from 2.4b1?
[08:33] <poolie> :/
[08:33] <maxb> yes
[08:33] <maxb> and of course right up there in front in bzrtools
[08:35] <maxb> I have a lot of disbelieve that bzrtools 2.3.x cannot function reasonably with bzr 2.4
[08:35] <maxb> *disbelief
[08:35] <maxb> but it insists on being awkward
[08:36] <maxb> aaaaanyway. I should probably go to work
[08:36] <poolie> i agree
[08:36] <poolie> i mean i share your disbelief
[08:36] <poolie> i'd like to put up a patch to relax the check
[08:36] <poolie> either in bzrtools or bzr core
[08:37] <poolie> hi jam
[08:37] <jam> maxb: abentley prefers to make sure that at least the test suite passes before he "signs off" on it being compatible
[08:37] <jam> hi poolie
[08:39] <poolie> jelmer are you up yet?
[08:40] <poolie> spiv, spm, i didn't getting a failure message from pqm
[08:40] <spiv> poolie: hmm!
[08:40]  * spm hi-fives spiv - troll successful;
[08:40] <poolie> i'm preitty sure
[08:42] <spiv> spm: it's cheating if you use your admin powers to crash the system to rig the result ;)
[08:42] <poolie> canberra must be more boring than i remembered
[08:43] <spm> poolie: 1, spm 0
[08:44] <bob2> haha
[08:46] <poolie> spm, so, seriously, is there any evidence?
[08:46] <poolie> hi bob2
[08:46] <bob2> 'evening
[08:46] <spm> poolie: that your patch crashed it? Idoubt it. the ui is independant of pqm itself. I've not et chased why it crashed.
[08:48] <spm> poolie: when was your patch sent in? I'm not seeing anything in the log since about 10am our time, and that was something from jam
[08:48] <poolie> ah, i wonder if it even left my machine
[08:49] <jam> spm: last patch was about 1am my time I think. Which is, 23:00 UTC?
[08:49] <spm> jam: dat's der bunny
[08:49] <poolie> nup, stuck in postfix!
[08:49] <spm> poolie: that's impressive! that your patch didn't even hit pqm and still managed to crash the ui!!
[08:53] <spm> spiv: hrm. looks like it may have been down for a while. since ~ 8am on the 11th our time.
[08:53] <spm> no reason why, just no running, afaict.
[08:55] <spiv> spm: hmm.  Please arrange the cosmic ray reflectors in the data centre to point at someone else's box, thx.
[08:55] <poolie> spm, you know bradm did the upgrade to lucid the other day?
[08:55] <poolie> ok, apparently a change to my internet setup was causing my mail to queue up here
[08:55] <poolie> it should have left now
[08:56] <spm> poolie: that was just in the chroots aiui?
[08:56] <poolie> yes, we copied the chroot, upgraded the new copy, and pointed pqm at that
[08:56] <poolie> so it should not have caused pqm to stop running
[08:56] <poolie> unless the config change had a typo or something
[08:56] <spm> hrm. the timing is sus
[08:57] <spm> very sus. aligns perfectly. I'd say that was it. something about the chroot upgrade crashed it.
[08:57] <jelmer> poolie: hi
[08:58] <spm> hey jelmer
[08:58] <jelmer> hey Steve
[08:59] <poolie> spm, but other pqm requests do seem to have got through in the interim
[08:59] <jelmer> maxb: having bzrtools in experimental seems reasonable
[09:00] <spm> poolie: for sure. the UI isn't needed to get stuff thru pqm; it's actually a very separate process(?) within the same code.
[09:00] <jam> poolie: are we doing the standup now?
[09:00] <maxb> ok, I'll look at that after I've got 2.4b1 done for all series
[09:04] <poolie> yes, it's time
[09:05] <jam> poolie: jelmer spiv and I are in mumble
[09:06] <poolie> hm having some trouble getting in
[09:06] <jam> poolie: mwa-ha-ha-haaaa!
[09:07] <jelmer> jam: your laugh is particularly diabolical today ?
[09:10] <jelmer> poolie: you've muted me, I can't unmute myself as far as I can tell
[09:11] <poolie> oop
[09:11] <poolie> why would i do that? :)
[09:20] <poolie> jam perhaps you should take more inprogress bugs onto your kanban
[09:21] <poolie> Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie
[09:22] <poolie> jelmer, https://wiki.ubuntu.com/UDS-O#preview
[09:43] <poolie> spiv, spm, i did get back an apparently real failure
[09:44] <poolie> i wish our pqm failures were a bit more to-the-point
[10:58] <poolie> SRU progressed, yay!
[10:58] <poolie> http://wiki.bazaar.canonical.com/UbuntuStableReleaseUpdates#preview
[11:10] <maxb> Yay
[11:10] <maxb> Give Karmic's impending EOL, any objections to changing "not urgent" to "not going to happen" ?
[11:12] <jelmer> maxb: I think so
[11:12] <poolie> +1
[11:13] <poolie> i would like to get the lucid one out though
[11:13] <poolie> someone asked about it the other day
[11:13] <maxb> poolie: Oh, if you really want to test in a ppa, if you define a new dput configuration stanza using incoming = ~%(ppa)s/ubuntu/maverick, the trailing path segment will override the specification in the changelog and changes file
[11:13] <poolie> perhaps this will get faster
[11:13] <poolie> maxb maybe you should apply for upload rights too?
[11:13] <poolie> oh, that's useful
[11:13] <poolie> could you add that to the page if you're changing it?
[11:13] <poolie> ok, really offline now
[11:13] <poolie> have a good night
[11:13] <poolie> or whatever
[11:13] <maxb> I'm not sure I recomment it however
[11:14] <poolie> i think on the whole there are probably enough checkpoints
[11:14] <maxb> Because it will cause .debs to exist in your ppa which are named and versioned like the primary archive, but are not the same build
[11:14] <poolie> right
[11:15] <maxb> yeah, maybe I should apply for PPU - between PPA stuff and Ubuntu process knowledge, I probably qualify
[11:32] <jml> poolie: your blog is down.
[11:32] <jml> http://sourcefrog.net/weblog/software/aesthetics/interface-levels.html fails
[11:33] <poolie> maxb: i would certainly endorse you
[11:34] <poolie> hi jml
[11:34] <poolie> i think the machine might be down
[12:44] <briandealwis> jelmer: thanks for the new bzr-git release.  But 0.6.0 complains that it needs dulwich >= 0.7.1 – which isn't available
[12:58] <briandealwis> …ah, but there is a dulwich-0.7.1.tar.gz available on jelmer's dulwich page, though it's not linked
[13:12] <jelmer> briandealwis: not linked where?
[13:29] <briandealwis> http://samba.org/~jelmer/dulwich/
[13:29] <briandealwis> Ah, it shows 0.7.0 twice
[13:29] <briandealwis> jelmer: ^
[13:30] <jelmer> briandealwis: should be fixed now
[13:30] <briandealwis> coolio, thanks.
[13:32] <briandealwis> jelmer: in case you want more nits, lp:bzr-git lists 0.5.4 as the latest and lp:dulwich lists 0.7..0 as the latest
[13:32] <jelmer> briandealwis: you mean the tags?
[13:37] <briandealwis> jelmer: both the latest file versions, and I guess the tags (they're listed as "milestones" with an open circle vs the closed circles for the other versions)
[13:37] <jelmer> briandealwis: the milestones aren't related to the tags
[13:38] <jelmer> briandealwis: the file versions on the site are updated automatically by Launchpad, I guess it hasn't picked them up yet
[14:10] <sambatyon> hey guys, I need some help. There is some file in the repository, the project file. This project file will be changed in my local branch but I don't want it to be commited, or updated nor pulled nor merged, or anything of the sort, since paths and other stuff are particularly to my environment. However the project needs to be in the main branch so new programmers can customized it. Is there a way to avoid these things to get caught by
[14:10] <sambatyon> bazaar in merges and things like that?
[14:18] <maxb> The standard solution is to keep a template file in the branch, and let developers copy it to a new name before making their local modifications
[14:18] <maxb> e.g. project.conf.template in the branch, people use it to create a project.conf locally
[14:21] <sambatyon> yes, I would do that… unfortunately I am not the admin
[14:26] <sambatyon> (and now it is too late for that)
[14:55] <gypsymauro> hi
[14:56] <gypsymauro> I'm trying to ceckout a working copy with sftp but I get this error: bzr: ERROR: Not a branch<EMAIL_ADDRESS>[14:57] <gypsymauro> any hint?
[14:57] <maxb> Ok... Is that location actually a branch? Does /home/bzr/.bzr/branch/format exist?
[14:59] <gypsymauro> yeah Bazaar Branch Format 7 (needs bzr 1.6)
[15:00] <maxb> OK, please try the command again with the -Derror flag and pastebin the output
[15:07] <gypsymauro> maxb: http://pastebin.com/WhdUW8A2
[15:07] <maxb> What version is Bazaar on the client side?
[15:08] <gypsymauro> the same on the server 2.1.2-1
[15:09] <gypsymauro> funny is that if I run bzr co on local machine it works
[15:13] <maxb> Please try running:
[15:13] <maxb> echo "get /home/bzr/.bzr/branch-format" | sftp<EMAIL_ADDRESS>[15:18] <gypsymauro> File "/home/bazar/.bzr/branch-format" not found.
[15:18] <gypsymauro> but there is that file
[15:19] <gypsymauro> doh...
[15:19] <mgz> spelling?
[15:19] <gypsymauro> two ssh processes on the same ip...
[15:21] <gypsymauro> sorry :)
[15:21] <gypsymauro> I need a cup of coffee..
[15:22] <mgz> maxb or someone, what's the right way of dealing with all these bzr (ubuntu) bugs poolie opened up?
[15:23] <mgz> I can mark it confirmed, but should I open it against bzr (upstream) where I have tracker rights?
[15:28] <jam> mgz: I would use "Also Affects Project"
[15:28] <jam> and add bzr
[15:28] <jam> and then we can decide what to do with the upstream portion
[15:29] <jam> I often close it with a "moving to upstream"
[15:29] <mgz> thanks jam.
[15:29] <jam> because we don't usually care about the status in a particular "Ubuntu" package
[15:29] <jam> It is unfortunate that you can't just say "this is Upstream" directly
[15:29] <mgz> just posting a commect on your bug 758652 as well.
[15:29] <jam> but I think there is a bug open in LP about it.
[15:29] <maxb> mgz: what bugs?
[15:29] <mgz> bug 686735 for eg. which I want to fix today.
[15:30] <jam> mgz: yeah, it looks like reporting bugs via apport defaults to making them private
[15:31] <jam> so Martin has to go through them and make sure there isn't anything personal included and manually make them public
[15:31] <mgz> right.
[15:31]  * jam doesn't like bottlenecking things through a single person
[15:40] <gypsymauro> suppose I move a repository from a machine to another , there is a way to udpate a local working copy to point to the new location of the repository?
[15:41] <jam> gypsymauro: if you are using a lightweight checkout "bzr switch --force"
[15:41] <jam> (--force if the old repo no longer is available)
[15:42] <gypsymauro> jam: not lightweight
[15:42] <jam> gypsymauro: heavy checkout then? 'bzr switch' still works
[15:42] <jam> if it isn't a checkout, and just a branch, and you want to update the push and pull locations
[15:42] <jam> use '--remember'
[15:42] <jam> bzr push --remember new-location
[15:42] <jam> etc
[15:43] <gypsymauro> doen with "checkout" is an heavy right?
[15:44] <vanguard> how much work would it be approx. to do i18n on the bzr cli?
[15:44] <jam> gypsymauro: yes
[15:45] <jam> vanguard: There are quite a lot of strings around. I think the biggest hurdle we ran into was that importing gettext is *slow*
[15:45] <jam> added something like 0.5s to every run
[15:45] <jam> I don't remember the details anymore, but that was a fair punishment for trying to do it.
[15:47] <vanguard> jam: so it is basically cancelled?
[15:49] <jam> vanguard: I don't think anyone has confirmed the results in a while (like a couple of years)
[15:49] <jam> so it might be wrong
[15:49] <jam> I know the guis are translated
[15:49] <vanguard> Explorer and qbzr are, bzr-gtk is not I think
[15:49] <jam> right
[15:50] <jam> I know bzr-gtk does import gettext
[15:50] <jam> it used to break when in a debugger because of gettext evil and the '_' operator
[15:50] <jam> (gettext would create a builtin '_' operator, but pdb uses '_' as the result-of-last-command variable
[15:50] <vanguard> maybe it just has no german l10n. What is the gettext evil?
[15:50] <vanguard> right, I see
[15:50] <jam> which would then break like mad when bzr-gtk would try to _() a string)
[15:51] <vanguard> so the _ is not that clever in python I gather
[15:55] <gypsymauro> there was a new file, I made a ci and it marked aas unknown, now if I do a bzr add it doesn't add it :/ the default is recursively right?
[15:56] <jam> gypsymauro: what does "bzr status" say?
[15:57] <jam> add is recursive by default, yes
[15:57] <jam> The file might be ignored?
[15:58] <gypsymauro> it says, unkown: pathofthefile
[15:58] <jam> gypsymauro: if it shows up as unknown, then it should be added by plain 'bzr add'
[15:58] <jam> Only thing I can think is if you have a secret subtree that is in the way
[15:59] <gypsymauro> uh
[16:00] <gypsymauro> no
[16:00] <gypsymauro> I defenitely need a coffee
[16:00] <gypsymauro> you can see the status if you are in a different subtree
[16:00] <gypsymauro> but bzr add doens't works globally
[16:00] <gypsymauro> u need to be on the root
[16:00] <gypsymauro> or on the right folder
[16:02] <jelmer> jam, vanguard: bzr-gtk uses _i18n rather than _()
[16:02] <jelmer> the gettext import overhead is negligable these days
[16:02] <jam> jelmer: it does *now* it didn't many moons ago
[16:03] <jam> AIUI, it does specifically because of that
[16:03] <jelmer> jam: Yes, exactly
[16:03] <gypsymauro> can bzr and svn work on the same working copy? :) I mean I've a project that is mantained by a guy that uses svn , but I want to keep the revision on my own too, can they live togheter?
[16:03] <jam> jelmer: are you including the time to install the specific language, etc for gettext?
[16:04] <jam> "import gettext" is pretty fast, but ISTR it costing more to actually set up translations, et.c
[16:04] <jam> gypsymauro: you can, but things get weird if you install bzr-svn and try to share a working tree
[16:04] <jelmer> jam: I'm not sure about that, this is the overhead on my system (which has LC_ALL=en_IE.UTF-8)
[16:04] <jam> (bzr-svn lets you checkout from subversion as though it were a bzr branch, etc)
[16:05] <jam> jelmer: my point is that it isn't just 'import gettext', I don't remember the specific invocation, though.
[16:06] <jelmer> jam: binding to a specific gettext domain, etc is included (but without any actual translations present)
[16:06] <gypsymauro> jam: oh no I want just let him to work on his project with svn , but I want to keep track of theproject on my own with bzr
[16:06] <jelmer> I'm not sure how worried we are about overhead for users without i18n enabled vs the overhead for users who do want i18n
[16:06] <jam> jelmer: you haven't actually said what the overhead is :)
[16:07] <jam> gypsymauro: jelmer is the man to talk to. Anyway, I need to go do family time. See you guys later.
[16:07] <jelmer> jam: have a nice evening :)
[16:07] <jelmer> jam: I said negligable, which can mean anything.. ;-)
[16:07] <jelmer> I'll get some more details
[16:07] <jelmer> gypsymauro: you should be able to just "bzr branch <svn-url>"
[16:09] <gypsymauro> jam:  tank you :D
[16:10] <gypsymauro> jelmer: ?
[16:10] <gypsymauro> I've already a working copy I want to create a new repository from it
[16:10] <jelmer> gypsymauro: you'd like to create a bzr branch from a svn repository?
[16:12] <jelmer> sorry, from a svn working copy?
[16:13] <gypsymauro> I'm not sure what u mean with "branch" , I mean that I want to version a svn working copy with bzr :)
[16:14] <gypsymauro> something like cvs add
[16:17] <jelmer> gypsymauro: so you'd just like to version the entire tree, without preserving any of the existing svn history?
[16:17] <jelmer> gypsymauro: in other words, the fact that it's a svn working copy isn't really relevant?
[16:18] <gypsymauro> jelmer: exactly
[16:19] <jelmer> gypsymauro: see the bzr in 5 minutes guide
[16:19] <jelmer> (http://doc.bazaar.canonical.com/latest/en/mini-tutorial/index.html)
[16:19] <jelmer> basically - "bzr init; bzr add ."
[16:36] <gypsymauro> tank you jelmer
[16:51] <mgz> vanguard: I'm curious, why do you want to work on making the cli german rather than just qbzr/explorer?
[16:53] <mgz> most devs I know, even the ones with localised web browsers and so on, don't expect native command line tools.
[16:53] <mgz> and the gnu stuff pisses the hell out of my by guessing my prefered language incorrectly.
[16:56] <briandealwis> Does anybody know if I can do a bzr-svn dpush from a loom or a pipeline?  I'm looking to "hide" some (orthogonal) local patches required to get the tree in a running state on my machine.
[16:58] <jelmer> briandealwis: Somewhat; if you don't dpush the tip of the pipeline then you'll have to rebase the unpushed pipes after dpushing
[16:59] <briandealwis> Ok, makes sense.  Unfortunately I'm working against an old Subversion installation that won't be upgraded, and I want to avoid polluting with file-properties.
[16:59] <briandealwis> Thanks Jelmer
[17:05] <jelmer> does anybody else have trouble accessing e.g. https://code.launchpad.net/~maxb/bzr-builddeb/no-error-unknown-distro/+merge/56998 when logged in?
[17:06] <maxb> trouble?
[17:06] <jelmer> I get a 403
[17:06] <maxb> How odd
[17:07] <maxb> I can see it fine, anonymous, as ~maxb, and as ~maxb-autobuild
[17:07] <jelmer> it's fine now if I refresh but I can confirm it from two machines
[17:08] <jelmer> maxb: what about the MP linked from https://code.launchpad.net/~spiv/bzr-loom/plugin-init ?
[17:08] <maxb> fine
[17:08] <maxb> oh, the MP
[17:08] <maxb> the MP OOPSes
[17:08] <maxb> Shall we transfer to #launchpad-dev ?
[17:09] <jelmer> sure
[18:07] <dpm> hi jelmer, all set for your appdeveloperweek session later on?
[18:08] <jelmer> dpm: still working on some notes, but ready otherwise
[18:08] <dpm> jelmer, excellent. Thanks and good luck on the session!
[18:09] <jelmer> dpm: It's 4 hours from now right?
[18:10] <dpm> jelmer, yeah, at 23:00 for you, if you're on CEST -> https://wiki.ubuntu.com/UbuntuAppDeveloperWeek/Timetable
[18:11] <jelmer> dpm: Thanks
[18:11] <jelmer> dpm: Just double checking, it wouldn't have been the first time I missed up a tz :)
[18:11] <jelmer> *messed
[18:11] <dpm> jelmer, no worries, thank _you_ :)
[18:11] <Fidelix> Hello. I have some files in an Unix remote server, and I'd like it to be a central place for developers to commit. How can I do that?
[18:16] <LeoNerd> Most likely just something simple over ssh; either bzr+ssh, or sftp.
[18:17] <Fidelix> LeoNerd, was that for me?
[18:17] <LeoNerd> Yes
[18:17] <Fidelix> LeoNerd, how should I create the repository on the remote server?
[18:17] <LeoNerd> bzr push sftp://server/path/to/repo
[18:17] <LeoNerd> will create it if it doesn't exist
[18:17] <Fidelix> LeoNerd, but the files are on the server.
[18:18] <LeoNerd> Hmmm?
[18:18] <Fidelix> The files are already on the server.
[18:18] <Fidelix> The files are ONLY on the server.
[18:19] <LeoNerd> Just as bare files, not managed by bzr?
[18:19] <Fidelix> The project was started there. Using simple FTP.
[18:19] <Fidelix> LeoNerd, exactly.
[18:19] <LeoNerd> I see.. Well... bzr init; bzr add them, bzr commit  to create the first revision... now it's a branch.
[18:19] <LeoNerd> Others can access that branch, check it out, commit to it, etc.. by any of the usual mechanisms
[18:19] <LeoNerd> Though note that not all transports can update a remote checkout after a push
[18:20] <Fidelix> LeoNerd, what is a transport? A user?
[18:20] <Fidelix> *an user?
[18:20] <LeoNerd> file or sftp or bzr+ssh or whatever...
[18:20] <LeoNerd> URL schemes
[18:20] <Fidelix> Oh, ok. Can bzr+ssh do that?
[18:21] <LeoNerd> Hmm.. pass. Not sure offhand. Try it out.
[18:21] <LeoNerd> There's a warning message if it doesn't.
[18:21] <Fidelix> OK. Thanks.
[18:21] <Fidelix> LeoNerd, what is "Lightweight Checkout" ?
[18:22] <LeoNerd> A checkout that doesn't haev a branch.
[18:22] <LeoNerd> Think like CVS checkouts
[18:22] <Fidelix> Alright. That's what I need. Thank you very much
[18:23] <Fidelix> Authentication (publickey) successful!
[18:23] <Fidelix> Secsh channel 1 opened.
[18:23] <Fidelix> bzr: ERROR: exceptions.UnicodeDecodeError: 'ascii' codec can't decode byte 0xe3 in position 15: ordinal not in range(128)
[18:28] <mgz> Fidelix: paste the full traceback somewhere? you possibly have some filenames that are not utf-8, or a misconfigured locale.
[18:28] <Fidelix> mgz, I closed the window, opened again, and it worked fine.
[18:29] <Fidelix> I'm using bzr explorer
[18:29] <mgz> I'm curious about what the actual error was, can you find it in .bzr.log and put it somewhere for me to see?
[18:29] <Fidelix> I believe it is this bug: https://bugs.launchpad.net/bzr-explorer/+bug/599860
[18:29] <Fidelix> yes, I'll paste.
[18:30] <Fidelix> mgz, where is bzr.log ?
[18:30] <mgz> I think explorer will tell you where to find it under 'about'.
[18:30] <mgz> otherwise run `bzr qversion` from the command line.
[18:34] <mgz> hm, not in about, can do Bazaar/All Commands... and type 'version' in the 'Command' drop down and hit okay, then scroll the output so you can see where the log file is.
[18:35] <Fidelix> mgz, I hope you don't mind... I removed some personal data. http://pastebin.com/H8vaabTX
[18:36] <mgz> that's fine.
[18:36] <mgz> actually, looks like the bug I am looking into *just this second* which is bug 686735
[18:37] <mgz> what's your qbzr version? that's something the explorer 'about' will tell you.
[18:38] <mgz> finally, in the parts you starred out, were there any non-ascii characters or % encoded URL bits?
[18:40] <Fidelix> mgz, http://felipefidelix.com/f/System_Information-2011-04-13_14.39.59.png
[18:41] <Fidelix> Not on the server, but on my computer, maybe... IF # is utf-8, which I don't think it is...
[18:43] <mgz> sorry, that's the other dialoge box, I wanted the info in Bazaar Explorer's Help/About Bazaar Explorer specifically the line that says for me:
[18:43] <mgz> QBzr 0.20.0.dev, ....
[18:44] <Fidelix> http://felipefidelix.com/f/About_Bazaar_Explorer-2011-04-13_14.43.57.png
[18:44] <mgz> The # should be fine indeed, just needed to check
[18:44] <mgz> thanks Fidelix.
[18:44] <Fidelix> No, thank you!
[18:45] <mgz> feel free to +metoo that bug I linked and I'll mark it confirmed.
[18:46] <Fidelix> Alright
[18:50] <mgz> wait, I... edited the wrong bug earlier >_<
[19:03] <TJNII_work_> I want to set up bzr to run a shell script on post_commit.  I'm looking at the docs, but I don't understand the naming system in .bzr/hooks.  Where should a script like this go?
[19:07] <TJNII_work_> The hooks page talks about "types": branch and server, but doesn't clearly state what the differences are, and the hooks help uses post_commit whereas the hooks page uses post-commit.
[19:09] <jelmer> TJNII_work_: the hooks are installed by bzr plugins, they're not shell scripts
[19:10] <jelmer> where do you see a reference to .bzr/hooks ?
[19:13] <TJNII_work_> wiki.bazaar.canonical.com/BzrHooks
[19:14] <TJNII_work_> under "Specify hooks in directories"
[19:14] <TJNII_work_> So I can't just have bazaar run a shell script on post_commit?  That is no longer supported?
[19:15] <TJNII_work_> I need soemthing server side.  Requiring all clients to install a plugin is unacceptable.
[19:15] <TJNII_work_> I was under the impression I could install a hook in the server .bzr direcroty and the "smart" protocols would activate it.
[19:22] <mDuff> TJNII_work_, I haven't kept up with bzr very closely, but I wasn't aware that server-side hooks were ever supported without a PQM.
[19:22] <mDuff> TJNII_work_, (...speaking of which, have you *considered* a PQM?)
[19:23] <mDuff> ...hmm. Actually, looking at that page, it looks like they are. Nifty.
[19:24] <mDuff> (supported since 1.6, apparently)
[19:24] <TJNII_work_> What is a PQM?
[19:25] <mDuff> a patch queue manager, a central daemon which receives and handles please-merge-my-branch requests (typically with configuration to support running unit tests, or voting on whether to accept the patch, or the like first)
[19:27] <mDuff> btw, http://doc.bazaar.canonical.com/latest/en/user-guide/hooks.html and http://doc.bazaar.canonical.com/latest/en/user-reference/hooks-help.html look relevant (the latter discusses exactly when hooks are run on the server)
[19:27] <TJNII_work_> I see.
[19:27] <TJNII_work_> Where is that documented?
[19:27] <TJNII_work_> Is is not in the users guide
[19:27] <TJNII_work_> The admin guide has a heading for it, but no content.
[19:28] <mDuff> https://launchpad.net/pqm is one particular PQM instance
[19:28] <TJNII_work_> Yea, I'm looking at those pages, but they don't clearly define what pathing bazaar uses
[19:29] <TJNII_work_> Would it be .bzr/hooks/branch/post_commit?  Or .bzr/hooks/branch/post-commit?  or .bzr/hooks/server/post_commit?  I don't know.
[19:30] <mDuff> Docs clearly specify "the plugins subdirectory of your configuration directory" should have a Python plugin that installs your hook.
[19:31] <mDuff> ...so you're writing Python code rather than a shell script (even if it's Python code that starts a shell script)
[19:32] <mDuff> ...in the initial BzrHooks wiki page you pointed at, support for shell scripts is listed as a "desired improvement", not a feature.
[19:35] <TJNII_work_> Oh, I see.  So even though the docs clearly say "In addition to plugins installing hooks, users can provide shell scripts to run when hooks are triggered. The scripts to run for hook xxx are specified in the following directories: " it doesn't actually do that.  Which is kinda documented in the "Requested Improvements (Dec 2007)" block.
[19:35] <mDuff> ...well, you'd want someone who actually knows the code (or is at least willing to grep it) to give a _conclusive_ answer
[19:38] <mDuff> ...but having a behavior that's documented only in the wiki but not the manual isn't exactly confidence-inspiring.
[19:38] <mDuff> oh, that's under "ideas"
[19:39] <mDuff> "Configuration Ideas"
[19:39] <mDuff> ...so yup, that would clearly look to be brainstorming for future implementation.
[19:43] <lifeless> TJNII_work_: there is a plugin that will run shell scripts of your choice on actions
[19:43] <lifeless> TJNII_work_: you can install that server side
[19:43] <lifeless> TJNII_work_: as long as folk use bzr:// to push it will run.
[19:44] <lifeless> I don't remember its hane, sorry - but jelmer may.
[19:44] <TJNII_work_> lifeless: Where?  I'm looking for it and not finding it.  If you know the URL that would help greatly
[19:44] <TJNII_work_> The plugins page lists shell-hooks, but that's dead
[19:44] <TJNII_work_> Nothing on the site
[19:45] <lifeless> thats what I was thinking of I suspect
[19:45] <TJNII_work_> Yea, there's a trunk directory from 2008 that is empty.  No code.
[19:45] <TJNII_work_> So, what would the python script / plugin need to be named?  post_commit_hook.py?
[19:47] <mDuff> TJNII, ...the plugin's name doesn't matter -- it's the contents that do the registrations
[19:48] <mDuff> TJNII, umm, you say "empty" -- it's a bzr repo
[19:48]  * TJNII_work_ smacks his forehead
[19:48] <TJNII_work_> duh.
[20:35] <maxb> OK, this is not so bad. All plugins in ~bzr/beta install and at least load except bzrtools bzr-pipeline and bzr-svn
[20:36] <maxb> abentley: What stage in the 2.4 beta process are you likely to release compatible versions of bzrtools and bzr-pipeline?
[20:37] <abentley> maxb: probably when bzr 2.4.0 goes gold.
[20:38] <maxb> ah. I should probably think about snapshot .debs then
[20:39] <abentley> maxb: currently, these are both slow-moving projects whose trunk declares compatibility.
[20:41] <abentley> maxb: The whole versioning thing is a mess, as we recently discussed on the list.  But I would expect the last release of bzrtools to work with beta versions of bzr.  It doesn't?
[20:43] <maxb> Oh!
[20:43] <maxb> It looks like we may have mis-transliterated its internal API versioning into debian package dependencies
[20:45] <abentley> maxb: Yeah, it wouldn't be compatible with final bzr releases, but it shouldn't complain about betas.
[20:55] <maxb> Ah....
[20:55] <maxb> bzrtools special-cases 'dev' but not 'beta'
[20:55] <maxb> So it will work, but it will warn
[20:57] <abentley> maxb: Oh.  I was assuming that betas were dev, since they're not releases.
[20:58] <maxb> They're beta releases :-)
[20:58] <maxb> Perhaps != 'final' would be best?
[21:00] <abentley> maxb: perhaps.  API changes can still happen in the betas, right?
[21:01] <maxb> IIRC we pick a specific beta as the start of API freeze? Usually the last beta?
[21:02] <maxb> (so, yes)
[21:05] <abentley> maxb: It doesn't make sense for bzrtools to claim compatibility with 2.4 until it the final bzr 2.4 API is available, so there ought to be a way for bzrtools to work with betas.
[21:05] <mDuff> -
[21:05] <maxb> Right - so, treat 'beta' and 'dev' version classes the same
[21:06] <abentley> maxb: okay, I'll look into revamping the versioning of pipeline and bzrtools so that they work with the subsequent betas.
[21:07] <maxb> Great!
[21:07] <maxb> bzrtools works now, except that it claims that bzrtools 2.4 should be available if you run it against a beta release
[21:10] <abentley> maxb: Yes.  For now, I guess snapshots are the way to go.
[21:58] <orospakr> Hey, can I delete tags from a repository (not a branch)?
[21:58] <orospakr> for that matter, how can I get the equivalent of "bzr log" from a repository?
[21:59] <fullermd> Oh, removing tags from a repository is easy.  You just...  do nothing   :).  Tags are in branches, not repos.
[22:01] <orospakr> ah, I found another way around my problem. nvm.