[00:08] calc: interesting, I didn't know about that change [00:09] 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:11] ah === robbiew is now known as robbiew-away [00:38] 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? === bryce_ is now known as bryce [00:41] 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. [01:16] wgrant: ok [01:20] is anyone else seeing oddly high load in jaunty/karmic? [01:20] Mine is constantly 10 [01:20] or 11 [01:20] but no IO, plenty of cache, cpu at 1% use [01:20] oh nevermind, it'll be a stalled sfs process === freeflyi1g is now known as freeflying === robbiew-away is now known as robbiew [06:40] good morning [06:58] any karmic users here? What is the contents of your /usr/include/linux/errno.h? [06:58] mine points to asm/errno.h which does not exist [06:59] robert_ancell: you're missing libc-dev or something I suspect [06:59] or being hit by a toolchain transition [06:59] <- guessing [06:59] there are ftbfs errors regarding that particular header [07:00] hyperair: ouch [07:00] yeh ouch indeed. [07:00] gnomeui is having issues [07:00] rather, stuff depending on gnomeui [07:01] hmm, I was going to use the PPA but that will have the same problems right? [07:02] indeed. [07:02] robert_ancell: try asking the guys in #ubuntu-kernel - they should know what's going on [07:02] ... even if I suspect that most of them are sleeping right now [07:03] dholbach: yeah, it's friday afternoon. I figure it will be fixed by monday :) I'll go drink beer instead [07:03] dholbach: it's a known issue, Stuff needs to be done on the buildds I heard :) [07:03] ajmitch: oh wow [07:06] It's a findutils bug that impacted on the linux-libc-dev binary package [07:30] robert_ancell: it's bug 373214 [07:30] 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] geser: thx [07:33] robert_ancell: oh right, you're in aus:) [07:33] beer sounds good about now ;) [07:34] 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] indeed. and we fly 10000 to actually meet soon :P [07:39] slangasek: I did not. [07:40] Hobbsee: right - Riddell confessed :-) [07:40] slangasek: oh, fair enough. I'm just looking through my highlights ;) [07:40] slangasek: I hope you didn't make him walk the plank? [07:41] no, I just demoted him to multiverse temporarily [07:41] haha [07:41] oh dear [07:42] Good morning [07:42] slangasek: libltdl-dev> I didn't [07:42] doko: nice! is it in c-mismatches? [07:45] slangasek: Along with all of KDE? [07:45] hah, twitch :) [07:45] It would improve the quality of translations. [07:46] * StevenK grins [07:50] * pwnguin gets to attend a public meeting about garmin's use of linux [07:50] anyone have a question they want answered? [07:51] pwnguin: apart from the obvious ones? No. I'd love to know what the answers to the obvious questions are, though. === tkamppeter_ is now known as tkamppeter [07:52] if there's a URL from it [07:52] i doubt it will be publicly recorded [07:52] darn [07:53] but what are the obvious questions? [07:54] 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:57] Hobbsee: http://developer.garmin.com/linux/ i'll let you know if they mention a device that isn't one of those [07:58] pwnguin: ah, sweet! === mkorn is now known as thekorn === mpt_ is now known as mpt === dpm_ is now known as dpm [10:35] anyone got a Sony laptop here? [10:37] ping manjo when he gets online in a few hours if you don't find anybody [10:37] pitti: ^ [10:37] amitk: ah, thanks [10:42] directhex: congratulations for your motu badge! well done! [10:42] cjwatson, smb: hm, why does the new linux upload bump abi? [10:42] if it's just a rebuild? [10:43] pitti, because i did not found/look far enough/trust the last abi files [10:43] 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] smb: fair enough; I was just curious [10:43] ABI changes are cheap enough at this point [10:43] pitti, So I bumped abi to be sure it passes the abi checks [10:43] yeah, we just need to watch out for NEWing [10:44] though it does mean NEW, but meh, lost in the noise of having to deal with the whole thing manually [10:44] thanks for getting this fixed [10:44] cjwatson, smb: YAY! :) [10:46] * 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] anybody else getting LP timeouts? [10:46] intermittently, yes [10:47] * TheMuso can't seem to view source package pages, i.e lp.net/ubuntu/+source/linux [10:47] hrm working now [10:50] 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:51] had intermitent issues with LP since last night. check /topic in #launchpad [10:54] What's up with these "asm/socket.h: No such file or directory" errors? Seen them failing a few builds now. [10:54] Laney: linux-libc-dev breakage. [10:54] bug 373214 [10:54] * TheMuso thinks a /topic tweak is in order. [10:54] Launchpad bug 373214 in linux "/usr/include/asm/* is not present in linux-libc-dev" [Critical,Fix released] https://launchpad.net/bugs/373214 [10:55] yes, it seems to be affecting builds all over the shop [10:55] james_w: ta [10:56] TheMuso: More correctly, findutils breakage that caused a linux-libc-dev [10:56] breakage [10:56] amitk: yes, but linux-libc-dev being broken is enough for most I would think. :) [10:57] anyway, really off. [10:59] on an upgrade would i expect to be seeing linux-generic being uninstalled? [10:59] (on jaunty) [11:00] are you using jaunty-proposed? [11:01] yes using -proposed [11:03] 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] slangasek, how would lacking binaryies trigger a meta to be removed? [11:04] 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] i am using it in the default way, it said a partial update was the only way forward, and i said yes [11:04] as encouraged to do by the defaults [11:05] anyway, lrm/lbm accepted now, which should fix linux-generic with the next publisher cycle [11:05] (with my behaving like a non-clued up user hat on) [11:05] i assume once i had lost linux-generic i wouldn't have got it back... sounds problematic for those users [11:05] 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:06] yeah ... i think there is some kind of bug in there offering that to normal users without a fight === 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 [11:11] (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:14] slangasek, Were the meta package in error or did something else go wrong? [11:16] slangasek, Have to be off now, but if there is anything that should get back into the linux-meta packages, let me know [11:17] smb: no package errors; we just needed some jaunty-proposed NEW processing, which is done now [11:17] slangasek, Ah, ok. Thanks [11:29] cjwatson, i wonder if you would have some minutes to talk about that kexec reboot bug (bug 251242) today [11:29] Launchpad bug 251242 in kexec-tools "Always kexecs on shutdown/reboot" [Medium,In progress] https://launchpad.net/bugs/251242 [11:34] apw: ah yes. I have a PDR panic day today, but have queued up that bug to look at the debdiffs therein [11:34] cjwatson, heh know _that_ panic ... no worries if busy it'll wait === 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 [13:43] 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] is there anyone who would know more about this? google was not very helpful [13:44] i think i may have missed a step, but im not sure where... [13:52] any developers of ubuntu-vm-builder here? [13:53] 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:55] yes, i created my own... but i did not include the indices. [13:55] that'll be your problem then [13:55] i can download that or do i need to generate that if i am using my own package set [13:56] start out with the downloaded ones, generating your own is a bit complicated [13:56] okay [13:56] you may need to edit them a bit [13:57] okay [13:57] ill start there [13:58] what files will i need? all of them fro my dist? [14:00] astrolite, #ubuntu-virt might be a better place to find those people [14:00] liw: ok, thanks! [14:07] cjwatson: where would be the documentation no how to generate my own indices files? [14:07] or is it easier to include the tasksel in my Packages file? [14:07] err Task: standard? [14:16] geiseri_: I don't know of any documentation on the subject, but the format should be clear from looking at the first [14:16] file [14:16] geiseri_: apt-ftparchive(1) documents how to refer to the index files [14:17] geiseri_: if you do that properly in your apt-ftparchive configuration, then it will include appropriate lines in Packages [14:18] 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] (the latter is mostly rather less important but does matter in some cases) [14:19] okay ill read up on ftparchive... i have a feeling i may be making this harder than it needs to be [14:20] because im using my local file based package repo [14:21] kernel is building on the afflicted architectures now (linux-libc-dev ftw or some such) [14:30] 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:31] apt-ftparchive generates the Packages files, using the .debs themselves and also the files from /ubuntu/indices/ as inputs [14:31] the installer does not itself use the files from /ubuntu/indices/ directly [14:32] ah, so really i need the indices files to include when i run the scanpackages then [14:33] 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] (well, for values of "we" = Debian) [14:34] okay, so im better off to use apt-ftparchive then === asac_ is now known as asac [14:36] 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] Launchpad bug 312396 in gvfs "Nautilus opens files over SSH as read-only when not owner." [Low,Incomplete] https://launchpad.net/bugs/312396 [15:07] Awsoonn: judging from the upstream bug, http://git.gnome.org/cgit/gvfs/commit/?id=4e49395240190526e is supposed to fix it [15:30] cjwatson: do you think it would be a bad idea to just get the latest version from git and make install? [15:32] 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] infinity: can we do a mass give-back of failed karmic builds after the new kernel is in? [15:32] pitti: lamont's going to [15:32] I see there are 4 patches on it [15:32] cjwatson: nice, thanks [15:32] (infinity is off sick, I think) [15:32] infinity: uh, get well soon! [15:32] Awsoonn: if it were me, I'd backport the change [15:33] so just make a patch of that one change and make a new patch based on it? [15:33] that would be the approach I'd take, yes [15:33] and report back to the bug if that solves it, of course [15:33] cool, and adding a patchfile to the patch dir will automagicly cause it to be applied when built right? [15:34] if that makes sense [15:35] Awsoonn: depends on the patch system; sometimes there's a '00list' or 'series' file that needs to be changed too [15:36] it does have a series file, so it looks like I should add it ther too, ok. I"m getting the idea now. :) [15:37] 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:38] 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:42] Awsoonn: if it were me, I would make a package of it (so also increment the version number in debian/changelog slightly) [15:43] it's entirely possible for packages to lay files out differently from 'make install' [15:45] that is what I was fearing, so I will go the package route, thank you cjwatson ! [15:45] upload queue index numbers have passed the wow million mark - wow [15:45] err, the one million mark [15:45] I think you were right the first time :) [15:50] cjwatson: what was the 1.000.000th upload? [15:50] (and wow! indeed) [15:51] pitti: manjo is here now. Hit him with your Sony fixes ;) [15:51] manjo: hello! [15:51] hi [15:51] referesh my mem pls ? [15:52] manjo: do you have some minutes to try out a new udev-extras package for sony fn key handling? [15:52] manjo: http://martinpitt.wordpress.com/2009/05/08/devicekit-update-future-handling-of-fn-key-maps/ [15:52] manjo: unfortunately the packages in my PPA didn't build yet (buildds blocked due to kernel bug) [15:52] manjo: but you can build it from the git branch (http://lists.freedesktop.org/archives/devkit-devel/2009-May/000171.html) [15:52] manjo: I'm interested in whether this package, and hal-info keymaps disabled, works on sony vaios [15:53] I need to disappear for 20 minutes for physiotherapy; bbl [15:53] pitti, my wife took the laptop with her to work... is it ok if I give you results on monday ? [15:54] amitk, ? [15:55] pitti: what were the odds ... a language pack [15:55] 1000000 | -B | language-pack-gnome- | 1:9.04+20090504 | 43 hours [15:56] language-pack-gnome-om actually [15:56] though confusingly something tried to upload that to jaunty, not jaunty-proposed [15:56] ArneGoetje: is langpack-o-matic still targeting jaunty rather than jaunty-proposed in its changelogs, by any chance? [15:58] ArneGoetje: never mind - I see now that it was actually a PPA upload. Pretend I never said anything. :-) [16:00] 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] I see that it’s the only package in yourppa/karmic, but that can change. :-) [16:00] pitti: oh, is *that* why you have enormous LP karma? it still seems to think all language packs are uploaded by you [16:00] pitti: at least to the ubuntu-langpacks PPA [16:13] * lamont goes to play with karmic [16:20] Can anyone look at this report? https://bugs.launchpad.net/ubuntu/+source/app-install-data-ubuntu/+bug/368580 [16:20] Ubuntu bug 368580 in app-install-data-ubuntu "aMule should be offered instead of aMule AdunanzA" [Undecided,Confirmed] [16:27] manjo: absolutely; thank you! [16:27] k [16:27] cjwatson: a PPA? [16:27] ah, right [16:27] cjwatson: oh, we get karma for uploads now? [16:28] I think so [16:28] Maintainer: Language pack maintainers [16:29] timestamp: Thu 2008-02-14 14:50:13 +0100 [16:29] ^ date of the change [16:29] I can set it to -core-dev, but I'd really keep it as that alias === quadrispro1 is now known as quadrispro [16:29] just curious why I'd get the karma for it personally [16:32] dunno, I was just looking at the display on ~ubuntu-langpacks/+archive/ppa [16:33] I wonder why I got the Karma then, and ArneGoetje didn't [16:33] * pitti files a bug [16:34] BTW I haven't actually checked whether you got karma for it [16:34] I just saw that the uploader was listed as pitti [16:34] cjwatson: ~pitti/+karma shows an abysmal soyuz component; it could only be that [16:35] you can't mean abysmal :) [16:35] unless soyuz karma is negative [16:36] right, seems I slightly misunderstood the word [16:36] * pitti looked into dictionary now and adjusted his vocab [16:37] like "scary" [16:37] * cjwatson wonders if the opposite of abysmal should be empyrean [16:37] perhaps not :) [16:38] lol [16:38] anyway, bug 373772 [16:38] Launchpad bug 373772 in launchpad "pitti gets karma for language pack uploads" [Undecided,New] https://launchpad.net/bugs/373772 [16:38] I want to compete on fair terms :) === pwnguin_ is now known as pwnguin_grmn [17:18] looks like the archive will be usable again in a few hours :) [17:18] i386/lpia have linux built now [17:18] yeah, lamont and I (mostly lamont) have been nursing things through [17:19] powerpc is done, amd64's nearly done [17:19] * calc hugs cjwatson and lamont :) [17:19] looks like ia64 failed for a strange rason [17:19] er reason [17:19] no it didn't, ia64 is built from linux-ports [17:19] oh i see [17:19] and never had this particular problem in the first place (by luck, I assume) [17:19] sparc was never broken either [17:24] cjwatson: and IA64 is WINNING on the shortest-queue-depth competition. whoda thought? [17:24] it had all that time of being non-broken to catch up [17:24] 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:25] hmm, I clearly should have published lpia rather than waiting for amd64 - oh well, it really is nearly done now [17:25] or is it better to put the first three questions on the boot arguments [17:25] 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] the only "better" about it is convenience for you [17:25] okay === ScriptRipper_ is now known as ScriptRipper [17:27] hey, does anyone know of a small command-line utility that wraps the XGetInputFocus function for X11? [17:27] I want to retrieve the ID of the window in focus, but preferably using a tool that is existing on the system already... [17:30] 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:53] 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:55] first I guess I'm assuming that I'm not allowed to modify anythign outside the debian directory, correct? [17:56] 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] s/that/than/ [18:02] lamont: publisher's running for the linux* packages that have made it so far, BTW [18:02] I verified that the diffs against older linux-libc-dev seemed reasonable [18:03] yay [18:04] 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:05] well 'apt-get source gnome-power-manager' is always up to date - ask the most recent uploader in its changelog [18:06] 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:07] 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] if the branch is already out of date, the hassling is not directed at you ... [18:08] cjwatson, heh yeah :) but i don't want to make it worse [18:08] apw: what bzr did you use? [18:08] the one it pointed me to i think in the debian/control file [18:08] which one is that? [18:08] let me have a look [18:08] https://code.launchpad.net/~gnome-power-manager-team/gnome-power/trunk [18:08] ok [18:08] but that as 2.5.99 on it [18:09] and neither jaunty nor karmic are at that version [18:09] it's lp:~ubuntu-desktop/gnome-power-manager/ubuntu [18:09] now [18:09] for which karmic or jaunty? [18:09] dunno about karmic [18:09] but we usually don't make different versions [18:10] we just have a trunk which has the unstable version [18:10] they are at rather different versions right now [18:10] no they are not [18:10] that's the same project [18:10] we don't have an hardy bzr, an intrepid bzr, etc [18:10] just trunk [18:10] gnome-power-manager | 2.24.2-2ubuntu8 | jaunty | source, amd64, i386 [18:10] gnome-power-manager | 2.26.1-0ubuntu1 | karmic | source [18:11] that tip can't be both? [18:11] no, as said it's current unstable [18:11] unstable = karmic [18:11] we don't keep stable series in a different bzr, we just keep upgrading the bzr [18:11] if you need to do a sru apt-get source the jaunty version and debdiff on that [18:11] 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] seb128, ok thanks [18:12] you're welcome [18:12] we don't do enough sru uploads to outweight the cost to carry several bzr versions, etc [18:12] i'll strip the vcs link for jaunty too at the same time [18:12] sru should be minimal changes if you aim for that [18:13] I'm not sure starting doing cleaning is a good idea [18:13] i would have hoped a branch in bzr would be next to free. but whatever you are doing is ok with me [18:13] 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] but your call, i'll ignore it [18:15] 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] 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] seb128: feel free to correct me on that. [18:16] apw: since often we will switch to a new unstable without touching the stable source [18:16] ie we work on jaunty, the bzr used is trunk and that's in the uploaded sources [18:16] then karmic open [18:16] I'm fine with a Vcs-Bzr correction in an SRU, personally [18:17] seb128, yep some process required for sure. i would have thought naming by series at the time of release would be appropriate [18:17] 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] probabally something someone should bring up at UDS with a view to producing guidance [18:17] apw: you would need to reupload everything to change the vcs [18:17] it'll then be lp:ubuntu/jaunty/gnome-power-manager etc. [18:17] cjwatson, there is a new scheme ... [18:18] and probably overrides to set Vcs-Bzr [18:18] apw: http://wiki.ubuntu.com/DistributedDevelopment et al [18:18] cjwatson, that makes a lot of sense i suspect [18:18] cjwatson, sounds like its already done [18:18] already extensively discussed, not quite done but we're cloe [18:18] close [18:18] * apw buts out of that one then :) [18:19] the discussions are for a scheme for the whole archive [18:19] right, which will account for this case [18:19] the current bzr packaging is not consistent accross the board [18:19] sounds like something to stay well clear of being blamed^Winvolved in [18:19] ubuntu-desktop is not an heavy bzr user and we picked easy scheme on the way [18:19] it's probably far from perfect but work for what we have to do usually [18:20] ie we usually focus on jaunty, spend some times on sru, then switch to karmic [18:20] 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] that's the first sru done after a karmic change, ie usually one bzr fits the work [18:21] apw: universal rule is "apt-get source, change, debdiff" and open sponsor request [18:21] then let the packagers deal with their bzr etc [18:21] and get whined at for ingnoring the bzr line (in my experience) [18:21] people usually complain when somebody upload without considering bzr [18:22] for sponsoring a debdiff should not be an issue [18:22] but cool. i was about to do the right thing, so all is good, which was to push a debdiff to launchpad and ... === hunger_ is now known as hunger [18:23] * Awsoonn is now hungry [18:25] 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:26] 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:27] yea, I and hitting gvfs with that patch, and now libglib2.0-dev seems to be missing a dep [18:29] strangly enough gvfs is not one it's depends. so i'm really confused there.. [18:30] Awsoonn: could you copy the error on pastebin.ubuntu.com? [18:31] you definitely need to be specific about the exact error message, yes [18:32] hmm did i386 not get published yet? [18:32] it's working on it [18:32] the publisher is not all that quick, be gentle with it [18:32] ok [18:32] I think the guts of it are done now, but it still has to run germinate before poking the mirrors [18:33] 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] http://ubuntu.pastebin.com/m10bdaae9 [18:33] run 'dpkg --configure -a' in a terminal and paste.ubuntu.com what it says [18:34] kk [18:35] ohh cjwatson that is very usefull. I think i have found the problem. :) [18:37] 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:40] dpkg -iO is your friend [18:40] (only install packages that were already installed) [18:40] oh, yea that would have been good to know indeed [18:42] cjwatson: hmm is -i0 documented anywhere? i didn't see it in the manpage [18:43] calc: O not 0 [18:43] oh [18:43] -O, --selected-only [18:44] linux-libc-dev fixed for most architectures (not armel/hppa yet), relevant buildds back to auto [18:44] ok [18:44] 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:45] cool :) [18:45] and the publisher's back to auto as well [18:53] seb128: hm, I have used bzr+ssh://bazaar.launchpad.net/~gnome-power-manager-team/gnome-power/trunk [18:53] apw: ^ [18:54] seb128: and that branch reflects what's in karmic [18:54] pitti: ok, apparently that's not uptodate [18:54] hm [18:54] * pitti pushes [18:54] oops, sorry [18:54] and I though we agreed to move it to ubuntu-desktop bzr? [18:54] not that I really care [18:54] seb128: can do, I don't mind much; would make sense [18:54] apw: so, if you uploaded something already, I'll just commit it [18:55] but to have a consistent namespacing [18:55] apw: anyway, it's current now [18:55] sorry [18:55] pitti, nothing has happened, we are good [18:55] pitti: he's working on a jaunty sru so it will not be really useful [18:55] okay [18:55] apw: I went through my AH talk and ignored IRC [18:55] ah [18:55] which leaded to a discuss about stable versions and bzr [18:55] feel free to create a bzr branch if you prefer [18:55] if not, just ignore it [18:55] yeah i am happy. and know what to do [18:55] yipee new linux-libc-dev is now available from mirrors :) [18:56] \o/ [18:56] * calc rebuilds OOo locally to track down the other bug [18:58] * calc hopes to have OOo 1:3.1.0-1ubuntu1 done today if he can resolve the OOo gcj issue [18:58] oh, it's released? nice [18:59] 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 [19:07] I'd like to share a bit of happienss in my world with you all... http://ubuntu.pastebin.com/d66e916ad [19:10] yay for linux-libc-dev, may you never die again [19:11] mterry: there have been some more interesting events in the past, to be sure, though [19:12] lamont: Fine. How about, "May we live in boring times", then. :) [19:13] heh [19:14] "oh meh. rebuild the archive and then throw the old stuff away. kthx" being my personal favorite. [19:14] :) [19:24] 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:30] maco, sure [19:31] ok thanks [19:31] * maco waits [19:40] 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:50] maco: but be aware that it might fail in karmic even if it builds in jaunty [19:50] this early even? [19:50] i didn't think they'd diverged that far yet [19:51]