| m4t | anyone here know which work-arounds are in place to ensure aligned partitions on drives using 4096phys/512log sectors ? | 00:17 |
|---|---|---|
| YokoZar | Is it possible to delete a dummy package from the archive and replace it with a non-dummy older version? | 02:35 |
| === Guest90447 is now known as Puritan | ||
| LaserJock | ScottK: around? | 04:01 |
| ScottK | LaserJock: I am now. | 04:17 |
| YokoZar | ScottK: Ahh, good. Now I can bother you too | 04:24 |
| ScottK | YokoZar: Hi. | 04:24 |
| YokoZar | ScottK: In order for the replaces/conflicts solution to work we'd still need for the binary wine package to be deleted from the repository | 04:24 |
| YokoZar | ScottK: Which is why I think we may have to do something like I have in my PPA where I make original Wine a new version like 1.1.42-0ubuntu3~1.0.1 | 04:25 |
| ScottK | YokoZar: Let's wait for slangasek to make an appearance. He knows strange and magical things about this sort of problem and may be able to save us. | 04:26 |
| YokoZar | all right | 04:26 |
| YokoZar | I'll update my PPA to have replaces/conflicts in wine1.2 like it should anyway (since it really does conflict) | 04:26 |
| ScottK | I think he's in transit to London for the release sprint this weekend. | 04:27 |
| === sconklin is now known as sconklin-gone | ||
| YokoZar | If there is a release sprint, he's clearly going to it ;) | 04:27 |
| ion | bgamari, meet Keybuk. Keybuk, meet bgamari. bgamari appears to have the starting of plymouth block the system startup indefinitely on the ubuntu kernel, but it works with his own 2.6.34-rc build. | 06:45 |
| Keybuk | ion: meet the calendar | 06:45 |
| Keybuk | the calendar: meet ion, explain about "Saturday" ;-) | 06:46 |
| ion | Heh | 06:46 |
| Keybuk | sounds like a drm bug anyway | 06:47 |
| ion | bgamari: While reporting the bug, please attach dmesg output with both kernels after plymouth has at least tried to start. | 06:51 |
| Keybuk | and file it on the kernel, rather than on plymouth | 06:52 |
| === yofel_ is now known as yofel | ||
| mantiena | hello | 10:49 |
| mantiena | maybe someone knows when new daily build will be available at ftp://cdimage.ubuntu.com/cdimage/daily-live/ ? | 10:49 |
| mantiena | maybe someone knows when new daily build will be available at ftp://cdimage.ubuntu.com/cdimage/daily-live/ ? | 11:18 |
| lool | persia: thanks for poking qemu-kvm on ia64 and ppc; in theory ppc has a kvm port, not sure how current it is | 13:17 |
| slangasek | bgamari: pong | 13:51 |
| persia | lool: KVM on powerpc works fine *if* you have a significantly newer kernel than lucid: I'll test, and probably reenable for maverick. ia64 has some preliminary stuff upstream for qemu: we should be able to build with --disable kvm in maverick, but I didn't see any evidence that kernel support had landed. | 13:55 |
| slangasek | YokoZar, ScottK: I think I'm missing conflict for what "the replaces/conflicts solution" is | 13:57 |
| persia | lool: I should mention that there has been a longstanding *embedded* powerpc solution for qemu/kvm, but that's not interesting to us, really, as we don't have kernels that can run on that target. Note also that we need a slightly newer libvirt to do anything useful on powerpc (0.7.7+). I'd appreciate any thoughts you have on how to do foreign-arch hosting with libvirt. | 13:58 |
| lool | persia: What do you mean with embedded powerpc solution for qemu/kvm? | 14:04 |
| lool | persia: I looked a bit into libvirt hosting for qemu-system-arm, and it seemed doable, but I didn't try it; you can request a XML of the vms which libvirt thinks it supports, and you can extend that list | 14:05 |
| persia | lool: upstream kernel support for "embedded" class processors. KVM support for PPC970/PPC7447A only landed in .33 or .34 (I forget). | 14:06 |
| persia | Cool, that sounds not too difficult: I suppose we'd want to have qemu-kvm-extras-static drop in some hint file to enable it? | 14:07 |
| lool | persia: Ok; didn't know that there was a class of CPUs named embedded; I think Debian got things working with qemu-system-ppc -M prep, but I didn't manage to get that to work on Ubuntu | 14:07 |
| lool | persia: qemu-kvm-extras-static is for the qemu-$arch linux-user helpers | 14:08 |
| lool | persia: So only CPU emulation | 14:08 |
| lool | persia: qemu-kvm-extras carries the qemu-system-foo for non-x86 arches | 14:08 |
| persia | But I'll want to wait for 0.7.7+ anyway, as it currently fails for any platform without /sys/class/dmi/* | 14:08 |
| persia | Ah, right. So qemu-kvm-extras should provide the libvirt hints. | 14:09 |
| persia | There isn't a class named "embedded" | 14:09 |
| * persia hunts a more specific reference. | 14:09 | |
| persia | lool: Seems there was in-kernel KVM support for powerpc 44x hosts, but not more common desktop processors. KVM upstream seems to be intentionally avoiding doing anything with the POWER series (probably because of PowerVM) | 14:12 |
| lool | persia: I couldn't find whether powervm is free software, so I suspect not? | 14:14 |
| persia | I think it's zero-additional-cost when you purchase an appropriate hardware solution from IBM. I don't believe the code is available. | 14:15 |
| persia | I'm uncertain whether it's delivered as "firmware" or "software". | 14:16 |
| persia | (note that zero-additional-cost above is in the same way that Mac OS X is zero-additional-cost with the purchase of an appropriate Apple hardware solution) | 14:17 |
| persia | Hrm. Looks like there's some ia64 kvm stuff in 2.6.34: maybe we can get full kvm there too. | 14:23 |
| ScottK | slangasek: The problem we are trying to solve is that there was a wine package and a wine1.2 package. Eventually wine1.2 became "the" package and wine was a dummy package provided by wine1.2. Now it looks like we want to ship both wine and wine1.2 because there are now wine reverse build-deps in the archive from Debian. So YokoZar uploaded a wine1.2 that no longer provided wine and a wine that (of course) failed to upload due to having a | 14:55 |
| ScottK | lower version than the wine package that wine1.2 used to provide. | 14:55 |
| ScottK | So the goal here is to disentangle the two package namespaces somehow. | 14:56 |
| ScottK | Any existing user that has wine installed has wine1.2 and should stay with that, but there should be an ability to install wine. | 14:56 |
| cjwatson | m4t: parted 2.2 does most of it, plus partman telling it to use optimal partition alignment (unless you override it). These aren't really workarounds - they're upstream-supported fixes | 15:56 |
| doko_ | siretart: could you update http://qa.ubuntuwire.org/ftbfs/test-rebuild-20100407/ for the superseded status? | 17:28 |
| persia | imbrandon: do you still have access to that? | 17:29 |
| * persia suspects it's too early for the rest of UWSA | 17:29 | |
| siretart | doko_: I think you should ask lucas, I have no idea about these ftbfs lists :-( | 17:32 |
| doko_ | siretart: no, lucas doesn't do the ubuntuwire stuff | 17:33 |
| persia | doko_: Just to confirm: are they being superceded in the rebuild as well? | 17:35 |
| doko_ | persia: what do you mean? | 17:35 |
| persia | doko_: Are new uploads to lucid *also* being auto-copied to the rebuild job? | 17:36 |
| doko_ | no | 17:36 |
| persia | I know that script collects data from the LP buildd status output, so it may be tricky to get it to analyse based on two different archive build statuses. | 17:36 |
| siretart | doko_: ah, while I have you here on irc. Do you remember if you left out 'scan-build' and 'scan-view' out of the clang package on purpose? - the clang static analyzer is really great, but it seems these utilities are just not installed into the binary package | 17:36 |
| doko_ | checked that the superseded build build ok in main | 17:36 |
| persia | geser: Do you know if that's possible with the script? | 17:37 |
| doko_ | siretart: clang is just the debian package. please file a report, I don't mind a sru for that | 17:37 |
| * persia suspects it may require additional script hacking to get the desired dataset | 17:37 | |
| siretart | doko_: debian seems to ship 2.6, while you already uploaded 2.7. the debian package does install clang-scan | 17:38 |
| doko_ | siretart: probably enabled after I switched to 2.7 | 17:39 |
| siretart | doko_: see debian bug #568499, fixed in 2.6-2 | 17:40 |
| ubottu | Debian bug 568499 in clang "clang: please ship scan-build and ccc-analyzer" [Wishlist,Fixed] http://bugs.debian.org/568499 | 17:40 |
| siretart | our changelog only includes 2.6-1 | 17:40 |
| doko_ | siretart: has to go into a sru | 17:40 |
| persia | doko_: At least from a quick glance at the code, I suspect it's hard to achieve what you request without pushing more stuff to the PPA (although you may be more proficient with that sort of thing than I) | 17:40 |
| doko_ | persia: thanks for checking, won't do that for this rebuild | 17:41 |
| persia | doko_: OK. The source link is at the bottom of the page: it's fairly easy to run locally. Maybe you can find a way to get the results you desire. | 17:43 |
| geser | persia: the FTBFS script for the archive rebuild checks if there is a newer version of a package in the main archive (those are the superseded packages) | 17:45 |
| persia | Hrm. I missed that bit somehow. So it's already up-to-date regarding superceded status? | 17:46 |
| geser | yes, but the status of those packages listed below superseded is that from the rebuild archive and not from the main archive (it's just "old" entries moved to separate tables) | 17:50 |
| * persia grumbles about IRC clients. | 17:53 | |
| persia | doko_: So, as described, your request is already accomplished :) | 17:53 |
| persia | geser: Thanks a lot for the explanation. | 17:53 |
| doko_ | geser: ??? there are no newer packages in the test archive, so why superseded at all? | 17:54 |
| geser | doko_: because there is a newer package in the main archive and a package listed as FTBFS in the rebuild archive might got fixed already. So those packages gets moved into their own list to not distract from those which still FTBFS. | 17:58 |
| doko_ | geser: right, but this checks seems to be only made, when the new ftbfs package gets added to this list, not when the list is generated | 17:59 |
| imbrandon | persia: pong | 17:59 |
| doko_ | geser: e.g. kdebindings | 17:59 |
| geser | doko_: the FTBFS page for the archive rebuild lists it in the non-superseded lists and according to LP 4:4.4.2-0ubuntu2 is still the most recent version for lucid | 18:03 |
| geser | or did I miss something or misunderstood? | 18:03 |
| doko_ | geser: gtkhtml3.14 is not, kdebindings maybe was wrong | 18:05 |
| geser | hmm, let me check why it doesn't get listed as superseded | 18:09 |
| doko_ | geser: compiz is superseded as well | 18:09 |
| persia | imbrandon: geser/doko may want your help to fiddle http://qa.ubuntuwire.org/ftbfs/test-rebuild-20100407/ later (but it may be not requied) | 18:09 |
| doko_ | geser: kdebindings, is not newer, but it was requeued, and then the build succeeded. maybe compare the build time stamps for the case where the version is identical? | 18:21 |
| persia | Could someone from the release team make a release/proposed call on bug #249295? It was highlighted in -java, and has a one-character fix | 18:23 |
| ubottu | Launchpad bug 249295 in java-common "incorrect path to jinfo file when doing "update-java-alternatives -list"" [Undecided,Confirmed] https://launchpad.net/bugs/249295 | 18:23 |
| YokoZar | slangasek: one (possibly ugly) option would be to delete the dummy wine binary package from the archive and then replace it with the lower versioned wine 1.0.1 that failed to upload earlier. Is that possible? The other options all involve creative use of package versioning that's similarly ugly | 19:06 |
| YokoZar | ScottK: ^^ | 19:06 |
| ScottK | YokoZar: No. You can't remove the history. | 19:09 |
| ScottK | YokoZar: Maybe a new wine1.0 package? | 19:10 |
| YokoZar | ScottK: Then we're left with either weird versioning or a new package entirely, yeah | 19:10 |
| ScottK | The binaries would have to be wine1.0 too | 19:10 |
| YokoZar | ScottK: wine1.0 is probably least ugly at this point, yeah. | 19:11 |
| YokoZar | ScottK: That even allows reintroducing the wine dummy package for upgrades | 19:12 |
| ScottK | Yes. It should. | 19:13 |
| persia | Yave wine-dummy (1.2) depend on wine-1.0 (1.0)? | 19:13 |
| persia | Your risk is really those users who still have the dummy wine package installed. | 19:13 |
| === j_ack_ is now known as j_ack | ||
| YokoZar | persia: dummy wine depended on wine1.2, we can reintroduce that and add a wine1.0 package that they will remain unaware of | 19:15 |
| YokoZar | Though I'll have to update app-install-data | 19:15 |
| persia | And patch all the reverse-build-deps that flow from Debian. | 19:15 |
| persia | When was the dummy package introduced? | 19:16 |
| YokoZar | only one exists anyway | 19:16 |
| persia | (so far ...) | 19:16 |
| YokoZar | dummy package was introduced in Lucid build cycle | 19:16 |
| YokoZar | persia: debian will need to be more specific anyway, as wine 1.0 and 1.2 differ in how they build things | 19:16 |
| persia | When will Debian have both? | 19:17 |
| YokoZar | I'm not sure, I'm in touch with someone from Debian at the moment about just using my packages there. Most likely transition is around wine 1.2 full release in a couple months | 19:17 |
| YokoZar | ScottK: Ok, I'll bang out a wine1.0 package later today and put it in a new ppa to test the transitions | 19:20 |
| persia | Cool. There were a few people asking about dssi-vst today. | 19:23 |
| imbrandon | persia: qokies, just have em ping me | 19:42 |
| imbrandon | okies* | 19:43 |
| * persia hopes they will, at this point :) | 19:43 | |
| persia | But it may be that it doesn't need to change: from the conversation earlier, I'm left unsure as to the final result. | 19:43 |
| imbrandon | k | 19:44 |
| === arand is now known as fakeubot | ||
| === tkamppeter_ is now known as tkamppeter | ||
| === fakeubot is now known as arand | ||
| slangasek | YokoZar: deleting the wine dummy to downgrade the version> nope | 22:53 |
| slangasek | YokoZar: so the current wine source fails to upload, I guess? | 22:55 |
| slangasek | YokoZar, ScottK: if what is wanted is a 'wine' package that continues to point to wine 1.0 the way it did in karmic, instead of wine1.2 as it does now, I think the only reasonable options are 1) keep building it as a dummy package from wine1.2 source but make it depend on wine1.0, or 2) add an epoch to wine1.0 | 23:06 |
| slangasek | i.e., 1:1.0.1-0ubuntu11 > 1.1.42-0ubuntu2 | 23:06 |
| elleuca | hi, anybody using lucid and USB speakers that could verify this: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/569926 | 23:08 |
| ubottu | Ubuntu bug 569926 in pulseaudio "[Regression] wrong audio volume output stepping for USB speakers" [Undecided,New] | 23:08 |
| chrisccoulson | slangasek - are nvidia users meant to see a text mode plymouth theme? i just upgraded my nvidia desktop tonight and i've got some weird issues | 23:21 |
| chrisccoulson | (upgraded from karmic -> lucid) | 23:21 |
| slangasek | chrisccoulson: no, they're not | 23:44 |
| chrisccoulson | slangasek - oh, ok. what vt is xorg meant to run on for nvidia users? it's running on vt6 on my desktop (on top of getty), and it uses a lot of cpu :-/ | 23:45 |
| slangasek | chrisccoulson: it's obviously not meant to run on the same vt as a getty, no matter what X driver you're using ;) | 23:46 |
| chrisccoulson | slangasek, that's what i thought ;) | 23:46 |
| slangasek | and I haven't heard of that happening and honestly am not sure how you would get in that state | 23:46 |
| slangasek | using gdm? | 23:46 |
| chrisccoulson | if i restart gdm, then it restarts on vt7 | 23:46 |
| chrisccoulson | but it's on vt6 when i boot | 23:46 |
| chrisccoulson | so, i'm confused ;) | 23:47 |
| slangasek | so there is a possible race condition here | 23:47 |
| slangasek | actually a pair of race conditions that, if you hit them both, could give you that result | 23:47 |
| slangasek | plymouth-stop.conf is 'stop on (starting gdm or [...] stopped rc RUNLEVEL=[2345])' | 23:48 |
| slangasek | if you have very little in /etc/rc2.d, rc could stop before gdm has started | 23:48 |
| slangasek | if this happens, you don't get the smooth transition from plymouth to X (which you wouldn't anyway in this case, due to the binary driver) | 23:48 |
| chrisccoulson | ah, ok. and that could cause xorg to start on the wrong vt? | 23:49 |
| slangasek | and tty6.conf is 'start on runlevel [23]', which means it starts in parallel to all this other stuff | 23:49 |
| slangasek | so if gdm starts before the getty has started, when it looks to figure out the first available vt, it might get it wrong | 23:49 |
| slangasek | but I thought gdm had some code to guard against this, too | 23:50 |
| slangasek | (and the race I've described is *very* unlikely to be hit) | 23:50 |
| Aquina | Oh someone saw these Microsoft Internet Explorer 8 ads? They really wanna tell us their shit is secure! :-( | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!