[00:03] Who do I poke for a higher PPA size limit? [00:11] YokoZar: ask a question at answers.launchpad.net/soyuz i think === kees___ is now known as kees [01:04] Is it just me, or is sbuild rather broken in natty? [01:06] * TheMuso notes he is not currently using a .sbuildrc [01:08] Not broken, but certainly *seriously* chatty about debug_level [01:09] Certainly not screen-reader friendly :) [01:11] heh right. I was wondering whether that had to do with why packages/essential build deps step is failing... Maybe my chroot is broken... [01:11] I.e essential build deps not being satisfied. [01:11] Oh, that. [01:11] I don't think I hit that brokenness because I use the aptitude resolver. [01:11] Ah. [01:12] (Because I need to build against Debian experimental sometimes, and that requires the aptitude resolver to work properly) [01:12] Right. [01:12] How does one change that? [01:12] $build_dep_resolver = 'aptitude'; in ~/.sbuildrc [01:13] Thanks, not mentioned in the example. [01:15] Ah much better. :) [01:17] Oh it failed because there are actually broken packages in the archive. :) [01:19] Heh [01:20] RAOF: following up from the conversation yesterday, do you think that delaying X from changing modes until g-s-d is up is something that could happen this cycle? [01:20] ebroder: Yes, I think it could. [01:21] I'll be walking through that code as a part of the multi-monitor experience stuff anyway. [01:21] Cool. Do you know yet when you expect to be looking at it? (It looks like I may need to attempt to backport whatever you come up with for work) [01:22] I was going to wait until we'd decided whether or not we were going to ship xserver 1.10; that'll be the beginning of December. [01:23] I could re-order that, though, and just work on xserver master (+ possibly backporting) anyway. [01:23] I don't want to make you go out of our way - I'm just making sure I know what to tell my boss when he asks :) [01:59] I have found the information in sysfs needed to decide that a disk is esata, and therefore udisks should auto mount it, but I'm a little confused and as a result, can't figure out how to have udev extract that information. Specifically the disk device is a child of a scsi target, which is a child of a scsi host, and the scsi host has a scsi_host/hostN/ahci_port_cmd file with the bit that says it's eSATA. [01:59] but it seems that udev searches for attributes walking up the tree, but you have to go back down a level to reach that attribute... which I can't make sense of or figure out how to get udev to do [02:01] it seems like sometimes a subdirectory in sysfs means it is a new device that is a child of the parent, and sometimes subdirectories are... personalities, for lack of a better term, of the device, but I can't figure out how to tell the difference or how to get udev to look at the attributes of a personality === asac_ is now known as asac [02:38] Ah. So thats why compiz is broken installability wise. [02:39] Hrm but the build log shows things correctly... [02:42] Hrm, mirror skew. [02:42] * TheMuso refreshes local mirror. [04:16] How would people feel about SRUing the fix for bug #589487 to Lucid and Maverick? [04:16] Launchpad bug 589487 in Percona Server "Add INFORMATION_SCHEMA table for time spent in different thread statuses" [Wishlist,Triaged] https://launchpad.net/bugs/589487 [04:16] Sorry - that's Debian bug #589487, ubottu :) [04:16] Debian bug 589487 in update-inetd "pawserv: "postinst configure" hangs" [Serious,Fixed] http://bugs.debian.org/589487 === _LibertyZero is now known as LibertyZero_ === almaisan-away is now known as al-maisan === amitk_ is now known as amitk-afk === amitk-afk is now known as amitk === dendrobates is now known as dendro-afk === hanska is now known as dapal [08:39] Good morning [08:40] superm1: right, it uses optipng and advancecomp on those [08:40] superm1: yes, I did :) [08:40] good morning! [08:40] superm1: http://launchpadlibrarian.net/58704226/optipng-check FYI [08:41] superm1: I used find /usr/share -name '*.png' | ./optipng-check [08:50] cjwatson: FYI, apt-listchanges should now work again as of yesterday evening; I tested it on a bunch of .debs (like on upower, which still has no changelog at all); but I couldn't get the apt-get dist-upgrade integration to work, not even with fully "normal" packages === hunger_ is now known as hunger [08:59] cjwatson: bah - after having said that, it just worked for my current dist-upgrade === Nafallo_ is now known as Nafallo [09:54] pitti: cool, thank you! I haven't upgraded to natty yet [09:55] apt-listchanges works fine in my natty. Upgraded from maverick a couple of days ago. [09:57] ion: it didn't show changelogs for packages which got their debian changelog completely stripped [09:57] that happened for a week === dendro-afk is now known as dendrobates [10:05] tkamppeter: won't coldplugging fail as well if there is no local unix socket? [10:05] tkamppeter: I made my patch so that it skips coldplugging in that case [10:05] tkamppeter: since it's very likely to fail [10:06] tkamppeter: and at that point (if you disable the local socket) you are on your own anyway IMHO [10:06] ah, I finally got cups to build with gcc 4.5 [10:08] lamont, how does the patch in bug 674199 - would you get it into debian too? [10:08] Launchpad bug 674199 in bind9 (Ubuntu) "bind9 1:9.7.2.dfsg.P2-1 FTBFS in natty" [High,Triaged] https://launchpad.net/bugs/674199 [10:08] ... err ... how does it "look to you"? :) [10:12] pitti, cold-plugging only needs the presence of CUPS. CUPS is only accessed via system-config-printer (executables udev-configure-printer and udev-add-printer) and this also works if CUPS is configured for local access via localhost. [10:13] tkamppeter: it tries socket and localhost TCP? [10:14] pitti, s-c-p does not nail down the access method. It simply uses libcups through the pycups byndings. [10:20] pitti, why do you supply the upstart script as a patch? It is one file in debian/ and no change on upstream files, so it is much simpler to supply the file directly. [10:20] tkamppeter: can't, since then it would be used in Debian as well [10:20] well, I don't know the exact reason any more, but having both in debian/ breaks stuff [10:21] yep, apparently it was that [10:22] in debian we need the init.d script === hanska is now known as dapal [10:40] hi everyone! i have a created a custom shortcut to 'gnome-screenshot --area' and it only works if i press it twice (fast). running the command from the terminal and via a panel launcher works fine. is this more likely a bug in gnome-screenshot or in gnome-settings-daemon? [10:43] cjwatson, would you object to build dpkg with dropped optimization for arm until the toolchain issue is fixed (so we can build images) [10:52] pitti, thanks for the patches on the PDF filters so that they build under GCC 4.5.x. I have upstreamized the changes now. [10:52] ogra: I'd rather have actually analysed the problem first [10:52] nobody else's images work yet either :) [10:52] cjwatson, indeed, but i'd like to have something by A1 [10:52] no hurry yet indeed === al-maisan is now known as almaisan-away === MacSlow is now known as MacSlow|lunch [11:17] tkamppeter: oh, cool; thanks [11:25] * cjwatson promotes unionfs-fuse temporarily [11:25] (let's see if that helps) [11:36] * pitti takes a first look at oversizedness [11:37] so we added 23 MB of packages and some grew quite a bit (gnome-system-monitor 1.8 MB, linux-firmware 3.9 MB) [11:38] out of interest, why do we currently install two python versions by default? [11:40] oh, and we have libicu42 and 44, both 7 MB [11:40] an OO.o rebuild should get us rid of 32 [11:40] 42, I mean === MacSlow|lunch is now known as MacSlow === ivoks-afk is now known as ivoks [12:18] pitti, how does the WI tracker handle the new spec namings, i.e. it currently mainly points to $team-$release_letter- will it automatically match $track-$teram-$release_letter- with that ? [12:19] s/teram/team [12:19] ogra_ac: it doesn't care about spec names except for the contact point [12:19] k [12:19] ogra_ac: it reads the specs targetted to natty [12:19] ogra_ac: and the contact point regexps over the names have been adapted [12:20] well, i have 'canonical-mobile': 'mobile', in the teams list for my team [12:20] * pitti uploads a fixed pkgbinarymangler to reclaim the 1.8 MB that gnome-system-monitor has grown [12:20] if i change the latter to arm that should just work ? [12:21] 'arm-': ['jb@linaro.org'], [12:21] that's the contact point [12:21] yes, that will go away [12:21] linaro wont use arm- anymore [12:21] thats reserved for ubuntu arm [12:21] ogra_ac: oh, I'm not sure about that "roadmap" thing, this is an apw-ism I believe [12:22] i'm just concerned about the teams [12:22] ogra_ac: so please update the error_contact matches as appropriate [12:22] yes, thats what i plan [12:22] but i'm not clear about the teams stuff yet [12:22] ogra_ac: teams has to include all teams who we want to generate reports for [12:22] yes [12:22] (other than the "all teams" report [12:23] as i said above, my team currently uses the "mobile" tag [12:23] for natty we properly switched to "arm" [12:23] i was just wondering if that will properly match [12:24] linaro will likely do its own thing and drop the 'arm' match from its setup [12:26] ogra_ac: error_contacts does match over the spec names, yes [12:26] and teams ? [12:26] * pitti toddles off for lunch, bbl [12:26] ogra_ac: teams are not a match, they are a simple list [12:26] ah, k [12:26] ogra_ac: I don't know what the "roadmap" bit is for, i. e. the values in the teams map [12:26] then the header is wrong [12:26] # lp team # spec name match to show up in roadmap [12:27] ogra_ac: the value is presumably a spec name match [12:27] but not the keys [12:27] k [12:28] go to lunch :) === zyga is now known as zyga-food === didrocks1 is now known as didrocks === almaisan-away is now known as al-maisan === beuno_ is now known as beuno === zyga-food is now known as zyga === fenris- is now known as ejat === dendrobates is now known as dendro-afk === jorge__ is now known as jcastro [13:47] james_w, pkgme trunk has odd layout: pkgme/pkgme/* instead of pkgme/* === jdstrand_ is now known as jdstrand [14:09] mterry, hmm, that's certainly not what I was intending [14:10] mterry, looks ok to me. Did you just check the branch out as pkgme? [14:11] james_w, just tried it again and it was fine. I must have created a pkgme directory in the past without realizing it, and the branch created a subdirectory for me [14:11] whoops [14:14] mterry, np. How's the vala backend looking? [14:15] james_w, good... I did some yak-shaving with vala-dep-scanner (which discovers dependencies) [14:15] cool [14:16] mterry, you might have seen that trunk now has ./bin/pkgme, and it will work on itself as there is a rudimentary python backend. My next task is to get it to write a changelog, as currently you can't build a source package from it. === tkamppeter_ is now known as tkamppeter [14:36] cjwatson: is it normal that tarballs on merges.ubuntu.com come with patches _already applied_ but no .pc directory? [14:37] good occasion to ask about .pc files in patches created by MoM - can we avoid to not including .pc files? [14:39] ari-tczew: I assume you mean "avoid including .pc files". But why on earth would you want that? [14:40] Chipzz: useless data. merges patched should be as clear as possible. [14:42] ari-tczew: I assume you mean patches which are shipped as a diff as part of the tarball should be applied before doing the diff? [14:42] "as part of the tarball" -> "as part of the debian diff" [14:43] You can use filterdiff to remove the .pc file from the diff you are looking at, but it's not useless data. [14:43] There was a discussion yesterday (I believe) about this [14:43] Chipzz: dunno how, just I hate cutting MoM patches from .pc files. [14:43] I just want to in diff: -x '.pc' [14:43] .pc~ [14:44] but... [14:44] .pc~ looks like a backup [14:44] mdeslaur: 3.0 (quilt), I assume? [14:44] cjwatson: yeah :( [14:44] seriously, you should just have cleaned your shit up and removed stray backup files [14:44] the problem with just removing .pc is that people need to know how to operate on the quilt patches if you do that [14:45] I don't think this can be fixed solely in MoM - dpkg needs to be improved. I filed a bug some time ago about that [14:45] I did think about simply removing .pc from MoM patches a while back, but concluded that it wasn't that simple [14:46] Laney: I never heard about include .pc files in merges. Did I came back from moon? [14:47] ari-tczew: lets for a moment assume you meant .pc and not .pc~ ... what you're asking for is basically doing the patching (ie, a step of the build process) while diff'ing [14:47] and diff'ing has very little to do with building [14:48] sorry, I have no strength to explain in detail what I mean. For me case is clear. [14:49] doko, could you take a look at bug 674146 ? seems to be a toolchain issue [14:49] Launchpad bug 674146 in dpkg (Ubuntu Natty) "dpkg segfaults during debootstrap on natty armel" [High,Triaged] https://launchpad.net/bugs/674146 [14:50] hi everyone, can someone tell me if its possible to drag a foreign window (firefox for example ) to my pygtk aplication? [14:51] skkeeper: wrong channel :) [14:51] shit [14:51] sry [14:51] ogra_ac: isn't james hunt looking at this one? [14:51] i noticed [14:51] xchat changed on me [14:51] xd [14:51] and I don't think you can - not with arbitrary windows anyway [14:51] doko, yes, but not at the toolchain stuff [14:52] doko: did you read my mail about sync gcc-snapshot ? [14:52] ogra_ac: are you sure that this is not due to the optimized memcpy? [14:52] ari-tczew: why? there will be a new snapshot anyway [14:53] doko, doesnt that live in the toolchain ? [14:53] doko: see my comment - I'm pretty certain it has nothing to do with memcpy, it's plain wrong assembler [14:53] cjwatson: why would you want to remove .pc files from patches? or do you mean .pc files which aren't shipped by upstream, but which are shipped by ubuntu? [14:53] Chipzz: sorry, I don't have time to go into this in more detail today again. We had a longish discussion about it here just yesterday [14:54] cjwatson: np, just trying to understand the issue :) [14:54] doko: hmm, I think about upload to Debian first and autosync to Ubuntu. [14:57] Chipzz: are you familiar with merging? [15:01] james_w, how do I run the pkgme testsuite? [15:02] mterry, you can install testrepository and use "testr run" [15:02] and python-subunit too [15:02] mterry, I think setup.py test works as well [15:03] james_w, ah, it does now that I have the packages === dendro-afk is now known as dendrobates [15:08] james_w, do they pass for you? I get errors like "AssertionError: Backend python (/home/mike/Projects/natty/pkgme/build/lib.linux-x86_64-2.6/pkgme/tests/../backends/python) has no 'want' script" and the backends don't seem copied to the build directory [15:11] mterry, ah, I haven't run them with setup.py yet. Seems setup.py is missing some of what we need. [15:11] james_w, testr run gives "ImportError: No module named Cheetah.Template", so maybe I'm missing something [15:14] and after installing python-cheetah and running 'testr init', I get AttributeError: 'module' object has no attribute 'test_backend' from testr run [15:15] cjwatson: heh, catching up with lucid fixes? :-) [15:18] pitti: yeah, a bit :) [15:20] ugh, that fuse upload has quite a diff [15:21] pitti: yeah, as I said in the SRU bug the three upstream patches I backported were so entangled and subtle I reckoned that if I tried to disentangle them I was likely to do more damage [15:21] *nod* [15:21] it was "add --no-canonicalise" "fix race condition [unclear if it was related]" "fix weird interaction between previous two" [15:22] ari-tczew: I've never actually done a merge, but I can imagine how it works, yes [15:23] pitti: just replied to your email... take a look and see if you can help me figure it out... or maybe involve someone more knowlegable about udev? [15:24] psusi: what I don't understand is why you so desperately need this in the udev db [15:25] psusi: why can't udisks check the sysfs attribute? it can then do some more elaborate checks of its parents and siblings [15:25] well, I guess it doesn't have to go there, it just seems to be a good place to put it once it's figured out... seems like what it's for [15:25] with the gudev interface [15:25] I suppose it could... [15:25] psusi: actually it's not; the udev db shouldn't really replicate stuff that's already in sysfs [15:26] we should add new information to it, like "this device is a camera" (ID_GPHOTO), or "don't show this for automount" (UDISK_PRESENTATION_HIDE) or so [15:26] but it seems like it might be better to keep udisks generalized to just checking a well known external attribute on the disk in the udevdb, and leave it to udev rules to figure out if the disk is external... [15:26] we _do_ replicate a few bits for convenience, like from usb_id [15:26] psusi: well, it's a valid approach as well [15:26] mterry, that will be another missing dependency. Probably python-fixtures, that I think is just in natty [15:27] psusi: you could just join #udev, explain the situation a bit, and then we'll discuss with davidz and kay [15:27] ok [15:27] psusi: i. e. the bit that we need to check is in the parental chain? [15:28] ah, no, nevermind; saw your mail [15:28] james_w: barry: hi, ISTR a recent email about UDD talking about .pc/ inclusion. Was there such an email, and what did it decide? [15:28] james_w, apt-cache search fixtures doesn't come up with anything named that, and the couple packages that it does hit don't make the testr run error go away (i'm in natty) [15:29] pitti: yea, up, but then back down another branch for some reason [15:29] Chipzz: my advice: do some merges and then talk about .pc utility in patches. [15:29] hallyn, there was, it is on my to-reply list [15:30] mterry, hmm, maybe it's not landed in natty. I thought Rob uploaded it [15:30] barry, what's the best way for mterry to continue? [15:30] james_w: ok, thanks. [15:31] ari-tczew: the .pc files are a limitation of source format 3.0 (quilt) [15:31] cjwatson: as far as you know, is there any bug report about ubiquity not making the installation possible because of the user account chosen starting with a capital letter? [15:32] cjwatson: from what I seen it makes the installation not possibile without a warning; do you plan to add a warning for that? [15:32] BlackZ: are you going to merge sbuild? [15:32] ari-tczew: no need to belittle me; I follow the conversations here closely, and I try to be aware of how things work [15:33] barry: hi! [15:33] james_w, I'm not blocked. setup.py test works for me, as long as I copy the backends into place [15:33] ari-tczew: and IMO you're the one that's wrong; if ubuntu ships a .pc file that doesn't exist upstream, that IS an integral part of the diff [15:33] Chipzz: I only show the way to the best understand. [15:33] ari-tczew: what if the .pc accidently gets dropped? [15:33] mterry, ok, great [15:33] ari-tczew: I'll merge it but if you want to, I don't mind :) [15:34] james_w: actually, I will 'hi' you too :) [15:34] Chipzz: merges should include only really required changes. [15:34] hi jdstrand [15:34] pitti, any idea who from the SRU team pushed alsa-utils to updates ? the fix is not done yet at all [15:34] barry, james_w: I am having trouble with udd. see http://paste.ubuntu.com/530751/ [15:34] ogra_ac: it was verified.. [15:34] huh ? [15:34] Chipzz: sorry, I don't have a time to explain how merge works if you didn't done any merge and you think that I;m wrong. [15:34] i talk about bug 637947 [15:34] Launchpad bug 637947 in linux-ti-omap4 (Ubuntu Maverick) "no sound devices on current ES2.0 boards" [High,Fix released] https://launchpad.net/bugs/637947 [15:35] james_w, barry: basically, with libvirt, we have been doing the whole 'quilt push -a ; bzr add' methodology [15:35] james_w, barry: but the tree with my commit yesterday for 0.8.5-0ubuntu1 totally blew apart with today's 'bzr update' [15:35] (a gagillion conflicts) [15:35] pitti, it definitely wasnt verfied [15:36] and its totally broken in -updates now [15:36] BlackZ: already fixed in natty - bug 555896 [15:36] Launchpad bug 555896 in ubiquity (Ubuntu) "Username starting with upper letter marked as OK during install and the refused" [Medium,Fix released] https://launchpad.net/bugs/555896 [15:36] ^^ [15:36] cjwatson: I thought that, thanks! [15:36] so I compared the apt-get source with what is in a newly checked out branch, and see that there are some slight differences... (as seen in the paste) [15:37] BlackZ: no, just I'm amazed that you didn't take this one yet :) (I know that sometimes you can response quickly) [15:37] james_w, barry: ^ (this is a source format 3.0 (quilt)) package [15:37] pitti, ugh, i see what heppened, seems lag just set it to fix released [15:37] based on a totally unrelated comment in that bug [15:37] james_w, barry: is there an official sanctioned way to handle quilt source format 3.0 with udd? [15:38] * ogra_ac curses [15:38] james_w, barry: every time I try to do it with libvirt, it blows up and I waste a ton of time. I seem to be doing it wrong, though I've tried several different things... [15:38] ari-tczew: I'll merge it then; I noted that now [15:38] ogra_ac: so, do we need to pull that alsa-utils package from maverick-updates then, or follow up with a reversion? for armel? was it the kernel or alsa-utils which caused the regressinon? [15:39] pitti, kernel is fine, alsa-utils isnt even near to be finished [15:39] pitti, how hard is it to pull it ? [15:39] ogra_ac, pitti: My bad :( [15:39] i'll have a completed fix on monday [15:40] lag, yeah, the conversation on that bug was quite confusing [15:40] ogra_ac: is 3.3 enough? [15:40] ogra_ac: we could upload a 3.5 which is 3.3 [15:41] pitti, i had uploads from ubuntu3 on, i'm not sure which one would unbreak [15:41] jdstrand, from your brief description it sounds like the right approach to me. I don't have enough info to be able to say straight away why you got the conflicts though. [15:41] pitti, after all it only breaks on omap4, we could still leave it in but be fast with the next upload [15:42] james_w: so the correct approach ismake sure to use 'quilt push -a', 'bzr add', bzr ci? [15:42] ari-tczew: I seen right now that lool merged it [15:42] pitti, if we can do a fast path for the actual 3.5 we shouldnt need to pull it [15:42] jdstrand, yes, I think so [15:42] james_w: right, so that is what I did :) [15:43] james_w: but if you look at the paste, there is a difference between the apt-get sourced package and the branch [15:43] BlackZ: ok sorry then for messing your head :) [15:43] james_w: which presumably has to do with the quilt source format 3.0 stuff... [15:43] jdstrand, right, that may be different dpkg-dev versions? [15:43] ogra_ac: so looking at https://launchpad.net/ubuntu/maverick/+source/alsa-utils/+changelog it seems that all SRUs were omap4 related, so if it causes trouble, we could pull it; but I'd prefer a new version, as we can't otherwise get it off people's systems [15:44] pitti, ok, then just leave it as is and i'll have a fix on monday [15:44] james_w: ugh. I'm on maverick, the package is natty and I don't know what udd used behind the scenes... [15:45] and, you shouldn't have to (he mumbles) [15:45] james_w,jdstrand: I've found that I generally have to do 'bzr add .pc/new-patch-name.patch/*' or life is inconsistent [15:45] cjwatson: I did that [15:45] (and there's a udd bug about that, I blieve) [15:45] jdstrand, hardy with a backported dpkg-dev I think [15:45] *believe [15:45] and, you shouldn't have to (he mumbles again) [15:45] hallyn: indeed not [15:45] cjwatson: well, much more generally, I just did 'bzr add' [15:45] hallyn, I absolutely agree, but bugs happen [15:45] ogra_ac: ok [15:46] * jdstrand can't decide on the most robust approach... [15:46] james_w: my problem with keeping the patches applied is that when you refresh patches, bzr doesn't seem to want to do the right thing with updating .pc/ contents [15:47] hallyn, agreed [15:47] james_w: slight history, hallyn and I (and soren) are trying to coordinate our libvirt work with udd [15:47] (and it complicates updates in general) [15:48] but, ok, - i wanted to check whether 'keep the patches applied' is the accepted best practice [15:48] yeah. it hasn't worked right yet... I feel like we are doing it wrong cause people are obviously using it, but based on feedback just now, it seems we are using the recommended procedures [15:48] hallyn, it is, and it sucks [15:48] hallyn: we talked about this yesterday, and what I said, in brief, was that for my own 3.0 (quilt) packages in bzr I just don't revision-control .pc, and that for the most part this works better *except* that people have to know to run a magic command after checking out or (sometimes) updating the branch [15:48] Hey there, do any of you devs know when the 260 series of NVIDIA drivers will be made available via Ubuntu --> System --> Administration --> Hardware Drivers? [15:48] cjwatson: do you quilt pop -a or just bzrignore .pc? [15:49] I keep patches pushed, quite deliberately [15:49] I just don't check in .pc [15:49] hallyn: I guess we can try to bzrignore .pc [15:49] but this doesn't work well when the importer touches the branch (so I try to avoid that happening ...) [15:50] if the importer has already given you a .pc, you need to keep it consistent [15:50] an inconsistent .pc is worse than either other option [15:50] cjwatson: can you explain that last comment? how do we keep the importer from touching the branch? [15:50] Hey there, do any of you devs know when the 260 series of NVIDIA drivers will be made available via Ubuntu --> System --> Administration --> Hardware Drivers? [15:50] do absolutely everything in bzr, mark-uploaded before uploading, etc. [15:51] * jdstrand will need to read the latest on UDD [15:51] I think I am out of date... [15:51] littlegirl: have you searched the bug database to see if there's a thread there? repeating your question here probably won't help [15:52] Is there a way to search for LP bugs linked to a particular Debian bug? [15:52] ebroder: yes, but it's a bit obscure, one moment [15:52] cjwatson: The bug database contains the bug that lead to this question. I'm not asking about a bug. I'm asking when the latest version of the NVIDIA driver will be made available in Ubuntu. This seems like the most appropriate place to ask that question. [15:53] hallyn: I didn't "bzr mark-uploaded" [15:53] I was unaware of that command [15:53] littlegirl: I'm asking because if you have a bug number I might be able to interpret it better. (I don't know anything about nvidia) [15:53] jdstrand: i've never heard of it [15:53] james_w, cjwatson: thanks [15:54] hallyn: https://wiki.ubuntu.com/DistributedDevelopment/Documentation. specifically 'Uploading a package' === yofel_ is now known as yofel [15:54] cjwatson: It's not about a bug. I am asking when the most recent NVIDIA driver will be made available via the Ubuntu --> System --> Administration --> Hardware Drivers interface that comes by default with Ubuntu. This has to be a bug in order for developers to help me with it? [15:55] ebroder: https://bugs.launchpad.net/bugs/bugtrackers/debbugs/ [15:55] cjwatson: Awesome, thanks [15:55] littlegirl: well, I don't know the answer to that question. If you happened to have a bug number I might have been able to make an intelligent guess. And no, it's not usually best to just ask here - not all developers are on IRC, particularly not at any given time [15:56] it seems to be in 10.10 already; as for lucid, I don't know [15:56] (but I'm just looking at package versions here) [15:56] cjwatson: Here is the bug: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/629910 and here is the solution: http://www.nvnews.net/vbulletin/showthread.php?p=2314331 but the solution is not available via Ubuntu --> System --> Administration --> Hardware Drivers. [15:56] i suspect #ubuntu-kernel is the place to ask? [15:57] cjwatson: If the developers cannot be contacted via IRC, how do I contact the developers that are in charge of the Hardware Drivers interface? [15:57] or #ubuntu-x [15:57] you shouldn't contact the developers responsible for Hardware Drivers for this. [15:57] cjwatson: so, iiuc, I do a branch, I do my quilt work, I bzr add debian/patches (ie, ignore adding .pc), then bzr mark-uploaded, then bzr push. [15:57] Lucid is the LTS. Why is a fix that is in place in 10.10 not in place for the LTS? [15:57] the change wouldn't be made by changing that interface, it would be made by upgrading the nvidia-graphics-drivers package [15:57] cjwatson: (I forgot to commit in there, but you get the idea) [15:58] littlegirl: We are probably not going to do a significant update like for an Ubuntu version that's already been released. However, there are generally newer versions of the proprietary NVIDIA and ATI drivers available at https://edge.launchpad.net/~ubuntu-x-swat/+archive/x-updates [15:58] lots and lots and lots and lots and lots of changes are in later versions and not in the LTS - the LTS only gets high-priority changes [15:58] tseliot is the developer assigned to that bug [15:58] he's not here right now [15:59] but he would be the person to ask, I imagine === dendrobates is now known as dendro-afk [15:59] of course, that bug as such doesn't seem to apply to 10.04 - it's about a regression in nvidia 256.53, and 10.04's version is older than that (195.36.24, by the looks of things) [16:00] ebroder: Thank you for the link! If I add that PPA to my system, will the Hardware Driver interface offer me the latest driver or will I still have to add that manually? [16:00] jdstrand: this only works if the branch doesn't already have a .pc [16:00] littlegirl: I honestly have no idea [16:01] Also, it is a very bad idea for you guys not to fix this in the LTS, since it *is* an LTS. This is a serious bug that affects text scrolling in everything (terminal and text programs) and I can't believe you would want to leave the LTS in such a condition. [16:01] cjwatson: the main point of my question isn't a rehash of UploadingAPackage but getting at your workflow for avoiding .pc breakage [16:01] ebroder: Well, thank you again anyway. That PPA will probably be a huge help. (: [16:01] cjwatson: hmm. so I guess we have to fiddle with .pc (it is already there) [16:01] littlegirl: "you guys" - the person who'd be involved isn't here so that's a rather misdirected comment [16:02] cjwatson: thanks [16:02] jdstrand: all of the 3.0 (quilt) packages I care about, I imported by hand myself from previous revision control systems [16:02] I don't have a good answer for such packages imported by the UDD importer [16:02] cjwatson: 10.04 has 195.36.24, which is way behind. [16:03] * jdstrand wonders if we should just ignore the importer branch... [16:03] littlegirl: it really is best to raise this kind of thing through the bug tracker, honestly [16:03] !sru | littlegirl [16:03] littlegirl: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [16:03] cjwatson: It was a general comment regarding whatever the approach is to the LTS. [16:03] cjwatson: it would seem I could just bzr --remove .pc and commit and then be ok, no? [16:03] jdstrand: I don't know [16:03] littlegirl: if you read that page, you'll see the policy reasons why "old" (ie stable) things are kept around [16:04] it's possible the importer will try to put it back [16:04] maco: I understand about stable things. This is an unstable thing. (: [16:04] (note that these policy reasons are *not* "we don't want to fix important bugs") [16:04] james_w: who should I talk to about the importer and the libvirt branch? (I realize this isn't really your main focus these days) [16:04] er...that bug just has a link to other stuff... [16:06] jdstrand, I'm happy to talk to you about it, I'm just in the middle of something OMFG URGENT right now, so if you can wait until later I'm happy to chat [16:06] james_w: sure. thanks === dendro-afk is now known as dendrobates [16:07] cjwatson, have you heard of issues with 'all' of a users initramfs's becoming dammaged during an update? [16:07] cjwatson: thanks again to you too :) [16:07] cjwatson, do we regenerate them all if the tools are updated ? [16:08] apw, cjwatson Which was lucid in my case [16:08] It was a bigger update though I did not pay attention on what changed [16:09] Just seemed that three versions of initramfs were updated into an unusable state [16:09] see bug 672964 [16:09] Launchpad bug 672964 in linux (Ubuntu Lucid) "2.6.32-26 unbootable: does not find root file system" [Critical,New] https://launchpad.net/bugs/672964 [16:09] hallyn: whenever I have my chat with james_w, I'll try to figure out a robust way to udd libvirt, commit my little patch and see how it goes. then I'll talk to you and soren about the new procedure. we can reevaluate if it doesn't work again [16:10] jdstrand: awesome, thanks [16:11] jdstrand: i'd like to listen in on yoru conversation, but i've got far less experience with udd than you, obviously - so i only have my blind unreasonable prejudices :) [16:11] * hallyn figures that makes him perfect for arguing on irc [16:11] hallyn: well, I think you are giving me too much credit. I've had many failures with udd. They are certainly experiences, but to say I have experience with it is probably overstated :) [16:12] hallyn: but I'll ping you [16:13] apw: not heard of such issues, no. bootchart regenerates all initramfses, but I don't think other packages do [16:13] cjwatson, the error on boot is this "udevadm trigger is not permitted while udev is unconfigured" [16:13] don't know, sorry [16:14] that isn't totally fair. I have had some successes outside of libvirt [16:14] cjwatson, would udev updates not need to regen as well === jjohansen is now known as jj-afk [16:14] no, most packages should only regenerate the *current* initramfs [16:14] by design [16:14] bootchart is a bit unusual because you're going to want to compare multiple kernel versions [16:14] cjwatson, ok there was a udev update 3 days ago on lucid [16:14] that symptom sounds as though update-initramfs was run between udev unpack and configure [16:14] udev itself will not be directly at fault [16:15] and as the message is the udev, .... i suspect that update has triggered the issue somehow [16:15] no [16:15] something else was doubtless upgraded at the same time as udev, and called update-initramfs at an inopportune point [16:16] but it's not udev's fault [16:16] oh in parallel ... ick [16:16] however, udev could avoid the problem by making its initramfs hook more robust [16:16] -copy_exec /sbin/udevadm /sbin [16:16] +if [ -e /sbin/udevadm.upgrade ]; then [16:17] + copy_exec /sbin/udevadm.upgrade /sbin/udevadm [16:17] +else [16:17] + copy_exec /sbin/udevadm /sbin [16:17] +fi [16:17] That still seems a little racy [16:17] [note: check that that copy_exec syntax actually works, in lucid as well as in more current releases] [16:17] cjwatson, Maybe you would see more in dpkg.log. I updated the bug report with those [16:17] maintainer scripts are not going to race with commands inside the update-initramfs run [16:18] Oh, I see. Yeah, that's fine [16:18] smb: grep 'initramfs.*all' /var/lib/dpkg/info/* [16:19]