=== Mez|OnAir is now known as Mez [00:09] oh whoa. I didn't realize you could actully debdiff .deb files. :P [00:09] haha [00:09] and changes files [00:10] yeah... just reading the manpage now. :P I've used it on .dsc for so long I didn't even think it could be used for other things. heh [01:09] evening guys, can I ask a silly question ? [01:09] Pelo: Perhaps, if it is related to Ubuntu development. [01:09] why doesn't the live cd default to vesa when detecting a nvidia or ati video card ? [01:10] does that count ? [01:13] That looks like an appropriate question, but I can't answer it. [01:15] I've been giving out ubuntu cds and dvd telling ppl they could try it without installing but this particluar issue is becomming a problem, I get why it doesnt have ati or nvidia driver , the non FOSS thing, but I started to wonder why not just vesa in those case, that is what get's instaled anyway [01:16] Pelo: what does it do currently? [01:17] LaserJock, is just fails [01:17] hmm, I think it's supposed to fall back to vesa [01:17] ifyou try the live cd or live dvd on a comp with either an nvidia or an ati videocard it just doesn,t recognise it [01:18] LaserJock, during the install yes, [01:18] well in text mode instal anyway it will instal the vesa driver [01:18] mind you, I'M starting to wonder if it is not supposed to be fixed in gutsy [01:19] I dont, hae a nvidia card myself so I don'T have this particualr problem but friends have , and there are a lot of ppl comming into the support channel with this issue as well [01:20] Pelo: I wonder if it's just certain cards or something [01:21] LaserJock, I think some older cards might work but they seem to be the exception [01:21] any way I have to go, consider it a suggestion for the hardy live cd if nothing else [01:22] thanks for your time [01:22] thanks for stopping by === tonyy is now known as tonyyarusso [03:20] hello [03:22] Why did my spec, https://blueprints.launchpad.net/ubuntu/+spec/dapper-to-hardy, not get excepted and this one, https://blueprints.launchpad.net/ubuntu/+spec/lts-upgrades, did? They accomplish the same thing. [03:23] I think it has something to do with how I worded it, but not sure. I never submitted a spec before. [03:23] Why did my spec, https://blueprints.launchpad.net/ubuntu/+spec/dapper-to-hardy, not get excepted and this one, https://blueprints.launchpad.net/ubuntu/+spec/lts-upgrades, did? They accomplish the same thing. [03:23] I think it has something to do with how I worded it, but not sure. I never submitted a spec before. [03:27] cellofellow: repeating yourself is not necessary... [03:28] cellofellow: the reason lts-upgrades was accepted is that it's the one that includes the link to the full specification with design information, https://wiki.ubuntu.com/LTSUpgrades [03:28] it appears that the lts-upgrades blueprint was also created 5 months earlier... [03:31] slangasek: sorry about the repetition, I just saw knew people in the channel and wanted them to hear too. [03:31] slangasek: I couldn't find dates in the Blueprints stuff. [03:32] cellofellow: the dates are shown under "lifecycle" on the left [03:33] so, what's some advice for spelling out specs in the future === tonyy is now known as tonyyarusso [03:33] (I did try to find one that was like this before submitting. I guess I just didn't search the right terms.) [03:35] cellofellow: well, in general terms, communicating with the developers who are going to have to do the work to make it happen is an important first step. :) For many specs, this happens at UDS where the developers are face-to-face === asac_ is now known as asac === j_ack_ is now known as j_ack [05:22] * lamont looks around for a package that delivers both python2.4 and 2.5 .py files [05:22] site-packages type, eh? [05:22] lamont: python-pyinotify? [05:22] kewl [05:22] hmm, in general packages aren't supposed to do that are they? [05:23] IRC works even better than google for somethings... [05:23] No, in general packages are supposed to ship .py for as many python versions as possible? [05:23] IRCpedia [05:24] Oh. Except they won't actually be shipping different .py files in the deb, the postinst script will be doing byte-compiling for all the installed python versions. [05:24] well, they should ship .py and let python-central/python-support handle versions [05:24] Heh. We converge on the answer from different directions :) [05:29] LaserJock: except that if you want pycentral to handle versions for you, you still have to build 2.4 and 2.5 [05:29] as I've been learning. [05:29] why? [05:30] doko told me that if I want 2.5 versions, then I need to build them.. is that not the case> [05:30] package currently delivers python2.4/site-packages/$mumble... [05:30] hmm, that's weird [05:30] are you telling me that 2.5 will magically appear? [05:30] I thought so [05:30] es [05:30] bleh [05:30] you tell pycentral what versions you want [05:30] it then in the postinst symlinks and byte compiles appropriately [05:31] lifeless: and deliver .py files where? [05:31] if you ahve a C extension they get built for the python version specifically. === imbrando1 is now known as imbrandon [05:31] * lamont notes that pyinotify specifically builds both versions [05:31] that's weird [05:32] I don't know why it would do that [05:32] unless it's legacy [05:32] lamont: dpkg -L python-gmenu [05:32] maybe it cloned from another package like I just did from it?? [05:32] hrm... OK. [05:32] lamont: pyinotify probably has a C extension in it [05:32] * lamont tweaks his source again [05:33] hrm... can I put wild cards in ${package}.files, I wonder.... [05:33] LaserJock: Yeah. It's the C extension. It has to be built against each python version. [05:34] LaserJock: Or you get the pyinotify bug I fixed, where you could use it in 2.5 but not in 2.4 :) [05:36] * lamont can hardly wait to see if there are any .so files in the build [05:37] * RAOF thought ${package}.files was generally generated during package build? [05:37] RAOF: in my experience, I've generated it myself [05:38] as in it's checked into source control [05:38] Maybe I was thinking of something else. [05:42] lamont: Some of the automated package checkers say it's deprecated (although it may still be required for your packages) [05:45] given that dh_movefiles uses it, and I use dh_movefiles...... :-) [05:47] Oldschool [05:48] lamont is deprecated ;-) [05:50] feh [05:50] you kids always creating new crackful ways of doing things... [05:50] why when I was a kid..... :-) [05:50] did you use CDBS? [05:52] * persia notes that dh_movefiles is more new-fangled than just calling install lots of times. [05:53] LaserJock: hell no. [05:53] CDBS is a maze of twisty mess [05:54] the only good thing about it is that it's miles less crackful than DBS [05:54] then again, when I look at a makefile, I want to look at a makefile [05:54] I also like it because it tends to reduce the use of debian/rules as a "bash script" [05:54] not an include of something that takes side-effects from a number of strange variables in the top level makefile [05:56] LaserJock: I expect that if I adopted a package using CDBS, it'd not be using CDBS sometime shortly thereafter. (for DBS, make that certainly wouldn't be :) [05:56] and these days, ditto for dpatch/quilt/etc. [05:56] if it's a really easy package where you can do a 2-line debian/rules it's not bad [05:57] but I tend to stay away from it [05:57] first I'd have to learn CDBS. and that would tend to make me drop in a trivial example debhelper makefile and be done. [05:57] seems like if I run into some problem it's always "solved" by some totally cryptic rule [05:57] my usual approach to fixing FTBFS packages with CDBS is to pester people who understand CDBS. [05:58] (since it's someone elses package, and ripping CDBS out to fix an ftbfs is kinda, um, rude. :) [05:58] heh, how about adding CDBS to fix a ftbfs? :-) [05:59] lamont: not a fan of dpatch? [05:59] I'd rather see my code as it will build. dpatch isn't so bad, other than the pain of not seeing exploded/patched code while you're working on it. [06:00] SCM belongs in SCM. implementing SCM in dpkg is kinda silly [06:00] so what do you do? [06:01] make upstream fix everything so you don't need patches? :-) [06:01] * lamont has the, uh, privilege of working on the debian-packaged kernel for his day job. That package boasts the ability to produce any earlier version of the package from the source package. [06:01] LaserJock: git clone git://git.debian.org/~lamont/bind9.git [06:01] that'd be one of my packages [06:02] if you want to see the patches, go to the SCM. if you want to build the source, there's this nice monolithic patch in diff.gz. :-) [06:03] right [06:03] I was using dpatch before (when my packages were all in cvs and arch and old bzr). When I switched everything to git, I retired my dpatch usage. [06:04] not to bzr? [06:04] and adding cdbs to fix an ftbfs would be equally rude.... and very unlikely to be adopted by the debian maintainer (unless he told you to do it...), so your patch becomes unwieldy [06:04] I deal with git all day. [06:04] and bzr infrequently. [06:05] makes sense [06:05] and bzr and I didn't understand each other wrt repositories at the time. so git won. [06:05] I expect that bzr has everything I care about now, so it's just a question of familiarity [06:06] and bzr checkouts have historically caused me pain in my bandwidth meter. I expect that's improved now, too. right lifeless? [06:06] * lamont has no real recent bzr history [06:07] lamont: how do you handle a new upstream release when the whole source is in git? [06:07] LaserJock: in the ideal case, I say 'git fetch origin' (see util-linux) [06:07] :) [06:07] well, yeah [06:07] I switched from bzr to git a while ago. Subjectively git seems faster (i haven’t done actual benchmarking, though) and i just love how it handles branches as opposed to bzr. [06:08] but that's more of a corner case at this point [06:08] in the less ideal case, I smash the new upstream in as one (or maybe more if I'm in a good mood) commits into either the upstream branch, or upstream git repo [06:08] do you keep debian/ in a separate branch? [06:09] lamont: Do you use pristine-tar, or just pull the upstream externally? [06:09] I learned about ‘bzr switch’ after the fact, but it only comes a few steps closer to how nicely git handles them IMHO. [06:09] hrm.. of 9 packages: 1 in git upstream, 1 where I _am_ upstream (git), and 1 with published upstream cvs, 1 with unpublished upstream cvs, and the rest are tarball only uploads [06:10] LaserJock: debian exists only in the debian branch, which is derived from upstream. [06:10] ok [06:10] git branches are decended from things, not separate source trees. [06:10] so it makes sense (in some way) to have two repos for upstream and debian, or one repo for the combination. [06:10] different source on different branches is contrary to the design. [06:10] at least as far as I understand it [06:11] persia: pristine-tar? [06:11] * persia goes to find a pointer to docs [06:11] if there's an upstream SCM, I pull from it for my tree. Where there's not an upstream SCM, then the upstream tarball gets to get unpacked and committed. [06:11] pristine-tar is joeyh's "recreate tarballs from repos" trick [06:11] ah [06:12] given that gzip tends to give a different hash everytime I create a tarball, I just use the upstream tarball. [06:12] which I'm still waiting to hear of a naming convention for, that's recommended for use with things like svn-buildpackage [06:12] known to work with git, but I didn't know if anyone other than joeyh actually used it. [06:13] lamont: it has an extension that's supposed to be usable for recreating tgz as well [06:13] lamont: git://git.kitenet.net/pristine-tar/ [06:13] I may have to look at that. [06:15] so the problem is that often the tarball downloaded from upstream has a different md5sum than a tarball created from the identical files in a SCM? [06:16] LaserJock: Yes, and moreso that the gz of the tarball has a different checksum as well. [06:16] OTOH, I had a nice chat today with a coworker about how to have an upstream branch, from which was derived a debian branch, and package a .orig.tar.gz and a diff.gz that delivered a debian/patches/foo and friends, so that the build process could untar upstream/tarballs/*.gz and patch them, and such [06:17] * lamont throws nmap at the grinder again, just for good measure. I might actually manage an experimental upload tonight [06:18] ScottK: pinentry is your merge - I just did a trigger rebuild... [06:18] OTOH, no reason I can't do it [06:19] lamont: It's late there: you may be waiting ~6-8 hours for a response [06:19] hmm, jbailey seems to be sending me lots of pharmaceutical offers ;-) [06:22] feh. he can't stay up until 1:30 AM just to talk to me? [06:22] OTOH, bed time for me too... alarm clock in 5.5 hours. [06:22] Has anyone noticed compiz hanging, like, all the time, after an update a couple of days ago? [06:22] ion_: I thought that was it's purpose. :-) [06:22] I’ll take a look at LP bug reports. [06:23] (was that my out-loud voice?) [06:23] :-) [06:25] dh_installman -pzenmap docs/zenmap.1 [06:25] so why does zenmap.1 wind up in the nmap package instead, I wonder. [06:26] maybe CDBS hear your comments earlier and switched out dh_installman with it's own, more nefarious, version [06:27] heh [06:28] where are the nightly build ISOs at for Hardy? [06:28] cdimage.ubuntu.com/daily or so [06:28] * lamont workraves while the build runs [06:29] lamont: is the script available that starts this nightly ISO build? [06:29] ?? [06:30] what software do they use to create the nightly builds or do they just have scripts as cron jobs? [06:30] the script that starts the build is run either from cron, or manually, on some machine in the data center. [06:31] and, iirc, that stuff is checked into bzr somewhere. [06:31] the livefs is built by the package livecd-rootfs, iirc [06:31] and that's in the archive [06:31] choudesh: what are you wanting to do? [06:32] LaserJock: oh sure, remove the mystery... [06:32] LaserJock: setup a nightly build iso repo for a ubuntu derivative [06:32] * lamont is trying to figure out if he wants someone to kick a daily build, or if he wants to build a custom CD [06:32] lamont: I was figuring the later [06:33] choudesh: you might want to check out https://code.launchpad.net/~kamion/ubuntu-cdimage/mainline [06:33] yeah... so he wants the script that builds the ISO, not the script that starts it... :) [06:33] ahh - that is where it is. [06:33] thanks. [06:33] which is just me having challenges parsing english tonight [06:33] choudesh: and that looks to be the right repo [06:34] choudesh: make sure to look in config/devel , it has more code to look at [06:34] ight [06:34] thanks guys [06:39] LaserJock: I wasn't remembering where kamion kept it... thanks [06:40] np, I did some debian-cd/ubuntu-cdimage patching for Edubuntu and learned about that [06:41] * lamont needs to clean that code up for non-alternate ISOs for hppa/ia64 [06:41] it currently has a "FIXME" for those... and they're not likely to clear the cutline any release soon [06:42] unless I either do it myself, or find someone else to badger into it. [06:55] * lamont sleeps. [07:23] Hi all! [07:24] is this where I should post for guidance with getting a blueprint accepted? (https://blueprints.launchpad.net/ubuntu/+spec/no-mono-by-default) Need to know what to do next [07:26] gQuig1: generally you want to have some discussion around a spec [07:26] gQuig1: I suspect there will be lots of discussion around that subject [07:26] probably a good place to get feedback would be the ubuntu-devel-discuss mailing list [07:27] LaserJock: has been on forum, ok.. I'll post to the mailing list [07:27] http://ubuntuforums.org/showthread.php?t=634805 [07:28] I'm aware of the thread :-) [07:29] gQuig1: you might want to try to come up with some more info for implementation, like what you're going to propose to replace the current mono apps [07:32] That's really only F-Spot.. [07:32] and gThumb does something very similar to F-Spot [07:34] (https://blueprints.launchpad.net/ubuntu/+spec/hardy-reducing-duplication for more info) [07:34] but you are right, I need to make my blueprint clearer in that regard [07:36] gQuig1: right, but if you're proposing to remove software you need to have good replacements so that's gonna be key to your argument [07:37] LaserJock: if the apps in question already have their primary functionality covered in other default applications? [07:37] well, the argument will be that they aren't covered [07:38] Tomboy != StickyNotes, Gthumb != Fstpot for instance [07:38] FSpot [07:40] what critical functionality is not in StickyNotes and is in Tomboy? [07:41] gQuig1: quite a bit actually [07:42] I can see F-Spot and Gthumb being more similar than Tomboy and StickyNotes [07:42] the only thing I know of is WikiLinking [07:42] Tomboy is killer [07:42] really? I had thought the opposite [07:42] syncing, exporting to HTML, and linking is good [07:43] to properly do this, I am going to have to do in-depth reviews of all the apps in question [07:43] that would be a good idea [07:43] a feature comparison would be good [07:44] I think arguments of "we can get the same functionality without the overhead" will go much further than "Mono is evil" [07:44] definitely [07:47] Good morning [07:47] ah pitti [07:47] morning [07:47] Hi [07:47] pitti: I have a question/request for you [07:47] Now my ISP offers native IPv6 connectivity for free, yay! [07:48] pitti: I need goffice0.4 un-blacklisted [07:48] good night all. thanks LaserJock [07:48] Morning pitti! :) [07:48] gQuig1: night [07:48] LaserJock: ah, can we sync from Debian now? [07:48] hey warp10! back again? how was the moving? [07:48] pitti: for some reason Debian put it into oldlibs, the package is only 1 month old [07:49] pitti: goffice0.4 was created to provide a lib for packages that use the stable version [07:49] gnumeric uses the unstable version 0.5 so that's what goffice is at [07:49] pitti: yep, I am back! Unfortunately I lost the fight against that hated usb modem :-S [07:50] pitti: does that make sense? [07:51] LaserJock: and you need 0.4 for something? [07:51] yep [07:51] gchemutils/gchempaint use it [07:51] I'm waiting on goffice0.4 to merge them [07:57] alright, I'll sync it then [07:57] ok, thank you very much [07:57] chemists around the world will thank you :-) [08:07] good morning === greeneggsnospam is now known as jsgotangco [08:08] Good whatever. [08:15] Greetings everybody! [08:18] moin [08:20] heya dholbach [08:21] hey mdke [08:21] dholbach: colin asked me yesterday to have a look at updating gnome-user-docs; I've created an ubuntu-hardy branch in Launchpad, which is the ubuntu-gutsy branch, merged with Gnome svn. I don't know whether there is anything we should merge from Debian [08:23] mdke: slomo did the update in debian - you could either check out what was changed in debian or ask him if it's worth [08:23] dholbach: ok, I'll try and do that [08:24] mdke: great [08:25] mdke: just file a upload request bug and subscribe ubuntu-main-sponsors once you're done [08:25] dholbach: thanks, I will. [08:25] rock on [08:26] Would a core dev be so kind as to sponsor bug 172310 please? Gnome-orca needs it to function. Thanks in advance. [08:26] Launchpad bug 172310 in brltty "Please upload merged brltty 3.9-4ubuntu1" [Undecided,New] https://launchpad.net/bugs/172310 [08:38] dholbach, mdke: i only updated it to the newer upstream version which had many updates from the ubuntu package it seems... [08:40] slomo: the upstream version only has added translations. There are a few places where the English text differs in Ubuntu from upstream, but that's because Ubuntu's desktop is a little different to regular Gnome === \sh_away is now known as \sh [08:42] slomo: so no changes to the packaging I need to worry about? [08:43] mdke: nope [08:45] slomo: thanks, that's very helpful :) === imbrando1 is now known as imbrandon [09:10] morning [09:10] pitti: please give-back: centerim. Thanks [09:10] geser: good morning! done [09:44] pitti, hi [09:45] pitti: please give back kdepimlibs [09:46] * pitti just read 'kdepimplibs' and thought "WTH..." [09:46] hi tkamppeter [09:46] Riddell: done [09:47] pitti, it is about bug 172264 [09:47] Launchpad bug 172264 in ghostscript "[Gutsy SRU Request] Ghostscript in Gutsy and Hardy is not able to print encrypted PDFs out of Adobe Reader 8.1.1" [High,Fix released] https://launchpad.net/bugs/172264 [09:47] pitti: kdepimplibs is for KDE 4 :-P [09:47] thanks pitti [09:47] tkamppeter: the upstream bug didn't enlighten me sufficiently, so I'd like to ask you about some insights [09:48] It is really strange that this problem gets fixed by simply changing the size of a buffer, for me a buffer size change should only influence performance. [09:48] tkamppeter: right, and that's what makes me nervous [09:49] as if it wouldn't work with the n+1st test case, and/or break PDFs which work fine ATM [09:49] Yes it can easily happen that this fix only helps on some files [09:50] pitti, perhaps you should ask on the gs-devel@ghostscript.com list or on the #ghostscript IRC channel. [09:52] tkamppeter: can you please ask on the upstream bug? [09:53] (sorry, swamped) [10:05] pitti, I will talk with them on IRC. === pitti_ is now known as pitti === pedro is now known as pedro_ [11:05] pitti: hal broke my compile http://paste.ubuntu-nl.org/47814/ [11:05] pitti: it that caused by your upload yesterday? [11:06] Riddell: compile? [11:06] Riddell: very well possible, sorry about that; where does that happen? [11:07] pitti: it happened in my compile of kdepimlibs in the buildds, but presumably any fresh hal install will fail [11:07] BenC: :( [11:07] Riddell: can you please file a bug about this and subscribe me? I'll track this down this afternoon [11:14] pitti: bug 175525 [11:14] Launchpad bug 175525 in hal "hal fails to install" [Undecided,New] https://launchpad.net/bugs/175525 [11:14] .win 17 [11:14] Oops. [11:15] Riddell: thanks [11:16] Riddell: please just add the failed builds to that bug, I'll give them back once it's fixed [11:17] ion_: which video card? [11:19] ion_: and if you're only getting a crash every 10 or so minutes, you're lucky... [11:19] * Hobbsee wonders if hte old compiz versions still install, and crash less. [11:19] 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4800 SE] (rev a1) [11:19] The proprietary :-( driver. [11:20] * Fujitsu managed to fully log in once out of a few times. [11:21] urg [11:22] I had while read; do pkill -9 compiz; done running in the virtual console for a while, until i got fed up and switched to metacity. :-P [11:23] It didn’t help that X insists on immediately switching back when i hit ctrl-alt-F1. [11:24] that's consolekit [11:25] Hobbsee: talking about the : compiz eats 100% of my CPU and makes the whole session to freeze ? :) [11:25] stgraber: yup [11:26] i'ts really getting overrated. [11:26] I had this one after the I updated to the new compiz on my laptop (Intel card) [11:26] I'm currently running metacity because of it [11:26] yup. [11:26] same here [11:26] it's just not worth crashes every few minutes [11:26] * Fujitsu too. [11:26] Yay for running dev releases. [11:27] we have to test and debug, no ? :) As soon as I don't have any libc/kernel/xorg issue I'm happy to run the dev release [11:28] running metacity instead of compiz isn't really a problem, just a bit annoying :) === dholbach_ is now known as dholbach === pedro is now known as pedro_ === \sh is now known as \sh_away === cjwatson_ is now known as cjwatson [12:38] * lamont yawns, waves === Hobbsee_ is now known as Hobbsee [12:56] hey lamont [12:56] hi Hobbsee [12:59] hey lamont. [13:00] lamont: what's the plan with your 5 outstanding merges? will you do them or shall we spread them amongst the distro team? [13:01] lamont: db4.2 is a sync, doing now [13:01] pitti, before you nag me as well, ltspfs will see a new upstream before feature freeze and we package that independently from debian ... [13:02] ogra: I won't, but thanks :) [13:02] :) [13:02] I'll file the sync request for e2fsprogs in a minute.. [13:03] soren: ah, is it? [13:03] That's my conclusion, yes. [13:03] soren: I looked at it a while ago, and Ian's patch wasn't directly applied [13:03] No, it wasn't. [13:03] might be that it was solved in a more general fashion [13:03] But Ted T'so implemented a different workaround that looks more correct. [13:03] ah, cool [13:04] Ian's patch made e2fsck ignore mount times in the future. Ted's patch add a new configurable to e2fsck.conf that can be set to allow mount times (and inode times) to be up to 24 hours in the future to account for differences in timezone settings. [13:05] ...and he even took care to enable it on Ubuntu and not in Debian. [13:05] * persia notes that there are actually 25 timezones [13:06] ScottK: would you mind merging pinentry? lamont only touched it for a rebuild, and you actually seem to care about that package [13:06] lamont: Could you add lpia to the list of archs for which we build syslinux? [13:07] lamont: are things like http://merges.ubuntu.com/libt/libtool/libtool_1.5.24-1ubuntu1.patch still necessary? hppa should have caught up now with building? [13:08] pitti: I need to work with doko and get java bootstrapped... hence the stalling on libtool, gettext, and such [13:08] s/bootstrapped/bootstrapped on hppa/ [13:08] lamont: ah, so the plan is to do that and then drop the delta [13:08] right [13:08] cool, thanks [13:08] lamont: Or is there someone more appropriate I should be asking? [13:09] and yeah, pinentry would be cool if ScottK did it, otherwise I'll just take it cold if no one beats me to it. [13:09] soren: I'd be the right victim [13:09] lamont: Cool. [13:09] or infinity or elmo [13:09] committed. [13:10] soren: fwiw, tradition is to send email to the 3 of us [13:10] lamont: Oh, I see. [13:10] that way we can silently ignore stupid requests together. :-) [13:10] Hah! [13:10] Well, up until about a week ago I had no idea such a thing as PaS existed. :-/ [13:11] "please make this change. here's a copy of the irc log where the maintainer agreed with me. .... " I think it would be better to get the port done" ...' [13:11] yes, well. [13:11] pitti: I can try and take a look at it today or tomorrow, but all I did was make sure it met your requirements (not build the GTK version) for Main. [13:12] ScottK: I see; well, please let us know if you don't care/don't have time [13:13] pitti: I'll try to find time today, If not I'll give you a ping. I hadn't noticed it as I just search for my name on the merges list. [13:13] ScottK: thanks [13:13] lamont: Do I need to reupload to have a build record created for lpia or will that magically happen somehow? [13:14] it should be automagic [13:14] lamont: Cool. [13:14] lamont: Thanks very much. [13:14] ISTR that LP autosyncs PaS every so often (15min??) [13:14] so if there's no build record in 90 min or so, then bitchslap #launchpad. :0) [13:14] well, gently... so they can tell you who to really pester. [13:14] in any case, uploads should not be required [13:15] soren: try #soyuz instead [13:15] lamont: Ah, it's just a direct sync from Debian? [13:16] lamont: Or what do you mean by "autosync"? [13:16] yep [13:16] we share the file [13:16] which has occasionally been interesting.. [13:17] lamont: How so? [13:17] lamont: Well, adding lpia might have been a bit controversial, I guess? [13:18] my favorite ever was a powerpc kernel package that was ": powerpc i386" [13:18] with a comment of "# I feel dirty - lamont" === ember_ is now known as ember [13:25] lamont: Erm.. Ok. :) [13:26] it built an arch-all package... [13:26] hmm, the devscripts update in debian adds a libfile-desktopentry-perl build-dep ... its apparently used for creating .menu files from .desktop .... do we drop that build-dep or do we want that lib in main ? [13:26] lamont: Oh, right. [13:30] lamont: getting java bootstrapped is easy; getting a working java bootstrapped is more difficult ;-p [13:45] doko_: I'm into option #2. :-) [13:45] OTOH, you get your unaligned loads/stores. [13:47] lamont: gcj-4.2 doesn't require java to build; that should be buildable on its own. then you face a problem building ecj and gjdoc. suggested workaround: don't build from source, but build-depend on the just built libecj-java, and build from bytecode. The same should be done by gjdoc after splitting out an libgjdoc-java [13:49] doko_: that almost made sense. [13:50] I understand the words, I'm just not sure how they translate into actions... it might help if I had any clue about java... :( === doko_ is now known as doko [13:51] what I need is a series of steps to get me a set of debs that I can use to build gcj-4.2, ecj, and gjdoc from source, and then use those binaries to build all 3 all over again [13:52] lamont: continuing on private channel ... [13:52] ok. thanks [14:08] slangasek: Around yet? === cprov is now known as cprov-lunch [14:23] Hi all! [14:40] pitti: May I request a sync for libpcap-ruby? [14:40] warp10: sure, if you checked it; please file a sync bug [14:43] pitti: done. Bug 175564 [14:43] Launchpad bug 175564 in libpcap-ruby "Please sync libpcap-ruby 0.6-7 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/175564 [14:45] warp10: ack'ed, thanks [14:45] pitti: :) === iceman_ is now known as iceman === tkamppeter_ is now known as tkamppeter [15:13] What are you guys doing to the Vcs-* headers when merging? [15:14] I've been renaming them to XSBC-Original-Vcs-blah.. [15:14] I don't change those [15:15] Oh, really? [15:15] On purpose? [15:15]