=== TerminX_ is now known as TerminX [00:15] rsalveti, yeah [00:16] bryceh: for the debootstrap issue I published my test result with multstrap at the merge request [00:16] this will at least make it possible to create images again === dendro-afk is now known as dendrobates [01:32] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [01:39] bryceh: right, we should certainly fix this ASAP, but if that doesn't fix it I don't know what will do the job [02:32] I'm trying to create an oneiric environment using pbuilder, but I keep getting stuck at "W: Failure trying to run: chroot /var/cache/pbuilder/build/1422/. dpkg --force-depends --install /var/cache/apt/archives/libc_2.13-9ubuntu2_amd64.deb" [02:32] Has anyone else experienced this problem? [02:32] I think pbuilder on oneiric is currently broken. I remember someone saying that yesterday. [02:38] It's actually base-files that's broken, but that's not unexpected. === phantomcircuit is now known as phantom === poolie_ is now known as poolie [04:08] serge_afk: it was the kernel [04:21] Good morning [04:22] debfx: kubuntu seed branch> oh, did I commit something to the wrong place? [04:22] morning pitti [04:22] RoAkSoAx: nothing to do with udev, it's because there's an incomplete /run transition -- just remove /run/*, and it will work again [04:26] pitti: to the contrary, people have been saying today that removing /run is insufficent [04:26] er, no, I may have that wrong [04:27] people have been saying that adding /var/run and /var/lock compatibility links doesn't fix it [04:27] I guess the advertised workaround is to remove /run/udev [04:27] so, why does that work? [04:27] that would seem to have *everything* to do with udev :) [04:30] slangasek: worked for me [04:31] sudo rm /run/* and rebooting helps [04:31] then udev consistently uses /dev/.udev/ again [04:31] slangasek: I followed up to bug 807306 explaining what happens [04:31] Launchpad bug 807306 in base-files (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X" [Critical,Triaged] https://launchpad.net/bugs/807306 [04:31] pitti: ok, ta [04:31] I hit it myself yesterday [04:31] pitti: we do want udev to be using /dev/.udev/ though, so I'd like to get this properly fixed [04:31] slangasek: it's because the initramfs starts its own udev instance, which uses /dev/.udev (as initramfs doesn't have a /run yet) [04:32] ok, so it's initramfs-tools where we need to fix it? [04:32] slangasek: do we? why does base-files create a /run then? [04:32] sorry [04:32] if we want to move to /run, initramfs needs to have it as well IMHO [04:32] I mean "we don't want udev to be using /dev/.udev" :) [04:32] ah :) [04:33] slangasek: do you know if someone is already on this? or shall I have a look? [04:34] pitti: I think it's best if you do - bryce and rsalveti were looking but hit a dead end when readding /var/{lock,run} to base-files didn't fix it [04:34] I'm taking care of sysvinit already fwiw [04:34] oh, is there another problem with /var/lock and /var/run, too? [04:34] I thought this was fixed at debian already [04:34] yes, that's the bug that prevents oneiric from bootstrapping at the moment [04:35] rsalveti: oh, does Debian use /run/ already? [04:35] yes [04:35] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620995 [04:35] slangasek: ah, much appreciated; that'll fix the libc6 install error? [04:35] Debian bug 620995 in udev "udev is making use of /run when this is not yet supported" [Important,Fixed] [04:35] pitti: [04:35] let me check what was the fix [04:35] pitti: yes [04:35] pitti: and I'll probably need to do coordinated uploads of sysvinit+mountall+base-files, at least [04:35] * [259ad09] mkinitramfs: creat /run initramfs directory. [04:35] pitti: https://code.launchpad.net/~rsalveti/ubuntu/oneiric/base-files/run-transition/+merge/67444 [04:36] this is for the debootstrap issue [04:36] yeah, I wasn't quite sure why Keybuk did it that way -- we create /run, but nothing actually makes it a tmpfs [04:36] that would be mountall, I figure? [04:36] (and might be covered in slangasek's work) [04:37] keybuk *didn't* do it that way, someone else uploaded changes he had partially staged in bzr ;) [04:37] ouch :-) [04:37] yes, mountall will need to take care of the tmpfs mounting [04:42] debian includes a fix at udev that makes it only use /run when it's a tmpfs [04:43] seems the right fix even during the transition [04:44] right, I'll check that [04:44] that will cover bug 807306 [04:44] Launchpad bug 807306 in base-files (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X" [Critical,Triaged] https://launchpad.net/bugs/807306 [04:45] pitti: http://paste.ubuntu.com/642376/, but you can just merge/check the patch from the debian src package [04:45] problem is that udev will always use /run if the directory is there [04:45] even if it's not a valid /run (not mounted as tmpfs) [04:46] as we had the directory there, when udev restarted, it got broken [04:46] rsalveti: right, trying to find the udev patch; thanks for the pastebin! [04:54] pitti: so to make it all work again we'll need both fixes [04:54] the bootstrap related one, and this udev update === Ursinha is now known as Ursinha-afk [06:47] Why does ubuntu-minimal depend on iputils-ping? [06:48] Why shouldn't it? [06:48] It certainly fits with the package description. [06:50] I mean, why does it depend only on that implementation? inetutils-ping works the same, though it has a much nicer --help. [06:51] e_t_: because inetutils-ping is in universe. [06:53] e_t_: File a bug on ubuntu-meta, we could conceivably mangle it to depend on "iputils-ping | ping", which would still get the supported one by default, but let you swap without losing the metapackage. [06:54] infinity: Thank you. [06:57] pitti: to fix the debootstrap issue we also need the base-files fix [06:58] rsalveti: right [06:58] at least while slangasek is merging the sysvinit package change [06:58] rsalveti: I understood slangasek was going to handle that [06:58] I'm currently working on merging initramfs-tools [06:58] to get proper /run handling [06:58] cool [06:58] the udev bandaid fix is uploaded [06:58] yeah, just saw it [06:58] thanks for fixing it [06:59] np, thanks for pointing it out === smb` is now known as smb [07:23] slangasek: hm, initramfs 0.99 already creates a /run tmpfs and mounts it over to the running system; do we actually need that in mountall still? [07:25] pitti: for the tmpfs-less case, yes [07:25] er [07:25] initramfs-less case [07:25] ah [07:25] * pitti tests initramfs merge [07:26] good morning [07:26] hey dholbach [07:27] hey pitti === dendrobates is now known as dendro-afk [07:30] good morning dholbach, pitti [07:30] hey geser [07:30] hey geser === pjdc_ is now known as pjdc [08:19] ping barry [08:20] hey evfool, he is probably still sleeping (us timezone) [08:21] thanks mvo, didn't know that [08:21] mvo: do you know anything about update-manager in natty-proposed with the apport-hook (bug 797894) [08:22] Launchpad bug 797894 in update-manager (Ubuntu Natty) "update-manager bug reports would benefit from an apport-hook" [Medium,Incomplete] https://launchpad.net/bugs/797894 [08:22] evfool: let me check [08:22] barry and raof have been talking about that, but now it's not in proposed, not in updates, and the bug's still there [08:22] evfool: thankss for your update-manager merge btw :) [08:22] evfool: eh, branch I mean [08:23] mvo: just trying to check for useful patches attached to bugs and convert them into merge requests, because patches attached tend to get lost [08:24] evfool: yeah, that is unfortunately true :/ thanks a bunch for going throught them, I find this really helpful [08:24] evfool: it looks like the u-m proposed version got uploaded without bzr-buildpackage so it includes the .bzr dir, I will do a reupload [08:24] thx mvo [08:29] yay, workign /run/udev/ === ikonia_ is now known as ikonia [08:38] slangasek: initramfs-tools working well now, thrown oneiric-wards === apachelogger_ is now known as apachelogger [08:57] GRRR [08:57] who brike update-manager [08:57] *broke [08:58] ogra_, wfm [08:58] partial upgrade ? === Spads_ is now known as Spads [08:59] ogra_, without details on what is broken it's hard to say [08:59] ogra_, try #ubuntu for "doesn't work" questions ;-) [08:59] i'm getting a partial upgrade offered which then starts fine ... during "preparing to upgrade" a white contentless window pops up [08:59] works fine here [08:59] oh, I didn't try to do partial upgrades [08:59] sadly without and windo buttons too ... so i cant close both windows (second one seems transiaent) [09:00] all i can do is kill from cmdline [09:00] its reliably reproducable but doesnt spit out a thing if i fire u-m off from cmdline [09:01] * ogra_ goes back to apt being not able to get any debugging info [09:02] hm, I just did a full upgrade cycle with current u-m for testing [09:03] can't try here, I've no "partial upgrade" [09:03] normal upgrades work fine [09:03] there might be a bug in the gir transition with the partial upgrade dialog dunno [09:03] check with mvo [09:03] might be arm specific or so, in any case i dont get any debugging output [09:03] seb128: currently there's a partial upgrade, as the evo binaries are held back [09:03] on arm there are the new indicators [09:04] ogra_, oh, we had that transition a week ago on other archs [09:04] pitti, it already built on i386 ;-) [09:04] but not published yet, I guess I will have the partial upgrade as well if I refresh, let's try [09:04] seb128, yeah, you had json-glib :) [09:09] ogra_: hmmm, that is probably the gtk3 port, if the window is still there, could you please do a ps afx and paste the output? [09:10] mvo, phew, thats timing, apt-was just ready downloading :) [09:10] apachelogger: software-properties trunk has your dbusworker stuff now (plus tests for them). thanks again for the initial work, no changes on the ui yet though [09:14] mvo, http://paste.ubuntu.com/642494/ [09:18] ogra_: hm, looks pretty normal, so there is a white window? could I see a screenshot maybe? any activity still? anything interessting in one of the logs /var/log/apt/{term.log,history.log} ? [09:19] evfool: That package got rejected pending a new upload without the .bzr and .bzr-builddeb cruft. [09:19] thanx RAOF [09:20] mvo, "Log ended: 2011-07-08 18:37:07" ... doesnt seem to get to apt [09:20] history.log ends also at that time [09:21] ogra_: anything /var/log/dist-upgrade/* that looks relevant? [09:21] does anyone know where is usb_dev_handle is defined in the linux sources? [09:22] mvo, hmm, now i cant reproduce it anymore, the "partial upugrade" window just closes, let me check that logfile [09:25] e_t_: FWIW I've always wontfixed bugs asking for alternative dependencies in ubuntu-* metapackages - the *purpose* of those metapackages is to make opinionated choices [09:25] e_t_: people can always remove the metapackages if they want to make a different choice [09:26] I appreciate that that doesn't make everyone happy [09:26] mvo: working on https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations - wgrant asked whether we should be generating Translation-C rather than Translation-en. What does apt do in the LANG=C case? [09:27] cjwatson: Since ubuntu-minimal recommends not to remove it, I was hesitant to do so. [09:28] mvo, there we go http://paste.ubuntu.com/642501/ [09:29] cjwatson: it will not download anything for LANG=C currently [09:30] ogra_: woah [09:31] yeah, looks evil [09:36] mvo: should it? [09:36] cjwatson: I'm not really sure if it makes sense to have Translations-C, conceptual its nice because it means we can have "real" description in -C and "translated" description in -en (translated in the sense that it allows out-of-band description overwrites and typo fixes). but it would also mean that the -C would have to be downloaded all the time in addition to the -en one [09:36] I'm not sure why you'd have to download it in addition [09:37] just the translated one would be fine [09:37] the -en one? [09:37] sure, if it had basically all the same data [09:38] right, that would be fine. the only remaining issue is that the ddtp stuff is (much) less often updated at least currently [09:38] my concern is for sysadmins who use LANG=C and still want 'apt-cache show' to be useful [09:38] so -C would be more fresh then -en most of the time [09:38] yeah, the LANG=C is a good point [09:39] we could simply provide both (even via a symlink) [09:39] a symlink could work, yes [09:40] though that gets me into more complicated bits of the publisher :-/ [09:40] :( [09:40] so far my patch is fairly straightforward [09:41] alternateively I can make it download Translations-en if you run LANG=C as a fallback [09:42] cjwatson: uhh, sorry, I was wrong, its actually already taking care of this [09:42] cjwatson: so "C" will simply queue Translations-en for download [09:43] * mvo notes that it helps to look at the right spot of the code… [09:45] mvo: oh, excellent [09:45] mvo: can you point me to the right spot? I did look but failed to find it [09:46] apt-pkg/aptconfiguration.cc, there is a envShort == "C" test in it [09:46] cjwatson: in getLanguages() [09:46] cjwatson: the code is a bit hard to follow unfortunately [09:47] mvo: perfect, much appreciated thanks [09:47] yw [09:47] this will require downtime to deploy AIUI, but the wheels are now in motion [09:48] great, thanks a bunch for driving this :) === psurbhi is now known as csurbhi-debuggin [10:43] mvo: I think we'll need a backport of apt to lucid to add LongDescription support. Could you take care of it? === daker_ is now known as daker === hunger_ is now known as hunger [11:03] mvo: if it isn't appropriate for lucid-updates (I guess it might not be), https://launchpad.net/~launchpad/+archive/ppa ought to be fine [11:05] mvo: so I guess that's at least 1327.52.28, 1327.52.29, 1327.65.10, and maybe 1327.84.57? === MacSlow is now known as MacSlow|lunch [11:24] hey guys I had the same issue as before with the kernel update last night on oneiric in that the keyboard and mouse don't function once x is started, works fine if I go into safe mode from grub but stops the minute I start lightdm or startx [11:25] mvo, the page about verifying SRUs: https://wiki.ubuntu.com/StableReleaseUpdates#Verification [11:25] mvo, it says that the SRU team will test the -proposed packages [11:25] but I guess that actually anyone can test them, am I wrong? [11:25] if that's the case, the wiki is a bit confusing [11:39] cjwatson: hi, I just came back from lunch. apt> I need to check, but I'm happy to do it (unless you cherry-picked the patches already [11:39] ara: yeah, anyone can [11:39] mvo: I haven't, hands still a bit full with LP bits [11:40] trying to set up to QA your python-apt backport [11:41] cjwatson: great, I will do the cherry pick now then === ximion_ is now known as ximion [11:42] thanks - I think I have a basic setup suitable for validating it [11:42] though outside the context of P [11:42] LP [11:54] davmor2: bug #807306 is your winner. [11:54] Launchpad bug 807306 in mountall (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X - incomplete migration to /run" [High,Triaged] https://launchpad.net/bugs/807306 [11:55] mvo: hmm, I wonder if it'll break anything that this causes 'apt-cache show' to display Description-en fields rather than Description [11:55] RAOF: Thanks [12:11] I thought there was supposed to be a /var/lock symlink to /lock for backwards compatibility in Oneiric? [12:12] soren: ITYM s/lock/run/; that's what slangasek is working on [12:12] My sbuild complains: E: Can't create lock file /var/lib/schroot/mount/oneiric-amd64-abf2953c-aa36-4fa9-bd6a-311004445b44/var/lock/sbuild: No such file or directory [12:12] Hmm... [12:13] * debian/1777-dirs: remove /var/lock (replaced by /run/lock on tmpfs) [12:13] ^ base-files 6.3ubuntu3 [12:13] i. e. this transition is incomplete [12:13] soren: sorry, you are right [12:13] soren: same answer, though [12:13] Ah :) [12:13] Had me confused there for a little bit. [12:14] soren: Yeah; just create /var/run in your chroot and it'll work again. [12:14] Ok, if the fix is in the works, that's great. I'll ninja my way out of it for now. [12:16] Yay. sbuild is all smiles and giggles again now. \o/ === MacSlow|lunch is now known as MacSlow [12:39] barry: ping [12:43] kirkland, pong [12:43] barry: so i dug through all the Ubuntu code I have in my /local/source/* directory [12:44] barry: the *only* way i could see that an .ecryptfs dir *might* have been removed is if you tried to deluser with the --remove-home option [12:44] barry: i don't know if you would have done that in your chroot [12:45] barry: but your report bothered me sufficiently that I had to do some digging [12:46] kirkland, no, i definitely didn't do that. thanks for digging into it though. very strange. i'm going to rebuild the machine today [12:46] kirkland, but i found a spare disk, so i'll make a backup. i can't see submitting a bug report since i don't even know for sure it's a bug (or where) [12:47] barry: cool [12:56] cjwatson: https://launchpad.net/~mvo/+archive/apt-ftparchive-lucid <- that ppa has the backport, should work, I verified it with lp:~mvo/+junk/apt-ftparchive-testsuit === Ursinha-afk is now known as Ursinha === doko_ is now known as doko [13:11] pitti: yeah did that already! Thanks! [13:20] Man thunderbird is heavy on CPU 90-132% usage :( on oneiric [13:22] 2 - 4% here [13:22] average [13:23] dupondje: I think it's just the importing, I'm going to check it again, once it's finished. [13:24] pitti: hi! did you get my email about ubuntu-sru? [13:35] hey mdeslaur [13:36] mdeslaur: I did, just didn't answer yet, sorry; the queues are empty right now, so we need to let them fill again [13:36] before we can do some examples [13:36] pitti: ah, cool...no rush :) thanks! [13:39] http://paste.ubuntu.com/642025/ => could this be a kernel bug? Or surely hw issue ? === ximion1 is now known as ximion === manjo` is now known as manjo [13:58] mvo: looks like we need 1327.95.5 as well for data.tar.xz support (bug 619152) [13:58] Launchpad bug 619152 in Launchpad itself "Add data.tar.xz support" [Low,Triaged] https://launchpad.net/bugs/619152 [13:59] actually I guess that's bug 805389 [13:59] Launchpad bug 805389 in python-apt (Ubuntu Lucid) "Support xz compression inside debs" [Medium,Fix committed] https://launchpad.net/bugs/805389 === shadowstalker is now known as jsmith-argotecin === jsmith-argotecin is now known as shadowstalker [14:03] cjwatson: hm, the python-apt bits I uploaded to lucid-proposed iirc [14:04] mvo: yes, but there's a bit in apt-inst too [14:04] I have your python-apt bits installed [14:04] cjwatson: ok, I have a look now [14:05] this is at least going faster now that I have a working LP dev VM === achiang` is now known as achiang [14:07] does it qualify for a bug if a process exits instead of either refreshing its configuration files or ignoring the signal on 'kill -1'? [14:08] tomreyn: I would say a wishlist bug. It might be convenient, but there's no rule for what processes must do on SIGHUP [14:09] and the default for SIGHUP is to terminate the process, which is appropriate for things that aren't long-running === shadowstalker is now known as jsmith-argotecin === zyga is now known as zyga-food [14:11] thank you. [14:16] somebody knowing by chance the deeper meaning of --dynamic-list-cpp-new --dynamic-list-cpp-typeinfo? === dendro-afk is now known as dendrobates === zyga-food is now known as zyga-coffee [14:41] hi guys, quick recipe question if I may: can a recipe file work with local branches or do they have to be lp: style branches? I tried putting a local path in there instead of an lp: branch and it failed [14:41] I'm using bzr dailydeb === zyga-coffee is now known as zyga [14:45] ahasenack, abentley and james_w probably know best [14:45] ahasenack, it should work with local branches [14:45] ahasenack, but obviously such a recipe isn't suitable for LP :-) [14:46] james_w: oh, I think this is a pbkac [14:47] james_w: dholbach; sorry, I had the wrong paths in my recipe [14:47] and jumped to conclusions [14:48] no worries :) [14:48] as long as you figured it out now it's all good :) [14:49] ofcourse, I'm getting another error now, but I will really read through it before posting it here :) === chrisccoulson_ is now known as chr1sccoulson [15:02] mvo: your previous ftparchive backport for LongDescription looks good [15:03] so bzr build doesn't actually build, it just puts the requested branches in place, ready for a build [15:04] cjwatson: great, I'm looking into the xz stuff now [15:04] I don't know what it does to the version/release the recipe specified, the debian/changelog is pristine from the branch [15:04] cjwatson: I suppose you want the full support, right? including everything that ftparchive is doing? [15:04] I think LP might need that yes [15:05] ok [15:05] pitti: is there a way to bypass the apport "This is not a genuine Ubuntu package" error for testing purposes? [15:07] mdeslaur: a slightly hackish one: let it complain, then edit the .crash file and remove the UnreportableReason:, then run the crash file through apport-bug again [15:07] pitti: ah, cool, that'll work thanks [15:08] mdeslaur: package hooks can decide to skip the check, too [15:08] if that's closer to your use case [15:08] by setting somethign like report['CrashDB'] = 'ubuntu' [15:10] pitti: thanks [15:12] james_w: hi, sorry to ping directly, I'm getting this error: bzr: ERROR: Invalid deb-version: {debupstream}+14-0ubuntu0+2: Could not parse version: {debupstream}+14-0ubuntu0+2 Pastebin here: http://pastebin.ubuntu.com/642701/ [15:13] I think your bzr-builder is too old for {debupstream} [15:14] oh [15:14] I got it from the ppa [15:14] dailydebs-team-bzr-builder [15:15] only oneiric has 0.7 [15:16] hmm [15:16] but I'm on lucid, yes [15:16] my bzr is 2.4.0~beta4-1~bazaar1~lucid1 [15:16] I thought that newer versions also told you want the valid substitutions were, and your error message doesn't contain that [15:16] (also from a ppa) [15:16] hmmm [15:17] I don't know why the ppa wouldn't have got a newer version [15:17] james_w: what is launchpad using, do you know? [15:17] eventually I want to try this out there, I'm just ironing out some obvious bugs locally first [15:18] it's using something recent enough, I don't know the exact version thoguh [15:18] I remember using recipes in LP several weeks ago, and I used debupstream without problems [15:19] maybe I have some typo or subtle syntax error here [15:19] cjwatson: I uploaded a new version with the cherry pick of the xz stuff to https://launchpad.net/~mvo/+archive/apt-ftparchive-lucid please let me know if it looks good, did only very light testing this time [15:21] james_w: I now tried with just "deb-version 0.1.0-1~{revno}", and got: [15:21] bzr: ERROR: No such tag: upstream-0.1.0 === seb128_ is now known as seb128 [15:37] https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 2 starting in 23 minutes in #ubuntu-classroom [15:50] ahasenack, double odd, as I think that's a brand new bit of code that would give that error :-) [15:50] james_w: the tag one? [15:50] yeah [15:50] james_w: maybe it leaked into that ppa then [15:51] james_w: fwiw, I uploaded the recipe to lp and am building there now, it seems to be working: https://code.launchpad.net/~landscape/+recipe/landscape-txstatsd-daily-test [15:51] james_w: except for the "2h to build" part :( [15:51] that's why I wanted to try locally too [15:51] ahasenack, yeah, it's on trunk, so should be in the PPA, but it's odd that one error suggests you are using really old code, and the other error suggests really new code :-) [15:51] I must be misremembering [15:52] ahasenack, try with --allow-fallback-to-native to get around the "no upstream tag" error [15:54] james_w: worked with 0.1.0-1~{revno}: https://pastebin.canonical.com/49640/ [15:54] cool [15:54] should work on LP then [15:55] james_w: but broke again once I used {debupstream} [15:55] bzr: ERROR: Invalid deb-version: {debupstream}-1~14: Could not parse version: {debupstream}-1~14 [15:56] hmmmmmmmm [15:56] and it doesn't say "here are the valid substitutions?" [15:56] same cmdline, with --allow-stuff [15:56] james_w: full output: http://pastebin.ubuntu.com/642724/ [15:56] I just replaced 0.1.0 in the recipe with {debupstream} [15:57] ok, give me two minutes [15:57] ok === beuno is now known as beuno-lunch [16:00] ah debupstream is excluded from the "here are the valid substitutions" code for some reason [16:01] cjwatson, who is the right person to talk to to figure out why a package is getting built on architectures not mentioned in its control file; its causing issues with our tooling [16:02] (that is building in a PPA) === serge_af1 is now known as serue [16:02] ahasenack, try {debupstream:packaging} [16:02] ok [16:03] james_w: no go: bzr: ERROR: Invalid deb-version: {debupstream:packaging}-1~14: Could not parse version: {debupstream:packaging}-1~14 === deryck is now known as deryck[lunch] [16:03] apw: abstractly, #ubuntu-devel :-) [16:03] still using that --allow switch [16:03] apw: what issues does it cause? it should just harmlessly fail [16:03] ahasenack, ok, please file a bug [16:03] james_w: ok [16:03] cjwatson, yeah but the tooling is seeing the errors and reporting the failure back instream of moveing the package on, now we could bodge the tools but it'd be nice to fix it if we can [16:03] apw: (but anyway, LP, perhaps bigjools) [16:03] probably two in fact, one about you not being able to get {debupstream} to work, and the other about the error not being at all helpful [16:04] james_w: do you know the project name by memory perhaps? [16:04] ahasenack, bzr-builder [16:04] of course :) [16:05] apw: Out of curiosity, which PPA and package? [16:07] infinity, the canonical-kernel-team PPA and the lts-backports-* packages [16:07] cjwatson, thanks will ask in that direction [16:08] Architecture: any [16:08] apw: ^-- Not seeing how you expect LP to do what you want there. [16:09] ha [16:09] infinity, Architecture: any mean arch-independant doesn't it ? [16:09] That would be "all". [16:09] which means essentially 'i386' no ? [16:10] oh have we borked it ? [16:10] What you want is "amd64 i386", if that's all you support. [16:10] "any" means "build on everything". [16:10] * apw looks foolish and goes figure out why thats not either i386/amd64 or all ... thanks [16:10] It definitely shouldn't be all. [16:10] Unless lts-backports has no compiled code. :P [16:11] we haven't borked anything, any and all have always had these meanings [16:11] james_w: #809412 files, thanks for the debugging session :) [16:11] filed [16:11] cjwatson: I think he meant "we" as "the kernel team". [16:11] aha [16:11] cjwatson, no i meant ... yeah what he said [16:11] thanks all [16:11] * ahasenack -> lunch [16:11] yep, sorry, misread === dendrobates is now known as dendro-afk === zyga is now known as zyga-afk === deryck[lunch] is now known as deryck [16:43] can someone do a no-change rebuild of gmime2.4 please? [16:44] for mono transition [16:45] Laney, should we just sync the current version from debian? [16:47] seb128: no, that got accidently made native [16:49] Laney, ok, can do the no change rebuild [16:50] thanks [16:50] yw === beuno-lunch is now known as beuno [16:54] skaet: seems the natty-backport lucid kernel got acked by kernel team (https://bugs.launchpad.net/bugs/806586) -- want to try? [16:54] Ubuntu bug 806586 in linux-lts-backport-natty (Ubuntu) "linux-lts-backport-natty: 2.6.38-10.46~lucid1 -proposed tracker" [Medium,In progress] [16:55] pitti, yes, lets see what happens this time. === dendro-afk is now known as dendrobates [16:57] pitti, same failure on the assert, I'm afraid. [16:57] skaet: weird -- I'm afraid that requires a launchpad guru at this point :/ [16:58] pitti, ack, will go and see if someone can help figure it. [17:01] janimo`, thanks for the gnome-utils build fix, do you plan to send it to upstream as well? === Ursinha is now known as Ursinha-lunch === daker is now known as daker_ [17:55] the vt6410 pci raid/ide card doesn't work in ubuntu 10.10 [17:58] good night everyone [17:59] nite [18:21] mvo: ping [18:25] has anyone ever gotten a pci vt6410 raid/ide card to work in ubuntu 10.10? [18:25] Phr3d13: whats not working? Tried 11.04 ? Do you find anything on google about it ? [18:26] ubuntu sees the card, but not any drives attached to it, and i have googled, but can't find any confirmed or unconfirmed fixes [18:26] any info i found is really ol [18:26] d [18:27] can you pastebin info of lspci -vvv ? [18:28] http://pastebin.com/pRSx2w6a [18:29] line 213 is the controller [18:30] it is supported ? [18:30] pata_via is loaded for it [18:31] i'm not totally sure [18:31] another reason i'm asking in the devel room [18:33] can you pastebin dmesg ? [18:33] cause card seems supported [18:35] i couldn't get it all [18:35] seb128, filed https://bugzilla.gnome.org/show_bug.cgi?id=654498 [18:35] Gnome bug 654498 in libgdict "casting error on ARM" [Normal,Unconfirmed] [18:35]