[00:36] TheMuso: i'm thinking more along the lines of providing it as a non-default but available stanza so that users can choose it [00:36] crimsun: Right, I have thought that since you proposed it. [00:37] crimsun: Were you thinking of tweaking the original snippet in any way? [00:37] If not, I can drop it in, and we may even be able to SRU it for intrepid. [00:38] TheMuso: yeah, need to investigate what max db should be set to (some "sane value", which means lots of feedback required) [00:39] crimsun: Right. [00:56] Is there any standard python parser for debian control files that's faster that debian_bundle.deb822 ? [00:56] elmo: I updated my branch of merge-o-matic (and asked Scott to review). it would be cool if you could, with your canonical sysadmin hat on, take a look at it, as I've made changes to address the potential security issues. see #192972 and my latest comment there. thanks [01:25] asac: no ubufox upload yet for bug #308397? [01:25] Launchpad bug 308397 in ubufox "localizable general.useragent.locale pref shipped by ubufox breaks mozilla OS usage stats (ubuntu not counted)" [Critical,Fix committed] https://launchpad.net/bugs/308397 [01:33] calc: there are a number of OOo bugs targeted for 8.04.2, but there haven't been any uploads, or indications in the bug logs that most of these are even in progress - should I simply untarget these? it's certainly too late for a general-purpose OOo SRU to land in time for 8.04.2 === hyperair1 is now known as hyperair [02:13] Riddell: hi there, i pushed another revision of screen-profiles, this one with a COPYING file in the tarball [02:34] slangasek: yea just untarget them is fine === racarr_ is now known as racarr === jono_ is now known as jono [03:33] calc: ok. are you planning to make time for an OOo SRU at some later time? [03:38] slangasek: perhaps, but i will be very busy at least for the next 1.5 months [03:38] * slangasek nods [03:39] got a 3.0.1 release coming up to get into jaunty this month then sprint and a week in hamburg at sun === hyperair1 is now known as hyperair === emgent_ is now known as emgent === emgent_ is now known as emgent [06:46] good morning [07:07] james_w: where's your ppamadison living? I'm curious to see the lplib bits [07:19] Good morning [07:20] morning, dholbach. i've pencilled in meebey & myself for a session for developer week [07:21] directhex: rock and roll! [07:21] you guys are heroes! [07:21] well poopy. looks like another total aircon failure in my machine room [07:21] that's a couple of million quid of kit offline [07:26] Hi all === tkamppeter_ is now known as tkamppeter === hyperair1 is now known as hyperair [08:45] there was a request for having a session about merging at Ubuntu Developer Week - who would like to give it? we still have a few open slots at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep [08:45] also there was a request about python packaging and how to make your application translate-able [08:59] pfft, python. who wants that when there's mono? [08:59] also, aircon failures hurt [09:14] * pitti slaps directhex [09:14] python ♥! :-) [09:14] * directhex hands pitti ironpython [09:15] latest release needs mono 2.2 or some backports to 2.0.1 tho [09:23] and this new ikvm package would be the smallest openjdk at our disposal, at ~35 meg on disk :p [09:38] tjaalton, tseliot: do you know where the xrandr applet saves its settings? [09:39] pitti: in ~/.config [09:39] tjaalton, tseliot: a friend of mine reports X crashes after he tries to log in, and I want him to reset this [09:39] ah, monitors.xml? [09:39] pitti: yep [09:40] pitti: is it this bug? https://bugs.launchpad.net/ubuntu/+source/gnome-desktop/+bug/314406 [09:40] Launchpad bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Confirmed] [09:41] cjwatson: I find it odd that USUITE in tasksel/Makefile was still intrepid in bzr HEAD. === Skiessio is now known as Skiessi === asac_ is now known as asac [10:26] tseliot: I don't know, it just started to happen recently [10:26] tseliot: (intrepid) [10:26] tseliot: I asked him some further questions [10:27] pitti: ok [10:28] pitti: let me know if you manage to get the error output so that I can try to fix it [10:32] persia: where do fridge requests get mailed to now? [10:33] tjaalton: xf86-input-evtouch FTBFS, and is uninstallable. It looks like it needs source porting. === thekorn_ is now known as thekorn [10:39] StevenK: yes, and no news from upstream [10:41] which reminds me.. pitti: there are a couple of patches for hal in fedora, making devices that declare input.touch to use evdev (which supports touchscreens now), for instance [10:42] StevenK: hum, that should be easy to fix though [10:42] tjaalton: Fix it? :-) [10:42] tjaalton: which we want, I assume? [10:42] pitti: yep [10:42] pitti: including the patch by mjg59 which he posted on u-d@ in October [10:43] or was it u-d-d [10:43] ScottK: Do you think #312659 should be extended to kfreebsd-6 and -7, too? [10:43] StevenK: looking :) [10:43] tjaalton: http://cvs.fedoraproject.org/viewvc//devel/hal/hal-tablet-evdev.patch?view=markup and http://cvs.fedoraproject.org/viewvc//devel/hal/hal-tablet.patch?view=markup ? [10:44] pitti: yes, and http://cvs.fedoraproject.org/viewvc/devel/hal/hal-joystick.patch?revision=1.2&view=markup [10:44] pitti: Do you also think I should kill kfreebsd-6 and -7 and blacklist them at the same time I kill -5? [10:44] tjaalton: I think our joystick patch is better [10:44] pitti: we have one? [10:45] tjaalton: http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/annotate/head%3A/debian/patches/07_joystick_detection.patch [10:45] pitti: yeah, saw that now, nice :) [10:46] tjaalton: so, I'll just review all fedora ones and clean harvest then [10:47] * pitti hugs dholbach for harverst [10:47] * dholbach hugs pitti back [10:47] pitti: great, thanks [10:50] pitti: while you're in there, is there a patch for the udev rules location? [10:50] Keybuk: not that I can see [10:50] Keybuk: there is one for hal dbus permissions [10:50] but debian just fixed that, too, I'll merge from them ASAP [10:51] (but not today, I finally need to work on the apport retracers) [10:51] ?! [10:51] who shot Marco? [10:52] or do you mean Debian just fixed the dbus permissions? [10:52] Keybuk: so the idea is that udev itself and packages ship udev rules in /lib now, and /etc/udev/rules.d is solely for the admin's customizations? [10:53] pitti: yes [10:53] however my understanding was that this change was going into Debian "over Marco's dead body" [10:53] Keybuk: right, they fixed dbus permissions, not udev rules path [10:53] he's also refused to adopt standard upstream udev rules [10:53] Keybuk: I know a few packages installing udev rules (libsane, libgphoto, etc.); so I guess best is to convert them to use dh_installudev, so that the change can go to debian? [10:54] that's the easiest way [10:54] though from a brief glance, neither libsane or libgphoto actually install udev rules now? [10:54] I saw your change to that yesterday, so it seems it's supposed to DTRT [10:54] Keybuk: ah, right. auto-ACL magic, I remember [10:54] (our change is to *drop* udev rules installation) [10:54] seems part of my brain is still in holiday mode... [10:55] of course [10:55] ironically [10:55] the FDI becomes a udev rule later on anyway [10:56] which is a significant part of the reason most distros are going to share a single set of common rules [10:56] heh [10:56] Keybuk: I hope hal-info will get an fdi2udev script, so that it remains useful for both current and older releases [10:56] I'm honestly not sure how they intend to do that transition [10:57] it's not as if fdi and udev rules are easily translatable [10:57] well, but all of us distros have long-term releases, so we will need FDIs for the next couple of years still (unless we want to stop updating them) [10:58] Keybuk: the format of the hal-info rules is relatively straightforward, though, so I guess for a subset it should be possible with some clever XSLT [10:58] yeah [10:58] many rules are simply "0x1234/0x5678 is a scanner" kind of thing [10:58] you'll need hal-info as long as you have hal [10:58] I guess an udev rule won't look much different [10:58] e. g. the hotkey assignments are a different beast, of course [10:59] since they need an actual backend which processes those [11:00] *nods* [11:00] I still don't think the whole DK thing is entirely well thought out [11:01] bryce: good morning [11:02] StevenK: bah, iz not that easy to fix I'm afraid [11:03] tjaalton: Oh? [11:04] maxb: we can tweak it easily [11:05] StevenK: uses some deprecated stuff [11:05] StevenK: just dropping some obsolete includes and copying xf86OSMouse.h didn't help (like with -mouse) [11:06] StevenK: I just hadn't run a real update since intrepid; fixed, thanks [11:08] meh, now I remember why I didn't convert pcmciautils to dh_installudev - the upstream Makefile installs the rules file [11:08] * cjwatson bodges [11:09] dh_installudev is really only suitable for udev rules shipped as packaging modifications [11:09] hm, remove it from *.install, and move debian/tmp/etc/udev/rules.d to *.udev won't work? [11:09] s/move/put/ [11:10] pitti: that's a bit evil :_) [11:10] Keybuk: why? [11:10] pitti: sounds like more effort than reimplementing the necessary bits of dh_installudev! [11:10] cjwatson: your other problem will be that dh_installudev will want to call your file 85-pcmciautils.rules [11:10] so you'll have to deal with the rename in your maintainer scripts *anyway* [11:10] aye [11:11] cjwatson: sure, you can also change the dest path in debian/pcmciautils.install, but then you'd still need the postinst etc. bits; I don't think it's less effort that moving a line from .install to .udev... [11:11] so for these kinds of packages, unless it's a trivial dhification, I'm just copying the preinst snippet in to remove unchanged rules and changing the debian/rules file to match the new path [11:12] oh, wait [11:12] pitti: I didn't say it was in .install [11:12] .udev doesn't *list* the rules files, it *is* the rules file [11:12] I said it was installed by the upstream Makefile [11:12] so yeah, that won't work then [11:12] plus what you said [11:12] cjwatson: ah, you are installing directly into debian/pcmciautils/, not debian/tmp? [11:13] yes [11:13] Keybuk: BTW your debhelper modification doesn't seem to have a maintainer script abort path [11:14] of course the original udev stuff didn't either [11:14] hm, seems like dh_installudev could do with supporting debian/package.udev-files and treat that as file list [11:14] cjwatson: a what? [11:15] pitti: it's modelled after installinit, which doesn't have such a thing [11:15] Keybuk: postrm abort-install or whatever [11:15] Keybuk: right, I thought it would be like dh_install or dh_installman [11:15] cjwatson: IME very few packages bother with it :-/ [11:15] Keybuk: actually I guess it isn't strictly necessary in this case anyway [11:15] then again, it took me a very long time to get it right for udev and dpkg, so I'm not entirely surprised :p [11:16] Keybuk: well, yes, but debhelper getting it right would go a long way :) [11:19] Keybuk: I notice that udev still seds /var/lib/dpkg/status directly; I thought modern practice was to use dpkg-query [11:20] modern practice requires you to know the package name :-/ [11:22] cjwatson: It seems kubuntu-kde4 needs to get ripped out too [11:23] Keybuk: yes, not hard :) [11:23] StevenK: kfreebsd-{6,7}> yes, makes sense [11:23] cjwatson: I'm not also convinced that the dpkg-query method is any better [11:23] after all, it still has to sed the output of dpkg-query [11:24] well, it's all based on the theoretical notion that the status file format might one day be changed; but dpkg-query's output could clearly be kept constant across such a change [11:24] StevenK: I guess so [11:24] StevenK: is the mobile branch ready for me to try? [11:25] cjwatson: Yeah, it's all commited. [11:32] of course, the *hope* is that now udev rules are standardised between at least Ubuntu, Fedora/RH, SuSE and Gentoo - more upstreams will just ship them in their package [11:36] calc: ping [11:37] calc: Is bug #66933 really fixed? Because I have that problem on a clean Intrepid install... [11:37] Launchpad bug 66933 in openoffice.org "Recent Documents doesn't include files opened from within OOO" [Low,Fix released] https://launchpad.net/bugs/66933 [11:42] Keybuk: is there a standard dependency or breaks or whatever for packages shipping new-location udev rules? [11:45] cjwatson: if they dependended on udev before, I've updated it [11:45] but I haven't added one where one didn't exist before [11:45] a lot of things ship udev rules without depending on udev [11:45] which makes it complicated :p [11:46] Keybuk: what should the version be - >> 136-1? [11:46] er >= [11:46] >= 136-1 [11:47] ok, pcmciautils done in my local tree then [11:52] hi [11:53] debhelper is 7.0.17ubuntu2 [11:53] i have patches against /var/lib/gconf/defaults/%gconf-tree.xml and /var/lib/gconf/debian/defaults/%gconf-tree.xml [11:53] if you use cdbs, 0.4.38 has the dh_installudev call [11:53] whom should i send them? [11:59] StevenK: tasksel updated - any problem with me uploading it now or do I need to wait? [11:59] actually I guess it really ought to be now since the seeds have already been changed [12:00] and I see that mobile-meta has been uploaded [12:01] done [12:02] cjwatson: Thanks! [12:02] cjwatson: I'll upload livecd-rootfs tomorrow [12:13] StevenK: I think extending to the other FreeBSD sources is reasonable. I only tripped over that one because of trying to get rid of old libdb versions. [12:14] ScottK: Yup [12:16] mhh weird [12:17] i tried to create a patch, but the diff is always double the size of the original/changed file [12:17] when i view the diff, it first removes _the whole_ original file and then adds _the whole_ new file, although just a few characters have been changed [12:18] soc: line endings change, probably. [12:18] but i want to have a diff with just the lines which were changed, not the whole thing [12:18] how can i ingore them? === nhandler_ is now known as nhandler [12:18] it's an xml file, btw [12:19] You're almost certainly actually changing all the lines in the file. [12:19] Possibly by changing the line endings, possibly some other way. [12:19] maybe tab to space? [12:19] does gedit make that automatically? [12:19] Might, but I'd be a bit surprised. [12:21] i hate it ... always the latest step fails for me ... [12:21] :-/ [12:22] last step [12:22] maybe something else is wrong... this is my line: diff -E --strip-trailing-cr -a --text -u /var/lib/gconf/debian.defaults/%gconf-tree.xml %gconf-tree.xml > debian.defaults-%gconf-tree.xml.diff [12:22] I wanted to do a distribution upgrade test with some update candidate packages I have for distro+1, is there some option for do-release-upgrade to use an extra repository? I would place my packages in this extra repository [12:23] for example, I want to test an upgrade from hardy to intrepid but I want it to consider my local repository as well [12:24] soc: try viewing the diff in an editor configured to show special characters [12:24] which editor could i use for that? [12:29] soc: well, I use vim but you may not be comfortable with that if you're used to gedit :) do some research [12:30] ok [12:30] soc: or you could run it through cat -A [12:31] ok === ember_ is now known as ember === The_Company is now known as Company [13:02] \sh: Hah. I finally managed to get tickets to karlsruhe. :) [13:06] mvo: hi, is there a way for me to supply an extra apt repository for consideration by do-release-upgrade during a distro upgrade? [13:07] <\sh> maswan: when? :) [13:08] \sh: 13th to early morning at the 16th [13:08] \sh: No plans for the 13th so far, might be meeting dinners etc at the other days though. [13:09] <\sh> maswan: 13th sounds great :) [13:10] so who owns the debian-installer in ubuntu [13:11] apw: *wave* [13:12] cjwatson, heh is there anything you don't own? [13:12] ahasenack: not easily unfortuntaely. what is the use-case? [13:13] apw: yes :-) [13:13] (fortunately) [13:13] \sh: see you then, then. :) [13:13] mvo: updating some distro+1 packages, and checking that that distro upgrade from distro to distro+1 doesn't break. I would need do-release-upgrade to consider this other repository with the test packages [13:14] apw: something up that I can help with? [13:14] cjwatson, Hobbsee reported that a dist-upgrade installed a lilo on her grub machine, looking at it it seems that the 32 bit intrepid installs are installing both grub and lilo, but 64 bit is only installing grub ... the initial thought was our recommends were causing it, but not as 32bit and 64 bit differ [13:15] apw: well, whether lilo or grub is installed depends on the installation parameters - for example if /boot is on LVM then lilo's needed [13:15] so i am wondering how d-i decides which to install, and why it might install both? our kernel recommends do mention both but as i say 64bit cd's don't seem to install lilo but 32bit do [13:15] ahasenack: there is a good way to test this via the noninteractive upgrade tester in do-release-upgrade. its not exactly greatly documented, but this is probably a good opportunity to change that :) [13:15] I'm very surprised about both being installed, and would like to see the installer log [13:15] (/var/log/installer/syslog) [13:15] mvo: how can I try it? [13:15] ahasenack: how urgent is it? i.e. can we talk about it a little bit later (~2h)? [13:15] mvo: sure [13:15] my 32bit sample is on a single normal ext3 disk and is using the grub by default [13:16] ahasenack: its in the update-manager bzr branch [13:16] cjwatson, typically i am remote from that laptop today ... i will get that off and to you [13:16] apw: Recommends are ignored while installing the kernel during initial installation, so it won't be that [13:17] Hobbsee, do you have your 32bit lilo/grub machine to hand? If so could you get the /var/log/installer/syslog off it and shove it into bug #314004 [13:17] Launchpad bug 314004 in linux "Lilo gets installed on dist-upgrades, due to the kernel image recommending it. Is this intentional?" [Medium,In progress] https://launchpad.net/bugs/314004 [13:17] apw: http://bazaar.launchpad.net/~ubuntu-core-dev/grub-installer/ubuntu/annotate/head%3A/debian/isinstallable is what controls whether grub or lilo is installed [13:17] apw: if that script exits zero, then grub's used, otherwise lilo [13:17] (approximately) [13:17] thanks, to basically its as expected, only one should be installed [13:17] apw: but that doesn't influence dist-upgrades [13:18] from memory it definatly put both on in the same original install block [13:18] that's incredibly weird [13:18] no i assume Hobbsee got the update just because there is a lilo update in jaunty and it was installed [13:18] I'd be astonished if the discrepancy were really due to i386 vs. amd64 [13:18] I think it's more likely to be something more subtle [13:19] apw: i got it installed at the point where I did the dist-upgrade. [13:19] cjwatson, if Hobbsee isn't able to get her logs, i will try and be where the other laptop is and get it off [13:19] the thing is that the kernel recommends lilo | grub [13:19] not both - either should satisfy it [13:19] apw: should be http://pastebin.com/f81055d5 [13:19] now, I do think the kernel should recommend grub | lilo instead, switching the order [13:19] but that's cosmetic from the point of view of this bug [13:19] elilo! [13:19] cjwatson, can i tell if there was a lilo update in jaunty [13:19] apw: shouldn't be relevant [13:20] apw: rmadison lilo [13:20] (i didn't check whether it had installed lilo in the original install of intrepid) [13:20] Hobbsee, i amhappy it installed lilo in the update. just want to know if it could also have been installed before dist-upgrade and was simply upgraded [13:20] apw: could have been [13:20] i think pgraner said his 32bit install had both too [13:21] apw: simply changing the version of lilo in jaunty wouldn't cause it to be magically installed [13:21] so its something more than just one or two of us [13:21] cjwatson, right, but it changing would make it upgrade at dist-upgrade which might explain why it was noticed by Hobbsee [13:21] I think this is related to installing with desktop vs. alternate/server [13:21] and yes it is differnt [13:21] lilo | 1:22.8-4ubuntu1 | intrepid | source, amd64, i386 [13:21] lilo | 1:22.8-7ubuntu1 | jaunty | source, amd64, i386 [13:22] so ... if she had had the same as me, that both were on, then lilo would be downloaded and installed as part of an update [13:22] installer log added to bug. [13:22] Hobbsee, perfect [13:22] this is interesting, lilo is installed as part of desktop [13:22] that would explain why ubiquity isn't removing it [13:23] mvo: update-manager might have to arrange to remove lilo :-( [13:23] (if unused ...) [13:23] Setting up lilo (1:22.8-4ubuntu1) ... [13:23] right, so i did get it in the intrepid version. [13:23] your initial install was intrepid desktop [13:24] so can we tell from the log what slurped it in? [13:24] cjwatson: sure, that can be arranged [13:24] not from the log but I can tell in other ways, please wait [13:24] apw: it installed it on a Intrepid->Jaunty upgrade [13:24] pgraner: but it was already installed on intrepid, I'm fairly certain# [13:24] pgraner, what he said [13:25] therefore focusing on the upgrade is an error [13:25] there was a new one in jaunty so if you had it already you get eh new one, even though you don't want it [13:25] cjwatson: it might have been, I never noticed it. In fact the only way I noticed was when I got the "Configure LILO" screen from apt-get [13:25] oh goodness, yes, you would [13:25] due to the large-memory thing [13:25] yargh, lovely bug that's now enshrined on lots of systems [13:26] apw: I bet your intrepid-installed system without lilo was installed using the text-mode installer, and your system with lilo was installed using the desktop installer [13:26] apw: can you confirm? [13:27] so it's true that the order of the kernel recommends is what caused this, but really, accident ... [13:27] cjwatson, i can confirm the 'broken' one was installed virgin from a desktop CD image [13:28] the working one i am struggling to remember if it was hardy CD installed and updated or reinstalled from the intrepid 64 bit CD [13:28] let me give you a potted summary of what happened, then [13:28] can i tell at all [13:28] yes, /var/log/installer/syslog will indicate, if only from the kernel version [13:28] in intrepid, we enabled recommends by default; this had some speedbumps but largely appeared to be working OK [13:28] Oct 21 12:47:25 ubuntu kernel: Inspecting /boot/System.map-2.6.24-19-generic [13:28] so hardy then upgraded me thinks [13:28] (therefore any installs from earlier than intrepid are entirely unaffected by this) [13:29] the alternate/server CD (d-i) installs as I described above, by explicitly choosing whether to install grub or lilo depending on installation parameters; no problem there [13:29] however, the desktop installer works quite differently [13:30] we put a "live filesystem" onto the desktop CD, a preinstalled filesystem image with lots of packages on it that's then copied to the target system [13:30] obviously, there are some things on this image that shouldn't end up on the target system, such as the installer itself [13:31] so we copy the filesystem image file-by-file, and then remove unwanted packages using apt (this is still a lot quicker than installing them all from scratch, and allows us to fit an installable live system onto a single CD) [13:31] the set of packages we remove is computed by taking the set-difference between a "desktop install" and the full live filesystem package list, plus one or two other tweaks [13:32] (things like language packs, removing unused kernels if there's more than one available, etc.) [13:32] cjwatson, a sneak solution indeed [13:32] for various reasons, the script that builds the live filesystem (in the livecd-rootfs package) installs the kernel before it says "right, that's it, what I've got now is a desktop install" [13:33] and, due to the kernel's Recommends, the bootloader (in this case lilo) is considered as part of the desktop install, and not removed by the installer [13:33] the installer notices that it needs grub, and therefore arranges for it to stay installed as well [13:33] and voila, two bootloaders [13:34] I recommend three fixes for this, and will update the bug accordingly: [13:34] 1) ubiquity should arrange to remove all bootloaders except for the one it's installing [13:34] 2) linux should switch the order of its recommends to suit the modern age (not required given 1, but probably sensible anyway, and I think there may well be other bugs about this) [13:35] 3) update-manager should clean up this mess on upgrade [13:35] (done) [13:36] ok ... so i can handle the linux(2) side under the linux task [13:36] yep [13:36] will you make tasks for the rest? [13:36] yes, already have [13:37] cool. will get on it. does this need doing for intrepid, or is it too late to matter [13:37] (we are going to make new CD's I assume for the intrepid update?) [13:37] too late for intrepid, and we weren't planning new CDs [13:38] we normally only do new CDs for point releases, which are normally only for LTSes [13:38] ok so then i'll just spin the change on jaunty [13:38] and they're a lot of work [13:38] yeah, jaunty will be fine [13:38] heh, yeah i did notice a lot of moaning when they were being spun last time [13:38] Hobbsee: thanks for spotting this [13:38] cjwatson: glad you can fix it :) [13:41] cjwatson: is there a bugnumber for this? I can do the work in u-m, just want to know a bit more about the problem (I can read scrollback if it was discussed here of course) [13:42] mvo, bug #314004 [13:42] Launchpad bug 314004 in linux "Lilo gets installed on dist-upgrades, due to the kernel image recommending it. Is this intentional?" [Medium,In progress] https://launchpad.net/bugs/314004 [13:43] cjwatson, thanks for the insight into d-i's guts [13:43] apw: ubiquity's guts in this case [13:43] (you're welcome) [13:45] fixed for next upload, pending testing [13:51] cjwatson, kernel patch out for review [13:52] cjwatson: heh, I spotted it the other day too but hadn't got around to mentioning it yet [14:02] james_w: around? [14:03] hey Keybuk [14:03] bzr build-deb appears to be ignoring my .bzr-builddeb/local.conf :-/ [14:03] quest ubuntu% cat .bzr-builddeb/local.conf [14:03] [BUILDDEB] [14:03] source-builder = dpkg-buildpackage -rfakeroot -uc -us -S -i'(?:/|^)(?:test|\.gitignore)(?:/|$)' [14:03] yet, when I do bzr bd -S I get lots of [14:03] dpkg-source: error: cannot represent change to udev-136/test/sys/devices/virtual/block/loop5/subsystem: [14:03] followed by (eventually) [14:03] dpkg-source: unrepresentable changes to source [14:03] dpkg-buildpackage: failure: dpkg-source -b udev-136 gave error exit status 1 [14:04] Keybuk: could you pastebin the full output please? [14:04] Keybuk: is the file versioned? [14:04] no [14:05] the full output is ~4 GB [14:05] ok, the top few lines should do [14:05] Keybuk, ubuntu-news-team@lists.ubuntu.com, I think. [14:05] the files its complaining about are versioned, but not in the tarball [14:05] sorry, is .bzr-builddeb/local.conf versioned? [14:05] http://paste.ubuntu.com/101665/ [14:06] james_w: yes [14:06] Keybuk: ah, it shouldn't be, it's local overrides [14:06] what file do I put that line in instead? [14:07] there is no way to set per-package overrides yet currently unfortunately [14:07] you can either move that file to ~/.bazaar/builddeb.conf [14:07] that means nobody else will be able to build a udev package from bzr other than me though [14:07] no? [14:07] which kinda defeats the object :p [14:07] or unversion it ("bzr rm --keep") [14:07] don't put it in the local file then [14:08] bzr mv .bzr-builddeb/local.conf .bzr-builddeb/global.conf [14:08] er, default.conf sorry [14:08] Building the package in ../build-area/udev-136, using dpkg-buildpackage -rfakeroot -uc -us -S [14:08] no change [14:08] still ignores it [14:12] python -c "from bzrlib.workingtree import WorkingTree; print WorkingTree.open_containing('.')[0].path2id('.bzr-builddeb/default.conf')" [14:12] what does that print? [14:13] local.conf-20081222123037-mhcrh47mqkmhxuj7-2 [14:16] james_w: Re debbug #426419 > no patch; did we actually patch this? [14:17] tkamppeter: so I'm looking at hplip's udev rules ... and I'd like to take your crack pipe away [14:25] heh [14:25] in fact [14:25] I can just delete the rules file entirely [14:25] because all it does is put things into the scanner group [14:25] which we, err, don't have [14:25] Keybuk, hmm, I have it [14:25] tills crack pipe ? [14:25] gid 105, so probably manually created [14:25] liw: it goes away in jaunty [14:25] Keybuk, ah [14:26] Keybuk: ah, I see the issue. builder commands can't be specified in those files. The rationale was that it was arbitrary code execution, but that doesn't seem like a good one. [14:26] james_w: it should be at least possible to specify the ignore string? [14:27] Keybuk: yeah, but does everyone's builder command accept that option? [14:30] liw: it isn't necessary to be in the scanner group since hardy any more (replaced by automatic ACLs); but of course on upgrades your user isn't removed from it [14:30] lool: seems we didn't [14:31] lool: http://patches.ubuntu.com/by-release/ubuntu/a/acpid/acpid_1.0.4-5ubuntu6.patch.bz2 is the patch referred to in the initial debian bug report [14:32] james_w: another option would be files you could not export across to the build area? [14:32] lool: well, we patched acpid to check for the file, but didn't patch it to fix the ubuntu bug I referenced [14:34] Keybuk: that could work. [14:34] I want to do something about the builder command handling anyway, as it's quite irritating, but I'm not sure what the best approach to take is [14:35] cjwatson: you remember how we couldn't figure out why hwclock wasn't working properly? [14:35] well, I just looked at the udev rules [14:35] KERNEL=="rtc", ... [14:35]