[08:01] <mup> PR snapd#12431 closed: tests/lib/muinstaller: build from master again <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12431>
[08:16] <mup> PR snapd#12434 closed: tests: add more disk space to ubuntu-22.04 for nested tests <Simple 😃> <Run nested> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12434>
[09:11] <mup> PR snapd#12378 closed: overlord: remove apparently unused sk.yaml <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12378>
[10:36] <mup> PR snapd#12438 opened: tests: fix shellcheck warnings on unreachable code and var quoting <Test Robustness> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12438>
[11:02] <mup> PR snapd#12439 opened: hookstate: log ignored hook errors also to the journal <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/12439>
[12:02] <mup> PR snapd#12436 closed: daemon: improvements to REST API helper and JSON responses <Pulse> <Needs Documentation -auto-> <Created by MiguelPires> <Merged by MiguelPires> <https://github.com/snapcore/snapd/pull/12436>
[12:22] <mup> PR snapd#12429 closed: tests: fix the tests.session-support test <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12429>
[12:27] <mup> PR snapd#12440 opened: o/devicestate: turn populateFromSeed into a DeviceManager method <Created by pedronis> <https://github.com/snapcore/snapd/pull/12440>
[13:07] <mup> PR snapd#12441 opened: daemon: improvements to REST API helper and JSON responses (2.58) <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12441>
[15:58] <mup> PR snapd#12438 closed: tests: fix shellcheck warnings on unreachable code and var quoting <Test Robustness> <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12438>
[16:24] <Guest80> There was a large service outage for various snapcraft services this morning.  The status page says all services are now resolved, but I still can't complete a "snapcraft push".  It is seemingly hung while processing the uploaded snap.
[16:32] <Guest80> And -- the status page is now showing the issue.  So I guess it is being addressed.
[16:33] <mup> PR snapd#12442 closed: tests: fix shellcheck warnings on unreachable code and var quoting (2.58) <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12442>
[16:33] <mup> PR snapcraft#4003 opened: Make test_patcher tests not require a real patchelf in /usr/bin <Created by lengau> <https://github.com/snapcore/snapcraft/pull/4003>
[16:58] <mup> PR snapd#12443 opened: many: support logging HTTP requests in the client <Pulse> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12443>
[17:44] <mup> PR snapd#12444 opened: cmd/snap,daemon: add 'held' to notes in 'snap list' (2.58) <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/12444>
[17:54] <mup> PR snapcraft#4004 opened: Suggest an arguably simpler alternative <Created by nicolasbock> <https://github.com/snapcore/snapcraft/pull/4004>
[18:09] <mup> PR snapd#12445 opened: Fix dm-crypt: add read access to /run for cryptsetup <Created by sabaini> <https://github.com/snapcore/snapd/pull/12445>
[21:10] <mup> PR snapd#12332 closed: tests: import changes from snapd-testing-tools project <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12332>
[21:25] <mup> PR snapd#12437 closed: cmd/snap,daemon: add 'held' to notes in 'snap list' <cherry-picked> <Pulse> <Needs Documentation -auto-> <Created by MiguelPires> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/12437>
[22:25] <mup> PR snapd#12372 closed: tests: running spread tests in ubuntu lunar <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/12372>


[02:33] <ciberBOB> hey guys just need some link or recommendations for initiatives in the development of the Linux kernel and contribute something to the community
[02:34] <ciberBOB> not is channel for disscusion for kernel developer ?
[08:57]  * abogani waves
[08:57] <abogani> smb_tp: Please remember to pull from my git tree to obtain PREEMPT_RT support update for Hardy.
[08:58] <smb_tp> abogani, I will do. :) Thanks for the reminder
[08:58] <abogani> smb_tp: Sorry to bother more and more. :-)
[08:59] <smb_tp> abogani, Hey, no problem. You had the work with it.
[09:04] <abogani> Are there some plan to change build system for kernel flavours (obviously generic/server excluded) ? Will it remain "out" (as did in Intrepid) or return to "in" (as did in hardy)?
[09:06] <abogani> Perhaps BenC know it ^^^
[09:13] <smb_tp> abogani, I frankly don't know at the moment. Ben might know. Or amitk, did you catch discussions about that ^^^
[10:40] <amitk> smb_tp: abogani: change build system for what again
[10:40] <amitk> ?
[10:41] <smb_tp> amitk, If I understood correctly the question was about -rt flavour
[10:42] <amitk> smb_tp: -rt flavour integrated into the Ubuntu kernel?
[10:43] <smb_tp> amitk, Into the build. But I think the intention was there to have a separate tree like lpia and ports. But I am not remembering well
[11:22] <apw> amitk, just was trying to edit the config lists in the a1 jaunty kernel and got the following error from armel
[11:22] <apw> About to configure armel config.iop32x
[11:22] <apw> make[1]: Entering directory `/home/apw/git2/ubuntu-jaunty'
[11:22] <apw> /home/apw/git2/ubuntu-jaunty/Makefile:449: /home/apw/git2/ubuntu-jaunty/arch/armel/Makefile: No such file or directory
[11:22] <apw> make[2]: *** No rule to make target `/home/apw/git2/ubuntu-jaunty/arch/armel/Makefile'.  Stop.
[11:22] <apw> make[1]: *** [sub-make] Error 2
[11:22] <apw> make[1]: Leaving directory `/home/apw/git2/ubuntu-jaunty'
[11:22] <apw> make: *** [editconfigs] Error 2
[11:25] <amitk> apw: this is with 'debian/rules updateconfigs'?
[11:25] <apw> d/r editconfigs
[11:28] <amitk> apw: hmm.. not sure if editconfigs can work on a different arch
[11:30] <amitk> apw: I know why now...
[11:30] <amitk> it should work... patch coming up
[11:35] <apw> amitk, cool ... will give it a try
[11:35] <apw> (when it appears)
[11:39] <amitk> apw: pushed..
[11:45] <apw> amitk, got it, seems to work just fine for me ... thanks
[11:46] <amitk> np
[12:21] <apw> better warn BenC that the jaunty tree has commits on top of it
[12:23] <amitk> BenC: ^
[12:40] <BenC> apw, amitk: Got it, thanks
[13:05] <BenC> amitk: have you compiled the current tree on armel to make sure things are good?
[13:07] <amitk> BenC: another trivial change to getabis pushed.
[13:07] <amitk> BenC: I haven't. I can kickstart a build now.
[13:25] <BenC> amitk: thanks, I want to upload today and I just need to make sure armel will build
[14:06] <mkrufky> smb_tp: hello.  I have some additional sms1xxx changesets that I merged into a separate branch.  These changes depend on the ones pending from last week.  Would you prefer that I generate a pull request against the last changeset in my last request, or should I just generate a whole new one with all pending changes altogether?
[14:07] <mkrufky> ...and yes, I have LP's created, etc... some of the LP's are private bugs for the Belmont project ....  the fixes can go both to Belmont and Hardy
[14:08] <smb_tp> mkrufky, since I did not get to those yet, I would prefer one new one with everything together.
[14:08] <mkrufky> ok, i will send that right now
[14:08] <mkrufky> thanks in advance :-)
[14:09] <smb_tp> mkrufky, Ah, ok. Could you probably open dummy ones for the private bugs. I know it is a bit tedious but then the references to those can be publicly be followed
[14:09] <BenC> A list of modules that I had to disable in jaunty kernel has been sent to kernel-team@ if any gets that forward porting feeling
[14:10] <apw> smb_tp, just found and interesting work around for my dell studio 15 hang, which fits with your suspicion of cpu concurrency issues
[14:10] <mkrufky> smb_tp: I can just make the bug public -- there isnt actually any private info in there ....  you should just ignore the pull request to mfrey INSIDE the bug report though
[14:10] <BenC> If you're not sure what that feeling feels like, it's a cross between a burning and slight tingling in the area of your brain where common sense takes place
[14:10] <apw> a script to disable all but one cpu for the suspend cycle sort it out
[14:12] <rtg> apw: https://bugs.launchpad.net/bugs/300159
[14:13] <smb_tp> mkrufky, Hm, I should be able to ignore that. rtg what do you think of that?
[14:14] <apw> rtg that one looks 'fun' too, but i think the issue is actually: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/276943/
[14:14] <mkrufky> i just say to ignore because my belmont pull requests are in separate branches against his git tree
[14:14] <rtg> smb_tp: if there is nothing proprietary in the bug, then just make it public.
[14:14] <mkrufky> i been using separate branches for belmont vs hardy mainstream, so that u guys can just pull / merge without any issue
[14:15] <mkrufky> yeah i will do that
[14:15] <rtg> apw: I just noticed that other folks have come up with the same work-wround.
[14:15] <smb_tp> mkrufky, Ok, great. Maybe you could refresh my memory with a mail to kernel-team if you are ready. ;-)
[14:15] <apw> its alll a bit frightening, stupid userland s/w accessing h/w, ouch
[14:16] <mkrufky> smb_tp: yes, will send that mail in a few minutes
[14:16] <smb_tp> mkrufky, Cool, thanks. :)
[14:16] <rtg> off-lining is actually a normal part of suspend, but its also almost the last thing that happens before calling ACPI to suspend.
[14:17] <apw> yeah the key seems to be not-onlining them again for 10s
[14:17] <apw> so that X has woken up and posted the h/w before they arrive
[14:18] <apw> if this suggested bodge patch is right it may be that we are loading irq handlers and not waiting for all cpu's to get with the program before dri interrupts start raining in ... its possible an rcu grace period wait in the dri driver would fix it
[14:19] <rtg> apw: sounds like it could be lieb's VT race.
[14:19] <apw> i thought the bug there was that the switch didn't occur correctly, in that overlapping vt switches could get lost
[14:19] <apw> this is definatly some kind of parallel hardware init problem
[14:21] <rtg> apw: I think it can manifest itself in a variety of ways. I assume you can reach your laptop over the network when its gets wedged on resume?
[14:22] <apw> nope, when it wedges its _hard_ gone
[14:23] <rtg> apw: well, then that isn't the VT lock.
[14:23] <apw> by suspending from a text console, i can resume correctly to there, and wait long enough for wireless to come back up
[14:23] <apw> then login from my 'tv' system, but when i switch to X she dies, and the cpu is pegged
[14:24] <apw> the network connection then times out
[14:24] <BenC> apw: even after waiting some time after resume?
[14:24] <apw> yeah ... its the switch back to X which takes the machine out
[14:25] <apw> and this workaround seems to demonstrate its lack of smp locking somewhere
[14:25] <BenC> apw: what xorg driver?
[14:25] <apw> the bug may well be in X dri drivers, or the real kernel dri drivers, its not clear
[14:25] <apw> intel xorg driver, i915 dri module
[14:30] <apw> other people are reporting it in other dri modules, so its likely a systemic failure across the family
[14:32] <mkrufky> email sent, smb_tp
[14:32] <smb_tp> mkrufky, ok. got it and put on todo list
[14:32] <mkrufky> thanks
[15:29] <apw> rtg this linux backports module (intrepid) seems to crap out if the directory above the build is dirty?  is that reasonable?
[15:30] <rtg> apw: no, its not reasonable, but it happens. it doesn't match correctly if there are old .deb files from a [previous version.
[15:30] <apw> at least i am not going mad
[15:30] <rtg> I've fixed many of the packages.
[15:31] <rtg> apw: since I'm working on Intrepid LBM today, I'll get that fixed.
[15:31] <apw> sounds good, thanks
[15:31] <apw> its the imagelist=$(cat .... bit which seems to die
[15:32] <rtg> thats the one.
[15:32] <rtg> rm -f ../*.deb and it should be OK.
[15:32] <apw> yeah will do that for now, to confirm my lbm patch actually builds
[15:33] <rtg> apw: I'm about to do a complete update from upstream.
[15:33] <apw> of the wireless yes?
[15:33] <rtg> for wireless, are you adding some new driver?
[15:33] <apw> yeah we talked about it last week, its a backport of some nic driver
[15:34] <rtg> apw: I had a vague memory of that (which should be OK)
[15:34] <apw> as its put in there now it would be independant of your changes
[15:34] <rtg> r8169, right?
[15:34] <apw> just trying to confirm i did it right by building it which is challenging at best
[15:34] <apw> yeah thats the one
[15:34] <amitk> rtg: I think the intrepid kernel has the same problem, IIRC
[15:34] <amitk> rtg: imagelist one, I mean
[15:35] <rtg> not too surprising.
[15:35] <rtg> it goes back as far as dapper
[15:35] <apw> its taken me sometime to work out what i needed in my chroots to get it building, and then a while to build them
[16:29] <BenC> apw: in buildscripts git there is a shell script that will create schroot compatible tarballs for chroots, complete with all the build requirements for the kernel
[16:30] <BenC> apw: if you want to just complete your current chroot's, there's a listing of the extra packages needed in there as well
[16:31] <apw> nice
[16:31] <apw> thanks BenC
[16:38] <BenC> np
[16:38]  * BenC needs more coffee
[16:38] <apw> the markets are up 9.2% ... hmmm
[17:03] <amitk> apw: for how long?
[17:05] <amitk> BenC: I got a build failure on ARM. will investigate now. Should I pull in cjwatson's patches as well?
[17:05] <BenC> amitk: I already pulled them and pushed
[17:06] <amitk> BenC: ok. I'll rebase and fix configs.
[17:08]  * amitk is going to setup cross-compilation now. Qemu builds are painful
[17:10] <BenC> amitk: does qemu take advantage of multicore?
[17:12] <amitk> BenC: it does have a -smp option. I have it set to 3. It improves things a bit.
[17:14] <apw> amitk, heh they are closed, so at least until tommorrow morning
[17:14] <apw> amitk, are we going to have some kind of cross-compile porter?
[17:18] <amitk> apw: I'll post instructions to setup a cross-compile toolchain. And then we can ask IS to do it on a fast porter machine. Ideally I would like Ubuntu to provide a cross-compiler package so that it is automatic.
[17:18] <apw> that sound perfect
[17:23] <BenC> amitk: best bet is to talk to doko...debian used to (may still?) have a cross-compile toolchain package, so it might not be too hard to do
[18:04] <kirkland> smb_tp: ping, regarding https://bugs.edge.launchpad.net/ubuntu/+source/iscsitarget/+bug/278625
[18:05] <kirkland> smb_tp: i merged a new iscsitarget package for jaunty, but this problem remains
[18:05] <kirkland> smb_tp: it seems that the kernel module code contained in the source of the new package fixes the "can't unload modules" problem
[18:06] <kirkland> smb_tp: is this module code something that can be merged into the kernel modules code?  what's the rules/policy/process for doing so?  can you help?
[18:06] <smb_tp> kirkland, yeah there was some proc (or sysfs) change
[18:06] <kirkland> smb_tp: cool, you're on top of it?
[18:06] <smb_tp> kirkland, I am not that familliar with why it isn't in the kernel. There was a guy involved who is the maintainer of the package. Maybe he is more up to it
[18:07] <kirkland> smb_tp: so what is in the kernel, iscsitarget wise?
[18:07] <kirkland> smb_tp: seems we ship an iscsci_trgt.ko
[18:07] <kirkland> smb_tp: is that from upstream?
[18:08] <kirkland> smb_tp: do they publish some additional code that's not upstream yet?  (i don't get it)
[18:08] <smb_tp> kirkland, In Intrepid its in the kernel because lum went in there
[18:08] <smb_tp> kirkland, I think the kernel itself has nothing of it
[18:08] <kirkland> smb_tp: so lum includes module code that's not in the kernel.org kernel?
[18:08] <smb_tp> kirkland, yes
[18:09] <kirkland> smb_tp: cool, and what's the process for getting that code update?
[18:09] <kirkland> smb_tp: ie, could we import the "working" iscsi_tgrt code from this package?
[18:09] <smb_tp> kirkland, For Intrepid that is basically what I did.
[18:09] <smb_tp> kirkland, There is a BOM file with the location of the original download
[18:10] <smb_tp> kirkland, IIRC iscsitarget.sf.net
[18:10] <kirkland> smb_tp: cool, so will you be doing the same for Jaunty, at some point?
[18:12] <smb_tp> kirkland, since there is a bit stacking on my queue and my memory isn't sometime lacking it would be good to add a pointer via kernel-team mailing list ;-)
[18:13] <kirkland> smb_tp: okay, cool.  what's that address, please?
[18:13] <rtg> kirkland: we'll have to for Jaunty since iscsitarget FTBS
[18:13] <kirkland> rtg: thanks
[18:13] <smb_tp> rtg, Are you on it
[18:13] <smb_tp> ?
[18:13] <kirkland> rtg: right now, package upgrades of iscsitarget will fail too, because it can't unload the modules on the initscript "stop"
[18:13] <rtg> yeah - we'll get there eventually.
[18:16] <smb_tp> kirkland, Oh just for general "reminders" kernel-team at lists.ubuntu.com :)
[18:16] <s0ullight> hi guys
[18:24] <BenC> just about to boot the jaunty kernel...
[18:26] <BenC> WARNING: I'm getting ready to do a force push
[18:30] <smb_tp> BenC, Did you pull the uvcvideo patch?
[18:31] <BenC> smb_tp: yeah, just did a pull to make sure I have everything
[18:31] <smb_tp> BenC, Cool. pfew :)
[18:32] <s0u[]ight> what kernel is this new release using atm?
[18:33] <NCommander> hey BenC
[18:38] <rtg> sconklin: did you get that? My nick isn't registered, so I never know if private chats work
[18:40] <BenC> NCommander: yo
[18:40] <NCommander> BenC, how goes 2.6.28?
[18:41] <sconklin> rtg: yeah, I got it
[19:02] <calc> BenC: i think you found a perpetual energy machine in your stove :-\
[19:13] <rtg> smb_tp: speaking of iscsitarget, did you build test the Intrepid commit? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commit;h=8c09ecb39475e13bc86dc6df3c7fa787abc34aae
[19:14] <NCommander> calc, BenC's cooking can't be that bad
[19:14] <smb_tp> rtg, At least I always wanted it. I am not sure anymore...
[19:15] <rtg> huh?
[19:18] <smb_tp> rtg, I might suffer from too many nested interrupts. I thought I had test build it might be just an intention that got dropped
[19:19] <rtg> smb_tp: well, reverting it allows the compile to continue. I'll figure it out later this afternoon.
[19:19] <smb_tp> rtg, Hm, found some debs with a matching git with iscsitarget on ronne.
[19:20] <smb_tp> rtg, but that was 9.18...
[19:20] <rtg> smb_tp:  probably some header that changed.
[19:22] <smb_tp> rtg, maybe. if you don't get to it maybe send me an email with the build log
[19:23] <rtg> smb_tp: don't sweat it. I'll get it figured out after lunch.
[19:23] <smb_tp> rtg, no worries. :) enjoy.
[19:23] <rtg> sconklin: you can work around that build failure by reverting the last commit to ubuntu/iscsitarget
[19:23] <smb_tp> rtg, I am off after one more mail
[19:24] <sconklin> rtg: ok, thanks.
[19:27] <lamont> how do I get kvm to _NOT_ stop doing stuff when I iconify the window?
[19:28] <lamont> because I'd like to set the machine to doing a task and then not have the window occupying realestate until I want to go look at it....
[19:30] <amitk> cross compiling is sooo much more bearable...
[20:51] <amitk> rtg: I've fixed armel configs and all four flavours compile now. Pushed fixes to jaunty. Could you inform BenC when he gets back?
[20:52] <rtg> amitk: sure, I'll even do some test building.
[20:53] <amitk> rtg: thanks. Good night...


[01:19] <fullermd> thumper: I'm pretty sure it only ever expands lp: through the UI.  The saved locs in branch.conf are pre-expanded, it won't indirect through the directory service for them.
[01:19] <fullermd> (so if one did get in there, it wouldn't work)
[01:35] <thumper> fullermd: ah, ok
[02:33] <wolter> does bzr use argparse?
[02:35] <mwhudson> no
[02:35] <mwhudson> it has its own thing that predates argparse (and uses optparse as a backend iirc)
[02:36] <mwhudson> see bzrlib.option?
[02:39] <wolter> hm dont know whats that
[02:46] <Peng> What it is is bzr's option parser.
[02:49] <mwhudson> wolter: it's a module within the bzrlib package
[02:52] <chx> how the years have passed :)
[02:54] <chx> six years almost, no wonder the option parse predates argparse :)
[07:00] <vila> wolter, chx : And IIRC argparse is not available for python2.4 (we still maintain compatibility with it so far) right ?
[07:04] <wolter> wouldn't know :s
[07:05] <vila> wolter: np, just saying
[07:06] <vila> wolter: it would be nice to switch anyway but that can't be done *now*
[09:17] <bialix> bonjour vila
[09:17] <vila> bialix: hey !
[09:18] <bialix> :-)
[09:18] <bialix> to continue our last conversation
[09:18] <bialix> I think qbzr really needs atomicity re group of options
[09:18] <bialix> and group of options per se
[09:19] <bialix> groups
[09:19] <vila> can you elaborate on that ?
[09:19] <vila> why is it needed, what are the failure scenarios ?
[09:19] <bialix> we have several pixels options: size, is_maximized flag, sometimes even the relative sizes of widgets
[09:20] <bialix> the scenario is simple: for qbzr those options should be read and written as one operations
[09:20] <bialix> to always have consistent state
[09:20] <bialix> that's my idea
[09:20] <bialix> currently config interface is one-option-at-time oriented
[09:21] <bialix> although some internal options are grouped as well
[09:21] <bialix> say, bound_location + is_bound flag
[09:21] <bialix> not sure about stacked on option
[09:21] <vila> yes, it's one option at a time and I'd like to change that, but when will that fail ?
[09:21] <vila> I mean, with the current implementation
[09:22] <bialix> smart server
[09:22] <vila> what will fail there ?
[09:22] <bialix> we're using commit_data group and older smart servers has no support for dicts in config
[09:22] <bialix> s/has/had/
[09:22] <bialix> now spiv fixed this
[09:23] <vila> that's a different problem, not related to atomicity
[09:23] <bialix> qbzr don't hold the lock all the time
[09:23] <bialix> and bzr-explorer for more broad example
[09:24] <vila> bialix: we're talking past to each other,
[09:24] <bialix> config's API is: if you need 1 option then read a config file
[09:24] <vila> if there is no atomicity, what could go wrong ?
[09:24] <bialix> I can't say
[09:25] <bialix> my point not about imaginary race condition
[09:25] <vila> mine is :)
[09:25] <bialix> but about the situation that sometime some code works with tightly coupled group of options
[09:26] <vila> if you don't encounter a race, then setting the options one by one gives the same end result
[09:26] <bialix> those options should be read simultaneously, and should be written simultaneously
[09:26] <vila> why ?
[09:26] <bialix> except that you have to re-read the same config many times
[09:26] <bialix> let's talk again about smart server
[09:26] <bialix> to change 5 opyions you need 10 operations
[09:27] <bialix> options
[09:27] <vila> yes, the concern is about performance but this can be address more easily than the race conditions
[09:27] <vila> and you can also get atomicity by bencoding your set
[09:28] <vila> of course bencode is user hostile, but that's another issue
[09:28] <bialix> bencoding the set is ad-hoc solution
[09:28] <bialix> I don't really like the idea of bencoding
[09:28] <bialix> I understand it and can use it if nothing else helps
[09:28] <bialix> but I'm not very keen to it
[09:29] <bialix> the very fact that I should bencode my group of options sounds wrong to me, and you?
[09:29] <vila> sure, I'm talking about a temporary solution there and what is the best trade-off
[09:30] <bialix> maybe that's why we have our own wheel in the qbzr
[09:30] <bialix> I can't say
[09:30] <vila> if/when we reach the point where a config *file* is read once and written once for a given transaction, we get the atomicity back without performance costs
[09:31] <bialix> vila: I'm going to implement "group" idea for qbzr's pixel settings
[09:31] <vila> bialix: don't do that with subsections please, you'll make my life harder :-}
[09:31] <vila> bialix: anything else is fine :D
[09:31] <bialix> oh no
[09:31] <bialix> you read my mind
[09:32] <bialix> where is my tin cap?
[09:32] <vila> hehe, may be I'm over concerned with compatibility...
[09:33] <vila> a radical way to address it will be to consider that the new features will be provided for new files only and leave the existing features for the existing files
[09:33] <bialix> yep
[09:33] <vila> then one new feature would be to bootstrap the new file from the old one, converting on the fly
[09:33] <bialix> as I said yesterday I want to extract pixels options into separate zoo
[09:34] <vila> but it still feels wrong to tell you:"yes, use that, I will remove it soon"
[09:34]  * bialix nods
[09:35] <vila> bialix: climb on my rug, I will pull it from under you :D
[09:36] <bialix> hehe
[09:38] <vila> except for the multi-line value problem, *sorting* the file on dotted names could address your finding issues...
[09:39] <vila> and by the way, X resources are also specified with dotted names, so we aren't inventing anything new there
[09:39] <vila> we're talking about a technic used for years
[09:39] <vila> decades
[09:39] <bialix> centuries...
[09:39] <vila> at least :D
[09:39] <bialix> I can't resist sorry
[09:40] <vila> and 'sort -c. -k<n>' is also a good friend to get various sort orders...
[09:41] <vila> yeah, I know, may not work on windows, but still
[09:42] <vila> 'bzr config' also accept regexps for NAME... we can imagine adding a sort option there and you wouldn't have to ever look at the file content
[09:42] <vila> bzr config *size*
[09:42] <vila> err
[09:42] <vila> bzr config .*size.* ?
[09:43] <vila> --scope qbzr
[09:43] <vila> (NIY)
[09:43] <bialix> niy?
[09:43] <vila> Not Implemented Yet
[09:43] <vila> --scope qbzr that is
[09:44] <bialix> that all sound good
[09:44] <bialix> but I think the groups and subsections are really cool
[09:44] <bialix> I understand your intents
[09:45] <vila> and *my* concern is that adding support for subsections will make the UI confusing
[09:45] <bialix> but I see how groups will simplify the things
[09:45] <bialix> I don't need those subsections to be editable by user
[09:45] <bialix> so no UI concerns here
[09:46] <vila> every difference between the data stored in the config files and the way it is accessed is a source of issues
[09:47] <vila> a basic line in a config file is: 'name =value'
[09:47] <vila> so far it translates at the UI level by: to refer to an option I use the 'name' I see in the config file
[09:48] <vila> if you add sections there, it's still valid as long as the sections are used to allow using the same name multiple times but still for the same option
[09:48] <vila> the sections are then used to decide which context is appropriate (extending the idea from locations.conf where the path defines the context)
[09:49] <vila> if you use subsections as part of the name, things become blurry
[09:49] <vila> I want to refer to this option, so wait, what's it's name ?
[09:49] <vila> s/it's/its/
[09:50] <vila> commit data is already violating this principle, hence my concerns about it
[09:51] <vila> overall, I'm trying to *reduce* the number of concepts the user has to deal with, without losing features
[09:52] <vila> so if dict values can be represented with a set of dotted names sharing the same prefix (the dict name), it's better than forcing the user to specify an option differently whether its value is a scalar or a dict
[09:53] <vila> *and* we regain control on section names to carry another kind of information
[09:53] <bialix> I don't understand why commit_data violates this principe
[09:53] <vila> because it uses section names to implement option names
[09:53] <bialix> no, it's not
[09:54] <vila> so we can't use section names for other purposes
[09:54] <vila> yes it is
[09:54] <bialix> it uses section name to get atomicity
[09:54] <vila> go to beginning-of-discussion
[09:54] <vila> atomicity can be achieved with other means
[09:54] <vila> and the user shouldn't have to care about it
[09:55] <bialix> here we call that "hand-made sunset"
[09:55] <bialix> ok, I understand, you want commit_data to die
[09:55] <bialix> that's possib;e
[09:57] <vila> no, I don't want it to die, I want it to be represented differently without losing any other feature
[09:57] <bialix> bencode everything everywhere everytime
[09:58] <vila> bialix: have you read configuration.txt in lp:~bzr-core/bzr/devnotes ?
[09:58] <vila> bialix: no, bencode is user hostile
[09:58] <vila> bialix: using bencode loses the user-friendly property of being able to read the config files
[09:58] <bialix> vila: I don't use locations.conf
[09:58] <bialix> so I don't really care about it
[09:58] <bialix> honestly
[09:58] <vila> bialix: that's not the point
[09:59] <bialix> there are too much config files
[09:59] <bialix> that bothers me
[09:59] <vila> bialix: really ?
[09:59] <bialix> sometimes
[10:00] <vila> bialix: then what about grouping them into the same config file then ?
[10:00] <bialix> maxb will complain
[10:00] <vila> bialix: and use section names to decide which section apply in which case
[10:00] <vila> bialix: rhaaaa, come on, maxb made it clear that he was referring to option specific to a given user on a given host
[10:01] <vila> bialix: and options that nobody want to see but still want to be persistent for that matter
[10:02] <vila> bialix: different type of options requires different config files, yet, the same kind of options should be in the same config file even if they are used by different parts of the code (including plugins)
[10:02] <vila> bialix: the bookmarks plugin is a good example here
[10:03] <vila> it's current implementation use a [BOOKMARKS] section in bazaar.conf but a name space trick (bookmark_xxx) in branch.conf
[10:03] <vila> that's not user friendly !
[10:04] <vila> if I define mypush=lp:~vila in bazaar.conf and want to specialize it in a given branch it will be called bookmark_mypush in branch.conf but when I want to use it I must use 'mypush' ghaaa
[10:04] <vila> bialix: what was the last msg you got ?
[10:05] <vila> jelmer: hi :)
[10:05] <bialix> vila: [12:01]	<vila>	bialix: and options that nobody want to see but still want to be persistent for that matter
 bialix: different type of options requires different config files, yet, the same kind of options should be in the same config file even if they are used by different parts of the code (including plugins)
 bialix: the bookmarks plugin is a good example here
[10:06] <vila> * jelmer<EMAIL_ADDRESS>has joined #bzr
[10:06] <vila> * jelmer has quit (Changing host)
[10:06] <vila> * jelmer (~jelmer@samba/team/jelmer) has joined #bzr
 it's current implementation use a [BOOKMARKS] section in bazaar.conf but a name space trick (bookmark_xxx) in branch.conf
 that's not user friendly !
[10:06] <vila> * tchan1<EMAIL_ADDRESS>has joined #bzr
 if I define mypush=lp:~vila in bazaar.conf and want to specialize it in a given branch it will be called bookmark_mypush in branch.conf but when I want to use it I must use 'mypush' ghaaa
[10:08] <bialix> I see
[10:08] <bialix> whar's the cure?
[10:08] <bialix> bookmarks might use sections everywhere? no wait, we going away of sections
[10:09] <jelmer> 'morning vila, bialix
[10:09] <jelmer> sorry, my VPS is giving me trouble this morning.. now connected directly to IRC :)
[10:09] <bialix> hey jelmer
[10:10] <vila> bialix: the cure is to use: 'bzr.bookmarks.mypush' that you can use in every section in locations.conf, in bazaar.conf and in branch.conf
[10:10] <bialix> vila: I think I don't like them to be in [DEFAULT] section of bazaar.conf
[10:11] <vila> another problem with dict values: say a user want to modify a single value in the dict, what would be the syntax for 'bzr config' ?
[10:11] <bialix> just because they're not defaults
[10:11] <vila> what ?
[10:11] <bialix> I dunno
[10:11] <bialix> vila: I think I don't like'bzr.bookmarks.mypush' to be in [DEFAULT] section of bazaar.conf just because they're not defaults
[10:12] <bialix> I dunno re dicts
[10:12]  * bialix has to press enter not so many times
[10:12] <vila> bialix: if they are defined in bazaar.conf *empty* section ([DEFAULT] is nothing more that an alias for an empty section in branch.conf that's why I want to get rid of it ([DEFAULT] in bazaar.conf that is))
[10:13] <vila> bialix: then they defined the default value for the bookmark if it's not defined anywhere else
[10:13] <vila> so it *is* a default
[10:13] <vila> if it's defined in branch.conf, it takes precedence
[10:14] <bialix> yes, I know this hack
[10:14] <vila> I want this hack to become a generalized feature
[10:15] <bialix> you know, in fact I really like how git works with configs
[10:15] <vila> and I want to reuse the locations.conf trick for naming sections as paths but allow it in bazaar.conf to define default values as opposed to overriding values in locations.conf
[10:15] <bialix> in git qbzr.foo means [qbzr] section and option foo
[10:15] <vila> I dunno how it works in git, tell me
[10:16] <vila> that's exactly my proposal, see configuration.txt in devnotes
[10:16] <bialix> that's how I understand it from their man pages
[10:16] <bialix> no, you say there should not be sections
[10:16] <vila> no
[10:16] <vila> read configuration.txt in devnotes
[10:16] <vila> I want to use sections, but not for dict values
[10:17] <vila> and if they are used for dict values I can't use them
[10:17] <bialix> vila: I'm reading now
[10:17] <vila> k
[10:21] <bialix> it said: This means that in the most common cases, the user doesn't need to define any section.
[10:22] <bialix> also: A section is named by the path it should apply to (more examples below).
[10:22] <bialix> vila: qbzr has several options that are not very suitable for bazaar.conf
[10:22] <vila> bialix: I thought we agreed yesterday that these options should stay in their own config file
[10:23] <vila> Not all config files needs to define sections (in the most common cases, the user doesn't need to define any section)
[10:24] <vila> I'm not aiming to collect all options in bazaar/branch/tree conf files if they don't fit, and I think the qbzr window options don't fit
[10:25] <vila> the commit data fits in tree.conf, I don't yet see a case where it would need sections (but I may be wrong there and maybe the colocated branch *relative* path may be useful)
[10:27] <bialix> ok, enough food for the mind, it's time to get some food for the body
[10:27] <bialix> vila: I'm sure we can continue our mindstorm later
[10:28] <vila> bialix: cool, one last thing:
[10:28] <bialix> I'm too qbzr-centric
[10:28] <bialix> vila: you want to get a broader picture
[10:28] <vila> bialix: when I wrote the devnotes doc, I was only considering paths for section names (and mostly absolute paths for that matter)
[10:28] <bialix> maybe that's why we can't find the common way
[10:29] <vila> bialix: now, I realize section names can be used for different cases, qbzr.windows.conf can use them for window names (since they are no overlap in this case), authentication.conf can use them for server urls or regexps, etc
[10:30] <vila> bialix: now, I realize section names can be used for different cases, qbzr.windows.conf can use them for window names (since there is no overlap in this case), authentication.conf can use them for server urls or regexps, etc
[10:30] <bialix> k
[10:30] <vila> bialix: but the basic idea is to not use section names if you can use the name space to achieve the same result
[10:30] <bialix> there is no rul for all, right?
[10:31] <vila> bialix: roughly yes, as long as a defined common set of rules is respected by all :D
[10:32] <bialix> I need to chew your words some time
[10:32] <vila> one is: option names are valid python identifiers (aka dotted names, no space, no funky stuff, may be even mo unicode if it makes things simpler)
[10:32] <bialix> no unicode -- that's right
[10:33] <bialix> but anyway, can I have groups API please?
[10:34] <jelmer> groups?
[10:34] <vila> you can build them yourself from get_option_matching('^qbzr.windows.')
[10:34] <bialix> what's about set?
[10:35] <bialix> jelmer: we're talking about groups of options
[10:35] <vila> bialix: or rather, forget about atomicity by considering that we will reach a point where we read/write a conf file once by transaction
[10:35] <vila> bialix: set ? You mean list values ?
[10:35] <bialix> no I mean about set options back
[10:35] <vila> EPARSE
[10:35] <bialix> write
[10:35] <bialix> get-set
[10:35] <bialix> you wrote get_option_matching
[10:36] <bialix> can I set dict :-D
[10:36] <bialix> ?
[10:37] <vila> if the conf file is written once, you don't care about setting each option separately, if you need helpers for that, we can think about it yes
[10:38] <bialix> (abort write commit group)
[10:38] <vila> bialix: [conf.set_user_option('qbzr.windows.%' % k, v) for k,v in d.iteritems()]
[10:39] <bialix> conf.set_user_option_group(mydict-here) :-P
[10:40] <vila> yes, that's the helper
[10:40] <vila> but you need to give it a name too
[10:41] <vila> probably set_user_option_from_dict(name, dict)
[10:41] <bialix> and it will bencode?
[10:41] <vila> and only scalars accepted as values in the dict
[10:42] <vila> nooo
[10:42] <bialix> I think we stuck around ConfigObj
[10:42] <vila> good enough for now, no need to change IMHO
[10:43] <vila> how we *use* it should be better enforced though
[10:43] <bialix> that's what I mean
[10:43] <bialix> it has many features
[10:43] <bialix> but some of them are not good enough or de-jure prohibited
[10:43] <vila> yup
[10:43] <bialix> but not de-facto
[10:44] <vila> but that's part of the evolutionary process, you start using/testing and change your mind along the way
[10:44] <bialix> ok
[10:44] <vila> many plugins poke under the cover because the proposed features were too limited
[10:45] <vila> I'm trying to summarize all the current needs so we can propose a better evolution
[10:45] <bialix> that's good
[10:45] <bialix> I hope shaggy qbzr needs gave you many food
[10:50] <alf> Hi, is there an easy way to change the nicknames of the commits in a branch (eg because I decided to rename a branch)?
[10:50] <vila> bialix: yup, very good feedback !
[10:51] <vila> alf: no, but further commits will respect the new nick
[10:51] <vila> alf: revisions are immutable, if you want to change them, you need to create new ones
[10:52] <vila> alf: they are immutable because it means they can be shared and everybody can refer to them by their ID and have the guarantee that they are talking about the same thing
[10:52] <vila> alf: so you can't change that thing without losing this property
[10:54] <alf> vila: sure, but the branch I am working on is still local/private...
[10:54] <alf> vila: could the rebase plugin help here?
[10:54] <vila> alf: sure, rebase will create *new* revisions
[10:55] <vila> if don't know if you can change *just* the nickname from the available UI, but rebasing is the way to go for that kind of change
[11:04] <alf> vila: thanks, although I cannot make rebase to work. When I try to rebase the existing revisions in a branch after having changed the nick it just says "Base branch is descendant of current branch. Pulling instead"
[11:05] <alf> vila: which makes sense, of course, but doesn't fit my needs in this case
[11:05] <vila> alf: right, that's... yeah, exactly
[11:05] <vila> alf: file a bug
[11:05] <vila> alf: out of curiosity, why does the nick matters in your case ?
[11:06] <alf> vila: just being pedantic, really :)
[11:06] <vila> alf: ok, np, I am pedantic myself on occasions ;)
[11:08] <jelmer> vila: are there still plans to switch to Tarmac at some point?
[11:09] <vila> jelmer: yes
[11:09] <vila> jelmer: we were supposed to do that back in Dallas and then... it didn't happen ;)
[11:15] <jelmer> vila: ah, ok
[11:32] <jelmer> vila: whoa, 33893 unit tests...
[11:32] <vila> ...and counting ;D
[11:34] <vila> jelmer: http://babune.ladeuil.net:24842/job/selftest-lang-C/25/testReport/ says 125,095 tests :D
[11:34] <vila> and some slaves are missing in this run ;)
[11:35] <vila> ...and that's without any plugins of course
[11:36] <vila> jelmer: but back to your remark, was there a recent increase because you managed to better plug the foreign tests ?
[11:37] <vila> jelmer: or are they already well plugged and you just noticed the number ?
[11:45] <jelmer> vila: yeah, this is partially because of the per_{workingtree,branch,repository} tests now running against the foreign plugins
[11:46] <jelmer> I think that accounts for a couple of thousand tests
[11:46] <jelmer> now to get them all passing..
[11:47] <jelmer> oh, and we do stuff like this:
[11:47] <jelmer> bzrlib.plugins.upload.tests.test_upload.TestBranchUploadLocations.test_set_push_location(HgWorkingTreeFormat)
[12:05] <vila> jelmer: O_O
[12:05] <vila> jelmer: fun ahead :D
[12:07] <vila> jelmer: if the end result is that suddenly upload works for svn, hg and it trees... that would be... an unexpected but interesting side-effect...
[12:07] <vila> where did that 'g' go ?
[12:07] <jelmer> vila: Yeah, that'd be nice.. not sure yet how shallow these test failures are
[12:08] <vila> jelmer: the root cause should be quite clear in upload sources, I was aiming in the same direction as you... getting test parametrization for free from bzr
[12:09] <vila> jelmer: and that's all I care about, whatever the way it's achieved
[12:09] <jelmer> vila: yeah, this is really neat
[12:10] <jelmer> I've already discovered some things that would be genuine bugs
[12:10] <vila> bingo !
[12:13] <maxb> So, anyone want to look at something weird?
[12:13] <maxb> There's a bzr-builddeb test that fails in the daily PPA, but not for me locally
[12:14] <maxb> Also, I have replaced my bzr-cvsps-import MP with two new ones that supersede it
[12:15]  * jelmer tries to run the bzr-builddeb tests
[12:19] <jelmer> maxb: Runs fine here too - what's the error in the daily PPA?
[12:20] <maxb> TestMergeUpstream.test_smoke_renamed_file fails in a way I do not really understand
[12:21] <maxb>   File "/build/buildd/bzr-builddeb-2.6+bzr526~natty1/merge_upstream.py", line 96, in changelog_add_new_version
[12:21] <maxb> OSError: [Errno 2] No such file or directory
[12:45] <jelmer> maxb: Hmm, no idea at a first glance..
[12:46] <jelmer> maxb: r=me for your bzr-cvsps-import MPs
[13:12] <wgrant> What's the conventional way to initialise plugins in a script?
[13:12] <wgrant> Just call bzrlib.plugin.load_plugins() after the imports?
[13:13] <jelmer> wgrant: yep
[13:14] <wgrant> jelmer: Thanks.
[13:29] <vila> wgrant: still up ???
[13:30] <wgrant> vila: Yes.
[13:30] <vila> wgrant: oh my, I wanted to ask you to keep an eye on package imports fallouts once I deploy a new driver there, but you will never wake up tomorrow :D
[13:31] <vila> wgrant: err, I mean, any potential fallouts on the lp side
[13:31] <wgrant> vila: What are you changing?
[13:31] <vila> wgrant: the mass_import.py script which should not change anything regarding launchpad, so you're not supposed to see anything unsual
[13:32] <vila> wgrant: and since I didn't hear rumours about a debian release, you may in fact see nothing at all, but just in case I wanted you to be aware of the change
[13:32] <wgrant> Haha.
[13:32] <wgrant> Thanks.
[13:37] <vila> jelmer: yes, I know, deprecating symbols is a pita
[13:41] <jelmer> vila: hmm?
[13:42] <vila> jelmer: oh, you haven't seen my last review yet :)
[13:42] <vila> jelmer: and thanks for yours by the way !
[13:42] <jelmer> ah :)
[13:49] <jelmer> thanks for the review(s), much appreciated :)
[13:51] <jelmer> only one branch left before being able to move the weave formats into a plugin..
[13:52] <vila> \O/
[13:53] <vila> one last test before pulling the new driver for the package importer
[13:55] <jelmer> niice
[13:56] <vila> ok, imports failed, test succeeded :D
[13:56] <vila> yes, the test was to collect the failures ;)
[14:18] <wam> How do I save credentials when using bzr+https so that the next bzr up or bzr commit won't ask me again?
[15:00]  * jdobrien is back from kneeling in the dirt
[15:00] <jdobrien> oops
[15:04] <maxb> wam: http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/authentication-help.html should tell you what  you need to know
[15:05] <wam> ah - authentication.conf. I just read about it as a feature-request.
[15:05] <wam> thanks. I'll try
[15:05] <wam> or is this 2.4 only?
[15:06] <maxb> no, it is fairly old
[15:07] <wam> nice, thanks
[15:16] <cr3> what's the proper way to merge diffs between releases from one branch to an unrelated branch, like lp:foo to lp:ubuntu/foo for example. I keep doing something like (cd /path/to/foo; bzr diff -r1..2) | patch -p0, but that's aweful :(
[15:18] <wam> maxb: yeah, works smoothly, although the scheme bzr+https is not recognized in my 2.2. But that's not requried. Any scheme will do. thanks again
[15:18] <maxb> wam: hmm. Does it support https: ?
[15:21] <wam> maxb: positive
[15:24] <maxb> wam: Hmm. It's definitely supposed to support bzr+https:
[15:26] <catphish> i was just about to ask about bzr+https
[15:26] <catphish> it doesn't seem to work well
[15:30] <catphish> i think there's a problem with python 2.6 + pycurl + bzr+https
[15:30] <catphish> which seems to be killing my attempts to use it
[15:36] <wam> dunno about pycurl, but it runs smoothly for me
[15:37] <catphish> https://bugs.launchpad.net/bzr/+bug/241698
[15:37] <catphish> https://bugs.launchpad.net/bzr/+bug/365874
[15:37] <catphish> that's the problem i'm having
[15:37] <catphish> it seems to affect only the combination of smart http + SSL + basic auth
[15:38] <catphish> but that's the configuration i need to use :(
[15:40] <maxb> catphish: have you tried uninstalling pycurl so that it uses urllib?
[15:41] <catphish> maxb: i'm told it can be made to work using https+urllib://
[15:41] <catphish> but that doesn't seem to try to use the smart protocol
[15:43] <catphish> yes, it seems to work when pycurl is uninstalled
[15:43] <catphish> that's annoying
[15:43] <vila> wam, maxb: https is the scheme to be used in authentication.conf when using either https or bzr+https
[15:43] <catphish> (not annoying that it works, but it would be nice if there were some other way to stop it using pycurl)
[15:44] <vila> bug #241698, ubot, tell me more
[15:44] <catphish> ubot5 is on the ball
[15:44] <vila> catphish: did you read the bug reports ?
[15:45] <vila> catphish: can you provide a .bzr.log while running a failing command with -Dhttp as an additional parameter ?
[15:45] <vila> vila: did you check your inbox ?
[15:45] <catphish> what does -Dhttp do?
[15:45] <vila> err, wait
[15:46] <vila> catphish: it will output a transcript of the http dialog in .bzr.log
[15:46] <catphish> ah
[15:46] <vila> catphish: for debug purposes
[15:46] <vila> catphish: so you didn't read the bugs comments then ?
[15:46] <catphish> i read much of it
[15:47] <catphish> but got distracted by someone else talking about it here
[15:48]  * wam winks
[15:49] <catphish> vila: http://paste.codebasehq.com/pastes/cx5364v4fo26
[15:49] <vila> catphish: but first, what bzr version are you using ?
[15:49] <catphish> 2.1.1, python 2.6.5
[15:50] <vila> nginx/0.7.65
[15:50] <vila> ouch, 2.1.1.. OS ?
[15:50] <catphish> ubuntu 10.04
[15:51] <catphish> User-Agent: bzr/2.1.1 (pycurl: libcurl/7.19.7 GnuTLS/2.8.5 zlib/<IP_ADDRESS> libidn/1.15)
[15:51] <catphish> seems to be what ubuntu installs by default, and therefore annoyingly what users are likely to have
[15:51] <vila> sudo add-apt-repository ppa:bzr/ppa will give you access to the latest and greatest stable versions of bzr itself and a bunch of plugins
[15:52] <wam> oh damn - i always used virtualenv + easy_install ;)
[15:53] <vila> why, do simple things when you can do complicated ones instead ;-D
[15:54] <vila> wam, catphish: But my suspicion will be against nginx
[15:55] <vila> wait, you're in touch with the admins there right ?
[15:55] <catphish> i am the admin there, thats why i'm trying to make this work :)
[15:55] <vila> cool, one less hop in the loop
[15:55] <catphish> and ideally trying to make it work against the old version of bzr that ships with ubuntu
[15:56] <wam> catphish: i just did setup this: http://thomaslow.com/2011/01/24/configure-redmine-advanced-bazaar-integration/
[15:56] <wam> catphish: works perfectly, but you need 2.2
[15:56] <wam> or you'll get a error that bzr can't understand what 401 means.
[15:56] <catphish> yeah, though you can work around that by specitying the username in the url
[15:56] <wam> ah
[15:56] <catphish> bzr+http://username@server
[15:56] <wam> interesting
[15:57] <catphish> it prompts you for the password before making the first request
[15:57] <catphish> so no 401
[15:57] <wam> catphish: are you going with redmine or is that just so that bzr+http works?
[15:58] <catphish> redmine sounds like a competitor
[15:58] <catphish> :)
[15:58] <wam> i see
[15:58] <vila> catphish: first things first: bzr+ssh is not an option ? Easier to setup (well, for some values of easier), guaranteed to work
[15:58] <catphish> bzr+ssh will work
[15:58] <catphish> i just want http(s) to work too
[15:58] <vila> k
[15:58] <catphish> and http works fine
[15:58] <vila> ook
[15:58] <catphish> it's just when ssl is enabled it throws this odd error
[15:59] <catphish> and only when pycurl is installed
[15:59] <catphish> but annoyingly that seems to be how ubuntu is set up
[15:59] <catphish> so id like to be able to work around it
[15:59] <catphish> either with a different URL or by adding headers at the server sidew
[15:59] <catphish> *side
[16:01] <vila> catphish: so, from my dusted memory, the issue was that somewhere in the stack (curl or ssl) someone was trying to seek the a file handle backwards which broke upper levels
[16:01] <catphish> ah
[16:02] <catphish> is there a way simply to disable pycurl?
[16:02] <vila> catphish: the immediate workaround would be bzr+https+urllib:// but this would mean that the certificate is not checked anymore
[16:02] <catphish> i tried that first, but it doesn't seem to recognise the protocol name
[16:02] <catphish> bzr: ERROR: Unsupported protocol for url<EMAIL_ADDRESS>[16:03] <vila> shudder
[16:04] <wam> right, i get that rewind bug too with ubuntu's 2.1
[16:04] <vila> wam: so you confirm it's fixed in 2.2 then ?
[16:04] <catphish> i realise its my own fault for using 2.1
[16:04] <catphish> but lots of my customers will :(
[16:04] <wam> at least it's fixed with my easy_installed 2.2
[16:04] <vila> catphish: sure, not your fault
[16:04] <wam> ah no
[16:04] <wam> 2.3
[16:04] <wam> is what i have now
[16:05] <wam> it's definitively fixed with 2.3
[16:05] <vila> catphish: but it's hard to fix bugs in old releases *and* get them deployed
[16:05] <wam> AND it works with Bazaar (bzr) 2.2b2 - which comes from ubuntu maverick
[16:05] <vila> catphish: we're working on it though, there is  a SRU in the pipes for 2.2, once we get that done... we *may* try one for 2.1
[16:06] <wam> maybe you can backport this package from 10.10
[16:06] <vila> that's what the ppa offers
[16:06] <catphish> any idea if i can do anything server side here?
[16:06] <catphish> or in the url
[16:07] <vila> catphish: stop using authentication may address the problem but I doubt you'll like that ;)
[16:07] <wam> catphish: are all clients yours and are they all ubuntu?
[16:07] <vila> catphish: seriously, it's a client-side issue
[16:07] <catphish> the clients are not under my control, they could be running anything
[16:07] <wam> k
[16:07] <catphish> i'm just trying to maximize compatibility
[16:07] <vila> catphish: will they *require* certificate validation ?
[16:07] <catphish> vila: no
[16:08] <vila> then urllib should work around the issue,
[16:08] <catphish> they just feel better if it says https
[16:08] <vila> shudder
[16:08] <catphish> indeed
[16:09] <catphish> is there a pay to persuade it to use bzr+https+urllib?
[16:09] <vila> damn, where did my defaultToUrllib plugin go ?
[16:10] <catphish> failing that i will have to tell people to upgrade and/or remove pycurl
[16:10] <catphish> and/or drop SSL support for a few months
[16:12] <maxb> It would be nice if we had a more structured approach to the url scheme decorators, such that arbitrary combinations were valid
[16:12] <catphish> is it just a hardcoded list at the moment?
[16:13] <vila> catphish: http://paste.ubuntu.com/571783/
[16:13] <vila> put that in ~/.bazaar/plugins/defaultToUrllib.py
[16:14] <vila> maxb: sure, with automatic tests :)
[16:14] <vila> maxb: unfortunately it's a bit more complex than it appears :-/
[16:14] <vila> maxb: but I agree it would be nice
[16:15] <catphish> vila: that works like magic :)
[16:16] <vila> cool
[16:16] <catphish> i can probably distribute that
[16:16] <vila> catphish: but keep in mind that it won't verify certificates
[16:17] <catphish> that's annoying but IMO less so than telling people they can't use SSL
[16:17] <vila> catphish: it's GPLed
[16:17] <catphish> i saw
[16:18] <catphish> i'll distribute it independently anyway
[16:18] <vila> I never bothered to publish it (and I don't use it anymor eeither 8-)
[16:18] <vila> wam:, ha he's gone :-/
[16:55] <vila> jelmer: what's up with get_module() ? It can returns a *name* or a *module* ? Sounds confusing from the diff, should I review in context or can you answer ?
[16:55] <jelmer> vila: it returns the name of the module
[16:56] <jelmer> vila: Though I can understand how that's a bit vague in the current docstring
[16:56] <vila> Haaaa, always the name, ok
[16:56] <vila> I don't use __module__ every day :)
[16:57] <vila> oooh, I'm not even sure I *knew* about module... how cute...
[17:02] <vila> errr, how come I'm reviewing a mp already marked as superseded >-/
[17:03] <jelmer> https://code.launchpad.net/~jelmer/bzr/per-interrepo-extra/+merge/51166 is the active one
[17:03] <vila> yup, figured that now ;)
[17:03] <vila> I should have think about instead of blaming the 4th dimension...
[17:06] <fullermd> Lousy 4th dimension.  Somehow I never have time to give it the whippin' it deserves.
[17:08] <vila> fullermd: ha ! here you are ! Hello :)
[17:09] <fullermd> I am!  Oh!  There I are.
[17:09] <epoxy> hello. if I 'bzr add' in a directory. then I remove the files with 'rm' (not bzr rm).. when I commit, will the files I 'rm' still be commited or will I get any errors?
[17:12] <epoxy> ah I think bzr status and diff answer that.
[17:19] <danielsh> I init'd a tree yesterday.  I'd like to rewrite history such that the root of the tree is now a subdir (eg, /README now becomes foo/README, with 'foo' a child of the tree root.)
[17:19] <danielsh> currently it seems to me that fast-export is the way to go,
[17:19] <danielsh> are there other/better options?
[17:49]  * danielsh (FTR, fast-export did it with some manual massaging of the stream.)
[17:49]  * danielsh afk
[17:49]  * danielsh (back later)
[18:08] <maxb> danielsh: Hi. Wouldn't it have been simpler to just move all the content into a subdir?
[18:10] <fullermd> Well you really need a pivot_root command.
[18:47] <vila> jelmer: do you have the bzr kanban URL handy ? The ones in my history seem to be 404'ing O_0
[18:51] <maxb> vila: This one? http://people.canonical.com/~mbp/kanban/canonical-bazaar-kanban.html
[18:52] <vila> maxb: Indeed ! Thanks ! I was totally on the bad track (devpad...)
[19:16] <wolter> is there documentation on the bzrlib.option module? I cound't find any yesterday
[19:49] <vila> wolter: pydoc bzlib.option
[19:50] <vila> ... again.... why don't I just use completion as ping-check...
[19:51] <vila> and mgz did that just to point out the flow in my logic... I'm sure !
[19:53] <fullermd> At least he didn't point out the flaw in your logic   :p
[19:55] <vila> fullermd: that's the most devastating thing you could have said at this precise moment :-(
[19:58]  * vila kicks off Marvin: "Don't ever touch this keyboard again !"
[19:58] <vila> :D
[19:58] <vila> still 4444 imports to go at http://package-import.ubuntu.com/status/
[19:58] <vila> now that's a number
[19:58] <vila> composed with the most delicates power of 2 represent as often as itself
[19:58] <vila> ted, represented
[19:58] <fullermd> Not only that, but the sum of them is a power of 2 too.  And it's the power of 2 represented by the digits themselves.
[19:59]  * vila sudo importer kill -9
[20:00] <vila> an oasis of beauty in an ocean of bits
[20:00] <fullermd> Their product maxes out a byte, too.  Which would be the bits numbered by the sum of the number of digits and the digit itself.
[20:01] <fullermd> And if you round off its square root, you get a quad-repeat of digits too; 66.66.
[20:01] <vila> OMG, the hidden perfection ! Nobody knew it and it just appeared from the middle of nowhere 8-)
[20:02] <vila> and now it's gone... impermanence..
[20:03] <fullermd> Halfway between the two would obviously be 555.5.  If we take that as a product and a subtraction, we get 5*5*5-5 = 120.
[20:03] <vila> only to be replaced by 4411 hehe
[20:03] <fullermd> Dividing that by the 66.66, we get another nice repeating series: 1.800180018001800...
[20:03] <fullermd> Take that 1800 away from our original 4444, and we get 2644; back with the 4's, and this time they're the average of the preceeding digits.
[20:04] <vila> hey, you seem to ob your way for the infamous five 5 games: with the usual operators and using the five 5, find all the integers starting from 0 and going as far as you can :)
[20:04] <vila> s/ob/on/
[20:06] <vila> s/ob/be on/ tyops while re-reading, the next level
[20:37] <vila> something weird is going on... with the net
[20:37] <fullermd> Probably needs to be rebooted.
[20:37] <vila> or shutdown to stay on the safe side
[20:38] <vila> I still suspect Morris to plan a come-back one of these days...
[21:09] <lamalex> Hi, I got a merge conflict and was wondering if there was anyway way to tell bzr to just throw out the incoming changes and use the in tree version whole hog
[21:10] <james_w`> lamalex, "bzr revert file"
[21:10] <lifeless> 'bzr revert .'
[21:10] <james_w`> lamalex, "bzr revert ." for all files
[21:10]  * lifeless hi fives james_w`
[21:10] <danielsh> maxb: morning. it would have worked, but I wanted to rewrite the 5 revisions' worth of history, too.
[21:10] <lamalex> thanks james_w`
[21:10] <lifeless> james_w`: also, your ` is showing.
[21:11] <james_w`> ooo-err missus
[22:07] <caravel> hi everybody
[22:08] <caravel> PREAMBLE I'm not trying to troll, okay ? I need to underand a few things :)
[22:09] <spiv> Hi caravel
[22:09] <fullermd> Well, that takes all the fun out of it...
[22:10] <caravel> it's about a web site for a self-employed food company. It was mounted by a friend who has very good marketing and web-art skills, but not that techy
[22:11] <caravel> (food retail) so he chose Magento then Joomla, tried to glue it all together as he could
[22:11] <caravel> today we end up with a MASSIVE amount of files, and to be honest, some kind of a mess
[22:11] <caravel> we're getting close to th0s channel topic, please be patient :)
[22:13] <caravel> So... 29,000 files on the hosting, including lots of stuff that should be removed. I'm family related to the retail shop, and try to enforce a few things, such as ... a VCS of course. So far, he's been hacking the hosted prod server directly ! Just learned this, he had "let us understand" that he was using sme dev copy on his laptop. Well, this was not the case
[22:14] <caravel> Anyway. More than 1 year ago, I had suggedted he'd look at bzr
[22:14] <caravel> he just did and said he had some head aches during HOURS, that bzr doesn't take so many files (apparently, he tried to feed the entire site in bzr !?!)
[22:15] <caravel> And in the same email, announced that he had setup hg. Well, I was a Ubuntu user for long, now I'm on Fedora KDE by choice, but I'm still scared of hg
[22:16] <caravel> https://developer.mozilla.org/en/Mercurial_basics
[22:17] <caravel> So I tried to explain that. He agrees to let me try, my turn. I'm a rather very strange programmer (niche market for 15 years, xml stuff), don't have web-dev experience
[22:18] <caravel> So I have a few questions. Thanks for having read so far, I'll start now :) </PREAMBLE>
[22:18] <lifeless> bzr should hangle 29K files
[22:18] <lifeless> we've testing up to 100K if I remember correctly
[22:18] <caravel> lifeless: I suppose so, and even many more
[22:18] <caravel> right
[22:18] <caravel> he didn't even tried the command line !!! he wrote something like "it just closed with no message", so he was using the GUI
[22:19] <caravel> but I'm glad to get some confrmation already, found it so strange
[22:19] <caravel> next... anyone here is using bzr for such a webapps repo ?
[22:20] <lifeless> We do the development for the launchpad.net website using bzr
[22:20] <lifeless> 8K files
[22:20] <caravel> does it make ANY sense at all, to store 29,000 files from Mage, Joomla, whatever plugins such as JFusion, FlexiContents, PhocaGallery and so on, in a VCS ?
[22:21]  * caravel assumes it does NOT
[22:22] <caravel> I've worked a lot as a tech lead with CVS and SVN, and I sometimes HAD to include a few libs "external to the project" in my own tree, but that was exceptional and due to specific integration processes
[22:23] <lifeless> so, you can do it
[22:23] <lifeless> but a little more structure would probably be better
[22:23] <lifeless> one project per thing - mage, joomla, etc
[22:24] <caravel> lifeless: yes, sure -- there are "source ours" in each app, so of course we need that
[22:25] <caravel> I just can't pronounce myself globally since I never used a VCS in such context
[22:28] <caravel> can you tell me how you do this briefly ? is there any useful tip that will permit to "bzr update" and push only specific files, even being able to push directly the changes eg. to the prod server... but avoiding "manual installation steps" hence working with bzr of our real, respective (local) LAMP stacks on a day to day basis ?
[22:30] <caravel> I can only assume that's why he tried it this way (and I know already I'm the one who will have to identify each default/custom resource, since it's obvious he doesn't know precisely. That explains it all, and oh well, that's okay. ^^ )
[22:36] <spiv> bzr is fine with that many files, but it can consume a lot of memory if you have individual large files.
[22:36] <caravel> spiv: yes, I'm guessing it had issues on the image tree -- by luck, vids are externalized ;-)
[22:37] <spiv> If you want to push only specific files, I'd try what lifeless says: break it down into multiple branches, one per project or whatever the natural boundary is for you.
[22:38] <caravel> my question is : is this practicle to set the repo at the LAMP root, add use it to manage only "our" custom files across the tree ? (never done this in my VCS projects, always "whole" tree, never had to ask me that question)
[22:38] <caravel> *add -> and
[22:40] <caravel> so we could gently tag, update/branch and push our files only, just like a "mask" on the whole thing ?
[22:40] <lifeless> caravel: certainly. you can use 'bzr ignore' to ignore files you got from elsewhere.
[22:40] <lifeless> or 'bzr ignore \*' to ignore everything, and then 'bzr add' specific things.
[22:41] <caravel> lifeless: thanks. so we can even recursively add stuff while ignoring other. Sounds as simple as expected. I'll take it from there. Thanks a LOT for your time, people.
[22:44]  * caravel 's thankful to spiv and lifeless (everyone deserves having his/her life back). Did fullermd have some fun anyway ? ;-)
[22:48] <BlazingSun> hi, anyone there familiar with bzr+ssh and working with multiple users?
[22:48] <BlazingSun> on the same branch
[22:49] <caravel> BlazingSun: tested this last year, seemed to work great, but I had to simulate all users so my tests were rather rudimentary and not so simultaneous
[22:49] <BlazingSun> i am trying for a few hours now, but setting the sticky-bit doesnt seem to affect newly created branches
[22:50] <BlazingSun> so only the "branch-owner" has write acess, all others only get read-access
[22:50]  * caravel should better leave before harming anyone with wrong answers
[22:50] <BlazingSun> ah i am using debian6 btw
[22:50] <caravel> BlazingSun: oh
[22:51] <caravel> BlazingSun: that should NOT be related to bzr, right ?
[22:51] <caravel> BlazingSun: but to ssh users and permissions
[22:52] <BlazingSun> caravel: i am not sure, could be
[22:52]  * caravel uses Debian also, but Lenny only (=stable, 5)
[22:53] <caravel> BlazingSun:  you are using distinct logins for each user, right ?
[22:53] <BlazingSun> sure
[22:53] <BlazingSun> but they share the same group, called bazaar
[22:53] <BlazingSun> permissions are drwxrws---
[22:54] <caravel> rwx--- at the end, you mean ? ^^
[22:54] <BlazingSun> nha rws, so newly created branches still have the same group
[22:55] <BlazingSun> when i set permissions manually everything works right
[22:55] <BlazingSun> but i need the possibilty that everyone can create new branches and everyone can access them
[22:58] <BlazingSun> without me setting the permissions everytime
[23:01] <BlazingSun> hmm i think its the global umask, so nothing bzr related
[23:02] <BlazingSun> debian has 0022 as the default but most distros use 0002, so i found my error :)
[23:03] <caravel> BlazingSun: just read again man:chmod, thanks :)
[23:04] <caravel> BlazingSun: if you use +s, you give the the id of your "bazaar" group, right ?
[23:06] <BlazingSun> caravel: sure, thats what i was using, but debians umask is 022 not 002 as i ecpected
[23:07] <caravel> ok, I got it
[23:07] <BlazingSun> thx anyway for the help
[23:07] <caravel> BlazingSun: I don't quite get the point of using s over x (and making the tree belong to the bazaar group) ? More than interested in this anwer, our bzr will be shared over SSH/SFTP (on Lenny)
[23:08] <BlazingSun> caravel:  if someone creates a new branch on the server he will be the owner of the branch, but i need the group to have still permission
[23:09] <BlazingSun> with the stickybit the group will stay the same
[23:26] <caravel> BlazingSun: all clear, thanks for your answer ;-)
[23:27]  * caravel better go and stop take the space for so little
[23:27] <caravel> night all
[23:29] <BlazingSun> caravel: cant fight where i can set the global umask thou ^^^n8 then
[23:50] <caravel> BlazingSun: sorry, was on something else
[23:51] <caravel> BlazingSun: in your sshd_config ?
[23:51] <caravel> BlazingSun: man sshd_config doesn't help much, right
[23:52] <caravel> BlazingSun: Subsystem sftp /bin/sh -c 'umask 0002; /usr/lib/openssh/sftp-server' ?
[23:52] <BlazingSun> caravel: im using ssh not sftp
[23:57] <caravel> BlazingSun: isn't sftp implicitely used ?
[23:58] <caravel> this could help you I guess http://serverfault.com/questions/231717/how-to-get-full-control-of-umask-pam-permissions


[11:06] <memphisto> nothing to ask, just to say Hi
[11:08] <Maik> hi
[11:10] <memphisto> hi : )
[11:14] <Maik> for casual talk we can use #kubuntu-offtopic :)
[11:14] <memphisto> ok, thank you Maik
[11:14] <Maik> np, yw
[12:53] <BluesKaj> Hi folks
[13:39] <elena_> How are you all?
[13:40] <diogenes_> good thanks, how are you?
[13:40] <diogenes_> also
[13:40] <diogenes_> !ask
[13:42] <elena_> Im Good
[13:42] <elena_> Thank You diogenes!
[13:42] <elena_> What are you doing
[13:42] <elena_> ?
[13:43] <diogenes_> !chat | elena_
[17:33] <masamiko> hi
[18:26] <quartz12> I'm running Kubuntu 20.10 and sometimes when I boot into my linux drive, I have no wireless connection. I don't know why this is. Sometimes it work, other times it does not. The network icon in the taskbar says "No available connections". I'm not sure what to do.
[19:13] <Lilly> Hey
[19:13] <Lilly> How are you all?