=== slank is now known as slank_away [00:44] the updater is trying to install nvidia-current but my card is unsupported should i skip that update? [00:45] tion, details? [00:48] the current drivers dont support FX5000 series [00:49] tion, explain more what you're trying to do [00:49] i had to revert back to 173 v driver to get OGL support back [00:49] now updater is pushing nvidia-current again along with xorg updates [00:50] tion, keep on going [00:51] the updater is trying to install nvidia-current but my card is unsupported should i skip that update? [00:51] are you just making conversation? [00:51] tion, no [00:53] http://www.ubuntuupdates.org/package/ubuntu-x-swat/precise/main/base/nvidia-current?id=436581&page=3 [00:53] it reads that only 6 gen and up are supported [00:54] that's true [00:54] xnox: Your nagios-plugins merge is dragging in a ton of new Perl modules. [00:54] i cant update im f*** [00:54] xnox: Not that I mind. I <3 Perl and all. But MIRs, please. Or drop the deps. Whichever. [00:56] tion, I'd need to know more to give you a proper answer. Like how did you install -173, what version(s) you had installed previously, what version of ubuntu you're running, etc. [00:56] tion, with so little info all I can guess is if it's offering to move you to an incompatible driver, maybe you manually installed nvidia and your system's broken. [00:57] i installed 173 from the hardware icon [00:57] tion: On which release? [00:57] 12 [00:57] 12.04 or 12.10? [00:58] lms [00:58] tion, and now the updater is saying it wants to uninstall -173 and move you to -304? [00:59] after i installed nvidia-current that actually updated to V 3xx and i lost OGL support [01:00] then a reinstalled 137 again res was 640.480 [01:00] tion, 137?? [01:00] bryce: So, there is a need to update nvidia-173 in precise to support xserver-xorg-lts-quantal, possibly. [01:00] now OPG is working [01:00] bryce: Not that I have any idea if that relates to whatever's being reported here. [01:02] infinity, that's #1064192 [01:02] the problem is nvida current install the wrong version and i lose OGL support [01:02] infinity, I'm guessing tion didn't upgrade his xserver though, so precise's -173 should still work [01:03] so i have to spik the updates ? [01:03] upodater is tring to push [01:03] Nothing should be trying to force nvidia-current on your if it wasn't previously installed... [01:03] s/your/you/ [01:03] tion, maybe, but if it's offering to put something broken on your system, it should not be doing that [01:04] infinity, it was installed and later removed [01:04] tion, do I understand you had -nvidia-173 installed, then you installed nvidia-current, and then again installed nvidia-173? [01:04] yes [01:05] so you have both nvidia-current and nvidia-173 installed? [01:05] no [01:05] so then it is offering to install nvidia-current and uninstall nvidia-173? [01:05] dpkg -l nvidia\* | pastebinit -f diff [01:05] GL_VERSION: 2.1.2 NVIDIA 173.14.35 [01:05] GL_VENDOR: NVIDIA Corporation [01:05] GL_RENDERER: GeForce FX 5200/AGP/SSE/3DNOW! [01:05] Err, without the -f diff. Finger habit. [01:05] Not that it matters either way. :P [01:06] tion: Can you paste the output of "dpkg -l nvidia\*" somewhere? [01:07] tion, do you have any ppa's installed? [01:07] no [01:09] infinity, see pm [01:09] tion: "ii nvidia-current 295.40-0ubuntu1.1" clearly shows you have nvidia-current installed. [01:10] Find obsolete NVIDIA drivers [01:10] If you don't want update-manager trying to upgrade it, just remove it. [01:11] nvidia-173-updates 173.14.35-0ubuntu0. NVIDIA binary Xorg driver, kernel module and VDPAU lib [01:12] are both drivers working at the same time? [01:12] WTF! [01:12] tion, you can have both installed but only one "activated", however it's better to just have the one you need installed [01:13] both say kernel module [01:13] wich is the one actually working right now? [01:13] tion, I would purge all nvidia-*, then reboot onto nouveau and install only nvidia-173. [01:14] tion, lsmod | grep nv [01:14] nvidia 7098356 24 ???? [01:15] "modinfo nvidia" is probably more likely to point you at a path that tells you which one you've built. [01:15] what are the numbers? [01:15] But yeah, just removing the whole lot seems saner. [01:15] tion, yeah try modinfo nvidia, or check dmesg. [01:16] ERROR: modinfo: could not find module nvidia [01:16] Cute. [01:17] OpenGL version string: 2.1.2 NVIDIA 173.14.35 this is the one driver [01:17] that's the mesa driver [01:17] thats actually in use [01:17] what mesa driver? [01:17] no, that's the mesa driver in use, not the kernel module [01:18] well, I mean the OpenGL driver [01:19] tion, https://wiki.ubuntu.com/X/Troubleshooting/VideoDriverDetection#Problem:__Need_to_fully_remove_-nvidia_and_reinstall_-nouveau_from_scratch [01:20] only novou driver supports the new X server? [01:21] will 173 still work after updates? [01:22] which new X server? [01:23] as long as you're not moving to the Q-series xserver you should be fine [06:22] good morning [06:22] xnox: a-i-d-parner> I thought it was merely a collection of .desktop files for software-center to pick up? [06:23] xnox: so if "work with" means "extend", I guess add a .desktop file there, and verify that s-c shows it and is able to install it; the package must be in the partner repo, of course === mossplix_ is now known as mossplix [08:01] good morning [08:08] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [08:10] * dholbach hugs infinity === bambee is now known as rperier [08:50] hi guys, need help: Device /dev/ttyUSB0 is locked (I locked it with pon) - can I send/rcv sms while this gsm modem is connected to the internet? thanks === Tonio_ is now known as Tonio_aw [09:06] pitti: ok. thanks. [09:07] infinity: yeah, noticed. i'll drop stuff instead. === stan_ is now known as stan === Sweetsha1k is now known as Sweetshark [09:43] infinity: openvswitch indeed had cosmic rays on powerpc, built fine after a whack. [09:44] xnox: Good deal. [09:44] infinity: also uploaded nagios-plugins which should stop dragging stuff in. [09:44] xnox: I swear, if we had the hardware resources, I'd build everything twice, and only accept the binaries after proving the output is the same in both runs. [09:45] =))))))))))) [09:45] xnox: I don't really want to know (I really don't) how many subtle bugs in any given piece of software (ours or anyone's, really) is due to random bitflips. [09:46] a modern cpu makes something like 10 000 mistakes a minute =/ to me it's magical any of it actually works =) [09:46] Probably another argument against "make world" proponents, actually. At least we can do targetted fixes if we find something needs a rebuild, they're just throwing it all back at the wall and fixing A while potentially breaking B, C, or D. === henrix_` is now known as henrix === smb` is now known as smb [10:35] hey, I upgraded this morning to 12.10 (from 12.04) everything works fine, just one problem: I have an intel 4000HD ivybridge and I am running VESA VGA :O [10:35] cat /proc/fb --> 0 VESA VGA [10:41] pitti: it fails to _build_? [10:42] mitya57: yes, in: [10:42] ln -sf -python3.3m-config \ [10:42] debian/libpython3-dev/usr/bin/-python3m-config [10:42] the extra - [10:42] I was using the wrong kernel (the one backported from quantal to precise and the real kernel from quantal was not used), it works fine now ^^ [10:43] chrisccoulson: hi - I'm looking at how gnome-session currently shuts down and trying to understand why the following is commented out: http://paste.ubuntu.com/1544640/ [10:43] hm, it built successfully for me both locally and in ppa:mitya57/test1 [10:44] jodh, IIRC it was to stop gnome-session from swallowing those signals so we got crash reports with apport [10:44] but this was a long time ago ;) === henrix_ is now known as henrix [10:49] chrisccoulson: ok, thanks. [10:49] jodh, technically, i think only the call to gdm_signal_handler_add_fatal() needs to be commented out [10:49] i can't remember why we disabled all signal handling [10:50] i've slept and drank beer since then ;) [10:50] chrisccoulson: or perhaps a merge error? in the original patch the commented out section might only have been for SIGSEGV, and in newer upstream versions the SIGTERMs got added? [10:52] pitti: seems like your $(DEB_HOST_GNU_TYPE) is empty for some reason [10:52] pitti, yeah, you're right [10:52] the original patch was http://bazaar.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu/revision/18 [10:52] jodh ^^ [10:52] should be set by dpkg-architecture [10:53] it got changed here by seb128: http://bazaar.launchpad.net/~ubuntu-desktop/gnome-session/ubuntu/revision/233 [10:53] not sure why ;) [10:53] that doesn't look intended [10:54] jodh, so, the short summary is - the patch is only meant to disable the SEGV handler ;) [10:55] mitya57: Which package is this you're talking about? [10:57] https://code.launchpad.net/~mitya57/ubuntu/raring/python3-defaults/resync/+merge/143697 [10:58] Yeah, I just hunted that down from /lastlog [11:00] pitti: I'm kinda with mitya57 on this one. What's breaking your environment? :P [11:01] pitti: DEB_HOST_MULTIARCH is set in debian/rules... [11:01] je ne sais pas; I'll run it again and log in after the failure === henrix_ is now known as henrix [11:02] man dpkg-architecture suggests me to add something like this: [11:02] DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) [11:02] mitya57: Why? You don't need GNU_TYPE. [11:03] Oh! [11:03] You do. [11:03] Wait, how did this work? [11:03] I assumed it was using DEB_HOST_MULTIARCH, which is set. [11:03] * mitya57 looks at his build log [11:04] $ dpkg-architecture -qDEB_HOST_GNU_TYPE [11:04] x86_64-linux-gnu [11:04] in my VM [11:04] pitti: Yeah. This is clearly a bug in debian/rules, I hadn't read far enough. [11:04] But I'm not confused as heck that this works anywhere. :P [11:05] mitya57: include /usr/share/dpkg/architecture.mk [11:05] and then _all_ DEB_(BUILD|HOST)_* vars become available to you =) [11:06] it's much cleaner that way. [11:06] xnox: thanks a lot, I like that much better [11:06] unless pbuilder is being funny inside adt. [11:06] xnox: No, it's the package that's buggy, not the environment. [11:06] infinity: ok. [11:07] But I'm still mind-numbingly confused that this worked on a buildd. [11:07] mitya57: please feel free to ping me when I should give it another go === henrix is now known as henrix_ === henrix_ is now known as henrix [11:08] chrisccoulson/pitti: thanks - bug 1101154 raised. [11:08] bug 1101154 in gnome-session (Ubuntu) "all signal handlers have been removed in error" [Undecided,New] https://launchpad.net/bugs/1101154 [11:11] pitti: I've updated the branch, please test if it builds for you now [11:13] Oh, wait. [11:13] pitti: Does your environment call debian/rules targets raw instead of using dpkg-buildpackage? [11:14] (Not that that's a bad thing if it does, cause that's meant to work) [11:14] Looks like dpkg-buildpackage has started exporting dpkg-architecture's variables to builds. I wonder when that happened? [11:14] But that's why it doesn't fail on buildds. [11:14] Despite the package clearly being broken. [11:15] infinity: indeed, it seems autopkgtest does that; dear Ian, why didn't you use dpkg-buildpackage? [11:15] pitti: Perhaps because he wanted packages to be policy-compliant? [11:15] opts.user_wrap(opts.gainroot+' debian/rules binary'), [11:15] pitti: You did just find a bug after all. :) [11:16] well, yes, but frankly that shouldn't be a bug [11:16] if dpkg exports those for you, then it seems redundant to fix each and every debian/rules files to include them again [11:16] It *is* a bug. But not a particularly critical one, no. [11:16] debian/rules targets are meant to work all by themselves without wrappers, however. [11:16] And it's a bug when they don't. [11:17] Still, if a-d-t is meant to replicate what a buildd does, dpkg-buildpackage -B/-b is probably saner. [11:17] mitya57: so it builds now, but one of the tests fails; hang on, running interactively again [11:18] Still, if a-d-t is meant to replicate what a buildd does, ('dpkg-buildpackage -b -r'+opts.gainroot) is probably saner. [11:18] Err, assuming gainroot is what I think it is. [11:18] (either sudo or fakeroot) [11:19] right, that [11:19] Oh, and a -uc -us on that commandline, so it doesn't vomit when you have no PGP key. :P [11:20] Oh, unless there was a reason he was splitting build and binary targets, maybe? [11:20] To allow for certain trickery? [11:20] So one can test in between targets, maybe... [11:21] mitya57: I get [11:21] dpkg-checkbuilddeps: Unmet build dependencies: python-all [11:22] mitya57: and indeed debian/tests/control does not require this [11:23] mitya57: and once I install python-all, it fails with http://paste.ubuntu.com/1544820/ [11:25] pitti: thanks, will look now [11:27] jodh, thanks === _salem is now known as salem_ [12:03] pitti: can you please paste the full log for dh_usrlocal issue? [12:03] there should be something like: D: dh_python3:80: moving files from debian/python3-foo/usr/local/lib/python3.3/dist-packages to debian/python3-foo/usr/lib/python3/dist-packages/ [12:04] the dependency is now fixed (python-all -> python3-all) [12:05] also, worksforme™ [12:06] mitya57: running again === yofel_ is now known as yofel [12:08] pitti: ah, I've found the issue myself [12:08] EXTENSION_TAG = 'cpython-%smu' [12:08] it should be 'cpython-%sm' for 3.3 [12:09] no, ignore that, I was looking at quantal's code, it's fixed in 3.3.x [12:10] pitti: about app-install-data-partner, I was hoping for a magic script that i can point at the repository & it would fetch all packages, extract and generate all the needed icons/desktop files for me. Since we do that sort of thing for the main ubuntu archive, don't we? [12:10] xnox: I'm not sure, i never really touched either; mvo knows this [12:11] ack. [12:32] xnox, thanks for noticing I'd managed to not include that typo fix in my last openvswitch upload... [12:39] xnox: hi, is it urgent? otherwise we should take monday, its just a script that runs and downloads a bunch of stuff [12:40] mvo: monday is fine. in the mean time i'll try to verify the quantal-proposed to release that before i'll try to do a next round of fixes for oneiric->quantal. [12:40] jamespage: =) just clearing up sponsorship queue. [12:40] xnox, nice one [12:40] xnox: cool, I give you details then, need to look what bzr branch to run myself, but its just ./update.sh on a fast machine, should be automated on some server anyway ideally [12:41] jamespage: I was like "what's the most scary package here, nobody wants to look at? ah openvswitch - hehe just a typo in a comment. win!" [12:42] mvo: i total rekall something along those lines. maybe I even tinkered with it at one point (when my package was missing an icon in Software Centre) [12:42] xnox, I'd noticed the MP and commented and then completely failed to include it when I did the work early this week to upgrade to the new snapshot release. [12:42] happens =) [12:42] yeah [12:42] rrd brain === scott-work is now known as Guest94797 === MacSlow is now known as MacSlow|lunch === cpg is now known as cpg|away [13:28] mitya57: I'm sorry, forgot: complete log is at http://paste.ubuntu.com/1545274/ [13:28] :) [13:29] pitti: in fact, I've finally set up my autopkgtest in pbuilder (as suggested by ScottK), and it fails with a different error for me === slank_away is now known as slank [13:41] pitti: strange, your dh didn't run override_dh_pysupport target at all :( [13:42] (not honoring debian/compat=7?) [13:42] it runs it between dh_installinfo and dh_installinit for me [13:45] ah, it seems to run it only if /usr/bin/dh_pysupport exists, I'll now add a dependency on python-support [13:47] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ogasawara [13:48] mitya57: python-support? Really? [13:48] mitya57: The vile thing we kicked to universe intentionally? :P [13:49] infinity: ok, I'll better refactor debian/rules so that it doesn't use override_dh_pysupport [13:53] pitti, infinity: done [13:55] mitya57: running again === security is now known as megha === sraue_ is now known as sraue [14:08] mitya57: works now \o/ [14:08] pitti: \o/ [14:09] pitti: but: can that happen that you vm has libjs-jquery installed? [14:09] *your [14:09] checking [14:10] for me it fails with "error: can't copy 'lib/foo/jquery.js': doesn't exist or not a regular file" when it's not installed [14:10] mitya57: it indeed does [14:10] because it's a symlink [14:10] pitti: is it really needed there? [14:11] presumably a reverse recommends of something [14:11] * mitya57 adds a dependency on libjs-jquery [14:14] done [14:20] hey guys I just hit this on raring https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1101213 is there any other info that would be useful? [14:20] Ubuntu bug 1101213 in gnome-control-center (Ubuntu) "G-c-c printing doesn't allow you to select a hp printer" [Undecided,New] === MacSlow|lunch is now known as MacSlow [14:37] ScottK: can I ask you to commit some of my changes to Debian? [14:37] I have prepared a branch: bzr+ssh://bzr.debian.org/~mitya57-guest/public_bzr/python3-defaults/merge-with-ubuntu [14:37] mpt: if we're trying to understand the frequency of the different reasons for not being able to process apport reports and thus would collect some information from a damaged or incomplete report, would there be something better to say than “No details were recorded for this error.” [14:38] ev, that sounds perfect to me. [14:38] oh, wait [14:38] sorry [14:38] :) [14:38] Didn't realize *why* it sounded perfect... [14:39] ev, if you have anything to report at all, does that mean you have a timestamp at least? [14:45] mpt: as it creates a file, yes [14:45] would it be helpful if I collected the types of errors in parsing the report that we account for? [14:46] ev, the reason I asked is that we could always show the timestamp, before the "No details were etc". [14:47] ah, that would be rather nice [14:49] Spec updated: https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=135&rev1=134 [14:51] mpt: I agree with that, but is that sufficient if we are still going to send some information for why we failed to parse that report (or ran out of memory in loading it, or the application isn't installed anymore, etc)? [14:52] ev, ah, sure. Yes, it would be informative to distinguish those cases. [14:57] mlankhorst: Can bug 1081122 be marked v-done now? The three packages you mentioned are in precise-proposed. [14:57] bug 1081122 in x11proto-randr (Ubuntu Precise) "x11proto-(gl,randr,dri2)-dev need to be updated for backport stack" [High,Fix committed] https://launchpad.net/bugs/1081122 [15:02] cjwatson: yeah considering the entire backports stack built :) [15:03] mlankhorst: OK, thanks, I'll do that and promote it [15:04] Should help the width of pending-sru.html too since x11proto-randr has a big long version ... [15:06] mlankhorst: How about the backport stack itself? Do you have a feel as to its safeness for -updates yet? [15:07] I think so, only outstanding bug is the mesa one with sru and https://bugs.launchpad.net/ubuntu/+source/libdrm/+bug/1086345 [15:07] Ubuntu bug 1086345 in libdrm (Ubuntu) "Quantal-LTS-stack: Showing low-resolution screen on shutdown/reboot" [Critical,In progress] [15:07] "the mesa one with sru"? [15:08] there's a mesa sru about libqt4-opengl-dev uninstalling the renamed stack, but it's solved by doing a sru in unrenamed mesa [15:08] erk, yes, I agree renaming plymouth would be enormously painful [15:08] bug 1098215 [15:08] bug 1098215 in mesa (Ubuntu Precise) "installing libqt4-opengl-dev uninstalls renamed stack" [Critical,Fix committed] https://launchpad.net/bugs/1098215 [15:10] I think we might have do an unrenamed copy of libdrm from quantal to precise, but I have no idea if we should also do a rebuild of the renamed stack without the renamed libdrm, it wouldn't be hard at least to do [15:10] Hmm. If you're going to do that it should be soon ... [15:11] And yes, if you do that I think you should rebuild relevant bits of the stack against it [15:11] yeah I've been asking raof, but no reply yet :( [15:12] So, I don't know. Is it better to drop the current stack into -updates and fix that in a second round? [15:12] infinity: ^- WDYT? [15:13] It might mean people end up with orphaned libdrm-ltsq-* packages on their system - but I somehow can't see that as a huge deal [15:13] I can regenerate the entire stack easily, I always kept the option open of not renaming [15:13] How much does it involve rebuilding? [15:13] And hence reverifying? [15:15] cjwatson: I'd prefer we not promote it while there are still open bugs on it, personally. Especially with fundamental questions like this still floating. [15:15] in theory it's just removing libdrm-dev-lts-quantal from build-depends, and setting it back to libdrm-dev [15:15] and then doing a rebuild of all packages that link against libdrm-ltsq2 currently [15:15] cjwatson: But you're the dot-two guy, it's your call. [15:15] mlankhorst: How many's that? [15:16] mesa, xserver, vmware, openchrome, modesetting, intel, nouveau [15:16] and radeon I think [15:17] So not totally awful [15:17] infinity: Yeah. I really want to get the new stack landed, but I think I agree with you. [15:17] mlankhorst: OK. Can we get this done today, then? [15:17] sure [15:17] I can review stuff for you. [15:18] I'll do a upload against libdrm from quantal [15:18] mlankhorst: Do we know that we don't need a new plymouth if we have a new libdrm? [15:19] quantal still builds the old nouveau1a, so we don't need a new plymouth, i think it might require a build fix to find the old nouveau, as does old xserver-xorg-video-nouveau [15:19] but that's only if you do a rebuild [15:19] Yeah, that fix was in Q, it can be cherrypicked. [15:20] We should include it, rebuild or not, but it needn't block libdrm [15:20] IMO [15:20] yeah it's just changing configure.ac from looking for pkgconfig libdrm-nouveau to libdrm-nouveau1 iirc [15:21] debian/patches/update-libdrm-nouveau-library-dependency.patch from http://launchpadlibrarian.net/112820397/plymouth_0.8.4-0ubuntu1_0.8.4-0ubuntu2.diff.gz [15:23] apw: Hmm, I thought we'd switched to shipping just .signature in linux-signed for 12.04.2? [15:23] apw: Urgh, maybe I forgot to backport those installer patches ... [15:23] ok I commented out the libdrm rename, regenerating entire stack. [15:28] apw: Actually, maybe it doesn't matter. I switched the livefs handling over, which is the important bit. Ignore me :-) [15:30] cjwatson: Any stellar plans on how we're going to shave the last ~12M off the precise CD size? [15:30] infinity: I'm just downloading .1 so that I can start doing fine-grained comparison [15:31] This is of course why I'm asking apw stupid questions :-) [15:31] 2.4.39.0ubuntu0.1 good enough as version for libdrm? [15:31] WFM [15:32] cjwatson: Well, we shrink a bit when we remove the duplicate libdrm. But that won't be a lot. [15:32] No, indeed [15:33] infinity: Not seeing much else at the package level. There's 2MB or so for SB loaders === kirkland` is now known as kirkland [15:33] (In terms of diff from .1) [15:33] cjwatson, i did think we had done it very much for the CD size issue in q [15:33] are we saying we didn't copy them back after all that [15:33] ok did a check, only build-depends changed on all affected packages, seems some more are affected than I thought [15:34] apw: I backtracked later on in your scrollback - I was misreading [15:34] nochange stood for that i removed the changelog entries http://paste.ubuntu.com/1545795/ [15:35] Right. I think we need to suck those up. [15:36] From the sounds of your assessment of the libdrm bug, anyway. [15:36] yeah [15:36] Would be nice to get feedback from RAOF too, but we're running out of time for .2 [15:37] cjwatson, phew :) [15:37] I mailed him about it on the 15th (well 16th for him), but didn't receive a relpy [15:37] anyhow rebuild order is libdrm, mesa, xorg-server, rest [15:38] x11-xserver-utils 7.6+3 [15:38] x11-xserver-utils-lts-quantal 7.7~3ubuntu1~precise1 [15:38] Do we need two of those? [15:38] the second one only has xrandr [15:39] and in fact depends on x11-xserver-utils for the rest :) [15:39] * ogra_ hopes all of that -lts stuff was heavily tested on arm before uploading ... [15:40] ogra_: Seems unlikely, since it's meant to go with the lts-quantal kernel, which is x86-only. [15:40] oh, ok, i thought it replaced the shipped xorg through -updates [15:40] I did test it on arm once [15:40] yeah, dont bother if it needs kernel changes arm doesnt have [15:40] but it was a bit of a pain because of blob being incompatible [15:40] ogra_: No, it's a replacement for new installs [15:40] ogra_: The general theory is that people can choose one stack or the other, it's not forced on you. [15:40] k [15:41] If it switches on upgrade then (AFAIK) that's a v-failed [15:41] only compiz failed on my pandaboard :) [15:41] mlankhorst, yeah, thats normal ... i'm still scared nvidia wont provide us a tegra update before we change the abi in raring [15:42] cjwatson: when you have a minute can you let my e-mail to ubuntu-devel-announce through [15:42] stgraber: dodne [15:42] -d [15:43] cjwatson: thanks [15:43] hm I need to fix the changelog entries [15:44] mlankhorst: llvm-3.1 should be good to promote to -updates, right? No libdrm dep there [15:44] yeah [15:46] hm is it ok if I rewrite the most recent changelog entry? my package generate scripts can't keep the old ones [15:47] Err, not exactly sure what you mean [15:47] What package? [15:47] And you can't reuse the same version if it's already in -proposed [15:48] all *-lts-quantal ones :) [15:48] Show me an example diff [15:49] it's just that when I upload ~precise2, the ~precise1 entry gets deleted [15:49] I'd still like to see an example diff :) [15:50] If the entries are just something like "autogenerated backporty thingamajig", and you're saying that it's easier to just generate a ~precise2 without preserving the ~precise1 history, that would be fine. [15:50] http://paste.ubuntu.com/1545849/ [15:50] infinity: I'll try to preserve it in ~precise3, but that has to wait [15:50] Yeah, preserving the history on that isn't meaningful. [15:51] That's tolerable, if confusing for anyone watching closely [15:51] Do fix your scripts, but not worth delaying in this instance [15:51] yeah [15:51] Dropping old changelog entries messes with apt-listchanges' tiny brain, but I'm probably the only person who still uses it. [15:51] I do! [15:52] I use it, and it's not that confused about it [15:52] Quite a few things seem to mess with its brain. Is that what causes it to show all changelog entries ever sometimes? [15:52] Ahh, well then. Yay. [15:52] I think it got smarter about it though [15:52] cjwatson: It shows the whole changelog if it can't find the entry for your currently installed version, yeah. [15:52] cjwatson: Though, there seem to be other cases where it does so as well. [15:52] Mm. But syncing over Ubuntu modifications would do the same, and we do that all the time ... [15:52] Maybe someone fixed that at some point. [15:53] Would just take a simple version compare and walking the known versions. [15:53] Well, I still get it showing me the whole changelog quite a lot :) [15:53] So maybe it's still there [15:53] I only run it on my stable production machines, maybe I should re-enable it on my raring laptop and actually fix the things that annoy me some time. [15:53] I uploaded libdrm, still playing with the stack, trying to add an entry [15:58] ev, I added a stub "Cross-release comparisons" list. https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=136&rev1=135 [16:02] dpkg-mergechangelog ftw [16:08] ok I think I may be able to upload precise2 rebuilds now [16:09] cjwatson, does LVM install ticky do anything in raring live CDs ? [16:10] apw: in desktop cd, it is meant to do separate /boot and the rest / on top of lvm. === henrix is now known as henrix_ [16:10] the effect seems to be to do nothing [16:11] ok great, I can preserve history of changelogs.. [16:11] xnox, it cirtainly is not doing that at all or indeed doing anything different at all === henrix_ is now known as henrix [16:12] apw: ... and you are doing wipe & install? (if you are doing upgrade or resize or reuse or replace it will do nothing) [16:13] as in the checkbox will not have any affect, unless it's a pure wipe & install. [16:13] xnox, wipe and install indeed [16:13] tjaalton, whats the status on the nx7 input issue, we're just having the weekly nx7 meeting in #ubuntu-meeting [16:13] though actually it just puked and broke, and didn't install a thing, gah [16:13] ok. I'll look into it. [16:13] it's a bit of a hack, but ok it worked.. === chiluk is now known as chiluk_away [16:18] hi. if I add the ddeb repo on precise on my x86_64 machine, and install the linux-image-3.2.0-36-dbgsym my /usr/lib/debug/vmlinux-* file is 32-bit ... is this a user-error or bug? [16:20] cjwatson: ok want me to upload the new affected packages too? [16:20] mlankhorst: Still reviewing libdrm [16:21] mlankhorst: We're going to need to backport a patch or two in plymouth aside from the build issue - bug 927424 at least [16:21] bug 927424 in plymouth (Ubuntu Precise) "Please backport commit to enable building without irrelevant drm libs on some arches" [Undecided,New] https://launchpad.net/bugs/927424 [16:21] hm right [16:22] sorry - I completely forgot that building intel on arm was needed === chiluk_away is now known as chiluk [16:22] mlankhorst: Do you want to do the plymouth changes or should I? If you do it then I can review :) [16:23] ok let me check [16:24] mpt: thanks [16:25] mlankhorst: I don't know if you need bug 1018907 as well - hopefully not, since the patch for that was quite large [16:25]