=== RoAkSoAx_ is now known as andreserl [00:15] Hm. I think you guys maybe have something broken in your tab complete... [00:15] svn diff sk.bash: [: too many arguments [00:15] sk.txt sk.zip [00:15] (that was me hitting tab on sk. ) [00:16] on a similar front, super annoying that mplayer startofogvfile does not tab complete - like it doesn't recognise *.ogv [00:17] nemo: File bugs. An IRC channel is not a very good bug tracker. [00:38] crimsun: Sounds good. === yofel_ is now known as yofel [01:17] cjwatson, think you can review my fix for the dmraid regression and upload it as an SRU once some other users successfully test it? see bug #568050 and the linked bzr branch [01:18] Launchpad bug 568050 in parted "Ubuntu 10.04 can't create partition on fakeraid" [High,In progress] https://launchpad.net/bugs/568050 === andreserl is now known as RoAkSoAx [02:49] ScottK: heh. actual bug tracker isn't a very good bug tracker either. but fine. [02:49] nemo: It tends to be a bit more peristent than IRC backscrolls though. === gospch_ is now known as gospch === ogasawara_ is now known as ogasawara [07:32] <\sh> moins [08:01] Good morning [08:05] <\sh> moins pitti [08:17] good morning [08:19] hey dholbach [08:19] hey mvo [08:20] hey dholbach, good morning mvo [08:21] salut didrocks [08:22] hey didrocks! [08:56] Hello [08:56] regarding this bug LP 580944 [08:56] Launchpad bug 580944 in sl-modem "package sl-modem-daemon 2.9.11~20100303-2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 127" [Undecided,New] https://launchpad.net/bugs/580944 [08:56] it is obvious that the /etc/default/sl-modem-daemon (ie. a conf file) has been damaged or tampered with severely, anyways it caused the package state to be not be fully installed [08:57] what's the optimum solution: shall I attach to the user the default conf file & tell him to put it there ? or is there a way to reinstall the package (& overwriting the conf files) [08:57] mvo: ping ^ [08:58] AnAnt: it would be interessting to know the state of the file [08:58] AnAnt: so attaching it is a good idea [08:58] mvo: state of the file ? [08:58] mvo: the file is attached [08:59] AnAnt: oh, ok. let me actually look at the bugreport then [08:59] mvo: that's why I said it was either damaged, or someone severely tampered it === radoe_ is now known as radoe [09:00] AnAnt: indeed, that looks like file system corruption [09:01] AnAnt: I guess best is removing it and reinstalling with "dpkg -i --force-confmiss /var/cache/apt/archives/sl-modem-daemon_" [09:01] AnAnt: or purge/reinstall with apt-get [09:02] mvo: do you think and can be purged ? [09:02] mvo: or even removed ? [09:02] I've seen packages that go into a real bad state that you can neither remove nor upgrade ! [09:02] unless I have to remove some prerm for example [09:03] AnAnt: that is (unfortunately) true, but happens not that often, in this casse it may work, but I have not looked at the orther scripts of the pkg [09:03] mvo: ok [09:05] thanks [09:05] bye === smb is now known as smb-afk [12:00] Keybuk: could you have a look at bug 581527 when you have a minute ? the attached patch should hoppefuly make the life of some OpenVZ users a bit easier as well as fix some other cases I don't know about ;) [12:00] Launchpad bug 581527 in udev "udev segfaults in udev_monitor_enable_receiving when netlink doesn't work" [Undecided,New] https://launchpad.net/bugs/581527 [12:00] the patch is still wrong [12:01] udev cannot function without the netlink socket [12:02] yes, I know that, I just don't think "cannot function" means it should segfault ... [12:02] in a VZ environment we don't have any kind of device anyway, so we really don't need udev to work, we just need it to not make the software crash because it segfaults ... [12:03] I'd be happy if your patch made it an assertion error [12:04] as I mentioned in the bug report, I really don't know much about udev's code and so don't have a clue about its error codes, so if you know what that function should return when it doesn't get a valid structure as parameter, I'll be happy to change the patch [12:04] if you pass invalid data to functions, that's always a programming error, thus an assertion error [12:10] Keybuk: ok, I'm looking at moving it to making an assertion error. Just wondering why it's not the case for all the other functions in that file that simply "return NULL" when udev_monitor is NULL, any idea ? [12:10] no idea, you'd have to talk to upstream [12:10] they may have a different opinion === cking is now known as cking-afk [12:44] Keybuk: so, casey's MoM lock is still held following the reboot a while back - can I remove it so that the cron job proceeds, or are you operating it manually? [12:47] cjwatson: I thought you were operating it ;) [12:48] nope [12:48] hello [12:49] I asked if I could remove the lock a few days ago, but I guess it got lost in UDSery and I didn't see an answer, so I stayed clear but forgot to re-ask on the train or whatever === barry` is now known as barry_ [12:55] Keybuk: I'm going to take that as a yes, and have removed the lock now [12:55] sorry, was on the phone [12:55] yes, it's ok for you to drive :p [12:55] ah ok [12:55] I don't want to drive, I just want to let cron drive. :-) [12:56] .oO( maybe mom should be an upstart service to avoid all this stale lock guff ) [12:57] heh [12:58] I suppose that's a sane thing to have in upstart-cron, run once an hour unless it's running already [12:58] though doesn't really cover running it by hand [12:59] indeed [12:59] "start mom" === cking-afk is now known as cking === tgall_out is now known as tgall_foo === jelmer_ is now known as Guest6486 === smb-afk is now known as smb [14:04] cjwatson, I have a bug that you will probably be interested in: bug 578742 [14:04] Launchpad bug 578742 in linux "Btrfs device balancing does not work" [Undecided,New] https://launchpad.net/bugs/578742 [14:05] I apologize in advance :-) [14:07] JFo: not too bothered yet, assuming that it can be forwarded upstream and fixed in maverick; at this point, given the lack of userspace support, I only care about problems that would make it difficult for us to implement that support [14:07] JFo, anything less than an rc of 2.6.34 is considered obsolete and basically dangerous to use by #btrfs :p [14:08] oh indeed [14:08] my concern is, how to address this with the reporter. Plus my boss (pgraner) told me to punt to cjwatson :-) [14:11] JFo: um, I don't see how it's anything much to do with me. I have many of the tasks to implement userspace support in maverick, but kernel support for btrfs is not my problem [14:11] heh [14:11] no problem [14:11] my desire is to respond that it is unsupported [14:11] a dkms package + more recent btrfs userspace would make upstream happier with us :p [14:11] so that is the plan [14:11] JFo: that would be inappropriate [14:11] and yet, that is what I am told from both sides [14:12] well *currently* unsupported [14:12] JFo: the correct way to deal with it would be to test whether it's fixed in a more recent release; if it is, it can be closed as Fix Released in maverick; if it isn't, it should be forwarded upstream [14:12] just closing it as "unsupported in lucid" deprives us of a source of problem reports, surely [14:12] it cannot be the case that all possible bugs people might file on lucid's btrfs are automatically fixed in maverick's [14:13] cjwatson, a dkms build of the latest or running 2.6.34 would suffice for that; upstream thinks it's saner to use a dkms build though [14:13] cwillu_at_work: sure, my point is it should be actually tested before closing it [14:14] fair enough; a ppa with up-to-date modules would be useful [14:15] there's lots of issues with btrfs in 2.6.32 though, somewhat fewer in 2.6.33; bug reports from those versions shouldn't be upstreamed until they've been tested with more recent versions imo is all I'm saying [14:15] JFo: to clarify, saying it's unsupported is fine, but not in itself a reason to close the bug since after all we do ship it, and the reason we ship it is to collect early feedback so automatically discarding that feedback is a bit odd [14:16] (I think the fact that people have to go through contortions to get their system to boot with a btrfs / is a fairly clear indication that it's unsupported in lucid) [14:17] JFo, you should mention on that bug that running btrfs on rootfs is actively dangerous; there's a dpkg bug that isn't fixed in lucid that hurts _really_ bad with btrfs [14:17] /var/lib/dpkg/info corruption specifically [14:17] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891 [14:17] cwillu_at_work: lies, that's fixed in lucid :) [14:17] Debian bug 575891 in dpkg "dpkg makes wrong assumption about readdir() and lose metadata files with btrfs" [Important,Fixed] [14:18] cjwatson, it is? I missed that commit then :p [14:18] cwillu_at_work: dpkg 1.15.5.6ubuntu4 [14:18] ah, goodie [14:18] I've been bind mounting my /boot onto /var/lib/dpkg for a while because of that :) [14:21] in related non-news, I'm trying to get btrfs to build as a dkms module, but I keep tripping on a permission error during dkms build [14:36] ah, got it; symlinked to the root of the tree instead of fs/btrfs [14:38] stgraber: Hey [14:38] stgraber: I just wanted to tell you your UDS demo was awesome [14:39] ooo yes, I agree lool ! [14:43] JFo: Bug #496093 looks like it's in need of some serious triage/sorting out how many problems are really in one bug. It's one of the two bugs the release team is subscribed to that is still getting piles of new comments. [14:43] Launchpad bug 496093 in linux "[lucid] rt2860 frequently fails to connect to mixed mode WPA/WPA2 secured wireless networks" [Medium,Triaged] https://launchpad.net/bugs/496093 [14:44] ugh, thanks for the pointer ScottK [14:44] JFo: Enjoy. [14:44] ;-) [14:44] heh [14:44] yea i'm actualy bit by that bug on my other laptop ( or a variant of ) [ rt2870 ] [14:44] i was just reading it too === oubiwann is now known as oubiwann_ === pgraner is now known as pgraner-afk === cking is now known as cking-afk === cking-afk is now known as cking [15:20] mdke: could https://help.ubuntu.com/9.10/installation-guide/ be updated to the version in karmic-proposed, which is actually distinct from jaunty? [15:21] or, well, meaningfully distinct in terms of version numbers and such [15:32] kenvandine, oops :-( sorry about that - did the bliptv title have it that way - I think that is where we pulled the titles from [15:33] :) [15:33] * kenvandine looks [15:34] akgraner, yup... it's wrong there [15:34] akgraner, can you fix it there? [15:34] kenvandine, I'll email them.. and let ya know [15:34] :-) [15:34] thx :) [15:36] kenvandine, popey is going to change it [15:36] :-) [15:38] kenvandine, I hope you badge was right as they even took pics of the badges :-) [15:38] hehe... it was [15:38] sorry for not spotting that on the day [15:38] thanks for catching that [15:38] no worries [15:39] have changed and triggered resync to youtube [15:39] awesome === deryck is now known as deryck[lunch] [15:44] who would I talk to about getting kde imported into launchpad? (likewise for qt) [15:44] shtylman: james_w ? [15:44] if you're talking about code [15:44] yea... code indeed [15:44] cjwatson: so you are going to SRU the libparted fix for the 10.04.1 respin? :) [15:44] hi shtylman [15:44] I expect most of our packages do have code branches in launchpad, some like kdebase don't but that should be fixable [15:45] james_w: howdy [15:45] psusi: it has my attention now at least [15:45] if you're talking about svn imports, that's more complex [15:45] cjwatson: looks like another user reported it worked for them... [15:45] shtylman: what can I help you with? [15:45] james_w: to bring you up to speed, the current plan is to be able to do qt and kde daily builds when launchpad supports it [15:46] james_w: this means that we need to make sure we have all the nessesary kde svn code in launchpad bzr (as I understand it) [15:46] psusi: I'm still catching up after UDS, I don't expect to decide today [15:46] k [15:46] I haven't the first clue on the proper way to import that or layout the bzr branches ... so I seek guidance :) [15:47] note that Qt is in Git [15:47] shtylman: that's correct. I'm not really the person to talk to about that, you want someone on the launchpad-code team. [15:48] shtylman: there is documentation at https://help.launchpad.net/Code/Imports, and you can find people on #launchpad that should be able to help [15:48] james_w: thanks [15:48] shtylman: let me know if you don't get anywhere [15:49] k [15:51] Keybuk: wait, what's this about udev not creating dev nodes anymore, but devtmpfs instead? yet another kernel fs to auto create dev nodes? I thought that was one of the reasons udev was made, to get away from devfs and move the dev node creation to user space? [15:51] that was *last year* :p [15:51] now udev doesn't create device nodes [15:52] psusi: well, the original objection was about the kernel defining names and permissions, not so much the actual mknod(), AFAIR [15:52] quest scott% cat /etc/issue.net [15:52] so it's back to a new devfs like kernel fs? ack... [15:52] Ubuntu 10.04 LTS [15:52] quest scott% mount | grep "on /dev" [15:52] none on /dev type devtmpfs (rw,mode=0755) [15:52] pitti: which is also ironic, since now we make the kernel define the names and don't let you change them in userspace ;-) [15:52] it's not really as much like devfs as all that [15:52] Keybuk: does the kernel just go in cycles about how to handle this stuff? [15:52] Keybuk: but we still control permissions and symlinks [15:53] pitti: right [15:53] which the original devfs didn't [15:53] the problems with devfs were (a) it had its own special and unique snowflake naming scheme (b) it introduced a huge pile of new kernel infrastructure just for itself (c) it didn't allow any userspace control at all [15:53] so wait... you can no longer use a udev rule to persistently name a given disk /dev/sda even if the kernel detects it in a different order? [15:53] devtmpfs doesn't suffer from these problems [15:53] psusi: you can do arbitrary symlinks, but not rename the "master" node [15:53] psusi: correct, you can only use a udev rule to persistently add a symlink to the disk with the name that is memorable to you [15:53] psusi: yay for UUIDs? [15:53] /dev/porn -> /dev/sdXY where the XY is whatever it is this boot [15:54] that seems like a big step backwards? [15:55] psusi: NB that even without devtmpfs current udev does not support renaming any more :) [15:55] not really [15:55] but symlinks are really just as good [15:55] allowing renaming of device nodes caused huge numbers of problems and gained nothing [15:55] it did? [15:55] symlinks work perfectly for "personal names" [15:55] psusi: yes, for example, swap /dev/sda and /dev/sdb atomically ;-) [15:55] hrm... I suppose [15:56] why need to do it atomically? just have udev create them with the correct name in the first place [15:56] and there's benefit to having a "master node" whose name matches the standard at all times [15:56] and whose name matches the sysfs object too [15:56] renaming sda to sdb would not rename /sys/devices/.../sd [15:56] renaming sda to sdb would not rename /sys/devices/.../sda [15:57] hrm... true... I have been getting annoyed lately running that script to parse the ureadahead output and it gets confused because the kernel name listed is dm-5, but there is no /dev/dm-5 [15:57] see, Symlinks 1 - Renames 0 [15:57] ;P [15:57] good point ;) === barry_ is now known as barry [15:59] now... I still see an issue with the naming of dm nodes [15:59] we're hoping that the devmapper kernel-side will start putting NAME= into its uevents [15:59] err, DEVNAME= sorry [15:59] if the native kernel name is dm-1 for the partition on dm-0... does that mean that devtmpfs will create dm-1, then udev will see that it is a partition and make a link for dm-0p1 to point to it? [15:59] if that's the desired behaviour, that makes sense [16:00] dm0 [16:00] dm1 -> dm0p1 [16:00] dm2 -> dm0p2 [16:00] dm3 [16:00] dm4 -> dm3p1 [16:00] doesn't seem terrible [16:00] except I got my arrows the wrong way around :) [16:00] personally I don't like the p in there, but can live with it... but really it seems cumbersome to map dm-1 to dm-0p1 rather than just partition dm-0... seems the kernel side really needs to just support partitions like md now does [16:01] that would be better, I agree [16:02] biab [16:03] why am I suddenly spammed with millions of merge proposals? is that just me? [16:04] pitti: I think it might be due to being in ~techboard. Does the mail say why? [16:04] not really [16:04] james_w: but I've been in TB for a long time, and this only started this week [16:05] or perhaps last week with a new LP rollout, and I just ignored them [16:05] pitti: ah, rollout [16:05] LP now sends mail on merge proposals via teams, it used to just be direct subscriptions [16:06] I've been trying for ages to restructure things so that ubuntu-dev would catch merge proposal mail, but it's slow going [16:06] I'll go ping the losas [16:06] james_w: thanks [16:17] is there a way to have network interfaces consistently appear as eth0, eth1, etc. based on mac address? [16:18] cr3: Yes. [16:18] cr3: /etc/udev/rules.d/70-persistent-net.rules [16:19] cjwatson: awesome! has this been around for long? [16:19] quite a few releases, yes [16:19] definitely at least hardy but I think rather longer [16:36] hey all [16:36] not sure if this is the proper outlet for this [16:36] but [16:36] does anybody know how to create a keyboard binding/shortcut without X running? [16:36] like in a virtual console? [16:41] bigcx2: It's #ubuntu for support. [16:51] arand: figured, didn't really feel like my message getting lost in the 1600+ people trying to get support in there === deryck[lunch] is now known as deryck === beuno is now known as beuno-lunch [17:49] what's the file under /proc, I think, which can be used to reset the buffer cache? [17:50] cr3: /proc/sys/vm/drop_caches [17:50] I think it's /proc/sys/vm/drop_caches, I wonder if I simply need to echo 0 in there... trying it out... [17:50] cr3: yes [17:51] proc(5). echo 3. [17:51] pochu: I was running top which showed something like: 84456k buffers. after running echo 0 | sudo tee -a /proc/sys/vm/drop_caches, the value didn't change significantly [17:52] ion: awesome, thanks! === pgraner-afk is now known as pgraner [18:09] echo 1 drops file cache, 2 drops dentry cache, 3 drops both [18:13] can anyone tell me how the 'Supported:' information gets into apt-cache showpkg output? [18:15] apw: talk to mvo [18:16] apw: and as of last week, there's a bug that shows all -updates packages as 'unsupported' === beuno-lunch is now known as beuno [18:17] slangasek, ahh i have new kernel packages with no line at all, likely related === pgraner is now known as pgraner-afk [19:06] nxvl: [19:06] ping [19:15] I couldn't find solang in ubuntu repo [19:15] it should be there so one can test it [19:17] Damascene: it was removed in debian and in ubuntu afterwards [19:18] do you know why? [19:18] Damascene: it got removed from lucid due to buggy nature and depending on deprecated libraries. no one has stepped in to help with updating it (neither then nor now). it also got removed from debian (probably the same reason) [19:18] because some one thought it is a port of f-spot? [19:19] kklimonda: i saw one bug report with an updated package [19:19] Damascene: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547506 [19:19] Debian bug 547506 in ftp.debian.org "RM: solang -- ROM; buggy, depends on deprecated libraries" [Normal,Open] [19:19] https://launchpad.net/bugs/512097 [19:19] Ubuntu bug 512097 in solang "[needs-packaging] Solang 0.4.1" [Wishlist,New] [19:19] I see [19:20] thanks [19:21] mlterm is now in version 3. it will be included in the next release or some on should ask for that? [19:21] solang 0.4 has one interesting feature - they have replaced their database with the tracker backend [19:22] on the other hand shotwell is written in Vala - also nice interesting technology.. choice, choices ;) [19:22] Damascene: what has been decided at UDS? [19:25] bdrung: pong [19:26] kklimonda, I don't know [19:26] who knows? [19:26] nxvl, how come no one knows about keyrx [19:27] nxvl: bug #581167 - should i remove "(Canonical)" from your name? a complaining gpg is a configuration problem. [19:27] Launchpad bug 581167 in openssl "Please merge openssl 0.9.8n-1 into ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/581167 [19:27] nxvl: the .pc directory came from the debian branch and it's probably a bug of the importer [19:27] bdrung: if you want to, the problem is that my gpg key is exactly like that, if not present it won't recognize my gpg key, but since i'm not signing + uploading, i don't really mind [19:28] bdrung: i just have it like this in my DEBFULLNAME for when i do universe [19:29] nxvl: most commands allow to set the key (i set DEBSIGN_KEYID in /etc/devscripts.conf) [19:29] huh [19:29] interesting [19:29] will take a look at that then [19:29] :D [19:29] thanks for the tip [19:30] Damascene: I think it was dpm who has asked you to raise this issue at the UDS and he may be a good person to ask anyway [19:30] i have two keys and want to force the correct one (and it's easier for sponsoring) [19:31] Damascene: about what? [19:31] nxvl, about the ubuntu should provide update packages bug [19:31] ohh [19:32] seem like keryx do the job [19:32] it should get some support form ubuntu [19:33] Damascene: will take a look at it later [19:33] ok [19:34] Damascene: ohh, gui, i'm not maintaining that [19:34] Damascene: ping mvo about this [19:34] ok [19:35] nxvl: configure changes the patched Makefile? [19:35] Bug 572776 [19:35] Launchpad bug 572776 in ubuntu "Ubuntu should provide update packages for download and use for offline users" [Undecided,New] https://launchpad.net/bugs/572776 [19:35] just for reference [19:35] bdrung: not as far as i remember, or we patched that aswell [19:36] mdeslaur: ^^ [19:36] mdeslaur: is about openssl [19:36] nxvl: "Those can't be striped out, please see changelog entry for 0.9.8k-7ubuntu2 and 0.9.8k-7ubuntu3 for more information" [19:38] bdrung: hmm...the pc directory was present because the patches are currently _applied_ in the source tree [19:38] nxvl: Configure and util/perlpath.pl are modified directly. so there should be no problem in putting these changes into patches. [19:38] bdrung: actually, is source format 3.0, so those are quilt patches anyway [19:39] let me find the wiki [19:39] nxvl: yes, but i want to avoid debian/patches/debian-changes-0.9.8n-1ubuntu1 [19:40] bdrung: configure was an issue too, because it didn't clean or something, mdeslaur knows more about the issue since he fixed it last time [19:41] an please get in touch with him since he had some plans for this upload aswell, or something [19:42] mdeslaur: ping [19:42] bdrung: yeah [19:43] mdeslaur: i was talking with nxvl about openssl [19:44] bdrung: are you reviewing it? [19:44] mdeslaur: the new package has "direct" changes and are put into debian/patches/debian-changes-0.9.8n-1ubuntu1 due to dpkg-source 3.0 (quilt). [19:44] mdeslaur: yes [19:45] hmm...I'm not sure how that will work with source 3.0 [19:45] it would be nice to have debian-changes-0.9.8n-1ubuntu1 reverted back to proper patches [19:45] bdrung: maybe the FTBFS issue is resolved now that the package has been migrated to 3.0 [19:45] it should work with 3.0 [19:46] bdrung: someone will need to test it with proper patches to see if it will build on all archs [19:46] mdeslaur: it's just an issue of building twice [19:47] bdrung: right, the patches wouldn't un-apply cleanly before, so the build would fail [19:47] yes, but 3.0 (quilt) does not unapply the patch [19:48] Damascene: i use apt-mirror to mirror the complete archive. then i transport this on an hdd to the networkless computer [19:48] do you want some one to download the whole ubutnu repo? [19:49] Damascene: i must admit that this is an overkill for just having the updates ;) [19:50] keryx seems fine but I've not tested it yet [19:50] I mean not so much testing [19:50] but having the packages from ubuntu would be fine too [19:58] nxvl: the package has many lintian error and warnings [19:58] ok, just unsubscribe -sponsors and i will take a closer look after work [19:59] and please add that infor to the bug report [19:59] i assume plane-merging isn't as good as it sounded :P [19:59] nxvl: i think it's better to work with debian to resolve the lintian errors [20:00] nxvl: the clean target isn't clean [20:03] mdeslaur, kees, jdstrand: next cicle i won't touch openssl, enough headache for 2 releases! [20:03] :D [20:13] should the libgs8 patch be taking an extra 1.5MB? [20:28] Will pbuilder run easily on a non-ubuntu host? [20:28] Right not I build in an ubuntu vm on arch linux host, but that's rather slow. chroot would be much nicer [20:29] is that easily set up? === dendro-afk is now known as dendrobates [20:33] !pbuilder | Daenyth [20:33] Daenyth: pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto [20:34] pochu: those instructions assume you are running on ubuntu [20:36] Daenyth: what's your host? [20:37] arch linux [20:37] it works. I dunno about arch linux instructions or success stories there though [20:38] I mean, if it's been known to work on at least *some* non-ubuntu systems, I can wing it from there [20:38] I just wanted to know if pbuilder will break if not run on ubuntu [20:38] I can't imagine it needs to know *that* much about the host system... [20:39] It will run on Debian. Not sure about anywhere else. [20:39] there were some pbuilder packages on arch, check google :P [20:39] I'll look into that [20:39] there is debootstrap, according to google [20:40] well yeah [20:40] chroot/debootstrap should be sufficient to install a debian base system [20:40] hrm [20:40] yes true [21:04] joaopinto, debootstrap has a specific target for pbuilder in fact :p [21:12] can someone clarify ? [21:12] grub 1.98-1ubuntu6 is grub 2 [21:12] right? [21:12] smoser: It is. [21:12] yeah, i see that now 'apt-cache show grub2 | grep Version' [21:12] just confusing. thanks though. === dendrobates is now known as dendro-afk [22:12] anyone have any git-buildpackage experience? ... is it possible to build without cleaning? it seems to want to clean all the time [22:13] does bzr buildpackage have a noclean mode? [22:15] shtylman: bzr-buildpackage doesn't clean, it just exports (which will ignore files in the working directory that bzr doesn't know about). If you want to skip the redundant clean afterwards, you would run 'bzr bd -- -nc' [22:15] (to tell debuild not to call debian/rules clean) [22:16] slangasek: thanks [22:17] * ScottK gives kees a hug. [22:25] if I have a project that builds with scons... is there something (env var or whatnot) that I can put in the debian/rules file to basically pass the -j flag onto scons when dpkg-buildpackage runs it? [22:26] shtylman, dh supports scons [22:26] %: [22:26] dh --parallel $@ [22:26] um... I don't follow :/ [22:27] this will pass -j flag to scons configure / build if DEB_BUILD_OPTIONS=parallel=X [22:27] is set [22:27] sorry for my newbieness :) [22:27] shtylman, read [22:27] $ man debhelper [22:27] $ man dh_auto_configure [22:27] k [22:27] $ man dh_auto_build [22:27] =) [22:27] * shtylman goes to read [22:31] tkamppeter: should the libgs8 update take an extra 1.5MB? [22:32] micahg, which libgs8 update? The recent SRU? [22:32] tkamppeter: yes [22:33] xnox: were you implying that it would automatically pass that to the build system? or that I need to make sure the rules file must have something special beyond running scons in the build-stamp target (which is what happens right now) [22:34] shtylman, dh $@ will automagically handle parallel, strip, optimize options for you. Beyond the two line snippet you shouldn't need anything else =) [22:34] xnox: gotcha... but from my memory of makefiles %: is a catch all ... why would I want to use that specifically? [22:35] right now, the rules file has a build target that calls scons itself [22:35] is that wrong? [22:35] shtylman, you can do that =) [22:35] It's not wrong, but it may make it harder than it has to be. [22:35] and yes %: is catch all [22:36] but that's the beauty of it [22:36] read [22:36] $ man dh [22:36] heh [22:36]