[18:25] <zequence> holstein: Actually, len may be doing more coding than me, so there's at least the two of us :).
[18:26] <zequence> I'm not burned out, so don't worry about me
[18:27] <holstein> oh, im not worried that you are burned out
[18:27] <zequence> But, there is a problem with how we deal with a lot of stuff - mainly because our community is too small
[18:27] <holstein> its that, you *will* .. since, there is literally no plan in place to swap leads
[18:27] <holstein> you just go, til, somewhere, behind closed doors, you hand it off to someone
[18:27] <zequence> That's not my plan though
[18:27] <holstein> we should just document it as such, thats all
[18:28] <zequence> My plan has always been to have an election, but for one to take place - with members who know what they are voting for, we need more people actively involved
[18:28] <zequence> Also, there needs to be more than one other person to vote for
[18:28] <holstein> i assure you, im not interested in beind lead
[18:29] <holstein> i was, as i told you, personally, in PM,when the lead position was handed over to you, interested in entertaining someone like falk, or the AVlinux creator.. for example
[18:30] <zequence> Can't hand anything over to anyone who doesn't do Ubuntu Studio development
[18:30] <holstein> lol
[18:30] <zequence> The only way to do this is to do this
[18:30] <holstein> they would do whatever it takes, and be voted on..
[18:31] <holstein> anyways, ideally, i think it was be great if you or len were MOTU's.. whatevrer sponsorship, $$, or work  that takes..
[18:31] <zequence> I have upload rights for our packages, so that's always something
[18:31] <zequence> I also have access to Debian multimedia sources
[18:32] <zequence> Neither falktx or the AVLinux guy (to my knowledge) have been even trying to get into that
[18:32] <zequence> That's kind of the problem
[18:32] <holstein> right
[18:32] <holstein> and why?
[18:32] <holstein> why are we not attracting that kind of talent?
[18:32] <zequence> No one is stopping them
[18:33] <holstein> right.. so, again... why?
[18:33] <zequence> It's up to them what they want to do
[18:33] <holstein> what limitations? can we do something to attract them? do we need to? etc..
[18:33] <zequence> It's not like there there are a lot of barriers in the way
[18:33] <zequence> It's pretty open to whoever has the interest
[18:33] <zequence> If you don't have the interest, well..
[18:34] <holstein> you would think.. so whats up?
[18:34] <holstein> thats all i would like to know, and address
[18:34] <holstein> is it upstream? is it not having support in the work flow? is it *us* here? etc
[18:34] <zequence> I think it's mostly personal stuff, but that's my opinion
[18:34] <holstein> not that we have to make it a goal to be attractive.. but, why are folks not working with us, and making their own stuff?
[18:35] <zequence> No one here is stopping anyone from doing stuff
[18:35] <zequence> falktx doesn't want to do things the hard way - following a policy made by a community
[18:35] <holstein> right.. the door is open, i get that.. but to what?
[18:36] <zequence> That's my interpretation of what he told me, anyway
[18:36] <zequence> He likes to do things his own way.
[18:36] <zequence> That doesn't work
[18:36] <holstein> nah
[18:36] <zequence> I mean, to a limit
[18:36] <holstein> thats what ubuntu is ;)
[18:36] <holstein> someone setting up a way, and the community following it, and re-defining it
[18:36] <holstein> falk is talented. if he wanted to get more involved upstream.. etc
[18:37] <zequence> Everyone is welcome to continue the work, but you also have to respect the work
[18:37] <holstein> anyways, its deoesnt have to be falk..
[18:37] <holstein> do you have to repect the work?
[18:37] <zequence> None of falktx applications have been packaged in Debian yet
[18:37] <holstein> respect what work? where?
[18:37] <holstein> you mean, they have to "respect upstream"? and who does? anyone?
[18:37] <zequence> What work? The work that the community does, for Debian, and Ubuntu
[18:37] <holstein> its not documented that respect is part of the equation.. etc..
[18:38] <zequence> You have to respect the policies, and other stuff that the community has agreed on, in one way or another
[18:38] <zequence> YOu cant just bypass everything
[18:38] <zequence> But, if you want to, you can always start your own distro
[18:39] <OvenWerks> Part of the limitation with US is that we have to work with our repo. Often the version of a major app or utility we are stuck with in an LTS ends up broken.
[18:39] <holstein> well, there was a suggestion to breakk it off into a PPA
[18:39] <holstein> which, i think is a valid conversation
[18:39] <OvenWerks> Jackd2 in 14.04 as an example.
[18:40] <OvenWerks> putting it in a ppa, makes it the same as falk's work
[18:40] <holstein> if we, based on work flow, are *always* limited by that, and releasing something that is always behind, or, not good enough, then, its something to discuss, for sure
[18:41] <zequence> I got to go, sorry. But, I will be available a lot more the coming week. Planning to do a lot of work then.
[18:41] <holstein> anyways, this is the kind of thing we can discuss at meetings.. which, i will hopefully be having time for setting up in the fall
[18:41] <OvenWerks> I am speaking from mostly an audio POV for sure as I don't do enough of anyting else
[18:43] <holstein> i would like to speak constructively about how to identify, and potentially address what may keep contributors from joining
[18:43] <holstein> "respect" is not a requirement ;)
[18:44] <OvenWerks> encouragement probably is
[18:44] <holstein> its not documented anywhere that i know of.. folks disagree all the time, and identify, and address, and change things.. it doenst have to be a sign of disrespect to want to change things..
[18:44] <OvenWerks> I agree
[18:45] <holstein> i would just like to brainstorm.. why do folks start their own spins, instead of contributing here, to US
[18:45] <holstein> if its because we are always limited to the repo, can we address that? do we need to maintain an official port, etc..
[18:46] <holstein> if its, "its just too hard to properly work with upstream ubuntu", then, we need to mention that to upstream, and see about getting a liason, or whatever..
[18:46] <OvenWerks> If you look at kzstudio, it always has the latest fixes. Even quicker than they get to debian, let alone ubuntu.
[18:47] <holstein> yup
[18:47] <holstein> and if thats the appeal, how do we compete with that? and do we need to?
[18:47] <OvenWerks> The day after (hour after?) ardour 4.1 was out, it was in kxstudio
[18:47] <holstein> ubuntu-mate is going to implement some form of 'work flows' soon.. meta packages for different production
[18:47] <holstein> are we being made irrelevant?
[18:48] <holstein> we dont contrbute any code, other than the low latency kernel, AFAIK
[18:48] <holstein> so, could we just do that? just be "the ubuntustudio kernel"..?
[18:48] <OvenWerks> When people ask for a recomended distro, it is almost never Studio.
[18:48] <holstein> again.. just brain storming.. but, having a kernel, in the main repo, that works well.. that would contribute to everyone..
[18:49] <OvenWerks> Yes.
[18:49] <holstein> OvenWerks: its always specifically, that ubuntustudio is *not* a good choice
[18:49] <OvenWerks> kx uses it :)
[18:49] <holstein> OvenWerks: i challenge it, and am usually met with "ok, i havent actually tried it in years".. or whatever
[18:50] <holstein> but still.. its a bad reputation.. and i would like to, from the ground up, look at all the moving parts.. or, non-moving parts, and see what we need to do to fit whatever goals it is we have
[18:50] <holstein> who is we? etc..
[18:50] <OvenWerks> holstein: I think there are some things in the linux world that are not generally done right for audio.
[18:50] <holstein> OvenWerks: for audio production, for sure.. and are we always burned by that? if so, the PPA thing sounds like a good idea
[18:51] <holstein> though, then, we compete with falk..
[18:51] <OvenWerks> right
[18:51] <holstein> i have to run, or i will miss the double gigs i have.. cheers!
[18:51] <OvenWerks> I think the (semi)pro audio linux world needs to start with running jack from session start
[18:51] <OvenWerks> holstein: o/


[02:21] <lotuspsychje> good morning
[21:57] <PeGaSuS> hey guys. I wonder if Ubuntu has some application like Microsoft has the Family Safety one, to allow kids to use the only only during the specified schedule
[21:59] <oerheks> there is a sort of parental control
[21:59] <oerheks> https://help.ubuntu.com/stable/ubuntu-help/parental-controls.html.en
[22:00] <oerheks> and timekeeper https://ubuntuhandbook.org/index.php/2021/11/time-limits-for-kids-ubuntu/
[22:02] <JanC> isn't that more like a challenge for kids to hack their parent's computers?  :P
[22:02] <oerheks> a timekeeper on your router is more effective
[22:03] <JanC> or to hack the router
[22:04] <JanC> which is usually trivial (just factory reset it)
[22:08] <PeGaSuS> thanks!


[12:31] <jdong> Riddell: kinda a late answer, but yeah, the second upload of ktorrent (-0ubuntu3) was confirmed to close bug 130300 by several people
[12:31] <ubotu> Launchpad bug 130300 in feisty-backports "[gutsy]  ktorrent 2.2.1-0ubuntu1 crash when I quit the program when uPnP plugin is loaded" [Undecided,In progress]  https://launchpad.net/bugs/130300
[04:46] <nixternal> what happened to openoffice.org base?
[04:47] <nixternal> seeing as we got rid of kexi as our default dbase app
[09:32] <_StefanS_> Riddell: morning.. I'm preparing that list of files now
[09:32] <Riddell> great
[09:33] <_StefanS_> Riddell: yea sorry for not providing it earlier, but had to attend to family stuff
[09:36] <Riddell> fair enough
[09:38] <_StefanS_> Riddell: the other updates I got today in lpia were they because of the changes to the packages you uploaded ?
[09:39] <_StefanS_> Riddell: because of dependencies I mean..
[09:39] <Riddell> dunno, depends on what the updates were
[09:39] <_StefanS_> uhm ok..
[09:39] <_StefanS_> argh.. seems like the new updates has screwed up includes for gcc
[09:39] <_StefanS_> Riddell: /usr/include/bits/types.h:31:20: error: stddef.h: No such file or directory
[09:40] <_StefanS_> and bunch of other stuff as well
[09:40] <_StefanS_> hmm
[10:04] <_StefanS_> Riddell: configure: error: Your Installation isn't able to compile simple C++ programs.... great.
[10:04] <_StefanS_> Riddell: know where to start ? libstdc++ is installed
[10:05] <_StefanS_> hey hobbs
[10:07] <Hobbsee> hi _StefanS_
[10:09] <Riddell> g++ installed?
[10:16] <_StefanS_> Riddell: yep
[10:17] <_StefanS_> Riddell: linux-headers, libstdc++* , glibc
[10:17] <_StefanS_> Riddell: gcc3, gcc4.x, g++
[10:17] <_StefanS_> I dont get it
[10:22] <Riddell> _StefanS_: what are you trying to compile?
[10:23] <_StefanS_> Riddell: digikam, libnjb.. nothing works anymore
[10:23] <_StefanS_> Riddell: cant even compile simple c++ programs
[10:25] <_StefanS_> Riddell: checking if C++ programs can be compiled... no :)
[10:26] <Riddell> "error: stddef.h: No such file or directory" hmm
[10:26] <_StefanS_> yea..
[10:29] <Riddell> njb is complaining about no libusb headers
[10:32] <_StefanS_> yep
[10:32] <_StefanS_> but I thats even when they're installed :)
[10:32] <Riddell> go complain to doko I guess
[10:33] <_StefanS_> done..
[10:33] <_StefanS_> Riddell: whats inifinity's mail address?
[10:34] <Riddell> adam.conrad@ whatever
[10:34] <Riddell> doko@ubuntu too
[10:34] <Riddell> (for doko obviously)
[10:37] <_StefanS_> yep ok
[10:40] <_StefanS_> Riddell: adam.conrad<at>ubuntu.com ?
[10:42] <Riddell> yes
[10:43] <_StefanS_> mail sent.
[10:43] <Riddell> mepis's KDE 4 CD uses my KDE 4 packages, despite slagging off Ubuntu and changing to Debian
[10:43] <Riddell> oh and there's no source for them
[10:44] <_StefanS_> not really professional is it ? :)
[10:44] <_StefanS_> guess thats a breach in GPL as well..
[10:45] <Riddell> somehow kicker seems to be working though
[10:45] <_StefanS_> shouldn't it?
[10:45] <Riddell> didn't for me
[10:45] <_StefanS_> Riddell: doko is looking into that wierd build issue.. its gcc-4.2 that has problems
[10:46] <_StefanS_> Riddell: hope that mail I sent is somehow understandable. Atleast you have debdiff this time :)
[10:47] <Hobbsee> Riddell: just change them to work only with kubuntu :P
[10:48] <_StefanS_> I can help with introducing random bugs if its not running on kubuntu :D
[10:48] <Hobbsee> that's the one
[10:48] <_StefanS_> :)
[11:00] <_StefanS_> Riddell: oh doko found the bug
[11:25] <Riddell> glatzor: software-properties-gtk --no-update  still does an update on close
[11:30] <glatzor> Riddell: indeed. this is a bug.
[11:32] <Riddell> glatzor: I'm implementing the opposite for -kde (so it has an update option), want me to implement --no-update for gtk?
[11:36] <glatzor> Riddell: we could also remove the option at all.
[11:39] <Riddell> glatzor: I need it for calling from adept, it has its own updater
[11:39] <glatzor> but this would require to patch the synaptic patch
[11:39] <glatzor> Riddell: the gtk frontend only performs a check if there isn't any transient_for
[11:40] <glatzor> but this is wrong
[11:43] <glatzor> Thanks for pointing me at this
[11:44] <glatzor> Riddell: the infimport module of guidance does not get shipped in the guidance-backends
[11:44] <glatzor> https://bugs.launchpad.net/ubuntu/+source/kde-guidance/+bug/131669
[11:44] <ubotu> Launchpad bug 131669 in kde-guidance "guidance-backends does not include the new infimport module" [Undecided,New]
[11:45] <Riddell> let me fix that
[12:13] <Riddell> glatzor: you didn't add it to setup.py so it wasn't being installed.  fixed in svn and uploaded to ubuntu
[12:15] <glatzor> Riddell: oh, I mainly work in a displayconfig only subtree. :)
[12:16] <Riddell> :)
[02:07] <Riddell> no amarok packaging volunteers yet?
[02:07] <Hobbsee> seems not
[02:10] <Riddell> I'll do it thursday morning if nobody has stepped up by then
[02:11] <Hobbsee> Riddell: check with imbrandon, i guess, but feel free to take it
[02:20] <\sh> amarok? new version for gutsy or updates for feisty?
[02:23] <_StefanS_> Riddell: networkstatus still depends on kdepimmacros.h.. how to do solve that the easiest way ? (I'm getting good progress on compiling it, btw)
[02:23] <Hobbsee> \sh: the former
[02:24] <_StefanS_> Riddell: I'm talking about kdelibs+networkstatus, in case you forgot about it :D
[02:24] <Riddell> \sh: gutsy
[02:25] <Riddell> _StefanS_: if it's just a bunch of macros you could probably just copy the .h files to kdelibs?
[02:25] <_StefanS_> Riddell: I'll try that.
[02:25] <\sh> Riddell: Let me check this evening at home :) hopefully my buildserver is back then
[02:28] <Riddell> \sh: ftp://ftp.kde.org/pub/kde/stable/amarok/1.4.7/src/amarok-1.4.7.tar.bz2 is where it's at
[02:28] <_StefanS_> Riddell: seems to work now. Just put kdepimmacros.h in networkstatus/ dir. It actually just includes two regular .h files (kdeversion, kdemacros.h + a define check)
[02:28] <Riddell> although that location (on a public ftp server) is top secret
[02:29] <_StefanS_> I guess if you told him now, you have to kill him :D
[02:30] <Hobbsee> Riddell: there's something seriously wrong with that statement...
[02:30] <\sh> Riddell, noted
[02:33] <Riddell> Hobbsee: tis not for us to question the wisdom of apachelogger
[02:34] <Hobbsee> Riddell: indeed.
[02:39] <apachelogger_> hm
[02:39] <apachelogger_> oh
[02:39] <apachelogger_> eh
[02:39] <apachelogger_> lol :P
[02:40] <apachelogger_> Riddell: gotta change that for .8 or 2.0 beta1, whichever comes first
[02:40] <apachelogger_> yesterday some news sites told 1.4.7 was out
[02:40] <apachelogger_> so either we have a mole or they just watched the server
[02:40] <apachelogger_> though I think the latter might be a boring job
[02:40] <Hobbsee> apachelogger_: wasnt me...
[02:41] <Hobbsee> yes, yes, it's all jdong's fault.
[02:41] <Hobbsee> !jdong | jdong
[02:41] <ubotu> jdong: jdong is Hobbsee: jdong: yes, but you're FULL OF CRACK!
[02:41] <apachelogger_> markey is already investigating!
[02:45] <Riddell> these things are scriptable
[02:46] <Riddell> apachelogger: the correct way to do it is to just change the permissions to not be chown ftprelease:packages and not be readable to other
[02:47] <Riddell> infact it already is, so just chmod 660
[02:48] <apachelogger> Riddell: well, I'm not sure whether everyone who gets packaging notifiation for amarok has an packager account on ktown
[02:48] <_StefanS_> Riddell: do you know if 'networkstatustestservice' is needed from networkstatus ?
[02:48] <apachelogger> I guess I'll just store the next release on amarok.kde.org until official release
[02:48] <Riddell> _StefanS_: I've no idea
[02:48] <_StefanS_> Riddell: its put under noinst_PROGRAMS in the Makefile.in
[02:49] <_StefanS_> Riddell: although the networkstatus.install seems to want to install it
[02:49] <Riddell> probably not then
[02:49] <_StefanS_> thanks for the help :D
[02:49] <_StefanS_> and all the fish.
[02:58] <_StefanS_> Riddell: should I strip out the .svn entries from inside networkstatus/ or do you want to keep them for reference?
[02:59] <Riddell> _StefanS_: I don't want them
[02:59] <_StefanS_> Riddell: ok, I'll just remove them.
[03:00] <_StefanS_> Riddell: any way to recover when the diff's arent reversible in the source?
[03:00] <Riddell> work out why they aren't?
[03:00] <Riddell> debian/patches/*log
[03:00] <Riddell> something will have edited one of the files
[03:01] <_StefanS_> yes.. the file cant be found. Great.
[03:01] <_StefanS_> I'm just going to piece a new archive together
[03:02] <_StefanS_> cant bothered to figure that out
[03:06] <viviersf> is beagle or tracker gonna be installed by default in gutsy ?
[03:06] <manchicken> Is koffice2 alpha2 included in the kde4 packages?
[03:07] <Hobbsee> viviersf: tracker is already in ubuntulog
[03:07] <Hobbsee> viviersf: tracker is already in ubuntu
[03:07] <viviersf> Hobbsee, the thing is
[03:07] <viviersf> on a default install of gutsy i see tracker is installed
[03:07] <viviersf> but
[03:07] <Hobbsee> strigi is installed in kubuntu, iijrc
[03:07] <viviersf> i can remove it without affecting ubuntu-desktop
[03:08] <viviersf> how on earth does it get installed ?
[03:08] <Hobbsee> viviersf: recommends.
[03:08] <viviersf> hmmmf
[03:08] <viviersf> tracker doesnt seem to work tho
[03:10] <viviersf> or does it just takes long to build the database ?
[03:11] <Riddell> you'd need to ask on an ubuntu channel about tracker
[03:11] <Riddell> packages in section metapackage have their recommends installed by default
[03:12] <viviersf> kk
[03:12] <Hobbsee> even in universe, now!
[03:13] <Riddell> I'm sure that's always been the case
[03:13] <Hobbsee> no it hasnt
[03:13] <Hobbsee> only main before
[03:14] <\sh> Riddell, any branches on LP bzr hosts somewhere?
[03:14] <\sh> Riddell, speaking of amarok?
[03:16] <Riddell> \sh: no, but debian does so we should branch theirs and do the whole branch/merge thing
[03:16] <Riddell> and host on launchpad
[03:17] <\sh> Riddell, will have a look what we can do
[03:22] <manchicken> Riddell: Is there anything different that needs to be done?
[03:22] <manchicken> Riddell: Adept is getting kinda dull.  I'll still keep playing with it from time to time, but it would be nice to play with something else, too.
[03:24] <manchicken> Riddell: And I suppose I could be persuaded to play with Python if it meant something interesting to play with.
[03:25] <Riddell> manchicken: package qtjambi?
[03:25] <Riddell> also qdasher and qt accessibility bridge
[03:26] <manchicken> I could learn to package.
[03:26] <manchicken> Of those which would you like me to start on?
[03:26] <manchicken> first
[03:26] <Riddell> qtjambi I think
[03:27] <Riddell> place to start would be just to get it compiling and working
[03:27] <Riddell> I don't even know if it works with gcj or needs sun java
[03:29] <Riddell> manchicken: any idea why the description in adept is showing the maintainer?
[03:29] <Riddell> in adept_manager
[03:30] <manchicken> Riddell: Nope.  I asked the same question about a week ago.
[03:30] <manchicken> Is it doing that on your branch?
[03:30] <manchicken> That should be an easy solution.
[03:31] <manchicken> I think the kdesudo change is getting things wrong with the kvpnc launcher.
[03:32] <manchicken> Argh, it's a kdelibs5 issue.
[03:32] <manchicken> That's bad.  I can't work without kvpnc
[03:37] <Riddell> don't use KDE 4?
[03:44] <manchicken> I've got dingleberries from when I compiled it myself.
[03:44] <manchicken> for X in $(ls -1); do P="$PWD/$X"; Y=$(dpkg -S $P); if [ "$Y" = "dpkg: $P not found." ] ; then echo "$P"; fi; done
[03:44] <manchicken> That should tell me which ones are not packaged :)
[03:44] <manchicken> This is all in /usr/local/bin, too.
[03:45] <manchicken> But kdesudo is screwing up kvpnc
[03:45] <manchicken> I think it's running kvpnc as a different user than kdesu used to.
[03:49] <manchicken> I'll try copying some config files.
[04:15] <manchicken> Well, I had to reconfigure kvpnc (a task in and of itself), but not too terrible.
[04:16] <manchicken> Their new wizard is nice, but they need to stop assuming that everybody is familiar with the latest networking.
[04:16] <manchicken> I had to read up on CIDR subnet masks just to get the damned thing configured.
[04:16] <Riddell> that sounds like something out of 24
[04:16] <manchicken> heh
[04:17] <manchicken> You and your man-dramas.
[04:17] <manchicken> Although I can't really say anything there... I'm a CSI fan.
[04:19] <manchicken> It's just counting bits, and it makes sense once you see the wikipedia article, but it's definitely a different way of doing things than I've done before.
[05:14] <DaSkreech> HI Hobbsee
[05:15] <Hobbsee> heya DaSkreech
[05:15] <DaSkreech> How are you?
[05:16] <Hobbsee> doing OK
[05:16] <Hobbsee> working thru the sponsorship queue again
[05:26] <nixternal> good mornin' my lil Kubuntu'oblins
[05:27] <Hobbsee> uh, hi!
[05:32] <nixternal> snorts and grunts...i love it :)
[05:32] <DaSkreech> Zug zug!
[05:39] <nixternal> boo!
[05:40] <bddebian> Heya
[05:40] <bddebian> Hehe nixternal :-)
[06:21] <Riddell> apachelogger: http://svn.opensuse.org/svn/kio_sysinfo/trunk/
[06:21] <Riddell> now in svn
[06:21] <Riddell> apachelogger: dirk says to let him know if there's anything to merge
[06:23] <apachelogger> hooray :D
[06:24] <apachelogger> Riddell: iirc, the patches just made the whole thing more generic, use lsb file for system detection and rename the css file, nothing that might be interesting for them
[06:24] <Riddell> apachelogger: well that is interesting to them, they're looking to open it up to more distros
[06:25] <Riddell> so you could add kubuntu and/or kde artwork
[06:25] <apachelogger> well, gotta have a look into it and mail master dirk the patches then
[06:26] <Riddell> great
[06:26] <Riddell> you should be able to get an svn account too if they like you
[06:27] <apachelogger> muahaha, access to opensuse ^_^
[06:42] <ScarFreewill> when I try to install kde4 beta1 (apt-get -s install kde4base-dev) I get the following: kde4base-dev: Depends: kdelibs5-dev but it is not going to be installed and Depends: kdepimlibs4-dev but it is not going to be installed
[06:42] <ScarFreewill> i've got feisty aswell as feisty-backports in my repostory
[06:46] <Riddell> install kdelibs5-dev and work out why it isn't being installed
[06:47] <ScarFreewill> kdelibs5-dev: Depends: kdelibs5 (= 3.80.3-0ubuntu4) but it is not going to be installed + Depends: libqt4-dev but it is not going to be installed
[06:47] <Riddell> recurse
[06:48] <Riddell> 3.80 isn't beta
[06:48] <Riddell> feisty or gutsy?
[06:48] <ScarFreewill> i know i've got beta on atm want to install beta
[06:48] <ScarFreewill> feisty
[06:49] <ScarFreewill> i mean i've got alpha atm
[06:49] <Riddell> do you have feisty-backports enabled?
[06:50] <ScarFreewill> yes deb http://archive.ubuntu.com/ubuntu feisty-backports main universe multiverse restricted + deb http://archive.ubuntu.com/ubuntu feisty main universe multiverse restricted
[06:50] <ScarFreewill> that is all I have.
[06:53] <Riddell> what does  apt-cache policy kdelibs5  give you
[06:54] <ScarFreewill> should i past or paste bin or prt ?
[06:54] <ScarFreewill> *paste
[06:54] <Riddell> pastebin
[06:56] <ScarFreewill> http://paste.ubuntu-nl.org/33717/
[06:58] <ScarFreewill> my firefox also crashes randomly while running google's web chat I blame java vm but its just odd (first time i'm experincing some thing like this)
[06:59] <Riddell> google web chat doesn't use java
[07:00] <Riddell> ScarFreewill: it's not seeing backports
[07:00] <Riddell> run apt-get update  maybe
[07:00] <ScarFreewill> i've got a pin though just for testing
[07:01] <ScarFreewill> but i'm sure it was like this before the pin
[07:01] <Riddell> well the candidate is not from backports
[07:05] <ScarFreewill> now I'm getting http://paste.ubuntu-nl.org/33718/
[07:06] <Riddell> 17:46 < Riddell> install kdelibs5-dev and work out why it isn't being installed
[07:09] <ScarFreewill> http://paste.ubuntu-nl.org/33719/
[07:11] <ScarFreewill> kdelibs5 libsoprano-dev libqt4-dev not one of them installs either
[07:12] <Riddell> so.. do the same for them
[07:12] <Riddell> until you actually get a reason why it won't install
[07:14] <ScarFreewill> http://paste.ubuntu-nl.org/33720/ looks like its some qt libs
[07:16] <ScarFreewill> ok i think its qt4-core
[07:16] <ScarFreewill> http://paste.ubuntu-nl.org/33721/
[07:17] <Riddell> should be sorted now I expect
[07:28] <ScarFreewill> I've got another problem: Package dbus-x11 is not available, but is referred to by another package.This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package dbus-x11 has no installation candidate
[07:33] <ScarFreewill> it appears that dbus-x11 is only avalible for gusty
[07:36] <ScottK> ScarFreewill: There's a later version of the package that's demanding it in feisty-backports that doesn't need it.
[07:38] <ScarFreewill> ScottK: how do you recommend how I should install it ? i treid sudo apt-get -s -t feisty install dbus-x11
[07:42] <ScottK> I don't recall which package it is that wants dbus-x11, but whichever it is, it's been updates in feisty-backports to not need it anymore.
[07:43] <ScottK> I'd try sudo apt-get update and then apt-get -f install and see if it resolves.
[07:43] <ScarFreewill> ok
[07:45] <ScarFreewill> i'm still getting "kdelibs5: Depends: dbus-x11 but it is not installable"
[07:46] <ScottK> Hmmm.  Let me check something.
[07:48] <ScottK> OK.  That's a different package than I saw the bug on.  It was Bug #130542 that I was thinking of.  Sorry.  Dunno what you should do next.
[07:48] <ubotu> Launchpad bug 130542 in feisty-backports "strigi-daemon 0.5.4: Depends: dbus-x11 but it is not installable" [Undecided,Fix released]  https://launchpad.net/bugs/130542
[07:50] <ScarFreewill> ScottK: can i try to install the gusty pkg?
[07:50] <ScottK> ScarFreewill: I really have no idea.
[07:51] <ScarFreewill> i'll try it anyways ^_^
[07:51] <ScottK> I'm not personally playing with KDE4, I'd just seen the bug in backports.
[07:53] <ScarFreewill> I should most propperly make a bug report..
[07:54] <ScottK> ScarFreewill: Please do.  If the package you had the problem with is in feisty-backports, please file the bug in feisty-backports.
[07:54] <ScarFreewill> will do.
[09:30] <miles> hey i am interested in getting a mentor for development
[09:30] <miles> can someone give me some details?
[09:34] <ScottK> miles: It generally works better to find some task you want to work on (fixing bugs that annoy you is a good place to start), figure out what you can, and then ask specific questions.
[09:35] <miles> ok, so i cant get paired up with a mentor and follow their lead?
[09:39] <ScottK> I don't think there is a specific mentoring program for Kubuntu.  MOTU has one.  You can ask in #ubuntu-motu if that's what you are looking for.
[09:39] <miles> ok, thanks
[10:07] <_StefanS_> Riddell: packaging for kdelibs+networkstatus is done. I'll send it to you tomorrow.
[11:34] <ScottK> Riddell: If you have a moment to play archive admin would you?  I'm trying to get a sync done prior to UVF: Bug #132543
[11:34] <ubotu> Launchpad bug 132543 in pypolicyd-spf "Please sync pypolicyd-spf 0.4.1-1 from Debian Unstable (Main)" [Medium,Confirmed]  https://launchpad.net/bugs/132543
[11:35] <Riddell> ScottK: ask seb128, he's doing syncs this evening
[11:35] <ScottK> Riddell: I will.  Thanks.


[08:54] <xhaker> man-di, Hi, i'm wondering if you could help me get eclipse 3.3 into ubuntu gutsy :d
[10:01] <xhaker> anyone here willing to help packaging eclipse 3.3?
[10:01] <xhaker> man-di?
[10:03] <vil> yeah, man-di does all the fun stuff
[10:04] <vil> seriously, man-di, how can we help?
[10:04] <vil> last time you mentioned jetty
[10:05] <vil> is that still valid?
[10:11] <xhaker> vil, are you lapacek?
[10:12] <vil> xhaker, that's me :)
[10:12] <xhaker> ohh, atleast i can guess :D
[10:13] <xhaker> what's man-di real name?
[10:13] <xhaker> doko directed me to him/her
[10:14] <vil> hope that it's not secret :)
[10:14] <vil> type in /whois man-di
[10:14] <vil>  ;)
[10:15] <xhaker> had figured it out before
[10:15] <xhaker> omg
[10:16] <xhaker> that whois command is awesome <\sarcasm>
[10:16] <xhaker> i forget that in these irc servers people actually identify themselves
[10:18] <xhaker> well, there's qualified manpower then. let's see if there's enormous power of will
[10:18] <vil> man-di is very active here and at debian-java
[10:18] <xhaker> yep, i can see that from the changelogs
[10:19] <xhaker> i've apt-get source eclipse
[10:19] <xhaker> not sure how to get the orig.tar.gz
[10:19] <xhaker> it is clearly smaller than the tar.gz i downloaded
[10:21] <vil> well, I don't remember exactly as I did not care about it for a while now
[10:21] <vil> but it is either a snapshot from the web
[10:22] <vil> or export from the eclipse cvs
[10:22] <xhaker> there is a watch file
[10:22] <vil> either way, the size will differ because it has all .jar .so .dll etc. deleted
[10:22] <xhaker> version=3
[10:22] <xhaker> ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/eclipse/R-([\d\.-] *)/eclipse-sourceBuild-srcIncluded-(.*)\.zip
[10:23] <xhaker> is there a script to do that trimming?
[10:25] <vil> I don't think so
[10:26] <vil> although it is a good idea to create one either as part of rules or stand-alone


[00:46] <bluesabre> knome, hoping for the wallpaper tomorrow :)
[01:01] <Unit193> We still ship /etc/xdg/xdg-xubuntu/orage/oragerc, we can likely remove.
[10:55] <knome> oh, oh
[10:56] <knome> let me boot up my laptop now
[11:13]  * knome hum-di-dums
[11:22] <knome> bluesabre, branch is ready for you...
[11:30] <flocculant> bluesabre: liking pa-plugin :)
[11:42] <knome> for information, sean is going to be interviewed for dedoimedo about xubuntu and probably a bit of xfce as well
[12:23] -SwissBot:#xubuntu-devel- ::xubuntu-artwork:: [artful] r325 Update desktop and Plymouth wallpapers... (by Pasi Lallinaho)
[15:27] <Unit193> That's cool then..  G'luck?  I uploaded pa-plug to extras.
[15:27] <Unit193> (It's not technically an extra though.)
[16:04] <flocculant> probably something we'll want people testing


[02:41] <bazhang> the time length between crossposting seems to be getting ever shorter
[02:41] <bazhang> ask , two seconds, crosspost
[02:42] <bazhang> I wonder if a full moon falling on friday the 13th would affect that


[01:29] <emma> is there a kde/kubuntu alternative to Xournal http://xournal.sourceforge.net/
[01:50] <valorie> !info xournal
[01:51] <valorie> in kubuntu there is no need for an alternative for everything
[01:51] <valorie> I expect people to use the tools that work for them, whether or not they are made by KDE
[01:52] <valorie> kubuntu has long shipped firefox by default for instance
[01:53] <valorie> although I hope soon we'll replace that with Falkon which I've been using pretty much exclusively for almost a year
 @DrKineticPie, What your expectation for dual monitor? Because im using it work reasonably well
[03:06] <emma> valorie: yeah but if it's a gtk+ app won't that be annoying on kubuntu?
[03:06] <emma> does shutter screen shot tool belong on kubuntu?
[03:07] <valorie> it won't be as pretty, but there is a setting to make gtk applications follow your theming
[03:07] <valorie> you can use anything in the archive
[03:07] <valorie> Spectacle works well IMO
[03:07] <valorie> I click the print screen button and up it pops
[03:07] <valorie> Just Works
[03:08] <valorie> but you can remove it and use something else if you like
[03:08] <emma> is spectacle what comes with kubuntu by default?
[03:09] <emma> valorie: i found some software that might be pretty good.  Called "Stylus Labs Write"
[03:10] <valorie> hmmm, wonder if it is in the archive
[03:11] <valorie> https://paste.ubuntu.com/p/BvSmhxP4Fj/
[03:11] <emma> im installing xournal to take a look at it but it's installing all kinds of gnome dependencies. I hope im not ruining my kubuntu experience.
[03:11] <valorie> not so much, but xournal is
[03:12] <valorie> it should not
[03:12] <valorie> as long as it doesn't drag in the desktop
[03:12] <valorie> or gnome shell or whatever they call it now
[05:54] <kalikatz> is the "online accounts" working?   I added my owncloud server to which it was happy to show me a green checkbox. the fan sped up and laptop running hot for 10 mins.  I removed the account settings and rebooted.  Is this normal? Do I give it more time?  Anyone can assure me this is normal?   to add.   earlier i installed the desktop client for owncloud. and pointed to my old folder to wich has been resynced and happy.
[05:54] <kalikatz> Kubuntu 18.04 K.4.15.0-38
[06:08] <valorie> kalikatz: I think it isn't working very well, no
[06:09] <valorie> it was part of a chat program
[06:09] <valorie> but all the APIs have been with drawn, one by one
[06:09] <valorie> :(
[06:09] <valorie> so work on it has stopped
[06:09] <kalikatz> hmmm :(
[06:09] <valorie> the online accounts part should be reworked, IMO
[06:10] <valorie> because some parts *do* work
[06:12] <kalikatz> yes i did have this working back in ubuntu 10.04 for years.   i wsa hoping since my install of kbun 18.04 that the online account activation would be more streamlined
[06:12] <kalikatz> perhaps with a few hrs of time, i could get this working again .  just alot of finagling
 Hello :)
 Anyone got an idea when Plasma 5.14 comin gon kubuntu?
 https://www.reddit.com/r/kde/comments/9q9qbe/psa_kubuntu_1810_users_can_update_to_plasma_5141/
 https://kubuntu.org/news/plasma-5-14-2-available-in-cosmic-backports-ppa/
 @Vamsi Krishna Reddy Mudamala, I would also like to know where I can look to find out about delays in Kubuntu startup.
[13:00] <BluesKaj> howdy folks
[13:57] <Captain_Haddock> Hello BluesKaj
[13:58] <BluesKaj> hi Captain_Haddock
[14:18] <ZeZu> After return from s3/sleep,  fonts are getting blurred very badly on widgets that aren't active
[14:19] <ZeZu> This is on current 18.10, 4.18.0-10-generic, using nvidia drivers
[14:20] <ZeZu> And it appears only the focus widget, not the window gets fixed ... it's really strange
[14:21] <ZeZu> https://i.imgur.com/LtvTTTt.jpg
[14:32] <BluesKaj> webtorrent? I don't see that in the repos
[14:33] <ZeZu> It's not
[14:34] <ZeZu> maybe on ppa, but you can grab a binary package of it why?
[14:37] <BluesKaj> ppas can cause conflicts as you probly know, especially with new releases
[14:38] <BluesKaj> I recommend qbittorrent myself, very configurable compared to most clients
[14:39] <ZeZu> Eh, yeah but i'm not getting any clashing packages ... and qbittorrent is decent: I use webtorrent for streaming because it works very well and is terribly simple :  my kids use my machine sometimes
[14:39] <ZeZu> I don't use it for files
[16:05] <Nomad_> Anyone have a good doc on installing a xscreensaver or similar on kubuntu 18.10 ?
[16:05] <Nomad_> mine's not working right so something is missing
[16:35] <Alexfrench> what kind of screensaver ? 3d, opengl ?
[18:55] <kalikatz> Is there an option to tell the system to do nothing when usb drive plugged in?
[18:56] <bprompt> kalikatz:   as in to not mount it?
[18:58] <kalikatz> no i guess that would be silly, lol.  "as in" the two options that show up to open in file manager, or photos. I find the choices in the way.  It already mounts in dolphin\
[19:00] <bprompt> hmmmm... I don't see it in the settings
[19:01] <kalikatz> ya me either, spent a few mins in there
[19:01] <kalikatz> maybe a hidden toggle
[19:01] <bprompt> kalikatz:   you could, stop it from automounting, and it will still show up in the file manager window, if used by any kde app, so in Dolphin it'll show up even if not mounted, and if you click on it, it mounts it right there and then
[19:02] <kalikatz> i see
[22:31] <hashrack> Good morning, everyone.


[09:25] <sa_> good morning yall anyone familiar with Hubot on xubuntu. i am trying to get hubot working, with campfire or any other way. so far i was able to get yo generator working, and i think i did setup npm correctly, but not sure how come hubot is not responding ? as you might be able to see in my terminal log http://paste.ofcode.org/tzk3tFA8TJRs63qP9eLkiT
[11:39] <BluesKaj> Hiyas all
[15:01] <yossarianuk> hi - i'm using libreoffice on kubuntu 16.10, I was trying to change the default spell check from English/USA -> Emglish/UK in writer
[15:02] <yossarianuk>  now spellcheck is totally empty
[15:02] <yossarianuk>  I can see both english uk + english USA in the text language drop down, however I cannot seem to choose any
[15:02] <yossarianuk> i.e the dictionary seems black and is defaulting to 'none' how can I fix this
[15:02] <yossarianuk> just did a 'rm -rf ~/.config/libreoffice/' and sudo apt-get --purge remove libreoffice-core  libreoffice-l10n-en-gb  - then reinstalled - same
[15:08] <somekool> could the kubuntu PPA include the latest QupZilla package for *buntu 16.04+16.10 ?
[15:09] <hateball> yossarianuk: that affects the ui, myspell is for spellcheck
[15:09] <hateball> yossarianuk: err hunspell
[15:11] <hateball> yossarianuk: so the british would be hunspell-en-gb
[15:11] <yossarianuk> I reinstalled the humspell package
[15:11] <yossarianuk> my issue is that in the tools -> spell check section I  can see the various languages in the drop down
[15:12] <yossarianuk> (which defaults to 'none')
[15:12] <yossarianuk> but I cannot select any
[15:14] <hateball> yossarianuk: well do you have the various libraries installed then?
[15:14] <yossarianuk> I should do - it worked previously before I tried to change the default to UK
[15:15] <yossarianuk> (before remove/purging anything
[15:15] <yossarianuk> the reason I removed libreoffice was due to this issue (to try to fix()
[15:23] <yossarianuk> any good altyernative to libreoffice ?
[15:23] <yossarianuk> I need to do some work...
[15:24] <yossarianuk> issue is just like -> https://forum.openoffice.org/en/forum/viewtopic.php?f=7&t=81640
[19:28] <jmalsz> ayuda sobre el menu de inicio
[19:29] <jmalsz> grub no se me carga con todos los sistemas operativos que tengo
[20:28] <viewer|82812> buonasera
[20:29] <viewer|82812> ho un piccolo problema, sono un newbbie di kubuntu
[20:29] <viewer|82812> non riesco ad installare programmi
[20:29] <viewer|82812> c' e qualcuno disposto ad aiutarmi?
[20:31] <genii> !it


[08:38] <cory_fu> Any idea what might cause one of my units to get stuck doing this for the past 3 minutes?
[08:38] <cory_fu> 2020-03-03 08:37:08 DEBUG update-status Unable to connect to the server: Forbidden
[08:38] <cory_fu> 2020-03-03 08:37:08 INFO juju-log Failed to apply label juju-application=kubernetes-worker. Will retry.
[08:41] <cory_fu> Hrm, maybe it's my proxy settings, but it didn't seem to affect other units
[10:32] <cory_fu> rick_h: Got a new KeyError from libjuju against a latest/edge controller: https://pastebin.canonical.com/p/BPDjBWBH6w/  Is that a known issue?
[10:33] <cory_fu> Bootstrapped from 2.8-beta1+develop-34bf6ce
[11:17] <stickupkid> achilleasa, "FAIL	github.com/juju/juju/cmd/juju/metricsdebug"
[11:17] <stickupkid> achilleasa, and FAIL github.com/juju/juju/cmd/jujud - FAIL	github.com/juju/juju/cmd/jujud/agent
[12:38] <hml> stickupkid: https://paste.ubuntu.com/p/2GJ7jGB5H7/
[12:40] <rick_h> cory_fu:  no, not known atm
[12:40] <cory_fu> rick_h: File against Juju or libjuju?
[12:41] <rick_h> cory_fu:  libjuju, thumper is working in there and might have work around it going down
[12:41] <rick_h> since it's coming from the modelwatcher stuff he's doing
[12:41] <rick_h> cory_fu:  he says the tip of pylibjuju fixes it
[12:41] <rick_h> cory_fu:  and if not then he owes you a coffee :P
[12:41] <cory_fu> rick_h, thumper: Huzzah.  Thanks
[12:51] <hpidcock> quick fix PR https://github.com/juju/juju/pull/11272
[13:25] <stickupkid> achilleasa, go build -tag json github.com/mattn/go-sqlite3
[13:41] <stickupkid> hml, https://github.com/go-goose/goose/pull/80
[13:43] <stickupkid> hml, https://github.com/go-goose/goose/pull/80
[13:50] <hpidcock> stickupkid: https://github.com/juju/juju/pull/11272
[13:50] <hpidcock> one moment of your precious time


[00:00] <jelmer> yacc: package support?
[00:00] <yacc> Well, if you want to make bzrlib.plugins.svn.lowlevel a module, you need to store that path in the filename of the .pyx for Pyrex. Cython automatically detects the package path.
[00:01] <jelmer> ah
[00:01] <yacc> In theory it works with Pyrex too, and you might get by my making the module thing it's something else that it is (as long as you do not need introspection about what module you are), ...
[00:01] <Peng> Also, isn't Cython supposed to have more optimizations?
[00:01] <yacc> Peng: it is.
[00:02] <Peng> Yeah, but I mean is more more than 3% faster?
[00:02] <Peng> Bzr is kind of laughably slow on Python's branches...
[00:02] <yacc> Peng: that depends on your code. For a C-library binding to Python it should make no real difference.
[00:03] <yacc> Peng: that's kind of because Python is a huge svn repo. Importing python into an svk depot is beyond laughable, it's more like crying from pain.
[00:03] <jelmer> yacc: ah, ok. I have no use for that right now though, so I'll try to keep the .pyx file usable by both as long as I can
[00:03] <Peng> yacc: Heh. Like I said, "missing" took a couple minutes, and "diff -c" is quite slow too.
[00:04] <jelmer> the C file generated by pyrex is 6500 lines, the one from cython is almost 11000 lines
[00:04] <yacc> missing?
[00:04] <yacc> jelmer: why do you care?
[00:04] <Peng> Woah.
[00:04] <Peng> yacc: "bzr missing".
[00:04] <yacc> jelmer: I mean how big is the difference in compiled size?
[00:04] <jelmer> yacc: It makes reading the source harder
[00:04] <yacc> jelmer: C is whitespacy language.
[00:05] <Peng> I was gonna say "who cares" assuming it was a small difference, but that is kinda significant.
[00:05] <yacc> jelmer: you don't want to read the source. Not as long as you don't want to debug or help debug Cython/Pyrex.
[00:05] <yacc> jelmer: kind of like me ended up peeking at your code :-P
[00:06] <jelmer> yacc: you end up having to
[00:06] <jelmer> yacc: pyrex catches a lot more errors in the .pyx file than swig does in its .i files
[00:06] <jelmer> but it still occasionally generates .c files that dont compile because of incorrect .pyx files
[00:07] <jelmer> and then you actually have to check the c file to see what is going wrong
[00:07] <yacc> jelmer: I was lucky with Pyrex (back then there was no Cython) that I did not need to debug the generated code :)
[00:07] <jelmer> or in the case of segfaults
[00:08] <yacc> jelmer: In my case back then in '03/'04, swig and the C++ core app where the usual culprits for "problems" ;)
[00:08] <jelmer> :-)
[00:09] <jelmer> if you guys have experience with pyrex, you may actually have a clue how to work around the issue I'm facing at the moment
[00:10] <yacc> jelmer: and well, nobody cared about all my little problems. The bad guys (as curious that sounds that was the sister company in NL) kept us busy with trying to decipher the file format ;)
[00:10] <jelmer> I've got a callback function in pyrex that needs to return a pointer to an error whenever an exception occurs
[00:10] <yacc> jelmer: tell, perhaps I can help.
[00:10] <yacc> paste?
[00:10] <yacc> Or branch url?
[00:11] <yacc> error being what data type?
[00:11] <jelmer> http://paste.ubuntu-nl.org/60476/
[00:11] <jelmer> the error is a pointer to a structure
[00:11] <jelmer> or NULL in the case no error occurrs
[00:12] <yacc> And what is your problem then?
[00:13] <jelmer> if an exception occurs in     self.set_target_revision(target_revision) I need to return a pointer to an error rather than NULL
[00:13] <yacc> try: except:
[00:13] <jelmer> I haven't figured out a way to do that yet though
[00:13] <yacc> put a try: except: as in Python around the call.
[00:13] <jelmer> yacc: I need to retain the exception as well
[00:14] <yacc> Well, in any chance to piggy pack it onto svn_error_t?
[00:14] <yacc> If not, you will probably need to keep it in a dictionary keyed by pointer address?
[00:17] <jelmer> ieuw
[00:18] <jelmer> yeah, I guess that would work
[00:19] <yacc> nobody said that it's cool to wrap a C API, especially one that uses callbacks and other stuff for a language like Python.
[00:20] <yacc> One of the better things about the Gnome Project was that it realized that from the beginning, and despite some flames, they managed to make their APIs "wrapping-friendly" ;)
[00:25] <jelmer> the svn API is pretty good overall
[00:25] <jelmer> pyrex is a little less powerful than swig though (which is used for python-subversion)
[00:25] <jelmer> the language is a lot saner though
[00:28]  * Peng gets a traceback using bzr-svn on Lighttpd's repo.
[00:29] <Peng> Somebody forgot to import "errors" in svk.py.
[00:29] <Peng> Well, I guess it'd just error out anyway for a different reason if it weren't for that. :P
[00:38] <yacc> less powerful?
[00:39] <yacc> I wouldn't say so. It's just way less automatic. OTOH, when you wrap something, you get usually a better designed wrapping, and potentially a faster one.
[00:40]  * Peng notices that his copy of bzr-svn is out-of-date.
[00:44] <radix> Peng: oh yeah, I've been noticing that like 100 times a day lately
[00:45] <Peng> Ok, updating didn't help.
[00:46] <jelmer> Peng: What branch are you using?
[00:46] <Peng> jelmer: Hold on.
[00:48] <Peng> jelmer: .bzr.log http://paste.pocoo.org/show/34862/
[00:48] <Peng> jelmer: svn://svn.lighttpd.net/lighttpd/trunk/
[00:48] <Peng> jelmer: svn import on the repo did it too
[00:49] <Peng> jelmer: Latest bzr-svn 0.4 and bzr.dev as of five minutes ago.
[00:51] <jelmer> Peng: You shouldn't get a out-of-date error with bzr-svn 0.4 though
[00:52] <jelmer> Peng: I've fixed the import error
[00:53] <Peng> Thanks.
[00:53] <Peng> Responsive developers are awesome.
[00:59] <Peng> jelmer: Um, yeah, now it works. Thanks. :)
[01:07] <jml> jelmer: that reminds me, the 0.4.8 branches works really well with the o-hand.com repos.
[01:24] <jelmer> cool :-)
[01:36] <ubotu> New bug: #145171 in bzr-svn "Invariant break on bzr missing in bzr-svn" [Medium,Incomplete] https://launchpad.net/bugs/145171
[02:26] <ubotu> New bug: #94316 in bzr-svn "Traceback doing log -v" [Low,Triaged] https://launchpad.net/bugs/94316
[02:39] <awmcclain> Where does bazaar.conf live? In site-packages?
[02:40] <abentley> awmcclain: in ~/.bazaar
[03:15] <jholman> I want to install bazaar on an ubuntu box.  I am pretty much an ubuntu noob, I confess.  I followed the link to the bazaar launchpad site, and added the 2 gutsy lines to my sources.list, and did apt-cache show bzr...
[03:16] <jholman> and I get 2 entries, first of all (one out of the main ubuntu package repository, I guess?)... and they're both old versions
[03:16] <jholman> 1.2-1 and 0.90-1
[03:17] <fullermd> Well, 1.2 is only old as of, like, 12 hours ago or something.
[03:18] <jholman> fair enough.
[03:18] <jholman> so the reasonable thing to do is to trust apt, remember that I should do an update/upgrade in a day or three, and go from there?
[03:18] <fullermd> With the caveat that I don't really know anything about Ubuntu packaging (or package using), that sounds right.
[03:19] <jholman> hmn, significant caveat, but fair enough
[03:20]  * fullermd is all about ambiguity, except when he's not   :)
[03:20] <jholman> =]
[03:30] <abentley> "We demand rigidly defined areas of doubt and uncertainty!"
[03:30]  * fullermd demands that he may or may not know about a bzr release.
[03:32] <abentley> Well, we haven't been quite punctual about getting the debs out in the past.
[03:33] <abentley> Yes, it does look like 1.3 hasn't hit our repo yet.  It should in the next few days.
[03:34] <jholman> ok
[03:50] <Odd_Bloke> Morning.
[04:06] <rusty> Hi all: I'm struggling to find out if there is an answer to the question of setting up multiple committers to a (remote) repository.
[04:07] <jml> rusty: hi.
[04:07] <jml> rusty: you mean multiple people pushing to the same branch?
[04:07] <rusty> jml: yes.
[04:08] <jml> rusty: that should pretty much work out of the box. what problems are you having?
[04:09] <rusty> jml: well, currently I'm using rsync to send to server, but that won't work for the second committer.
[04:09] <rusty> jml: so I wondered what the "correct" way to do this is.
[04:10] <jml> rusty: well, the "correct" thing is both people should be using 'bzr push bzr+ssh://..."
[04:10] <jml> but let me do an experiment
[04:10] <rusty> jml: for mercurial, I have an acct on the server with write access to the repo and put their ssh key in the authorized_keys with command=
[04:11] <jml> rusty: is the issue is that the push overwrites permissions / ownership?
[04:11] <jml> you could do that with bzr, I think
[04:12] <rusty> jml: no, sorry, the issue is that I haven't tried it, was looking for advice :)
[04:12] <jml> oh :)
[04:12] <jml> so, I think you don't have to do that, if you wanted you could have an account per user.
[04:12] <jml> (that's what I'd do, if I weren't using something like PQM)
[04:12] <rusty> jml: I really don't want to hand out accounts on the server.
[04:13] <jml> rusty: you could also do what you just described -- a special account with authorized_keys
[04:13] <jml> rusty: alternatively, you could use Launchpad (but I'm guessing you want to host this yourself).
[04:15] <jml> rusty: what do you know about PQM?
[04:15] <rusty> jml: nothing, I just googled it when you mentioned it :_
[04:16] <jml> rusty: ok. PQM acts like an automated gatekeeper. You send it signed emails and it does the merge.
[04:16] <jml> rusty: Bazaar itself uses PQM to make sure that the test suite passes before it lands anything.
[04:17] <jml> rusty: I haven't set it up myself, but if that sort of thing appeals to you then you might want to check it out.
[04:17] <jml> (is this for libantithread, perchance?)
[04:17] <rusty> jml: ccan :)
[04:18] <jml> heh.
[04:20] <rusty> jml: OK, I think I'll try adapting the "hg-ssh" wrapper for bzr.  Looks like it'll be fairly easy.
[04:20]  * jml thinks
[04:21] <jml> rusty: why do you need a wrapper?
[04:21] <rusty> jml: you use "command=wrapper <repos>" and it restricts that key to only running bzr, and what repositories it can access.
[04:22] <rusty> jml: it's a cute ssh feature (the command they wanted to run is in $ORIG_SSH_COMMAND)
[04:24] <Odd_Bloke> jml: http://bazaar.launchpad.net/~daniel-thewatkins/+junk/merged-branches now has working shelved changes logic, and a test to go with it.
[04:24] <jml> Odd_Bloke: you mean my previous logic was not working? inconceivable!
[04:25] <jml> rusty: it'd be cool if you could post it to the Bazaar ML once your done. That is, if there's anything interesting and not site-specific :)
[04:26] <rusty> jml: sure!
[04:27] <Odd_Bloke> jml: It wasn't so much that the logic wasn't working as that you weren't actually referencing bzrtools and you were getting hit by double-underscore munging. :p
[04:27] <jml> Odd_Bloke: I guess now that I've got more than one user and more than one contributor I should register a project for it.
[04:28] <jml> Odd_Bloke: can you suggest a name better than "merged-branches"?
[04:28] <Odd_Bloke> jml: The little thought I've given it didn't produce anything better, sadly.
[04:29] <jml> Odd_Bloke: merged-unchanged-unshelved-branches doesn't have quite the same _energy_.
[04:29] <jml> Odd_Bloke: what do you think of 'boring-branches'?
[04:32] <Odd_Bloke> jml: I'm not sure it conveys enough of what it actually means.  How about 'redundant-branches'?  Or 'removable-branches'?
[04:32] <Odd_Bloke> Perhaps 'excess-branches'?
[04:32] <jml> luxury-branches :)
[04:33] <fullermd> this-is-an-ex-branch
[04:33] <Odd_Bloke> gratuitous-branches :p
[04:34] <jml> ok. As benevolent dictator for today, I am going to call the project bzr-removable
[04:36] <jml> Odd_Bloke: OK w/ MIT license?
[04:37] <Odd_Bloke> jml: I'd prefer GPL, but I'm easy.
[04:38] <jml> fine by me.
[04:39] <rusty> jml: Erk, hit a snag.  bzr push bzr+ssh runs 'bzr serve --inet --directory=/ --allow-writes' on the remote end, indep. of what repo it's trying to access.
[04:39] <rusty> jml: Makes it hard to restrict the repo by looking at command line.
[04:40] <rusty> jml: (0.9 does this as well as 1.3)
[04:40] <jml> *nod*
[04:40] <jml> I should have foreseen that, sorry.
[04:40]  * jml has a look around
[04:42] <jml> rusty: ok, so I have a crummy workaround.
[04:42] <jml> rusty: but it's pretty terrible.
[04:42] <rusty> jml: well, I was going to ignore it for the moment, so I doubt yours will be worse :)
[04:43] <jml> (Bazaar should change to let you specify a directory)
[04:43] <jml> rusty: you were warned
[04:43] <jml> rusty: you can tell it which bzr executable to run using BZR_REMOTE_PATH.
[04:44] <jml> and then you could dispatch off that.
[04:45] <rusty> Erk, I was thinking to change --directory=/ to --directory=<acct home dir> so they can only access stuff in their home?
[04:45] <jml> rusty: yeah, that would be better if you could do that :)
[04:46] <jml> rusty: but if you have a wrapper script that's parsing the contents of SSH_ORIGINAL_COMMAND then you could do something horrible based on the specified location of the bzr executable.
[04:46] <jml> ugh.
[04:47] <jml> that's a bad idea, forget I said anything.
[04:49] <jml> Odd_Bloke: with bzr plugins, is there a convention for the team that owns trunk?
[04:49] <rusty> jml: hmm, want to give me a hint on how to s,--directory=/,--directory=sys.argv[1], in python?  And then exec it?
[04:50] <jml> rusty: sure
[04:51] <jml> os.system(command_string.replace('/', sys.argv[1], count=1)) should do the trick.
[04:51]  * AfC waves to rusty
[04:52] <rusty> jml: don't I want .exec to avoid quoting troubles?
[04:52] <AfC> rusty: I've been through a lot of the hosting pain; if you're still stuck next week I can totally try to help you out when I get back.
[04:53] <rusty> AfC: this is self-inflicted... bzr is the one distributed vc system I hadn't tried yet.
[04:53] <jml> rusty: was being quick and dirty
[04:53] <AfC> rusty: I've had some nice results, though... things like http://research.operationaldynamics.com/bzr/java-gnome/mainline/ instead of an empty directory
[04:53]  * jml always has to look this stuff up
[04:54] <rusty> jml: I think I'm almost there...
[04:54]  * AfC really needs to move that server from Europe to western North America somewhere :)
[04:54] <jml> rusty: using exec would work fine too.
[05:02] <jml> Odd_Bloke: I'm getting hungry and kind of bored of sitting at a computer. I'll have a play with your branch tomorrow.
[05:02] <jml> Odd_Bloke: the bzrtools fix is obviously right :)
[05:02] <fullermd> Erk.   See 'bzr help working-trees' for more information.- [==                                                        ] Transferring 0/4
[05:08] <rusty> jml: I ended up with babytalk python: if orig_cmd == 'bzr serve --inet --directory=/ --allow-writes':    os.execlp('bzr', 'bzr', 'serve', '--inet', '--directory=' + sys.argv[1], '--allow-writes')
[05:08] <jml> rusty: nothing wrong with simple.
[05:09] <rusty> jml: no doubt it will break if bzr changes cmdline, but it should be obvious.
[05:10] <jml> right.
[05:11] <jml> rusty: I look forward to reading your email. :)
[05:11]  * jml is really gone now
[05:39] <Odd_Bloke> jml: Sorry, I was playing Peggle.  I don't know about convention, enjoy your food and have a good Easter. :)
[10:10] <thekorn> hi all, In a script I would like to get all revision numbers of a branch,
[10:10] <Odd_Bloke> thekorn: What do you mean by "all revision numbers of a branch"?
[10:10] <thekorn> is it save to do something like    range(1, number_of_last_rev +1) ?
[10:11] <thekorn> Odd_Bloke, a list of all revision numbers of a branch
[10:11] <Odd_Bloke> I can't immediately see why not, but that will obviously exclude merged revisions (i.e. dotted revision numbers).
[10:11] <thekorn> are this rev numbers continuous and linear?
[10:12] <Odd_Bloke> The mainline revision numbers are, but merged revisions use dotted revnos.
[10:12] <thekorn> Odd_Bloke, that's fine I'm only intrested in the "main-line"
[10:12] <Odd_Bloke> Then you should be fine. :)
[10:12] <thekorn> thanks
[10:13] <Odd_Bloke> What are you using all the revision numbers for?
[10:14] <thekorn> Odd_Bloke, well I started to play around with bzrlib yesterday and I ended in writing a fuse-file-system for bzr
[10:16] <Odd_Bloke> thekorn: Ah, interesting.  Someone at the sprint was looking at that, though I can't remember who.
[10:16] <thekorn> within the filesystem there are two main directorys "revisions" and "tags"
[10:18] <Odd_Bloke> thekorn: I think enough people would be interested in looking at that to make it worth sending something about it to the mailing list.
[10:20] <thekorn> Odd_Bloke, sure, will push the code to launchpad project soon and can also write a mail to the ML
[10:21] <Odd_Bloke> Awesome, thanks. :)
[12:27] <nubbun> In bzr 1.3, I have an error loading bzrlib .  It recommends setting PYTHONPATH.  Setting PYTHONPATH has no effect.
[12:27] <nubbun> on this error.  The error is still reported.
[12:27] <nubbun> Running bzr from the top of its directory tree, works.
[12:33] <Odd_Bloke> nubbun: Could you pastebin the error?
[12:35] <nubbun> http://www.pastebin.org/24836
[12:45] <Odd_Bloke> nubbun: Just having a look now. :)
[12:45] <Odd_Bloke> nubbun: How did you install bzr?
[12:45] <Odd_Bloke> And what type of sustem are you on?
[12:46] <Odd_Bloke> *system
[12:46] <nubbun> extracting a tarbal
[12:46] <nubbun> linux
[12:46] <nubbun> Debian Etch
[12:46] <dato> nubbun: did you cp bzr to your ~/bin?
[12:46] <Odd_Bloke> nubbun: So you did 'tar zxvf bzr-1.3.tar.gz' (or equivalent)?  Did you take any further steps?
[12:46] <nubbun> no did ln
[12:46] <dato> nubbun: if so, I recommend that you symlink it instead
[12:46] <dato> nubbun: ln -s?
[12:47] <dato> or ln alone
[12:47] <nubbun> Trying now.
[12:48] <nubbun> Now it works as symlink.
[13:46] <ubotu> New bug: #205112 in bzr "bzrlib in PYTHONPATH not found" [Undecided,New] https://launchpad.net/bugs/205112
[14:14] <ubotu> New bug: #161830 in bzr-svn "log should show subversion revision numbers as well as branch/bzr revision info" [Wishlist,Triaged] https://launchpad.net/bugs/161830
[15:10] <radix> Am I the only person that often runs into problems using bzr-svn on a project that already uses lots of branch-based SVN development?
[15:10] <radix> like, trying to merge stuff with SVN often results in a conflict on "."
[15:11] <jelmer> radix: Haven't seen that issue before
[15:12] <jelmer> radix: conflict on . ?
[15:12] <radix> jelmer: properties, presumably
[15:12] <jelmer> radix: Ah, svn merging bzr branches in svn?
[15:12] <radix> jelmer: svn merging SVN branches that happened to have bzr commit to them in svn
[15:13] <radix> to be precise :)
[15:14] <jelmer> That's basically unsupported by bzr-svn at the moment
[15:14] <radix> it seems bzr-svn would be great if I were only trying to integrate with projects that mostly do trunk-cowboy hacking
[15:14] <jelmer> until the ability in bzr-svn to use revision properties (as opposed to file properties) lands
[15:14] <radix> jelmer: ah, that sounds exciting
[15:26] <ubotu> New bug: #205156 in bzr "KnitRepository.insert_data_stream() copies data in improper order" [Critical,Triaged] https://launchpad.net/bugs/205156
[15:35] <arnetheduck> hi, I'm about to migrate from svn to bzr and I noticed that there are several options available - does anyone have any tips on which one to choose?
[15:35] <arnetheduck> bzr-svn seems nices to me, but it seems like it doesn't keep the tags for example...
[15:35] <arnetheduck> (I have a classic trunk/branches/tags type of svn repo)
[15:41] <jelmer> arnetheduck: it will keep the tags (if you use "bzr svn-import") but as branches
[15:55] <arnetheduck> jelmer, so I noticed - does that make sense? I usually tag my releases (and I don't touch them any more after tagging) so it seemed like real tags were more suitable
[15:59] <jelmer> arnetheduck: yes, but there are certain issues that have to be addressed first for that to be supported
[16:02] <jelmer> bug 81102
[16:02] <ubotu> Launchpad bug 81102 in bzr-svn "Tag support" [Wishlist,Triaged] https://launchpad.net/bugs/81102
[16:06] <arnetheduck> jelmer, assuming that there were no changes from the tag to it's source revision (which is verifiable via log), it shouldn't be too hard, right?
[16:06] <arnetheduck> I poked around in the bzr-svn code a few weeks ago and saw that there are at least some functions for detecting tags / tag dirs
[16:08] <jelmer> arnetheduck: tags and branches are considered equally at the moment
[16:08] <jelmer> furthermore, you have to make sure the revision that created the tag didn't introduce any other changes to it
[16:09] <jelmer> there can be multiple tags directories in a repository, possibly not related to the branch you're checking out
[16:18] <ubotu> New bug: #81102 in bzr-svn "Tag support" [Wishlist,Triaged] https://launchpad.net/bugs/81102
[16:29] <dato> arnetheduck: I think you could easily script converting the resulting tag-branches to real tags after bzr-svn did its
[16:29] <dato> arnetheduck: job?
[16:32] <arnetheduck> dato, that's crossed my mind but would leave some cruft in the repo...
[16:32] <dato> arnetheduck: cruft?, what cruft?
[16:33] <arnetheduck> dato, the branches
[16:33] <dato> arnetheduck: uh, you'd just rm -rf them after converting them to real tags
[16:34] <arnetheduck> dato, well, not if they're imported too (they'd show up in logs etc)
[16:35] <dato> ok, maybe you're still not fully familiar with bzr and that's why we're not understanding each other :)
[16:35] <dato> arnetheduck: each branch is mostly independent from each other, there is no such think as "log for the repository as a whole"
[16:36] <dato> does your SVN repo contain many projects, or only one (with its tags, and maybe some branches of it as well)
[16:41] <arnetheduck> dato, yep, I'm a 100% noob, as green as they come =)
[16:43] <dato> ok. I think the user guide has some parts explaining this stuff, but as a crash course:
[16:43] <arnetheduck> dato, it's a single project, no branches, one trunk, tags every now and then
[16:43] <dato> - each branch is
[16:43] <dato> ok, scratch that
[16:43] <arnetheduck> I think get your point though
[16:43] <dato> great
[16:43] <arnetheduck> I'm kind of used to the svn/cvs mindset after a few years
[16:44] <dato> each tag-branch will be like a "cp -r" from the original branch *at some point of its history*
[16:44] <dato> so, as svn does "copies", but in its svn-filesystem, you do copies here, but in the real filesystem
[16:45] <arnetheduck> dato, yeah, in my mind the branches remained in the .bzr folder thus created cruft, but then it your point sunk in =)
[16:45] <dato> ok
[16:46] <ubotu> New bug: #205181 in bzr-svn "importing https://svn.xiph.org/trunk/theora fails" [Undecided,New] https://launchpad.net/bugs/205181
[16:56] <arnetheduck> dato, so conceptually, the script would read each branch created by the importer, find out which revision of the trunk branch it was copied from and add a tag to the trunk
[16:58] <dato> more or less. if the tag-branches created by bzr-svn contain no additional commits, which I don't think they do but jelmer can confirm, it's just a matter of:
[16:58] <dato> for each tag-branch:
[16:59] <dato>   r=second word of `bzr revision-info`
[16:59] <dato>   in trunk: bzr tag -r revid:$r $tagname
[16:59] <jelmer> they always contain at least one extra revision (the one in which the tag was created)
[16:59] <dato> oh, ok
[17:00] <dato> then `bzr revision-info -r -2`, with manual supervision, I guess
[17:08] <arnetheduck> thanks, brb, gotta feed the kid =)
[17:20] <AfC> How many tests in the Bazaar test suite, roughly?
[17:20]  * AfC refers to this in our HACKING document as a point in bzr's favour
[17:20] <dato> AfC: the other day 10,000 was reached
[17:21] <AfC> dato: nice. 10K it is.
[17:21] <AfC> dato: thanks!
[17:22] <jelmer> and that's just in bzrlib.. with a couple of plugins installed it's closer to 15k here
[17:22] <AfC> jelmer: wow
[17:22] <AfC> jelmer: that's amazing
[17:23] <AfC> [not that you really care, but what me write about this is at: http://java-gnome.sourceforge.net/4.0/HACKING.html under "Why bzr?"]
[17:25] <AfC> yikes
[17:25] <AfC> what I have written*
[17:32] <jelmer> AfC: nice
[17:33] <jelmer> AfC: btw, "bzr send" should now Do The Right Thing[tm] if you have the child_submit_to setting set to an email address in your main branch
[17:34] <jelmer> as alternative to running "bzr bundle" and then manually attaching the bundle and specifying the email address
[17:34] <AfC> jelmer: yeah, I'll work out the wording for that down the track.
[17:34] <AfC> (is that something that will propagate? No, I believe? Only if someone creates a new branch, right?)
[17:35] <AfC> (Will it "remember"?)
[17:35] <AfC> (that'd be nice)
[17:36] <jelmer> AfC: It retrieves it from the submit branch so there shouldn't be a need to propagate it
[17:36] <jelmer> for example:
[17:36] <AfC> ah
[17:36] <jelmer> bzr branch lp:bzr-gtk; hack-hack; bzr commit -m "foo"; bzr send
[17:37] <jelmer> will do the right thing and retrieve the email address from the branch configuration of lp:bzr-gtk
[17:39] <AfC> That's what I meant about it working for a new branch; people who have existing repository/branch structures will need to twiddle something manually I expect.
[17:39] <AfC> (is what I was asking, that's all)
[17:39] <jelmer> AfC: in the scenario I just mentioned, no extra twiddling would be required
[18:04]  * Rhamphoryncus checks to see just how well bzr handles merging without known common bases
[18:07] <Rhamphoryncus> I was using a svn checkout initialized as a bzr repository (without the bzr-svn plugin!).  Now upstream has an official bzr mirror, so I'm trying to switch to that and eliminate svn..
[18:10] <Rhamphoryncus> aha, it gave up.  bzr: ERROR: Revision {('rhamph@base-two-20071105225603-16zlps51e17ghkzl',)} not present in "<bzrlib.knit.KnitGraphIndex object at 0x106d8f2c>".
[18:10] <Rhamphoryncus> So, can anybody think of an option that gets me most of the history?
[18:15] <Rhamphoryncus> assuming my initial checkin had no changes over upstream I should be able to do a patch set and reapply them somehow, right?
[18:16] <awilkins> AfC: btw, bzr merge won't let you merge if your tree has diffs from -r -1
[18:17] <awilkins> Hence "do the merge after you.ve finished anything you might happen to be doing" is redundant.
[18:17] <AfC> awilkins: Did I imply that it would somwhere?
[18:17] <AfC> awilkins: ah.\
[18:18] <AfC> awilkins: well, I'm not really a big fan of Bazaar's error messages.
[18:18] <awilkins> Although you could use the point as an opportunity to mention shelve
[18:18] <AfC> awilkins: so while you are indeed correct that it is redundant, it doesn't hurt to be attempt to set newbies on the right track habit wise.
[18:18] <AfC> awilkins: that in core yet?
[18:19] <awilkins> shelve is still in bzrtools AFAIK
[18:19]  * AfC only just grabbed 1.3, so I'm not current with the latest state-of-play
[18:19] <awilkins> I switched back to 1.2 from 1.3 on the chance that it might be futzing with the pyrex version of the bzr-svn branch
[18:21] <jelmer> Rhamphoryncus: you may be able to use rebase or replay to replay the changes your local branch has on top of the new upstream branch
[18:22] <jelmer> awilkins: It would be awesome if we could get that exception handling fixed so 0.4.9 can be released with the pyrex bindings
[18:24] <awilkins> jelmer: I was thinking of running the test in Python running attached to a debugger, but I've not got Python 2.5.2 building on Win32 yet ; and I don't have a full 7.1 toolkit
[18:24] <awilkins> My best chance so far seems to be using the 9.0 toolkit because you can at least download it as part of the PSDK
[18:25] <jelmer> awilkins: Running the tests doesn't make a lot of sense until this problem is resolved
[18:25] <jelmer> until then, you'll probably keep getting segfaults
[18:25] <awilkins> jelmer: What is so frustrating is that it only segfaults if you run the test suite - the test on it's own passes
[18:26] <awilkins> Running the host class is enough to trip the fault
[18:26] <awilkins> Sounds memory-flavoured
[18:27] <awilkins> something being initialized wrong or a pool going bad or something
[18:27] <jelmer> awilkins: that's probably related to it not reporting the test that's segfaulting properly
[18:28] <awilkins> So it could be the following test?
[18:28] <awilkins> Which DOES throw an exception
[18:28] <jelmer> if it prints "ignored exception ..." that's probably a test that's causing a segfault
[18:28] <awilkins> WindowsError, as I recall
[18:29] <awilkins> Not got my desktop fired up ATM though
[18:29] <jelmer> Ignored Exception "WindowsError ..." ?
[18:29] <awilkins> Possible
[18:30] <awilkins> Give me a few minutes, I'll boot my desktop and run it again
[18:34] <arnetheduck> returning to my repo move, once I have my repository converted I'll be keeping a main development branch that I'd like to sync the old svn to, one-way, so that commits to the bzr branch are merged to the svn branch...this should be doable with the bzr-svn plugin, right?
[18:35] <awilkins> jelmer: It's an "Access is denied"
[18:35] <jelmer> awilkins: hmm, ok
[18:36] <jelmer> awilkins: what happens if you run selftest with --one ?
[18:37] <awilkins> jelmer: On just that test, or the whole bzr-svn tree?
[18:38] <jelmer> awilkins: all of bzr-svn
[18:38] <jelmer> it should then quit and print the backtrace as soon as it hits a single exception
[18:38] <awilkins> jelmer: fails on test_branch.WorkingSubversionBranch.test_create_checkout
[18:38] <awilkins> SubversionException: ('Unable to open an ra_local session to URL', 180001)
[18:39] <awilkins> jelmer: This is bzr 1.2, that right?
[18:40] <jelmer> awilkins: should be 1.3
[18:41] <jelmer> or bzr.dev
[18:43] <awilkins> http://pastebin.ca/953008
[18:47] <jelmer> awilkins: I think that one is probably specific to your environment
[18:58] <awilkins> Are these bindings SVN 1.5 specific or are they still 1.4.6 compatible?
[18:59] <awilkins> Well, I've built them against the 1.4.6 deps packs, so I guess they should work, eh?
[19:04] <jelmer> awilkins: yeah, 1.4 and 1.5 should both work
[19:05] <awilkins> jelmer: Arrgh, it works from Eclipse/PyDev but not from my shell
[19:05] <awilkins> I HATE Heisenbugs
[19:05] <awilkins> Hmm
[19:05]  * awilkins diffs plugins tree and source
[19:06] <ubotu> New bug: #205230 in bzr "error message recommending incorrect setting of PYTHONPATH" [Undecided,New] https://launchpad.net/bugs/205230
[19:08] <j1mc> hi there.  a group i work with was interested in upgrading our repository to the new pack format, but don't know if it's possible with bzr-svn (which we use)
[19:08] <j1mc> here's what i get when i do a bzr info: Checkout (format: dirstate-with-subtree)
[19:10] <jelmer> you could upgrade to --pack-0.92-subtree
[19:12] <j1mc> jelmer: thanks... i will check into that.
[19:13] <j1mc> jelmer: per this page ( http://doc.bazaar-vcs.org/latest/developers/packrepo.html#testing-packs-for-bzr-svn-users ) it says that this kind of subtree support is bleeding edge.  is that still accurate?
[19:14] <jelmer> j1mc: the format is not experimental but some of the functionality it enables is
[19:18] <j1mc> jelmer: could you recommend a page that would detail some of this advanced functionality?  i think we use bzr in a pretty straight-forward manner, but it would be good to know what options are more experimental, and what options are better supported.
[19:23] <nubbun> Odd_Bloke: thank you for the response to the first PYTHONPATH bug report.
[19:25] <jelmer> j1mc: it's fairly simple actually; it enables by reference nested trees
[19:25] <jelmer> j1mc: created using "bzr join --reference". If you avoid using that command you should be fine
[19:25] <j1mc> jelmer: thanks.
[19:29] <TheMonkey> hola
[19:30] <TheMonkey> what is the recommended way of setting up a read-only bzr repo over http?
[19:30] <james_w> TheMonkey: there should be no setup needed, just serve the branch over HTTP.
[19:31] <awilkins> jelmer: Mutters should be showing up in the test log?
[19:31] <TheMonkey> so just copy the folder to the server?
[19:32] <james_w> TheMonkey: yes, bzr push can do that.
[19:32] <TheMonkey> james_w bzr push over http?
[19:33] <james_w> TheMonkey: no, bzr push over ssh or something.
[19:33] <TheMonkey> ah, yes
[19:34] <TheMonkey> is there webDAV support or similar planned to support http for writing, too?
[19:34] <TheMonkey> just curious, being a long time svn user
[19:38] <james_w> TheMonkey: there is a webdav plugin, but it is marked experimental.
[19:39] <jelmer> awilkins: yep
[19:39] <TheMonkey> james_w, i see. thanks for the info, i can wait :)
[19:40] <awilkins> jelmer: This stack dump lists a line that occurs after a mutter, but the mutter output isn't showing
[19:41] <jelmer> awilkins: it may not have been flushed to disk
[19:42] <awilkins> jelmer: can you force it, because knowing the value would really help :-)
[19:43] <awilkins> jelmer: It's to STDOUT anyway, why would disk flush be a problem?
[19:49] <jelmer> mutter doesn't print anything to stdout
[19:49] <awilkins> Oh, so the test routine is reading the log file then
[19:50] <awilkins> Might it be in the log?
[19:50] <jelmer> awilkins: no, it's not reading the log file either
[19:50] <jelmer> mutter writes to the log file
[19:50] <awilkins> I'm seeing text that is in mutters in my output when I run this test
[19:53] <awilkins> Or maybe I'm not
[19:53]  * awilkins is going mad
[19:54] <awilkins> Nope, there it is "Guessed branching scheme" - the only place I can find it is in a mutter and it shows in the output
[19:55] <jelmer> awilkins: it will remember the mutters for a particular test in memory and output that when the test fails
[19:55] <jelmer> after all tests have run
[19:55] <awilkins> jelmer: Which is what's puzzling me because the stack dump says line 94, the mutter is on line 93
[19:55] <awilkins> Just before it enters the pyx code
[19:55] <jelmer> it should never be printing any of the mutters data to stdout during the test run, only afterwards
[19:56] <awilkins> This is afterwards on a --one run
[19:56] <jelmer> awilkins: But that one's not crashing then?
[19:57] <awilkins> jelmer: No, but it's weird ; if I run it from Eclipse it passes, from the shell it fails
[19:57] <jelmer> have you tried running it inside a debugger?
[19:58] <awilkins> jelmer: Does "debug as python unit-test" from Pydev in eclipse count?
[19:59] <awilkins> jel
[19:59] <awilkins> jelmer: I presume the debugging is just calling pyunit
[19:59] <jelmer> awilkins: Not really - I mean a C/C++ debugger
[20:00] <awilkins> jelmer: I'd have to run it from a python console and attach it, yes?
[20:10] <james_w> dato: hi, I think taking the first line of the commit message as special has something to do with it.
[20:10] <dato> james_w: sorry?
[20:10] <james_w> dato: also the fact that the commit messages are shown much more prominently with git's usual submit message.
[20:10] <james_w> dato: re: your blog, sorry.
[20:11] <dato> aah, for the "good" part?
[20:11] <james_w> yeah,
[20:11] <dato> possibly, yeah
[20:11] <james_w> I do agree that it is a good thing that is much more common there.
[20:19] <jelmer> awilkins: You should be able to start the python debugger in visual studio or sometihng
[20:21] <awilkins> jelmer: I have python.exe attached ... now I'm having a hard time running the test from the console
[20:23] <awilkins> jelmer: tried "commands.run_bzr(["selftest", "svn", "--one"])    but it stops in __init__ for tests because theres no log file
[20:25] <jelmer> awilkins: can't you just attach to "python.exe c:\path\to\bzr.exe selftest svn" ?
[20:30] <awilkins> jelmer: Yes, I think so ... C dev is not my usual domain, I'm a Java / VB6 / CSharp coder by trade
[20:31]  * awilkins energises
[20:32] <mw-home_> I've got a question.  I use SVN right now, on a remote server.  I'm going on vacation and bringing my laptop.  Can I make a local bazaar repository based on my svn repository, then do lots of local commits, then when i come back, push it all into the svn repository?
[20:32] <awilkins> mw-home_: YEs
[20:33] <mw-home_> thanks!
[20:33] <awilkins> jelmer: That test still fails and throws no unhandled exceptions that a debugger catches
[20:33] <awilkins> mw-home_: You need the bzr-svn plugin
[20:34] <awilkins> jelmer: If you have VS on windows it tends to allow you to attach a debugger JIT just before the process drops dead anyway
[20:34] <arnetheduck> awilkins, when recommitting those changes, will each local commit become a svn revision or will all changes go into one svn rev?
[20:34] <mw-home_> awilkins: ok.  i'll try to get that plugin.
[20:35] <awilkins> arnetheduck: Each mainline revision becomes a single SVN revision
[20:36] <arnetheduck> awilkins, nice - that means that I can keep a read-only svn repo in sync with a particular bzr branch with very little effort
[20:39] <mw-home_> i installed bazaar, but i don't have a bzr in my path.  i have a baz in my path.  are these the same?
[20:39] <LeoNerd> No... baz is the arch reimplementation; a totally differnet program
[20:40] <james_w> mw-home_: if you are Debian/Ubuntu install bzr instead of bazaar.
[20:40] <mw-home_> thanks
[20:40] <jelmer> awilkins: It should be possible to start a process in the debugger
[20:41] <awilkins> jelmer: Yes, I've managed that, but it didn't trap anything
[20:41] <awilkins> jelmer: For this bug, the default branch_implementations.test_branch.TestBranch.test_create_checkout tests are failing the same way
[20:41] <jelmer> awilkins: how do you mean? Running "bzr selftest svn" inside the debugger doesn't make it crash?
[20:42] <awilkins> jelmer: No, I was just running with --one and the first fail isn't scary
[20:42] <awilkins> jelmer: Running without --one now ; it was attaching to the process before
[20:43] <awilkins> jelmer: One problem is I don't think my Python has debug symbols (the Windows build is a bit short of them)
[20:43] <awilkins> jelmer: Can Pyrex build with DEBUG on ?
[20:43] <awilkins> jelmer: That wasy the extensions at least would have symbols
[20:50] <awilkins> jelmer: Well, the debugger traps it, it's in libapr.dll
[20:51] <arnetheduck> dato, managed to make a little bash script that creates tags based on the tags
[20:52] <awilkins> jelmer: I'll load APR sources into VS and try againb
[20:52] <arnetheduck> there are some problems though - it seems that when one does svn copy, it doesn't always note the correct revision that the copy came from - sometimes it uses an old revision + changes made since that revision
[20:55] <arnetheduck> or rather, that the revision of the directory isn't always the revision of the entire copy, but older, so if I tag that revision in bzr, it doesn't get all changes...
[20:58] <mw-home_> subversion does checkout, mercurial does clone; what do i do to get a working copy of somebody else's project in bzr?
[21:00] <awilkins> jelmer: bzr-svn needs sqlite, yes?
[21:02] <james_w> mw-home_: branch (or clone) if you want a proper branch like mercurial, checkout if you just want a working copy for their branch like subversion
[21:02] <jelmer> awilkins: yep
[21:03] <awilkins> jelmer: I'm having success building the python 2.5.2 sources from scratch, few deps like sqlite missing ATM though
[21:03] <awilkins> Also running that APR project in DEBUG now (doh)
[21:04] <arnetheduck> jelmer, found a place where bzr-svn loses history when doing svn-import
[21:05] <mw-home_> i'm going to read the bzr for subversion users guide, then try to figure out what I need to do to use both a remote SVN repository and a local bzr repository.
[21:06] <james_w> mw-home_: you will want "bzr branch" for the use case that you described above.
[21:06] <james_w> you can then take that on holiday, commit as you like, and the when you come back "bzr push" to update subversion.
[21:07] <arnetheduck> jelmer, here are the two log entries if you have a second to take a look: http://pastebin.ca/953159
[21:08] <mw-home_> james_w: i thought I wanted to do a bzr checkout of my svn repository.  I should use bzr branch instead?
[21:09] <awilkins> mw-home_: Yes, you do. Or even better, create an empty branch (--pack0.92-subtree) and pull into it (if it's a big SVn repo)
[21:09] <james_w> mw-home_: if you do checkout then it will update subversion on every commit, if you do branch then it only does it when you push.
[21:09] <james_w> so you need network access to the svn server to commit in a checkout, and if you are on holiday this may be
[21:10] <james_w> difficult, so I would say branch is better.
[21:10] <jelmer> arnetheduck: ?
[21:10] <jelmer> arnetheduck: where?
[21:10] <james_w> You can switch between them as you like with the "bind" and "unbind" commands though, so the decision is not too big now.
[21:11] <arnetheduck> jelmer, the files, those that are added & removed
[21:11] <jelmer> arnetheduck: what would you expect it to do? bzr doesn't have a "replace" operation
[21:11] <arnetheduck> if you look at the svn log, you'll see they've been replaced (R), but that that new versions came from trunk
[21:12] <jelmer> arnetheduck: you'd expect them to be M ?
[21:13] <mw-home_> james_w: thanks!  That makes a lot of sense.  So, bzr push sounds sort of like merging.
[21:14] <arnetheduck> jelmer, I'm not sure what I'd expect them to be...I would expect having full logs for those files though...if you look at the svn log you'll see that the files come from trunk
[21:15] <arnetheduck> jelmer, so doing svn log you get the full history...doing bzr log on the same files gives just one revision
[21:16] <jelmer> arnetheduck: R in this case is an alias for delete existing file + copy from somewhere else
[21:16] <jelmer> arnetheduck: bzr doesn't support copy tracking (yet)
[21:16] <jelmer> so there's nothing sane bzr-svn could map this to
[21:16] <jelmer> it could do extra processing to infer that there are no other ancestors of those particular files in the current tree, but that would be very expensive performance-wise
[21:17] <jelmer> arnetheduck: I would rather instead wait for copy tracking support in bzr to land
[21:18] <james_w> mw-home_: merging in bzr is a bit different, you can only push if the two branches haven't diverged.
[21:18] <james_w> if you both have commited some revisions then you need to merge in one branch and then push to the other.
[21:19] <mw-home_> james_w: I really should just read the docs.
[21:20] <james_w> mw-home_: that would probably help. Also just playing with a couple of branches for a minute might help
[21:21] <james_w> mw-home_: just create a throwaway branch with "bzr init foo" then add some files, commit and then branch, push, pull, merge etc. to see what is possible.
[21:21] <james_w> then "bzr log" can show you what you did.
[21:22] <james_w> Also "bzr viz" from bzr-gtk can show you a graph that may help you to visualise what is going on.
[21:24] <arnetheduck> jelmer, but it does track the copy for the directory (and the unchanged files...)?
[21:27] <mw-home_> I installed the bzr-svn package; is there a separate bzr-svn executable, or does it augment the bzr executable?
[21:27] <jelmer> arnetheduck: The branch root copy is tracked yes, but that is not a copy in the bzr sense
[21:28] <jelmer> mw-home_: You should be able to use most bzr subcommands with subversion urls now
[21:28] <jelmer> just like you would with bzr urls
[21:29] <mw-home_> jelmer: my svn repository requires http authentication.  the bzr-svn FAQ says that it will use cached userIDs and passwords.  but it ain't working for me right now.
[21:29] <mw-home_> I'm doing bzr branch http://myrepository/myproj
[21:29] <mw-home_> And I get a 401 reply (of course).
[21:30] <arnetheduck> jelmer, ah, ok...because I guess it's a fairly common situation for svn repos - the above probably happened because if you do a commit, the revision of the directory won't be updated until you do an update (directories generally get the same revision as the revision of the newest sub-entry), so if you do svn copy from a working copy that hasn't been updated, you end up with logs like mine above
[21:31] <jelmer> mw-home_: have you forced subversion to cache the password for you?
[21:31] <jelmer> mw-home_: what os are you on?
[21:32] <jelmer> arnetheduck: I agree it's not as nice as it could be
[21:32] <jelmer> arnetheduck: it leads to confusing logs in svn itself as well though
[21:32] <mw-home_> jelmer: yeah, i have a cached password.  I can do svn info http://myrepos/myproj and I get data back, and I don't get prompted.  I'm using ubuntu gutsy.
[21:34] <jelmer> mw-home_: you may have to use svn+http:// rather than http://
[21:34] <arnetheduck> jelmer, indeed - although I must admit it's the first time I look at the log entry of a branch in svn =) I didn't expect it either...
[21:35] <mw-home_> jelmer: yeah, that seems to be working.  Thanks!
[21:35] <mw-home_> Will I now have my entire svn repository, history and all, inside bzr now?
[21:35] <mw-home_> or do I only get the most recent (HEAD) revision?
[21:36] <arnetheduck> jelmer, in any case, I have a bash script now that reads the revision of the directory and makes a tag for that revision in the trunk so that tags are tagged...let me know if you think it could be useful...
[21:36] <arnetheduck> *the tag directory
[21:36] <jelmer> mw-home_: you'll get the full history of that particular branch
[21:36] <jelmer> mw-home_: I'll update the FAQ
[21:36] <mw-home_> jelmer: wow.
[21:37] <jelmer> mw-home_: assuming you used "bzr branch" and not something like "bzr co --lightweight"
[21:37] <mw-home_> jelmer: I did bzr branch.
[21:38] <mw-home_> And so now, can I use bzr commit to do local commits, and bzr push to put stuff into SVN?
[21:38] <jelmer> mw-home_: yep
[21:39] <mw-home_> I wish there weren't so many competiting source-control projects.  it's intimidating for people that don't want to do a lot of research.
[21:40] <arnetheduck> jelmer, dato, thanks for the help! (In my case, I can make it tag correctly by not using the revision of the first common tag/trunk ancestor but the revision that matches the svn revsion of the tag -1)
[21:41] <jelmer> arnetheduck: cool
[21:42] <jelmer> arnetheduck: Any chance you can link to your script on the wiki
[21:42] <jelmer> arnetheduck: It may be useful to others (although hopefully we'll have a more structural solution soon)
[21:44] <arnetheduck> jelmer, I can paste it on the wiki if that's ok? I have no good web host to put it on...
[21:45] <arnetheduck> jelmer, it's pretty crude too, I really don't like bash scripting and consequently I suck at it...
[21:46] <arnetheduck> jelmer, last questing, is there a good way of finding the bzr revid of the last revision on trunk that preceded the revision of a branch?
[21:47] <arnetheduck> jelmer, in other words, if I made a tag on svn revision 501, is there a good way of finding the last revision on trunk before 501 (500 in my case since I only commit to trunk)?)?
[21:49] <mw-home_> To pull in from svn into bzr, since I did a bzr branch, do I need to do a bzr pull?
[21:50] <james_w> yep
[21:50] <mw-home_> ignore me.  i'm trying it out.
[21:50] <mw-home_> it worked!
[21:50] <mw-home_> bzr seems great so far.
[21:53] <Manu_> I would like to know how to specify the drive letter with the file:// protocol under windows
[21:59] <mw-home_> Thanks to everyone that has helped me out.  I now know how to use bzr to make local commits and to still use svn.  This is a really nice set up.
[22:03] <awilkins> jelmer: I now have a working debug build of Python, but joy of joy, it can't seem to load Pyrex modules
[22:04] <awilkins> jelmer: Maybe I should rebuild them with the compiler I used to build the python
[22:13] <james_w> Manu_: I don't know I'm afraid, have you tried file:///c:/whatever?
[22:14] <jelmer> awilkins: Ouch
[22:14] <awilkins> jelmer: Par for the course, I fear
[22:14] <jelmer> awilkins: Is the difference so big between the code generated by differnet compilers on windows?
[22:15] <awilkins> jelmer: Well, the distutils build_ext stuff refuses to build unless you have the same compiler that Python was built on, so I presume there is a good reason
[22:23] <Manu_> james_w: yes it works i forget to add an extra /
[22:24] <awilkins> jelmer: Damn, damn, damn. The modules built with VC8 (after inserting enough into the registry to convince distutils that I had it installed...) but they still don't load
[22:25] <awilkins> jelmer: Maybe if I put the plugin folder on the pythonpath
[23:10] <tca> When I install bzr in my home dir on line with  "--home ~", is it only bin/bzr and python/bzrlib that needs to be deleted to uninstall?
[23:12] <tca> I'm having seeing this (http://www.pastebin.org/24908) when running bzr log with bzr 1.3, and want to completely reinstall before bugging people more.
[23:25] <tca> "bzr log --long" fails with the error mentioned above, but with --line or --short it works ok.


 Yes, I really liked that one.
[17:34] <Mamarok> very beautiful, I downloaded it
 I have it as my desktop right now on my workstation.