[00:00] cjwatson: I even followed the instructions in the wiki for using chroot and there are some things left out that I had to figure out on my own [00:00] and I am using schroot instead of dchroot [00:01] so this learning process will be slow [00:01] YokoZar, which player? [00:02] directhex: default totem (installing -restricted-extras didn't change anything) [00:02] the most important thing to realise is which things are important ... chroots are a nicety that you can look into once you have the basics working. The purpose of using a chroot is either to make sure that your package builds in a clean environment, or to build it for some different environment than your usual one. It is not the first thing that you should be reaching for when trying to debug why something is not working [00:02] start small and build up [00:03] I wanted to build on a machine running Intrepid, but the package is for another running Hardy [00:03] hence the chroot [00:04] and I wanted to make a custom deb package because one does not exist [00:04] I have used checkinstall for this for years but I wanted to do it the right way [00:04] well, if you're using a chroot for that purpose then you probably need it, but you should start by constructing an environment within the chroot that you can debug in just as you would outside the chroot [00:05] the goal being that you shouldn't need to remember that you're in a chroot most of the time [00:05] the fewer bits of state you have to keep in your head at once, the better [00:05] the fact that you mention that a chroot is slowing your learning process indicates to me that you haven't quite got there yet :) [00:05] i find a stateless brain helps [00:06] no chroot is not slowing the process [00:06] the process is just a slow one [00:06] since some things are not documented [00:07] what you need to do is teach yourself the basic tools first [00:07] trying to figure out what DEB_CONFIGURE_EXTRA_ARGS does is starting from the wrong end [00:07] and when I came to Ubuntu from Debian, I found some things are not the same [00:07] start by learning the basics of GNU make and shell scripting if you don't already know them [00:08] though they are similar [00:08] k [00:08] good advice [00:08] then read through the policy manual and familiarise yourself with the packaging format [00:08] then pick a sample package, read its debian/rules, and look up manual pages for anything you don't recognise that looks interesting [00:08] repeat [00:09] is the Ubuntu Policy Manual different from the Debian one? [00:09] in small ways, none of which are relevant to you [00:09] at least not the problem you have described [00:09] I wanted to do that with kmail but I think I should pick a smaller app [00:10] cjwatson: I read this same advice about learning a package, but perhaps kmail is too complex for a first package [00:10] Pollywog: cdbs is the least well-documented of all the popular helper packages [00:11] not only is kdepim large in and of itself, but it's using a packaging helper which is designed to allow the maintainer to express very powerful things while typing very little [00:11] while furthermore largely not explaining what it does [00:11] this is certainly not going to be conducive to learning; but the majority of Ubuntu (and Debian) packages are much simpler [00:11] Yeah, that's definitely true. The people I learned packaging from use cdbs exclusively, but you can't really use it without understanding at least the concepts behind debhelper packaging [00:11] I guess I could use some smaller package like equivs [00:12] ebroder: right, hence my comments about building up [00:12] the reason I picked kmail is that it has an annoying bug of long standing [00:12] debhelper is a straightforward set of helper tools that operate by abstracting out things you might otherwise type into debian/rules, but in a fairly simple subroutine-call kind of way [00:12] debhelper is also generally very well-documented [00:13] since cdbs builds on top of debhelper, you must understand debhelper first [00:13] in order to understand debhelper, you must understand the things it's abstracting, i.e. the basic packaging format [00:13] if you work in the right order, it is all much easier and less overwhelming [00:13] I will read the debhelper stuff again and again, it was hard to digest [00:14] did you read it before understanding the basic packaging format, though? [00:14] it's written for people who already know that [00:14] no [00:14] k [00:14] we've seen some frankly bizarre ones here before from people seeking to avoid learning the "right way" - one guy was editing control.tar.gz in a .deb by hand [00:15] oh, well, I've done that for very specific reasons, but I already knew what I was doing ;-) [00:15] ..eww [00:15] (it's a straightforward way to work around broken preinsts if you're in a rush) [00:15] cjwatson, i think you've probably earnt the right to do sordid things to packages by now [00:16] I had to fix a script in a Debian package once and then put the package together again [00:16] so I could remove it and then install it again [00:16] it worked :) [00:16] the preinst (well, and nowadays the config as well) is the only case where you actually need to reassemble the package like that [00:16] everything else you can just fiddle about in /var/lib/dpkg/info/ or elsewhere on the filesystem [00:17] yes a preinst or postinst was broken [00:17] editing a postinst does not require disassembling and reassembling the .deb [00:18] for the simple reason that the postinst is run in a distinct step (with its own dpkg option, even) after the package is unpacked [00:18] another trick I have used is to make a fake package with equivs [00:18] then remove the fake [00:19] none of this is required to deal with problems removing packages [00:20] if a prerm fails (which is one case where dpkg doesn't provide you a clean get-out), then it's much simpler and more reliable to edit the script in /var/lib/dpkg/info/ [00:20] well I did not know that at the time [00:20] yes I have done the editing too [00:20] I think someone told me to do that instead of making fake packages [00:21] the point I'm trying to make is not "woo I'm so tough I can edit files in /var/lib/dpkg/info/" :-) but that, rather than having to remember all the tricks, it all becomes obvious once you know how the mechanisms work [00:22] it's like your car mechanic mostly doesn't have to learn every single possible part number and what might fail with each - they learn how cars work instead [00:24] * NCommander kicks debmirror [00:29] * cjwatson stops preaching and goes to bed. :) [00:32] have a good night cjwatson [00:40] Is script/runner "Repository.fetch_changesets" what causes tickets to get updated based on commit messages? [00:40] Err..sorry - wrong window [00:54] Nafallo: and that's exceptional based on the previous pattern? === Ampelbein is now known as ampelbein === ampelbein is now known as Ampelbein [02:42] anyone know enough about python/launchpadlib to know why this code is wrong: if task.bug_watch != "None": [02:43] Remove the quotes around None. [02:43] are you sure it's "None" and not None ? [02:43] I'd guess it's a NoneType and not the string None [02:43] "task.bug_watch is not None" would be the more typical way of doing that [02:45] ah maybe so [02:45] thanks guys that worked [02:52] * calc thinks launchpadlib is really slow [02:53] something like 2 seconds per bug that it is checking [02:59] calc: It can't be any faster than Launchpad. [02:59] ScottK: true, maybe there isn't a quick way to get at this data, similar data comes up nearly instantly in the web interface [03:00] i ended up with this, i think it works but its still running [03:00] for pkgbug in package.searchTasks(status=['Triaged']): [03:00] for task in pkgbug.bug.bug_tasks: [03:00] if task.target.resource_type_link.split('#')[1] is 'project' and task.status is 'Invalid' and task.bug_watch is None: [03:00] print task.bug.id, "-", task.bug_target_name [03:01] those are the type of bugs that end up vanishing at least afaict when searching in the web interface [03:01] eg if you use hide_upstream they are hidden and if you use resolved_upstream it only shows invalid if it has a bug_watch [03:13] slangasek: new -base language-packs for Jaunty have been uploaded. [03:19] ah is and == aren't quite the same thing [03:21] Right - "is" is pointer equality, and "==" are value equality, roughly speaking [03:27] ebroder: ok [03:34] ArneGoetje: thanks; accepting === Ampelbein is now known as ampelbein [04:10] jcastro: what format was she trying to save in? [04:11] jcastro: i'm guessing at word 2003 xml [04:19] calc: I think so, I will investigate tomorrow [04:19] I've been trying to deal with this crap all night. :-/ [04:20] jcastro: fun :\ [04:20] jcastro: too bad we can't just cram java onto the cd, it breaks lots of bits of OOo [04:21] ok so it's not really a bug, it's just a tradeoff for that certain format? [04:22] the filters are written in xsl which OOo uses java for the xslt libraries, etc [04:22] ScottK: launchpadlib can be faster in theory, as portlets are not rendered etc [04:25] calc: it would be nice if it installed that kind of stuff on-demand like with mp3's, etc. [04:25] can it be taught that? [04:26] we do it with rhythmbox and totem, how hard could it be? *grin* [04:28] lmao [04:28] for one OOo is its own platform [04:28] not easy at all, i am accepting patches of course :) [04:28] pretty much if you use OOo you need Java [04:29] you can't even search help without Java [04:29] really? eek [04:29] i suppose i could add a check to the OOo startup script to automatically ask the user to install java if it isn't already [04:30] you know, I think I'd prefer if it did just that, be honest to me upfront, etc .. [04:30] i added to the javaldx error message a few weeks ago to tell the user to install the openoffice.org-java-common package which installs java along with it [04:30] a "No seriously you need this" thing on startup or something [04:31] jcastro: problem is that would happen for all instances running OOo pretty much [04:31] jcastro: which would cause people to complain that it annoys them, heh [04:31] yeah but on the other hand she had no idea what to do when she got the error [04:32] we just need to bite the bullet and either 1. force Java onto the CD somehow, 2. ask the user to install Java when they get a net connection, or 3. get rid of OOo from default install so it can have proper depends [04:33] the more OOo is developed the more things in it depend on Java [04:33] thats... um.... icky. [04:33] IMO [04:33] in 10 years it probably will be completely written in Java ;-) [04:33] calc: going to bed now, I'll add it to my "things I should bring up at UDS" [04:33] thanks for the tip! [04:34] jcastro: rick mentioned getting Java onto the cd for karmic, but i'm not sure how that will happen it pulls in a lot of packages to make OOo work [04:34] isn't the cd image size currently pushing 700 already? [04:34] Yes [04:35] calc: what if in ~/.openoffice it touched a file after they'd been prompted once? [04:35] calc: check for that file's existence and don't prompt again [04:36] maco: maybe, i don't know how to hook that into OOo itself though, its pretty ugly as it has its own toolkit, etc [04:36] if that was checked on the first startup of OOo, then you wouldn't really have utility of using it on a live disk anymore, as you'd use use up the the tmpfs with those installed packages if you installed on the live session [04:37] * calc wishes people would stop writing their own toolkit for their apps and just use something standard [04:37] superm1: its not needed to run, just to use some of the more advanced features and help [04:37] so maybe....is there a way to see if its the live cd and not prompt? [04:37] oy, getting complicated [04:37] maco, but wasn't calc proposing possibly adding it to the startup script? [04:37] maco: or saving to file formats [04:37] yes [04:38] maco: its used in many features, i don't even know what all myself [04:38] oh right what jorge was just saying [04:40] superm1: yes. i was suggesting that the script do if ((java not installed) && (not live cd) && (havent prompted before)): ask [05:24] Where can I find documentation on how the netboot images are built? [05:25] (Is there documentation?) [05:28] for booting workstation terminals or remote installation? [05:29] Err, sorry - not actually netboot. The mini.iso images that are buried in the netboot directory [05:31] iirc, mini.iso is if you want to boot from a small cd image and install the rest of the system over the network [05:31] Right. I'm looking to customize it, and I was wondering how they're generated for the archives [05:31] ah, ok [05:32] It's, uh, relatively hard to try and search for [05:33] ebroder: you want the dbian-installer source package. [05:33] debian-installer even [05:35] * ebroder stares at the build-depends [05:37] I'm mildly disturbed by this package [05:37] Thanks, TheMuso [05:37] ebroder: np [05:40] ebroder: I think everyone is, really [05:40] Here there be dragons === foxbuntu` is now known as foxbuntu [06:30] Good morning [06:34] slangasek: 345531> I agree that forward is better than backwards; I saw the branch, I'll review/pull/upload [06:34] calc: 325973> no, it's not supposed to happen by default; as I read it, you need to disable a gconf key (manage desktop with nautilus) to get it [06:35] calc: there might be some timing issues which trigger the same behaviour on the live system, though [06:35] good morning [06:35] calc: do you get that every time you boot a live system, or just seldomly? [06:36] * pitti hugs dholbach [06:36] * dholbach hugs pitti back :) [06:38] there's lots of good stuff still in the sponsoring queue [06:42] pitti: spiff; let me know if there's anything you think should be changed about it, I don't really understand how things are meant to split between hal vs. hal-info and policy vs. information vs. preprobe [06:46] slangasek: what sets the sony-nvidia method? [06:47] pitti: it's set in the added fdi file; that got committed, right? [06:47] slangasek: ah, I see it now; odd, that got dropped from the patch attachment in the merge request email [06:48] ah, no [06:48] the merge request mail went out before I committed that part [06:48] (at that point, I was thinking perhaps it belonged in hal-info instead of hal) [06:48] slangasek: ideally the fdi file should be in smartdimmer [06:48] but hal-info is also okay [06:48] but not hal? [06:49] most 'policy' stuff of this sort seems to be in hal [06:49] as I said, I don't understand how things are actually divided [06:49] hal-info has the hardware specific lists [06:49] slangasek: but either way, if that's for beta, let's leave it like it is [06:49] then why is 10-dell-laptop-brightness.fdi in hal? :) [06:50] slangasek: but that needs to be discussed upstream first, I don't want to just commit those patches upstream [06:50] sure [06:50] I don't mind moving it to hal-info; not knowing which package it belongs in was part of why I sent the merge request [06:50] (or to smartdimmer, either) [06:51] slangasek: indeed 10-dell-laptop-brightness.fdi is weird; it's not a vendor/product list, but rather a kludge (it will disappear with kernel 2.6.29) [06:51] ah [06:51] slangasek: don't waste too much work on it; we can clean it up after beta, when it got discussed upstream [06:51] slangasek: I'm happy to upload this now [06:51] also, are the fdi files parsed in alphabetical order? If so we may need to rename this file, so that it sorts before 10-laptop-panel-mgmt-policy.fdi [06:52] slangasek: they are [06:52] ok, then we need a different name for this file [06:52] hmm, I think [06:52] slangasek: shouldn't make a difference, though? since you use , i. e. the device will get all access methods anyway? [06:52] oh, right [06:52] yeah, doesn't matter after all [06:53] slangasek: if you change keys, the last change wins, not the first change [06:53] sure [06:53] so sorting after sounds right [06:53] I was concerned that laptop-panel-mgmt-policy was doing things that were conditional on the keys we set in this new fdi [06:53] but it doesn't, it just cares that access_method != "custom" [06:54] feel free to upload, then - I actually wasn't expecting all the pieces to come together until after beta, since there's an MIR involved also [06:54] slangasek: how urgent is the upload? do you need it right now, or can I have another hour or so for bug 322798? [06:54] Launchpad bug 322798 in hal "Segfault in hald startup (hald/linux/devices.c)" [High,In progress] https://launchpad.net/bugs/322798 [06:55] slangasek: it has a patch, but I'd like to go through it with a fine comb first [06:55] speaking of which, could you review bug #95444 for me? (FFe request for nvclock, which motu-release punted back to ubuntu-release due to the MIR) [06:55] Launchpad bug 95444 in nvclock "No Screen Backlight Control; Notebooks (Vaio, Macbook, HP/Compaq, Samsung, Zepto et al.) with Nvidia Geforce8/Geforce9/Quadro series graphics" [Undecided,Confirmed] https://launchpad.net/bugs/95444 [06:55] pitti: not urgent at all [06:55] okay, great [06:56] slangasek: so the acpi-support task should be wontfix then? [06:57] if there's agreement to move forward, yes [07:00] siretart: you could've reuploaded ffmpeg-debian with the same version number and asked for the first to be killed from the unapproved queue ;) [07:01] slangasek: I'm a bit confused; your hal patch adds a dependency to smartdimmer, and there you need a newer nvclock which talks about obsoleting the smartdimmer package and include its own smartdimmer program? [07:02] pitti: plan goes like this: 1) newer nvclock, 2) MIR, 3) make nvclock start building the smartdimmer binary package from the new source, 4) profit [07:03] pitti: I may have said something different in a bug log at an earlier point, but that's the current plan [07:06] slangasek: ah, I see [07:09] slangasek: reviewed and comment added; looks fine to me, modulo the Encoding= line from the .desktop file [07:11] oh, buildds are langpack'ed [07:11] slangasek: on a tangent, new langpacks won't help CD downsizing; the update packs replace -base, thus there should never be duplicate files on the live system [07:11] yeah; I accepted those ASAP to try to get them through for beta [07:11] hmm [07:12] well, maybe that's why only alternates are currently oversized :) [07:12] er, except i386 desktop is also oversized, darn [07:13] still, that's only 1 ISO to worry about shrinking, instead of all 4 [07:14] pitti: the .desktop file isn't shipped in the package; ok to punt on that change? [07:15] slangasek: fine [07:16] slangasek: except I had a gdm screen waiting this morning :-/ [07:17] Nafallo: aha; so doesn't appear to be toolchain-related after all [07:17] Nafallo: do you have a useful backtrace in your gdm.log? [07:17] er, s/\./ / [07:23] * Nafallo installs pastebinit [07:25] slangasek: http://paste.ubuntu.com/135876/ [07:31] slangasek: oh, seems we need to keep the hal patch as Ubuntu specific for now, see mjg59's response to http://lists.freedesktop.org/pipermail/hal/2009-January/012858.html [07:33] pitti: yes, not surprising, this ultimately should be a sensible sysfs interface [07:33] slangasek: oh, and the patch doesn't cause the fdi to actually be installed; I'll fix that [07:33] oh [07:33] ok [07:33] didn't realize there was an explicit list, sorry :) [07:34] the comment about sony-laptop providing a backlight interface worries me slightly; I hope this change isn't a regression for users of any of these models who don't have smartdimmer installed [07:34] slangasek: explicit list> welcome to automadness :/ [07:34] :) [07:40] * Nafallo heads in for breakfast and data centres [07:48] slangasek: hal uploaded; the other patch I was talking about was already in === thekorn_ is now known as thekorn [07:54] bryce: around? do you know the state of the x11proto-xext libxi-dev depends discussion? [07:54] seems that libvncserver (bug 346836) and libxtst (bug 346841) FTBFS because of that [07:54] Launchpad bug 346836 in libvncserver "FTBFS in jaunty" [Undecided,New] https://launchpad.net/bugs/346836 [07:54] Launchpad bug 346841 in libxtst "FTBFS in jaunty" [Undecided,New] https://launchpad.net/bugs/346841 [07:55] bryce: debian bug 499858 is still open [07:55] Debian bug 499858 in x11proto-xext-dev "x11proto-xext-dev: Missing libxi-dev dependency" [Important,Open] http://bugs.debian.org/499858 [07:55] (and the patch in there says "libx1-dev" instead of "libxi-dev" :)) [08:01] Nafallo: aha, your backtrace matches mdz's latest - very promising progress [08:02] hmm, only the inner part matches [08:02] but this could mean it's a bug in the logging routines themselves... [08:02] bryce: nevermind, just read up on the situation [08:10] Nafallo: would appreciate it if you could post that backtrace to bug #328035 [08:10] Launchpad bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] https://launchpad.net/bugs/328035 === crdlb_ is now known as crdlb [08:29] * NCommander wonders if debian-cd comes with instructions ... [08:33] Nafallo: how do you feel about running your X under valgrind, btw? :) [08:34] your crash seems to happen at the exact point that mine did before; I can't see any bugs in the actual log handling code, so it looks like it's external heap corruption [08:35] Nafallo, slangasek: I just encountered an X.org crash after suspend yesterday, is that what you are talking about? (I only got some drm:i915 unknown parameter error in dmesg, no xf86Wakeup() call messages) [08:35] pitti: that matches the high-level description of the bug, yes. [08:36] pitti: check gdm log for the glibc backtrace [08:36] (it's SIGABORT on heap corruption, so no apport love) [08:36] er, SIGABRT rather [08:37] pitti: bug #328035, targeted for jaunty but we don't have any real traction on it yet [08:37] Launchpad bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] https://launchpad.net/bugs/328035 [08:37] [ 30.805891] (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70. [08:37] I have a ton of those [08:37] but none of xf86Wakeup [08:37] * pitti checks the bug [08:37] slangasek: thanks [08:38] which version of xserver-xorg-core do you have? [08:38] (the fix to have glibc stacktraces dumped to the log was only added in the latest upload) [08:40] hrm, I wonder why iwl3945 is being totally inconsistent today about seeing the APs in the neighborhood [08:41] slangasek: 2:1.6.0-0ubuntu4, the one with Kees' patch [08:41] it couldn't see our own AP earlier today when it was sitting right above my head; now it only sees our AP, when there are two others in range [08:41] pitti: ok [08:41] hm, but it was only installed yesterday around noon [08:41] ah :) [08:41] I'm pretty sure I rebooted after that, though [08:42] yep, I did, 5 hours later [08:42] alrighty [08:42] and I got the crash this morning [08:42] I'll keep this under observation [08:42] * slangasek nods [08:43] * slangasek is going to try to spend some more time today reproducing it again here [08:43] if I can get the backtrace, I can start fiddling with valgrind [08:44] slangasek: do you know enough about NIS to make a call on bug 345137? I'm afraid it's a little outside of my realm [08:44] Launchpad bug 345137 in nis "nis should recommend nscd" [Undecided,New] https://launchpad.net/bugs/345137 [08:45] I know enough about nscd to say that nothing should recommend it ;) [08:45] +1 slangasek [08:45] (to be fair, that's based on earlier versions of nscd... maybe it's saner now) [08:46] pitti: libnss-ldap only Suggests: it; the same is probably appropriate for nis [08:47] how about gnscd? [08:47] we use it in production, it seems to suffer far less from terminal suck [08:48] slangasek: okay, I leave the reply to that to you then :) [08:51] pitti: oh, recommending nscd would also mean a universe -> main promotion [08:51] right [08:51] it doesn't seem very appropriate to me at this late time, but I know next to nothing about nscd [08:52] slangasek: sure. can do. [08:53] slangasek: (posting the output. the valgrind thing I would need hand holding on I reckon ;-)) [08:55] Nafallo: it involves dpkg-divert /usr/bin/X and replacing it with a shell script that exec's valgrind. :) [08:55] (may require setting valgrind suid since X is suid, sigh) [08:55] also: yuck, why is gdm still referencing /usr/X11R6/bin as the path to X [08:56] in case you decide to run it on RH7.2? [09:13] Nafallo: valgrind recipe posted, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/328035/comments/34 [09:13] Ubuntu bug 328035 in xserver-xorg-video-intel "*** glibc detected *** free(): invalid next size (fast) for xf86Wakeup() call" [High,Triaged] [09:13] (untested, so keep hold of the unwind directions in case the valgrind script breaks your X ;) [09:15] slangasek: anything else then valgrind needs installing? [09:15] nope [09:15] Suggested packages: [09:15] libc6-dbg kcachegrind alleyoop [09:15] oki :-) [09:16] and since valgrind traps & handles most heap corruption on its own, you probably have to peek in the log after each resume to check if there's anything interesting there [09:16] since chances are X won't crash [09:17] btw, you've used valgrind before, right? You know this is probably going to make X an order of magnitude slower / more memory-intensive? [09:17] hehe. no. didn't know that :-) [09:17] ah, yeah [09:17] *cough* [09:17] Yeah, just slightly slower... [09:17] oh well. let's wait until X crashes so GDM launches the valgrind then :-) [09:17] it has to intercept all heap activity. That's expensive. :) [09:26] TheMuso: this dmraid debdiff is hard to read given that it clobbers previous ubuntu revisions; is this targeted for beta, or should I set it aside for the time being? [09:27] slangasek: feel free to set it asside, it clobbers Ubuntu revisions because they are in Debian, and due to differing MD5 sums for orig tarballs, its a fake sync. === yofel_ is now known as yofel === cjwatson_ is now known as cjwatson [09:30] slangasek: oh, indeed, well version numbers are cheap, aren't they? ;-) [09:35] Riddell: could you please apply http://people.ubuntu.com/~mvo/tmp/desktop-effects-kde_0.4.4.1.debdiff to the bzr tree or give me acccess to the bzr so that I can commit it myself? [09:37] damn, if it had occurred to me that language packs wouldn't affect desktop CD size, I'd have done something about the latter yesterday [09:43] well, the langpacks took care of alternate CD size nicely in any case [09:43] asac: ping [09:43] agateau_: hello [09:44] asac: I was sent to you because I have troubles connecting to my wifi AP with NM === agateau_ is now known as agateau [09:45] I am running Jaunty and can connect to my wifi AP manually or with wicd, but not with NM (tried KDE plasmoid and nm-applet) [09:46] asac: what's the best way to give you useful info about this? [09:48] agateau: a good start is starting your system, trying to connect once and then give me your syslog [09:49] asac: ok, going for this [09:58] asac: just tried it and realized i did not use the appropriate entry in "Security" combo box. It works now, problem was between keyboard and chair... sorry for the noise :) [10:03] agateau: is that WEP? [10:18] doko: I uploaded a new command-not-found that should suggest "pythonX.Y" now instead of "pythonX.Y-minimal" when "pythonX.Y" is not found [10:19] nice === azeem_ is now known as azeem [10:38] pitti: btw, over the weekend we converted the hal bzr branch to 1.6.1-rich-root instead of the dead-end dirstate-with-subtree; so you may want to redo any local checkouts you have, for a noticeable speed boost. :) [10:38] slangasek: I can't, since mine is a branch from an svn checkout [10:39] slangasek: well, bzr-svn might have caught up in the most recent version, trying [10:39] 1.6.1-rich-root is specifically one of the formats that can handle bzr-svn [10:39] (getting it there is a PITA though, you can't bzr upgrade you have to bzr init + bzr pull) [10:39] It is the second-latest recommended format for bzr-svn. [10:39] bzr: ERROR: Cannot convert to format . Does not support rich root data. [10:40] nope, seems not [10:40] er, see above [10:40] That's not the same error, is it? [10:40] pitti: What command was that? [10:40] bzr upgrade --1.6.1-rich-root [10:40] I tried that, but doesn't work either [10:40] bzr: ERROR: No repository present: "file:///home/martin/ubuntu/hal/ubuntu/" [10:40] 10:39 (getting it there is a PITA though, you can't bzr upgrade you have to bzr init + bzr pull) [10:40] so bzr init --1.6.1-rich-root and then bzr pull into that [10:41] oops, the previous attempt moved .bzr away, sorry [10:41] yeah, it has a habit of doing that :-P [10:41] ok, sorry [10:41] * pitti engages full brain here [10:42] oh, the :-P wasn't for you, it was at the memory of how many times I had to restore .bzr on the LP branch using lftp the other night :) [10:42] would be nice if bzr were more clever about that [10:42] * wgrant forgot it did the rich root error, *then* the subtrees error. [10:43] hm, so what's the magic incantation to pull into a freshly init'ed branch? [10:43] bzr pull, oddly enough. [10:44] cd into the new branch, bzr pull from the old one. [10:44] oh, interesting; magic.. [10:46] pitti: if you know of any other bzr branches of interest on LP that were made using old bzr-svn (and are therefore using dirstate-with-subtree), feel free to let me know; I seem to be becoming quite practiced at such conversions, perhaps eventually they'll stop being painful :) [10:47] slangasek: the only other one I'm aware of is cdbs; but I think that's even older (pack-0.92) [10:48] it's again a case where I have debian (bzr-svn) and ubuntu branches, and merge from the former [10:48] ah - pack-0.92 might actually upgrade cleanly [10:48] trying [10:48] [10:48] heh, try it locally first to spare yourself the lftp pain ;) [10:49] pack-0.92 will upgrade to 1.6 fine. [10:49] yes, works fine [10:49] pack-0.92 is positively modern compared to dirstate-with-subtree, AFAICT. [10:51] unfortunately the upgrade broke merging again [10:51] .. but I think that was rather due to the bzr pull in the debian branch [10:51] *sigh* [10:56] slangasek: I know what you mean; for cdbs I got a "file exists: backup.bzr" [10:56] slangasek: (on the remote lp branch) [10:57] * pitti lftps it away [11:01] * slangasek opens evolution for the first time since the font size change and snorts at the ridiculousness [11:05] asac: this default font size change makes evolution look absurd; is that a known issue on its way to being fixed, or should I be sending screenshots? [11:05] (and does it actually look !absurd in some configuration?) [11:06] slangasek: it does look alright there [11:06] it looks fine here, but then again I might have a manual configuration of my font setting [11:06] seb128, asac: is there some magic gconftool -R /some/path for resetting font configuration to the factory defaults? [11:06] slangasek, can i see a screen? [11:07] seb128, pitti: System -> Preferences -> Appearance -> Fonts -> Application font: 13.333? [11:07] hm, that says "10" here [11:08] I thought it'd be 10 pt == 13.333 px on my 96 dpi? [11:08] erm, I mean s/-R/--recursive-unset/ [11:09] slangasek: http://people.ubuntu.com/~seb128/evo.png [11:09] slangasek: what is stupid looking there? [11:09] seb128: ah; I meant the calendar panel [11:09] (I don't use it for mail) [11:10] me too, and it looks fine to me [11:10] the 2 labels in the sidepane could be a tide smaller [11:10] seb128: that's the part that was looking absurd :) [11:10] slangasek: http://people.ubuntu.com/~seb128/evocal.png [11:10] ah, is it /desktop/gnome/font_rendering ? [11:10]