bryce_ | calc: interesting, I didn't know about that change | 00:08 |
---|---|---|
bryce_ | calc: on the plus side, that may result in a reduction of duplicate tasks (I get a lot of tasks that I assign away from xorg, that grow another xorg task after a while - I finally just wrote a script to detect and eliminate these) | 00:09 |
calc | ah | 00:11 |
=== robbiew is now known as robbiew-away | ||
relnev | what do I need to do to build a replacement snd-usb-audio.ko (a kernel module found in the linux kernel source) that i can load without having to rebuild the kernel and reboot? | 00:38 |
=== bryce_ is now known as bryce | ||
wgrant | calc: It was causing problems because people would click on a bug link in an email after somebody had reassigned a task. They'd then immediately click on the button to recreate the original task. You were always meant to use 'Also affects (project|distribution)...' normally, anyway. | 00:41 |
calc | wgrant: ok | 01:16 |
lifeless | is anyone else seeing oddly high load in jaunty/karmic? | 01:20 |
lifeless | Mine is constantly 10 | 01:20 |
lifeless | or 11 | 01:20 |
lifeless | but no IO, plenty of cache, cpu at 1% use | 01:20 |
lifeless | oh nevermind, it'll be a stalled sfs process | 01:20 |
=== freeflyi1g is now known as freeflying | ||
=== robbiew-away is now known as robbiew | ||
dholbach | good morning | 06:40 |
robert_ancell | any karmic users here? What is the contents of your /usr/include/linux/errno.h? | 06:58 |
robert_ancell | mine points to asm/errno.h which does not exist | 06:58 |
lifeless | robert_ancell: you're missing libc-dev or something I suspect | 06:59 |
lifeless | or being hit by a toolchain transition | 06:59 |
lifeless | <- guessing | 06:59 |
hyperair | there are ftbfs errors regarding that particular header | 06:59 |
robert_ancell | hyperair: ouch | 07:00 |
hyperair | yeh ouch indeed. | 07:00 |
hyperair | gnomeui is having issues | 07:00 |
hyperair | rather, stuff depending on gnomeui | 07:00 |
robert_ancell | hmm, I was going to use the PPA but that will have the same problems right? | 07:01 |
hyperair | indeed. | 07:02 |
dholbach | robert_ancell: try asking the guys in #ubuntu-kernel - they should know what's going on | 07:02 |
dholbach | ... even if I suspect that most of them are sleeping right now | 07:02 |
robert_ancell | dholbach: yeah, it's friday afternoon. I figure it will be fixed by monday :) I'll go drink beer instead | 07:03 |
ajmitch | dholbach: it's a known issue, Stuff needs to be done on the buildds I heard :) | 07:03 |
dholbach | ajmitch: oh wow | 07:03 |
StevenK | It's a findutils bug that impacted on the linux-libc-dev binary package | 07:06 |
geser | robert_ancell: it's bug 373214 | 07:30 |
ubottu | Launchpad bug 373214 in findutils "/usr/include/asm/* is not present in linux-libc-dev" [Critical,Fix released] https://launchpad.net/bugs/373214 | 07:30 |
robert_ancell | geser: thx | 07:30 |
lifeless | robert_ancell: oh right, you're in aus:) | 07:33 |
lifeless | beer sounds good about now ;) | 07:33 |
robert_ancell | lifeless: it's rapidly approaching beer o'clock | 07:34 |
* robert_ancell rubs it in for those who have a day to go | 07:34 | |
lifeless | indeed. and we fly 10000 to actually meet soon :P | 07:34 |
Hobbsee | slangasek: I did not. | 07:39 |
slangasek | Hobbsee: right - Riddell confessed :-) | 07:40 |
Hobbsee | slangasek: oh, fair enough. I'm just looking through my highlights ;) | 07:40 |
Hobbsee | slangasek: I hope you didn't make him walk the plank? | 07:40 |
slangasek | no, I just demoted him to multiverse temporarily | 07:41 |
Hobbsee | haha | 07:41 |
Hobbsee | oh dear | 07:41 |
pitti | Good morning | 07:42 |
pitti | slangasek: libltdl-dev> I didn't | 07:42 |
pitti | doko: nice! is it in c-mismatches? | 07:42 |
StevenK | slangasek: Along with all of KDE? | 07:45 |
slangasek | hah, twitch :) | 07:45 |
ScottK | It would improve the quality of translations. | 07:45 |
* StevenK grins | 07:46 | |
* pwnguin gets to attend a public meeting about garmin's use of linux | 07:50 | |
pwnguin | anyone have a question they want answered? | 07:50 |
Hobbsee | pwnguin: apart from the obvious ones? No. I'd love to know what the answers to the obvious questions are, though. | 07:51 |
=== tkamppeter_ is now known as tkamppeter | ||
Hobbsee | if there's a URL from it | 07:52 |
pwnguin | i doubt it will be publicly recorded | 07:52 |
Hobbsee | darn | 07:52 |
pwnguin | but what are the obvious questions? | 07:53 |
Hobbsee | pwnguin: which devices do they use linux in, what are their future plans with linux and their devices, whether people will be able to mod them / write plugins etc for them, etc, etc, etc | 07:54 |
pwnguin | Hobbsee: http://developer.garmin.com/linux/ i'll let you know if they mention a device that isn't one of those | 07:57 |
Hobbsee | pwnguin: ah, sweet! | 07:58 |
=== mkorn is now known as thekorn | ||
=== mpt_ is now known as mpt | ||
=== dpm_ is now known as dpm | ||
pitti | anyone got a Sony laptop here? | 10:35 |
amitk | ping manjo when he gets online in a few hours if you don't find anybody | 10:37 |
amitk | pitti: ^ | 10:37 |
pitti | amitk: ah, thanks | 10:37 |
pitti | directhex: congratulations for your motu badge! well done! | 10:42 |
pitti | cjwatson, smb: hm, why does the new linux upload bump abi? | 10:42 |
pitti | if it's just a rebuild? | 10:42 |
smb | pitti, because i did not found/look far enough/trust the last abi files | 10:43 |
directhex | pitti, thanks. i still need to bug you over stuff in main though ;) | 10:43 |
* cjwatson has no idea but doesn't care enough to worry | 10:43 | |
pitti | smb: fair enough; I was just curious | 10:43 |
cjwatson | ABI changes are cheap enough at this point | 10:43 |
smb | pitti, So I bumped abi to be sure it passes the abi checks | 10:43 |
pitti | yeah, we just need to watch out for NEWing | 10:43 |
cjwatson | though it does mean NEW, but meh, lost in the noise of having to deal with the whole thing manually | 10:44 |
pitti | thanks for getting this fixed | 10:44 |
dholbach | cjwatson, smb: YAY! :) | 10:44 |
* TheMuso suspected there would have been an ABI bump for ports also, but avoided enabling checks since all ports kernels are not yet setled. | 10:46 | |
TheMuso | anybody else getting LP timeouts? | 10:46 |
pitti | intermittently, yes | 10:46 |
* TheMuso can't seem to view source package pages, i.e lp.net/ubuntu/+source/linux | 10:47 | |
TheMuso | hrm working now | 10:47 |
TheMuso | anyway I'm off for the evening, will check in tomorrow morning in case anything is needed ports wise, but I think things should be fine. | 10:50 |
directhex | had intermitent issues with LP since last night. check /topic in #launchpad | 10:51 |
Laney | What's up with these "asm/socket.h: No such file or directory" errors? Seen them failing a few builds now. | 10:54 |
TheMuso | Laney: linux-libc-dev breakage. | 10:54 |
james_w | bug 373214 | 10:54 |
* TheMuso thinks a /topic tweak is in order. | 10:54 | |
ubottu | Launchpad bug 373214 in linux "/usr/include/asm/* is not present in linux-libc-dev" [Critical,Fix released] https://launchpad.net/bugs/373214 | 10:54 |
Laney | yes, it seems to be affecting builds all over the shop | 10:55 |
Laney | james_w: ta | 10:55 |
amitk | TheMuso: More correctly, findutils breakage that caused a linux-libc-dev | 10:56 |
amitk | breakage | 10:56 |
TheMuso | amitk: yes, but linux-libc-dev being broken is enough for most I would think. :) | 10:56 |
TheMuso | anyway, really off. | 10:57 |
apw | on an upgrade would i expect to be seeing linux-generic being uninstalled? | 10:59 |
apw | (on jaunty) | 10:59 |
slangasek | are you using jaunty-proposed? | 11:00 |
apw | yes using -proposed | 11:01 |
slangasek | apw: then it's not surprising; let me check whether the binaries are all built now and ready to be accepted from NEW | 11:03 |
apw | slangasek, how would lacking binaryies trigger a meta to be removed? | 11:03 |
slangasek | the meta packages are currently uninstallable in -proposed, so if you're using the package manager in a way that tells it it's ok to remove packages... | 11:04 |
apw | i am using it in the default way, it said a partial update was the only way forward, and i said yes | 11:04 |
apw | as encouraged to do by the defaults | 11:04 |
slangasek | anyway, lrm/lbm accepted now, which should fix linux-generic with the next publisher cycle | 11:05 |
apw | (with my behaving like a non-clued up user hat on) | 11:05 |
apw | i assume once i had lost linux-generic i wouldn't have got it back... sounds problematic for those users | 11:05 |
slangasek | yeah, I've never quite understood why update-manager calls that a "partial" upgrade; half the time it fails to find a solution at all for me, whereas if I click 'close', it lets me do a real, partial upgrade | 11:05 |
apw | yeah ... i think there is some kind of bug in there offering that to normal users without a fight | 11:06 |
=== cjwatson changed the topic of #ubuntu-devel to: most builds broken due to bug 373214, being fixed | Archive: open for development! | Ubuntu 9.04 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | ||
cjwatson | (obviously if your build doesn't involve compiling anything then it won't fail. I don't care enough to fine-tune the topic) | 11:11 |
smb | slangasek, Were the meta package in error or did something else go wrong? | 11:14 |
smb | slangasek, Have to be off now, but if there is anything that should get back into the linux-meta packages, let me know | 11:16 |
slangasek | smb: no package errors; we just needed some jaunty-proposed NEW processing, which is done now | 11:17 |
smb | slangasek, Ah, ok. Thanks | 11:17 |
apw | cjwatson, i wonder if you would have some minutes to talk about that kexec reboot bug (bug 251242) today | 11:29 |
ubottu | Launchpad bug 251242 in kexec-tools "Always kexecs on shutdown/reboot" [Medium,In progress] https://launchpad.net/bugs/251242 | 11:29 |
cjwatson | apw: ah yes. I have a PDR panic day today, but have queued up that bug to look at the debdiffs therein | 11:34 |
apw | cjwatson, heh know _that_ panic ... no worries if busy it'll wait | 11:34 |
=== ember_ is now known as ember | ||
=== lamont changed the topic of #ubuntu-devel to: most builds broken due to bug 373214, being fixed - buildds manual | Archive: open for development! | Ubuntu 9.04 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | ||
=== azeem_ is now known as azeem | ||
=== freeflyi1g is now known as freeflying | ||
geiseri_ | hi i am having problems creating my own allternates installer. it gets pretty far but bombs out with an error of "Couldn't find task standard" | 13:43 |
geiseri_ | is there anyone who would know more about this? google was not very helpful | 13:43 |
geiseri_ | i think i may have missed a step, but im not sure where... | 13:44 |
astrolite | any developers of ubuntu-vm-builder here? | 13:52 |
cjwatson | geiseri_: it's looking for sections with "Task: standard" in the Packages file - if you're missing those then perhaps you generated your own Packages file but didn't use the override file from archive.u.c/ubuntu/indices/ as input? | 13:53 |
geiseri_ | yes, i created my own... but i did not include the indices. | 13:55 |
cjwatson | that'll be your problem then | 13:55 |
geiseri_ | i can download that or do i need to generate that if i am using my own package set | 13:55 |
cjwatson | start out with the downloaded ones, generating your own is a bit complicated | 13:56 |
geiseri_ | okay | 13:56 |
cjwatson | you may need to edit them a bit | 13:56 |
geiseri_ | okay | 13:57 |
geiseri_ | ill start there | 13:57 |
geiseri_ | what files will i need? all of them fro my dist? | 13:58 |
liw | astrolite, #ubuntu-virt might be a better place to find those people | 14:00 |
astrolite | liw: ok, thanks! | 14:00 |
geiseri_ | cjwatson: where would be the documentation no how to generate my own indices files? | 14:07 |
geiseri_ | or is it easier to include the tasksel in my Packages file? | 14:07 |
geiseri_ | err Task: standard? | 14:07 |
cjwatson | geiseri_: I don't know of any documentation on the subject, but the format should be clear from looking at the first | 14:16 |
cjwatson | file | 14:16 |
cjwatson | geiseri_: apt-ftparchive(1) documents how to refer to the index files | 14:16 |
cjwatson | geiseri_: if you do that properly in your apt-ftparchive configuration, then it will include appropriate lines in Packages | 14:17 |
cjwatson | geiseri_: you'll need all the files for your distribution - the ones with ".extra." in the name include Task fields, while the others deal with getting Priority and Section correct | 14:18 |
cjwatson | (the latter is mostly rather less important but does matter in some cases) | 14:18 |
geiseri_ | okay ill read up on ftparchive... i have a feeling i may be making this harder than it needs to be | 14:19 |
geiseri_ | because im using my local file based package repo | 14:20 |
lamont | kernel is building on the afflicted architectures now (linux-libc-dev ftw or some such) | 14:21 |
geiseri_ | cjwatson: okay i think im still missing something here... apt-ftparchive generates the indices files? or it just creates a Packages file that causes me not to need them? | 14:30 |
cjwatson | apt-ftparchive generates the Packages files, using the .debs themselves and also the files from /ubuntu/indices/ as inputs | 14:31 |
cjwatson | the installer does not itself use the files from /ubuntu/indices/ directly | 14:31 |
geiseri_ | ah, so really i need the indices files to include when i run the scanpackages then | 14:32 |
cjwatson | dpkg-scanpackages is what we used to use before we had apt-ftparchive; I don't think it supports "extra overrides" (which contain Task fields) | 14:33 |
cjwatson | (well, for values of "we" = Debian) | 14:33 |
geiseri_ | okay, so im better off to use apt-ftparchive then | 14:34 |
=== asac_ is now known as asac | ||
Awsoonn | hi guys, bug 312396 is cramping my workflow and I would like to have some guidance in fixing it. Who would be the best person to talk to? | 14:36 |
ubottu | Launchpad bug 312396 in gvfs "Nautilus opens files over SSH as read-only when not owner." [Low,Incomplete] https://launchpad.net/bugs/312396 | 14:36 |
cjwatson | Awsoonn: judging from the upstream bug, http://git.gnome.org/cgit/gvfs/commit/?id=4e49395240190526e is supposed to fix it | 15:07 |
Awsoonn | cjwatson: do you think it would be a bad idea to just get the latest version from git and make install? | 15:30 |
cjwatson | Awsoonn: I wouldn't like to say, since I have not looked at the changes in detail; it's entirely possible that that would cause problems | 15:32 |
pitti | infinity: can we do a mass give-back of failed karmic builds after the new kernel is in? | 15:32 |
cjwatson | pitti: lamont's going to | 15:32 |
Awsoonn | I see there are 4 patches on it | 15:32 |
pitti | cjwatson: nice, thanks | 15:32 |
cjwatson | (infinity is off sick, I think) | 15:32 |
pitti | infinity: uh, get well soon! | 15:32 |
cjwatson | Awsoonn: if it were me, I'd backport the change | 15:32 |
Awsoonn | so just make a patch of that one change and make a new patch based on it? | 15:33 |
cjwatson | that would be the approach I'd take, yes | 15:33 |
cjwatson | and report back to the bug if that solves it, of course | 15:33 |
Awsoonn | cool, and adding a patchfile to the patch dir will automagicly cause it to be applied when built right? | 15:33 |
Awsoonn | if that makes sense | 15:34 |
cjwatson | Awsoonn: depends on the patch system; sometimes there's a '00list' or 'series' file that needs to be changed too | 15:35 |
Awsoonn | it does have a series file, so it looks like I should add it ther too, ok. I"m getting the idea now. :) | 15:36 |
Awsoonn | when I build the package with the patch added should I just use .configure make make install or do I need to make a package of it before installing? | 15:37 |
Awsoonn | i hope you dont mind so many questions. I really want to be MOTU someday so I'm still learning as much as possible. :P | 15:38 |
cjwatson | Awsoonn: if it were me, I would make a package of it (so also increment the version number in debian/changelog slightly) | 15:42 |
cjwatson | it's entirely possible for packages to lay files out differently from 'make install' | 15:43 |
Awsoonn | that is what I was fearing, so I will go the package route, thank you cjwatson ! | 15:45 |
cjwatson | upload queue index numbers have passed the wow million mark - wow | 15:45 |
cjwatson | err, the one million mark | 15:45 |
Awsoonn | I think you were right the first time :) | 15:45 |
pitti | cjwatson: what was the 1.000.000th upload? | 15:50 |
pitti | (and wow! indeed) | 15:50 |
amitk | pitti: manjo is here now. Hit him with your Sony fixes ;) | 15:51 |
pitti | manjo: hello! | 15:51 |
manjo | hi | 15:51 |
manjo | referesh my mem pls ? | 15:51 |
pitti | manjo: do you have some minutes to try out a new udev-extras package for sony fn key handling? | 15:52 |
pitti | manjo: http://martinpitt.wordpress.com/2009/05/08/devicekit-update-future-handling-of-fn-key-maps/ | 15:52 |
pitti | manjo: unfortunately the packages in my PPA didn't build yet (buildds blocked due to kernel bug) | 15:52 |
pitti | manjo: but you can build it from the git branch (http://lists.freedesktop.org/archives/devkit-devel/2009-May/000171.html) | 15:52 |
pitti | manjo: I'm interested in whether this package, and hal-info keymaps disabled, works on sony vaios | 15:52 |
pitti | I need to disappear for 20 minutes for physiotherapy; bbl | 15:53 |
manjo | pitti, my wife took the laptop with her to work... is it ok if I give you results on monday ? | 15:53 |
manjo | amitk, ? | 15:54 |
cjwatson | pitti: what were the odds ... a language pack | 15:55 |
cjwatson | 1000000 | -B | language-pack-gnome- | 1:9.04+20090504 | 43 hours | 15:55 |
cjwatson | language-pack-gnome-om actually | 15:56 |
cjwatson | though confusingly something tried to upload that to jaunty, not jaunty-proposed | 15:56 |
cjwatson | ArneGoetje: is langpack-o-matic still targeting jaunty rather than jaunty-proposed in its changelogs, by any chance? | 15:56 |
cjwatson | ArneGoetje: never mind - I see now that it was actually a PPA upload. Pretend I never said anything. :-) | 15:58 |
ion_ | pitti: Could you put the udev-extras package to a separate section in your PPA? I’d feel more easy about adding it to sources.list that way. | 16:00 |
ion_ | I see that it’s the only package in yourppa/karmic, but that can change. :-) | 16:00 |
cjwatson | pitti: oh, is *that* why you have enormous LP karma? it still seems to think all language packs are uploaded by you | 16:00 |
cjwatson | pitti: at least to the ubuntu-langpacks PPA | 16:00 |
* lamont goes to play with karmic | 16:13 | |
jeki | Can anyone look at this report? https://bugs.launchpad.net/ubuntu/+source/app-install-data-ubuntu/+bug/368580 | 16:20 |
ubottu | Ubuntu bug 368580 in app-install-data-ubuntu "aMule should be offered instead of aMule AdunanzA" [Undecided,Confirmed] | 16:20 |
pitti | manjo: absolutely; thank you! | 16:27 |
manjo | k | 16:27 |
pitti | cjwatson: a PPA? | 16:27 |
pitti | ah, right | 16:27 |
pitti | cjwatson: oh, we get karma for uploads now? | 16:27 |
cjwatson | I think so | 16:28 |
pitti | Maintainer: Language pack maintainers <language-packs@ubuntu.com> | 16:28 |
pitti | timestamp: Thu 2008-02-14 14:50:13 +0100 | 16:29 |
pitti | ^ date of the change | 16:29 |
pitti | I can set it to -core-dev, but I'd really keep it as that alias | 16:29 |
=== quadrispro1 is now known as quadrispro | ||
pitti | just curious why I'd get the karma for it personally | 16:29 |
cjwatson | dunno, I was just looking at the display on ~ubuntu-langpacks/+archive/ppa | 16:32 |
pitti | I wonder why I got the Karma then, and ArneGoetje didn't | 16:33 |
* pitti files a bug | 16:33 | |
cjwatson | BTW I haven't actually checked whether you got karma for it | 16:34 |
cjwatson | I just saw that the uploader was listed as pitti | 16:34 |
pitti | cjwatson: ~pitti/+karma shows an abysmal soyuz component; it could only be that | 16:34 |
cjwatson | you can't mean abysmal :) | 16:35 |
cjwatson | unless soyuz karma is negative | 16:35 |
pitti | right, seems I slightly misunderstood the word | 16:36 |
* pitti looked into dictionary now and adjusted his vocab | 16:36 | |
pitti | like "scary" | 16:37 |
* cjwatson wonders if the opposite of abysmal should be empyrean | 16:37 | |
cjwatson | perhaps not :) | 16:37 |
cody-somerville | lol | 16:38 |
pitti | anyway, bug 373772 | 16:38 |
ubottu | Launchpad bug 373772 in launchpad "pitti gets karma for language pack uploads" [Undecided,New] https://launchpad.net/bugs/373772 | 16:38 |
pitti | I want to compete on fair terms :) | 16:38 |
=== pwnguin_ is now known as pwnguin_grmn | ||
calc | looks like the archive will be usable again in a few hours :) | 17:18 |
calc | i386/lpia have linux built now | 17:18 |
cjwatson | yeah, lamont and I (mostly lamont) have been nursing things through | 17:18 |
cjwatson | powerpc is done, amd64's nearly done | 17:19 |
* calc hugs cjwatson and lamont :) | 17:19 | |
calc | looks like ia64 failed for a strange rason | 17:19 |
calc | er reason | 17:19 |
cjwatson | no it didn't, ia64 is built from linux-ports | 17:19 |
calc | oh i see | 17:19 |
cjwatson | and never had this particular problem in the first place (by luck, I assume) | 17:19 |
cjwatson | sparc was never broken either | 17:19 |
lamont | cjwatson: and IA64 is WINNING on the shortest-queue-depth competition. whoda thought? | 17:24 |
cjwatson | it had all that time of being non-broken to catch up | 17:24 |
geiseri_ | if i am generating my iso image from a script is it better to just inject my preseed file right into the initrd vs putting it on the cdrom filesystem? | 17:24 |
cjwatson | hmm, I clearly should have published lpia rather than waiting for amd64 - oh well, it really is nearly done now | 17:25 |
geiseri_ | or is it better to put the first three questions on the boot arguments | 17:25 |
cjwatson | geiseri_: if you're rebuilding the initrd *anyway*, then you might as well inject it in there, but otherwise I'd put it on the cdrom filesystem and edit boot arguments | 17:25 |
cjwatson | the only "better" about it is convenience for you | 17:25 |
geiseri_ | okay | 17:25 |
=== ScriptRipper_ is now known as ScriptRipper | ||
shodges | hey, does anyone know of a small command-line utility that wraps the XGetInputFocus function for X11? | 17:27 |
shodges | I want to retrieve the ID of the window in focus, but preferably using a tool that is existing on the system already... | 17:27 |
shodges | My searching so far has retrieved nothing, I've written my own program as a test, but I need to support remote Ubuntu systems over SSH, so transmitting the the binary program over the wire is a less desirable than just piggy-backing on an existing utility | 17:30 |
Awsoonn | cjwatson: I was able to manually apply the changes and it works! but what command should I use to generate a patch for it that i can put in the debian folder? | 17:53 |
Awsoonn | first I guess I'm assuming that I'm not allowed to modify anythign outside the debian directory, correct? | 17:55 |
cjwatson | depends on the patch, I think you should perhaps read documentation under wiki.ubuntu.com/UbuntuDevelopment and wiki.ubuntu.com/MOTU which will be ultimately more rewarding that asking me :) | 17:56 |
cjwatson | s/that/than/ | 17:56 |
cjwatson | lamont: publisher's running for the linux* packages that have made it so far, BTW | 18:02 |
cjwatson | I verified that the diffs against older linux-libc-dev seemed reasonable | 18:02 |
lamont | yay | 18:03 |
apw | can anyone tell me where i might find the uptodate source for gnome-power-manager ... both jaunty and karmic point me to the same bzr branch which seems to have no releveance to either | 18:04 |
cjwatson | well 'apt-get source gnome-power-manager' is always up to date - ask the most recent uploader in its changelog | 18:05 |
apw | cjwatson, thanks ... i knew that the apt-get source was always reliable, but it bitches at me and tells me not to use that ... will hastle someone :) | 18:06 |
apw | seb128, pitti you have both updated gnome-power-manager recently. the package claims to be in bzr but the reference there seems bogus and out of date... what did you use just the package? | 18:07 |
cjwatson | if the branch is already out of date, the hassling is not directed at you ... | 18:07 |
apw | cjwatson, heh yeah :) but i don't want to make it worse | 18:08 |
seb128 | apw: what bzr did you use? | 18:08 |
apw | the one it pointed me to i think in the debian/control file | 18:08 |
seb128 | which one is that? | 18:08 |
seb128 | let me have a look | 18:08 |
apw | https://code.launchpad.net/~gnome-power-manager-team/gnome-power/trunk | 18:08 |
seb128 | ok | 18:08 |
apw | but that as 2.5.99 on it | 18:08 |
apw | and neither jaunty nor karmic are at that version | 18:09 |
seb128 | it's lp:~ubuntu-desktop/gnome-power-manager/ubuntu | 18:09 |
seb128 | now | 18:09 |
apw | for which karmic or jaunty? | 18:09 |
seb128 | dunno about karmic | 18:09 |
seb128 | but we usually don't make different versions | 18:09 |
seb128 | we just have a trunk which has the unstable version | 18:10 |
apw | they are at rather different versions right now | 18:10 |
seb128 | no they are not | 18:10 |
seb128 | that's the same project | 18:10 |
seb128 | we don't have an hardy bzr, an intrepid bzr, etc | 18:10 |
seb128 | just trunk | 18:10 |
apw | gnome-power-manager | 2.24.2-2ubuntu8 | jaunty | source, amd64, i386 | 18:10 |
apw | gnome-power-manager | 2.26.1-0ubuntu1 | karmic | source | 18:10 |
apw | that tip can't be both? | 18:11 |
seb128 | no, as said it's current unstable | 18:11 |
seb128 | unstable = karmic | 18:11 |
seb128 | we don't keep stable series in a different bzr, we just keep upgrading the bzr | 18:11 |
seb128 | if you need to do a sru apt-get source the jaunty version and debdiff on that | 18:11 |
apw | right so ... to make a change in jaunty, should i just produce a debdiff or should i make a new bzr branch off somwhere in history myself | 18:11 |
apw | seb128, ok thanks | 18:11 |
seb128 | you're welcome | 18:12 |
seb128 | we don't do enough sru uploads to outweight the cost to carry several bzr versions, etc | 18:12 |
apw | i'll strip the vcs link for jaunty too at the same time | 18:12 |
seb128 | sru should be minimal changes if you aim for that | 18:12 |
seb128 | I'm not sure starting doing cleaning is a good idea | 18:13 |
apw | i would have hoped a branch in bzr would be next to free. but whatever you are doing is ok with me | 18:13 |
apw | well having stale information in there is rather confusing ... it pointed me to bzr, when we arn't using it, and to the wrong one even so | 18:13 |
apw | but your call, i'll ignore it | 18:13 |
Awsoonn | apw, you may concider submitting your minimal debdiff for the sru and a second one with the updated link for karmic or something that. | 18:15 |
seb128 | apw: it's probably next to free, we just don't have a policy for naming, where to store those, how to update the vcs field in control, etc | 18:15 |
Awsoonn | seb128: feel free to correct me on that. | 18:15 |
seb128 | apw: since often we will switch to a new unstable without touching the stable source | 18:16 |
seb128 | ie we work on jaunty, the bzr used is trunk and that's in the uploaded sources | 18:16 |
seb128 | then karmic open | 18:16 |
cjwatson | I'm fine with a Vcs-Bzr correction in an SRU, personally | 18:16 |
apw | seb128, yep some process required for sure. i would have thought naming by series at the time of release would be appropriate | 18:17 |
cjwatson | apw: it's not worth putting lots of effort into putting that in place across the board now - we'll get it once we switch to the new source package branches scheme that james-w and others are working on | 18:17 |
apw | probabally something someone should bring up at UDS with a view to producing guidance | 18:17 |
seb128 | apw: you would need to reupload everything to change the vcs | 18:17 |
cjwatson | it'll then be lp:ubuntu/jaunty/gnome-power-manager etc. | 18:17 |
apw | cjwatson, there is a new scheme ... | 18:17 |
cjwatson | and probably overrides to set Vcs-Bzr | 18:18 |
cjwatson | apw: http://wiki.ubuntu.com/DistributedDevelopment et al | 18:18 |
apw | cjwatson, that makes a lot of sense i suspect | 18:18 |
apw | cjwatson, sounds like its already done | 18:18 |
cjwatson | already extensively discussed, not quite done but we're cloe | 18:18 |
cjwatson | close | 18:18 |
* apw buts out of that one then :) | 18:18 | |
seb128 | the discussions are for a scheme for the whole archive | 18:19 |
cjwatson | right, which will account for this case | 18:19 |
seb128 | the current bzr packaging is not consistent accross the board | 18:19 |
apw | sounds like something to stay well clear of being blamed^Winvolved in | 18:19 |
seb128 | ubuntu-desktop is not an heavy bzr user and we picked easy scheme on the way | 18:19 |
seb128 | it's probably far from perfect but work for what we have to do usually | 18:19 |
seb128 | ie we usually focus on jaunty, spend some times on sru, then switch to karmic | 18:20 |
apw | seb128, no what you are doing is completely fine. i care not to be fair, just as someone bumping into your package i am not finding it easy. in fact this is the second time and its moved every time :/ | 18:20 |
seb128 | that's the first sru done after a karmic change, ie usually one bzr fits the work | 18:20 |
seb128 | apw: universal rule is "apt-get source, change, debdiff" and open sponsor request | 18:21 |
seb128 | then let the packagers deal with their bzr etc | 18:21 |
apw | and get whined at for ingnoring the bzr line (in my experience) | 18:21 |
seb128 | people usually complain when somebody upload without considering bzr | 18:21 |
seb128 | for sponsoring a debdiff should not be an issue | 18:22 |
apw | but cool. i was about to do the right thing, so all is good, which was to push a debdiff to launchpad and ... | 18:22 |
=== hunger_ is now known as hunger | ||
* Awsoonn is now hungry | 18:23 | |
Awsoonn | sorry to interupt, but when I built my package and installed it appears another package requires a dependancy update to mach my new version. when I submit to LP do i ned to produce a debdiff for every package that needs a bump? | 18:25 |
cjwatson | that's very odd; such dependencies (that require changes when you *increase* a version) are rare in the extreme. Can you give specifics, please? | 18:26 |
Awsoonn | yea, I and hitting gvfs with that patch, and now libglib2.0-dev seems to be missing a dep | 18:27 |
Awsoonn | strangly enough gvfs is not one it's depends. so i'm really confused there.. | 18:29 |
seb128 | Awsoonn: could you copy the error on pastebin.ubuntu.com? | 18:30 |
cjwatson | you definitely need to be specific about the exact error message, yes | 18:31 |
calc | hmm did i386 not get published yet? | 18:32 |
cjwatson | it's working on it | 18:32 |
cjwatson | the publisher is not all that quick, be gentle with it | 18:32 |
calc | ok | 18:32 |
cjwatson | I think the guts of it are done now, but it still has to run germinate before poking the mirrors | 18:32 |
Awsoonn | I'll need some help here, when I rebooted after installing the new gvfs update-manager put an error in my notification area and says Error: BrokenCount >0 This usually means that your installed packages have unmet dependancies. | 18:33 |
Awsoonn | http://ubuntu.pastebin.com/m10bdaae9 | 18:33 |
cjwatson | run 'dpkg --configure -a' in a terminal and paste.ubuntu.com what it says | 18:33 |
Awsoonn | kk | 18:34 |
Awsoonn | ohh cjwatson that is very usefull. I think i have found the problem. :) | 18:35 |
Awsoonn | when I installed all of my .debs that were producded from pbuilder I mistakenly installed all of them, including a -dev package. It didn't automagicly pull in teh dependancies since I used dpkg -i to install it and was now complaining that libgvfscommon-dev needed some dependancies. :) | 18:37 |
cjwatson | dpkg -iO is your friend | 18:40 |
cjwatson | (only install packages that were already installed) | 18:40 |
Awsoonn | oh, yea that would have been good to know indeed | 18:40 |
calc | cjwatson: hmm is -i0 documented anywhere? i didn't see it in the manpage | 18:42 |
cjwatson | calc: O not 0 | 18:43 |
cjwatson | oh | 18:43 |
cjwatson | -O, --selected-only | 18:43 |
cjwatson | linux-libc-dev fixed for most architectures (not armel/hppa yet), relevant buildds back to auto | 18:44 |
calc | ok | 18:44 |
cjwatson | give-backs have been queued, please tell me if you still see failures that indicate missing asm/*.h headers (do not tell me about any failure you happen to see!) | 18:44 |
* calc definitely needs new glasses | 18:44 | |
calc | cool :) | 18:45 |
cjwatson | and the publisher's back to auto as well | 18:45 |
pitti | seb128: hm, I have used bzr+ssh://bazaar.launchpad.net/~gnome-power-manager-team/gnome-power/trunk | 18:53 |
pitti | apw: ^ | 18:53 |
pitti | seb128: and that branch reflects what's in karmic | 18:54 |
seb128 | pitti: ok, apparently that's not uptodate | 18:54 |
pitti | hm | 18:54 |
* pitti pushes | 18:54 | |
pitti | oops, sorry | 18:54 |
seb128 | and I though we agreed to move it to ubuntu-desktop bzr? | 18:54 |
seb128 | not that I really care | 18:54 |
pitti | seb128: can do, I don't mind much; would make sense | 18:54 |
pitti | apw: so, if you uploaded something already, I'll just commit it | 18:54 |
seb128 | but to have a consistent namespacing | 18:55 |
pitti | apw: anyway, it's current now | 18:55 |
pitti | sorry | 18:55 |
apw | pitti, nothing has happened, we are good | 18:55 |
seb128 | pitti: he's working on a jaunty sru so it will not be really useful | 18:55 |
pitti | okay | 18:55 |
pitti | apw: I went through my AH talk and ignored IRC | 18:55 |
pitti | ah | 18:55 |
seb128 | which leaded to a discuss about stable versions and bzr | 18:55 |
pitti | feel free to create a bzr branch if you prefer | 18:55 |
pitti | if not, just ignore it | 18:55 |
apw | yeah i am happy. and know what to do | 18:55 |
calc | yipee new linux-libc-dev is now available from mirrors :) | 18:55 |
pitti | \o/ | 18:56 |
* calc rebuilds OOo locally to track down the other bug | 18:56 | |
* calc hopes to have OOo 1:3.1.0-1ubuntu1 done today if he can resolve the OOo gcj issue | 18:58 | |
pitti | oh, it's released? nice | 18:58 |
calc | pitti: yea was released late wednesday but we then had the linux-libc-dev headers problem, and some sort of weird failure in building OOo due to gcj on a couple arches | 18:59 |
Awsoonn | I'd like to share a bit of happienss in my world with you all... http://ubuntu.pastebin.com/d66e916ad | 19:07 |
mterry | yay for linux-libc-dev, may you never die again | 19:10 |
lamont | mterry: there have been some more interesting events in the past, to be sure, though | 19:11 |
mterry | lamont: Fine. How about, "May we live in boring times", then. :) | 19:12 |
lamont | heh | 19:13 |
lamont | "oh meh. rebuild the archive and then throw the old stuff away. kthx" being my personal favorite. | 19:14 |
mterry | :) | 19:14 |
maco | so uh, when syncing has the archive broken six-ways-to-tuesday and pbuilder can't pull dependencies does it make sense to test that packages builds by using jaunty? | 19:24 |
cody-somerville | maco, sure | 19:30 |
maco | ok thanks | 19:31 |
* maco waits | 19:31 | |
geiseri_ | grmbl... okay my installer starts now but it keeps complaining that ppoe is not installed.... even though i dont need it... did i screw something up in my preseed file? | 19:40 |
geser | maco: but be aware that it might fail in karmic even if it builds in jaunty | 19:50 |
maco | this early even? | 19:50 |
maco | i didn't think they'd diverged that far yet | 19:50 |
geser | new library versions or gcc-4.4 comes to mind | 19:51 |
cody-somerville | Should one use ${source:Version} or ${binary:Version}? ${binary:Version} will only ever mismatch ${source:Version} if the binary specifies a specific version, right? | 19:53 |
james_w | cody-somerville: or binary rebuilds in Debian | 19:53 |
cody-somerville | james_w, so I should use ${binary:Version} for arch:all packages? | 19:54 |
james_w | any -> all should be source:Version | 19:54 |
james_w | any -> any should be binary:Version | 19:55 |
cody-somerville | okay | 19:55 |
cody-somerville | thanks | 19:55 |
james_w | all -> any should be source:Version | 19:55 |
james_w | I *think* | 19:55 |
james_w | I know lintian knows the rules | 19:55 |
james_w | the last shouldn't be an exact dependency though | 19:56 |
geser | cody-somerville: http://lists.debian.org/debian-mentors/2006/09/msg00230.html and http://wiki.debian.org/binNMU should help you | 19:56 |
cody-somerville | Thanks :) | 19:56 |
james_w | *phew* | 19:57 |
cody-somerville | guh | 19:59 |
cody-somerville | This is going to get hairy | 19:59 |
* cody-somerville is fixing a package with 46 occurrences of ${Source-Version} | 20:00 | |
cody-somerville | and mismatch of any and all packages | 20:00 |
cody-somerville | Hopefully lintian will help me | 20:01 |
cody-somerville | sweet, it does. :) | 20:02 |
cody-somerville | james_w, geser: Whats more correct? Lintian suggests to do (>= ${source:Version}) instead of using ${binary:Version}. | 20:05 |
geser | it probably depends on the use-case | 20:06 |
cody-somerville | ok | 20:07 |
calc | cody-somerville: >= ${source:Version} probably is better since it won't break cases where debian has to do binary NMU's (At least I think that is why there is a difference) | 20:07 |
* cody-somerville nods. | 20:07 | |
geser | calc: but wouldn't that break -dbg packages? as you could use the -dbg package with a newer package | 20:08 |
Awsoonn | now that I have a debdiff for bug #312396 uploaded should I subscribe someone or e-mail someone? | 20:09 |
ubottu | Launchpad bug 312396 in gvfs "Nautilus opens files over SSH as read-only when not owner." [Low,Fix committed] https://launchpad.net/bugs/312396 | 20:09 |
calc | geser: i'm not sure... wouldn't the dbg package be rebuilt as well in the debian case when a binary NMU is done? | 20:09 |
calc | geser: the issue (i think) that source:Version vs binary:Version tries to solve is when there are dependencies between any and all packages in the same source | 20:10 |
geser | calc: they would get rebuilt but the dependency wouldn't force to have matching versions installed | 20:10 |
cody-somerville | should an all -> all use source or binary version? | 20:12 |
calc | geser: ah well that is a good point in that -dbg packages probably should have binary:Version depends instead of source:Version, other things in particular any vs all packages shouldn't | 20:12 |
calc | cody-somerville: this is probably documented somewhere better than just going by my opinion :) | 20:12 |
calc | cody-somerville: though i think it should be safe using either for a all -> all dependency | 20:12 |
calc | cody-somerville: was lintian telling you to use source:Version on dbg packages that depend on other any packages? | 20:13 |
calc | if so that is probably a bug | 20:13 |
calc | although if it isn't i would like to hear the reasoning for that :) | 20:13 |
cody-somerville | No | 20:13 |
geser | source:Version would be more correct but as there aren't any binNMUs for arch:all packages binary:Version should also work | 20:13 |
cody-somerville | Its complaining about meta packages | 20:13 |
cody-somerville | ex., not-binnmuable-all-depends-any pike7.8 -> pike7.8-core | 20:14 |
calc | ok yea that makes sense | 20:14 |
calc | any time you cross the all<->any line you don't want a binary:Version (afaik) | 20:14 |
calc | or even a source:Version without the >= for that matter | 20:15 |
cody-somerville | Won't the source version stay the same though? | 20:15 |
cody-somerville | (everything is built out of the same source package) | 20:15 |
infinity | cody-somerville: The arch:all package might not get rebuilt in a binNMU | 20:16 |
infinity | cody-somerville: We don't actually DO binNMUs in Ubuntu, mind you, because all this mess annoys me. | 20:16 |
cody-somerville | won't the source version for both the rebuilt any package and the not-rebuilt all package be the same though? | 20:16 |
infinity | cody-somerville: But the correct thing for all->any is "Depends: package_any (>= SourceVersion)" | 20:16 |
infinity | cody-somerville: No, source version gets the binNMU version on a rebuild. | 20:17 |
infinity | cody-somerville: binNMU isn't magical, it just increments the source version and pumps through sbuild. | 20:17 |
cody-somerville | I thought binNMU was just bumping the binary version and not the source version *specifically*. | 20:17 |
geser | cody-somerville: yes, but you would probably be more strict than necessary if you use = source:Version | 20:17 |
infinity | cody-somerville: There's no way to do what you think it does. | 20:18 |
infinity | cody-somerville: binNMU is literally forcing the source version to rev slightly, then rebuilding. | 20:18 |
infinity | geser: "= source:Version" breaks, period. It's not just "too strict". | 20:18 |
calc | infinity: you can rev the output version without changing the source version | 20:18 |
cody-somerville | infinity, I thought the whole point of specifying the version of the source package was to allow for the binary version to mismatch the source version | 20:18 |
calc | infinity: OOo does that itself | 20:18 |
calc | infinity: at least for the case where source version != binary version | 20:19 |
infinity | calc: You can specify versions yourself. That's not what I'm talking about. :P | 20:19 |
calc | infinity: ok | 20:19 |
infinity | calc: The binNMU process literally just says "now our source version is 1.2.3-4+b1" and rebuilds. | 20:19 |
infinity | calc: What your rules file does with that source version is up to you, obviously. :) | 20:19 |
calc | infinity: won't that cause problems if a package has binary packages that has source:Version in it though? | 20:20 |
calc | infinity: eg (package all) >= source:Version ? | 20:20 |
infinity | cody-somerville: Yes, binary package versions and source versions can mismatch, and often do (see gcc-defaults for some serious fun there), but we're talking about different things here. | 20:20 |
cody-somerville | oh, okay | 20:21 |
infinity | calc: Hence why lintian has checks to make sure you don't use relationships that break on binNMUs. :P | 20:21 |
infinity | calc: And now we've come full circle! | 20:21 |
calc | infinity: hmm i thought it was suggesting to cody-somerville to put those in | 20:21 |
calc | infinity: instead of using eg (package all) binary:Version | 20:21 |
cody-somerville | It says to do: Depends: arch_any (>= ${source:Version}) | 20:22 |
calc | infinity: if it actually increments the source:Version then that would break any kind of dependency on arch all packages form an arch any package that tries to do a version | 20:22 |
calc | cody-somerville: ok | 20:22 |
infinity | calc: any->all should pretty much never have a strict source-version dep, no. | 20:22 |
infinity | calc: all->any can have a source-version dep, but it needs to be >= | 20:23 |
calc | infinity: any- | 20:23 |
infinity | cody-somerville: Yeah, for your use case, that's correct. | 20:23 |
calc | infinity: any->all is common on packages who have their shared data split out though, so was that case really not catered for? | 20:23 |
infinity | calc: If you look at such cases, they never have strict deps. | 20:23 |
cody-somerville | infinity, Would you be kind enough to review my control file after I sort out all the binNMU errors out from lintian? | 20:23 |
calc | ah, well seems pretty boneheaded since that can easily cause major problems if not even the same upstream version is installed of the shared data :\ | 20:24 |
infinity | calc: (First case I could think of, readline... libreadline5 has an unversioned dep on readline-common) | 20:24 |
infinity | calc: Like I said, there are reasons why I *always* push back against people who want to do binNMUs in Ubuntu, and it's not because I couldn't implement it in short order. | 20:25 |
infinity | calc: It's all very messy for very little reward, IMO. | 20:25 |
calc | infinity: yea | 20:26 |
infinity | calc: From the any->all data perspective, though, my best solution (and I've done this in the past) is "Depends: foo-data (>= $Upstream-Version)" | 20:26 |
infinity | calc: THat should tend to get you the correct data for the runtime, but not worry about debian revisions and other pain. | 20:26 |
calc | is Upstream-Version a defined variable or something you have construct yourself? | 20:27 |
infinity | There are lots of pre-defined ones now, and that may exist somewhere... I construct it myself, though. | 20:27 |
calc | ok | 20:27 |
\sh | a bit late...but congrats to 9.04...I was busy to congrats you all during release time :) | 20:28 |
Laney | congrats to you, \sh! | 20:30 |
cody-somerville | infinity, How does this look? http://pastebin.ubuntu.com/167087/ | 20:30 |
\sh | Laney: thx :) | 20:31 |
infinity | Wow, pastebin.u.c has markup for control files? | 20:31 |
infinity | Or maybe it just sees it as rfc822 and goes from there. | 20:32 |
cody-somerville | infinity, sure does :] | 20:32 |
infinity | cody-somerville: How is this changed from grendel's original control files? | 20:32 |
infinity | cody-somerville: (I have a hard time believing his have been horribly broken for years...) | 20:33 |
cody-somerville | infinity, They were all =${Source-Version} | 20:33 |
cody-somerville | And the standards version was 3.6.2.1 | 20:35 |
infinity | cody-somerville: At a glance, it looks fine to me. | 20:35 |
cody-somerville | infinity, Awesome, thanks | 20:35 |
=== beuno_ is now known as beuno | ||
cjwatson | geiseri_: make sure your Packages file is sorted alphabetically by package. (Yes, really - there's a bug filed about this somewhere ...) | 20:41 |
cjwatson | geiseri_: bug 362989 | 20:42 |
ubottu | Launchpad bug 362989 in anna "custom ISO breaks due to d-i undefined behavior, Packages file ordering affects issue" [Low,Triaged] https://launchpad.net/bugs/362989 | 20:42 |
cjwatson | geiseri_: you can just take ppp-udeb off your image as another convenient workaround; you almost certainly don't need it | 20:43 |
cjwatson | hppa buildds back on auto | 20:45 |
=== blueyed_ is now known as blueyed | ||
cjwatson | infinity: could you do a mass give-back on ia64 and sparc? they weren't affected by the linux-libc-dev breakage, so lamont didn't do a give-back on them, but there was an earlier problem there which made little things like debhelper and gettext uninstallable (due to some component override breakage) and so I think a give-back would be worthwhile | 21:05 |
infinity | cjwatson: Doing. | 21:05 |
cjwatson | ta. I eventually figured it was probably a waste of time having me click around ... | 21:06 |
infinity | cjwatson: Done. | 21:06 |
cjwatson | hmm. can I do a mass give-back, seeing as I'm an archive admin and in launchpad-buildd-admins? or does it need direct access to the buildds? | 21:07 |
infinity | cjwatson: You can probably do it, yes. But you'd totally make me redundant if you did! :P | 21:08 |
cjwatson | heh | 21:08 |
infinity | Wow. My brain just shot way in the past. That can't be healthy. | 21:08 |
cjwatson | (in theory, I know how to do manual builds of single packages on the buildds. that doesn't mean I want to.) | 21:08 |
infinity | drescher.ubuntu.com: forward host lookup failed: Unknown host | 21:08 |
infinity | ^-- Seriously, what now? | 21:08 |
infinity | cjwatson: Anyhow, "buildd-mass-retry" as "lp_buildd" is the command you'd be after. | 21:09 |
infinity | cjwatson: Seems to work from cocoplum just as well as cesium, so.. *shrug* | 21:10 |
infinity | cjwatson: (And it behaves kinda poorly without arguments, so at least throw it a --help) | 21:10 |
cjwatson | fair enough, thanks | 21:10 |
jdstrand | slangasek, Riddell, kirkland, StevenK: has syncbugbot been working for you guys lately? it is failing with "message: An internal server error occurred. Please try again later." | 21:52 |
slangasek | jdstrand: it worked for me on Monday, after I grabbed a fresh lpcookie | 21:52 |
slangasek | LP had logged me out, the week before | 21:52 |
slangasek | kirkland said it wasn't working for him after a cookie change, though, so maybe something else is broken since Monday | 21:53 |
jdstrand | slangasek: yeah, I saw you mentioned that, but the sum on my cookie is the same | 21:53 |
jdstrand | hrm... | 21:53 |
cody-somerville | Whats the best way to deal with a package that requires its self to build? | 21:53 |
slangasek | care to give me a bug num for one you're trying to sync, I'll see if it works for me? | 21:53 |
jdstrand | slangasek: 371796 -f | 21:53 |
slangasek | cody-somerville: the best way is to fix it so it doesn't require that. :) | 21:53 |
slangasek | cody-somerville: the other option is to ask for manual bootstrapping by the buildd admins | 21:54 |
slangasek | jdstrand: WFM | 21:54 |
cody-somerville | slangasek, Does python require its self? I'm working on packaging pike7.8 and one of its module (which is included as part of pike) seems to require pike for a script it runs or something. | 21:55 |
slangasek | python does not. | 21:55 |
Adri2000 | Keybuk: you around? | 22:15 |
calc | what is the buildd url on lp? | 22:16 |
cjwatson | calc: which buildd url? | 22:17 |
calc | i guess i was looking for launchpad.net/builders | 22:18 |
cjwatson | that's one possible meaning, yes :) | 22:18 |
calc | ok :) | 22:18 |
cjwatson | I thought you might have meant URLs for particular builds | 22:18 |
calc | wow big queues | 22:18 |
cjwatson | yeah, the give-backs will take a while to churn through | 22:19 |
Adri2000 | Keybuk: never mind | 22:49 |
calc | ugh this OOo test build is taking forever :-\ | 22:49 |
Nafallo | calc: you act surprised? | 22:51 |
=== beuno_ is now known as beuno | ||
calc | Nafallo: well it is taking longer than i expected, at 3.5hr and still unknown amount of time left | 22:57 |
* TheMuso sighs in relief at the new ports kernel working. | 23:23 | |
calc | it finally finished and failed in the same way again | 23:27 |
calc | it builds on amd64 but not on i386/lpia due to claim that libgcj.spec missing | 23:27 |
calc | doko: ^ | 23:27 |
calc | /usr/bin/gcj -c -g -O2 -fPIC -findirect-dispatch -fjni LuceneHelpWrapper.jar.1.jar -o LuceneHelpWrapper.jar.1.o | 23:28 |
calc | gcj: libgcj.spec: No such file or directory | 23:28 |
calc | but its there: /usr/lib/gcc/i486-linux-gnu/4.4/libgcj.spec | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!