| * doko curses xnox for multiarching tcl/tk | 00:09 | |
| doko | xnox, any any reason for not doing tcl & tk at the same time? | 00:17 |
|---|---|---|
| xnox | doko: multi-arch? | 00:25 |
| * xnox was sponsoring a patch for tcl, and I accepted the work to make tcltk match for tcl m-a upload. | 00:25 | |
| xnox | (defaults that is) | 00:25 |
| xnox | cjwatson now said he is ok to finish tk m-a for +1. | 00:26 |
| doko | xnox, yes m-a | 00:26 |
| doko | ok. will need another change for hfsutils | 00:26 |
| xnox | doko: hfsutils sounds like a package I should be maintaining =) | 00:26 |
| doko | ? | 00:27 |
| xnox | file systems =)))) | 00:27 |
| xnox | although I don't have macs any more. | 00:27 |
| mathomastech2 | Trying to deploy an app to Ubuntu Touch on my Nexus 7. It's prompting for a password but not accepting the default "phablet" Anyone else run into this? | 00:36 |
| xnox | mathomastech2: see #ubuntu-touch people there should know. | 00:39 |
| mathomastech2 | xnox: Thanks, I am actually cross posting from there. Not having much luck yet. | 00:39 |
| slangasek | xnox: I don't understand what "for the node itself" means here. Do you mean that the server mounts the filesystem the same way as the clients? | 00:39 |
| xnox | slangasek: maybe, my memory is fuzzy. | 00:40 |
| xnox | slangasek: I'll get back to you about that. | 00:40 |
| slangasek | ok :) | 00:40 |
| xnox | mathomastech2: i'm sorry to hear that. Last resort try the ubuntu-phone mailing list. https://launchpad.net/~ubuntu-phone | 00:41 |
| xnox | slangasek: new guile-pg uploaded "closing" the guile-1.6 RM task. | 00:41 |
| slangasek | xnox: cheers :) | 00:45 |
| === bjsnider_ is now known as bjsnider | ||
| infinity | Who demoted tcl/tk8.4 to universe? | 04:03 |
| micahg | infinity: doko was working with that stuff earlier... | 04:04 |
| * StevenK grumbles at SourcePackagePublishingHistory:+publishinghistory | 04:05 | |
| infinity | @pilot out | 04:05 |
| === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion 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: | ||
| doko | who promoted tck/tk8.4? demoting again ... | 04:41 |
| StevenK | infinity: [15:41] < doko> who promoted tck/tk8.4? demoting again ... | 04:42 |
| micahg | doko: it registered on c-m | 04:43 |
| doko | I assume I know who did promote it again. there is no reason to promote it for a work in progress, not even for infinity | 04:44 |
| micahg | doko: why not just fix what would pop up on c-m before demoting? | 04:44 |
| doko | micahg, did *you* see this? | 04:45 |
| micahg | I saw it register on c-m... | 04:45 |
| micahg | ah, you fixed it, so that should be that then :) | 04:46 |
| doko | so you did look up bug reports for tcl8.4, or tk8.4, or blt? | 04:46 |
| micahg | I didn't do the demotion/promotion | 04:46 |
| micahg | doko: honestly, I figured infinity would chat with you before playing override pong | 04:48 |
| * micahg enjoys removing old cruft as much as the next person | 04:51 | |
| * micahg would love to rm vala-0.14 for raring... | 04:51 | |
| infinity | doko: Typically, we remove the rdeps, then demote things when c-m whines, specifically to avoid pong. Having to trawl bug reports to figure this out doesn't scale. | 05:02 |
| infinity | doko: (I did look at blt, and there had been no uploads changing build-deps at the time) | 05:02 |
| === freeflyi1g is now known as freeflying | ||
| pitti | Good morning | 06:28 |
| dholbach | good morning | 07:26 |
| === smb` is now known as smb | ||
| pitti | Laney: can you please remove the systemd and udev blocks? | 08:49 |
| Laney | hello | 09:08 |
| Laney | pitti: sure, if you're sure ;-) | 09:08 |
| === davidcalle_ is now known as davidcalle | ||
| pitti | Laney: the initramfs-tools bug has been fixed, and otherwise the libudev1 transition is done | 09:09 |
| pitti | Laney: so with unblocking we merely get libudev1, logind etc. is still kept in universe | 09:09 |
| * Laney nods | 09:09 | |
| pitti | (as with the current raring package) | 09:09 |
| Laney | ok, done | 09:10 |
| pitti | Laney: thanks; that should flush quite a bit from excuses | 09:10 |
| Laney | hmm, udev didn't go | 09:33 |
| pitti | Laney: "go"? | 09:33 |
| Laney | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt | 09:33 |
| pitti | oh, I was looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html and that says "udev valid candidate" | 09:34 |
| pitti | skipped: udev (1 <- 466) | 09:34 |
| pitti | got: 278+0: i-278 | 09:34 |
| pitti | * i386: bluedevil, blue... | 09:35 |
| pitti | I can't parse that, can you? | 09:35 |
| seb128 | can't either | 09:37 |
| Laney | it thinks that those things are made uninstallable | 09:37 |
| seb128 | it's a long list | 09:38 |
| pitti | perhaps it'll catch it in the next iteration when all the libudev1 stuff is i? | 09:38 |
| pitti | s/i/in/ | 09:38 |
| Laney | I guess the last try is more interesting | 09:38 |
| === yofel_ is now known as yofel | ||
| Laney | there are a few trying: udev there | 09:39 |
| Laney | chromium might need force hinting due to the armhf ftbfs | 09:39 |
| pitti | the previous upload FTBFSed too, was that also manually pushed? | 09:40 |
| Laney | think so | 09:40 |
| Laney | yes, it was forced | 09:40 |
| cjwatson | pitti: parse> if you scroll way to the right you'll see that it thinks udev itself is uninstallable | 09:49 |
| cjwatson | pitti: the very long line is just an expression of the fact that udev has lots of reverse-deps | 09:49 |
| cjwatson | pitti: note that this means that it thinks (current raring) + (all binaries from udev in raring-proposed) results in uninstallable udev - so it's possible it needs manual hinting together with something else in -proposed | 09:50 |
| pitti | hm, udev just dropped the libudev0 dependency and binary | 09:50 |
| cjwatson | Which seems likely given that udev is installable in raring-proposed | 09:50 |
| pitti | yeah, I dist-upgraded to raring-proposed just fine, I have 175-0ubuntu21 installed | 09:51 |
| cjwatson | Bet you'll find that if you take raring and then try to upgrade to just udev/raring-proposed, it adds something else | 09:52 |
| Laney | A lot of the ones it's complaining about seem to come down to xorg-server AFAICT | 09:52 |
| pitti | libudev1, yes | 09:52 |
| pitti | for the initramfs-tools dependency | 09:52 |
| cjwatson | Laney: I don't think it's worth looking at anything else when udev itself is listed | 09:53 |
| cjwatson | (It might be worth making update_output sort the binaries from the source itself to the start) | 09:53 |
| Laney | I was trying to ascertain what to hint together | 09:53 |
| cjwatson | Hm, wait, it's not listed in the final entry for udev | 09:53 |
| Laney | right | 09:53 |
| Laney | that's the one I'm looking at | 09:53 |
| cjwatson | pyudev needs to be fixed | 09:54 |
| cjwatson | And yeah, in general anything with Depends: libudev0 needs to be fixed | 09:54 |
| cjwatson | proposed-migration normally computes installability based on all-NBS-removed | 09:55 |
| pitti | oh, hardcoded libudev0 dep, fixing | 09:55 |
| cjwatson | So, certainly worth trying 'hint udev/175-0ubuntu21 xorg-server/2:1.13.3-0ubuntu2' - if nothing else you'll get more useful output that way | 09:56 |
| Laney | well: skipped: xorg-server (1 <- 498) got: 96+0: i-96 * i386: xserver-xorg-core-udeb, xserver-xorg-input-evdev-udeb, xserver-xorg-video-fbdev-udeb | 09:56 |
| cjwatson | And you can see a reflection of that in update_excuses | 09:56 |
| pitti | pyudev uploaded | 09:56 |
| cjwatson | xserver-xorg-core-udeb/i386 unsatisfiable Depends: udev-gtk-udeb | 09:56 |
| Laney | right | 09:58 |
| cjwatson | Ah, you'll need xserver-xorg-input-evdev/1:2.7.3-0ubuntu2b1 xserver-xorg-video-ati/:7.1.0-0ubuntu1b1 xserver-xorg-video-intel/2:2.21.4-0ubuntu1b1 xserver-xorg-video-modesetting/0.6.0-0ubuntu1b1 xserver-xorg-video-nouveau/1:1.0.6-0ubuntu3b1 too | 09:58 |
| cjwatson | And more - anything that mentions "Depends: ... systemd' in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 09:59 |
| cjwatson | Which implies that this is blocked on chromium-browser/armhf | 09:59 |
| Laney | not sure about that - at least nouvaeu went in the last run | 09:59 |
| cjwatson | Ah, OK | 09:59 |
| cjwatson | Try it a bit at a time and wait for another cycle, I guess | 10:00 |
| Laney | I'll just try it with xorg-server | 10:00 |
| Laney | it will come down to chromium but as that's a force we should wait until we're certain | 10:00 |
| cjwatson | aye | 10:01 |
| pitti | I'm not sure about udev-gtk-udeb | 10:02 |
| pitti | our udev source package didn't build that, and I didn't drop it | 10:02 |
| pitti | systemd builds it now, but I disabled it | 10:03 |
| cjwatson | It's built by Debian | 10:03 |
| pitti | (because we keep the standalone udeb for now) | 10:03 |
| pitti | err, udeV | 10:03 |
| cjwatson | Either start building it, or remove the dependencies | 10:03 |
| cjwatson | I don't really mind which :) | 10:03 |
| pitti | I mean, how did that work before? | 10:03 |
| pitti | i. e. how did we get anything depending on udev-gtk-udeb into raring when that package didn't exist? | 10:04 |
| cjwatson | Let me look | 10:04 |
| cjwatson | The previous version of at least xserver-xorg-core-udeb doesn't depend on udev-gtk-udeb | 10:04 |
| cjwatson | It's a new dependency | 10:05 |
| pitti | oh, perhaps it was synced, and this was added independently from my libudev transition | 10:05 |
| pitti | hm, no | 10:07 |
| cjwatson | Well, it's 2:1.13.2-0ubuntu3 to 2:1.13.3-0ubuntu2 - I assume there was a packaging sync in there even if not a verbatim sync | 10:08 |
| Laney | yikes | 10:09 |
| Laney | why did alt+left/right just start switching me between ttys? | 10:09 |
| cjwatson | And yet xserver-xorg-input-evdev-udeb gained it with just a rebuild | 10:09 |
| cjwatson | pitti: I suspect udev's shlibs are wrong | 10:09 |
| cjwatson | Or rather systemd's | 10:10 |
| * cjwatson peers | 10:10 | |
| cjwatson | ubuntu-archive@lillypilly:/srv/archive.ubuntu.com/ubuntu/pool/main/s/systemd$ dpkg -I libudev1_198-0ubuntu2_i386.deb shlibs | 10:10 |
| cjwatson | libudev 1 libudev1 | 10:10 |
| cjwatson | ^- smoking gun | 10:10 |
| cjwatson | udeb: libudev 1 udev-gtk-udeb | 10:10 |
| pitti | aah | 10:11 |
| pitti | dh_makeshlibs -plibudev1 --add-udeb=udev-gtk-udeb | 10:12 |
| * pitti drops | 10:12 | |
| cjwatson | Can't drop that entirely | 10:12 |
| cjwatson | Still needs to have some --add-udeb value | 10:12 |
| cjwatson | Hm, is it intentional that systemd doesn't build any udebs at all? | 10:13 |
| pitti | libudev0-udeb ? | 10:13 |
| pitti | cjwatson: right now yes, I disabled all of them because we want to stay on the separate udev for now | 10:14 |
| cjwatson | Um, confused. Isn't libudev0 meant to go away? | 10:14 |
| pitti | yes, it is | 10:14 |
| pitti | I guess we need to build a libudev1-udeb | 10:14 |
| cjwatson | I guess I don't see how libudev0-udeb can be a legitimate udeb substitution for libudev1 :) | 10:14 |
| cjwatson | Sounds like it | 10:15 |
| pitti | cjwatson: so having libudev1 only implies that we cannot continue to use libudev0-udeb and udev-udeb built from the udev source? | 10:15 |
| pitti | I kept those for now | 10:15 |
| pitti | I had assumed keeping libudev0-udeb would be okay, and we could do that as a separate transition | 10:16 |
| cjwatson | I'm not sure about the new layout. In general life will be simpler if you have debs and udebs in sync | 10:16 |
| cjwatson | I think trying to avoid that is a false economy | 10:16 |
| pitti | libudev1-udeb sounds harmless | 10:16 |
| pitti | what I'd like to avoid is building udev-udeb from systemd | 10:16 |
| cjwatson | Well, you don't build udev from systemd right now, do you? | 10:17 |
| pitti | but just like the real udev, udev-udeb shouldn't depend on the library | 10:17 |
| cjwatson | That's what I mean by in-sync | 10:17 |
| cjwatson | And indeed it doesn't | 10:17 |
| cjwatson | So it's just a matter of getting the linkage sorted for stuff that requires libudev1 | 10:17 |
| pitti | so, so I'll build a libudev1-udeb from systemd, drop libudev0-udeb from udev, and adjust the shlibs | 10:17 |
| cjwatson | That sounds right to me | 10:18 |
| pitti | ok, thanks | 10:18 |
| pitti | sorry about the mess | 10:18 |
| cjwatson | that's ok, catching this is what these tools are meant to do | 10:19 |
| cjwatson | so this is a success :) | 10:19 |
| pitti | actually, udev-gtk-udeb is supposed to be libudev1-udeb AFAICS, /me asks mbiebl | 10:20 |
| seb128 | @pilot in | 10:30 |
| === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion 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: seb128 | ||
| pitti | cjwatson: systemd with libudev1-udeb installed; so I'll let that build and publish, then rebuild the X.org bits again to pick up the fixed shlibs | 10:38 |
| pitti | err, s/installed/uploaded/ | 10:39 |
| pitti | which would be xorg-server and xserver-xorg-input-evdev | 10:41 |
| cjwatson | COol | 10:43 |
| cjwatson | With sane capitalisation | 10:43 |
| tjaalton | I can handle the xorg rebuilds | 10:48 |
| pitti | meh, FTBFS due to enabled "make check" | 10:48 |
| pitti | tjaalton: ok thanks, I'll ping you when it's ready? | 10:48 |
| tjaalton | sure | 10:49 |
| pitti | I guess the chroots don't have an /etc/hostname or so | 10:49 |
| pitti | Laney: do you need to adjust your autohints for udev somehow? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt header looks a bit odd | 11:26 |
| pitti | Laney: (I don't quite know yet how this works, I'm just curious) | 11:26 |
| Laney | pitti: likely, since you uploaded it | 11:27 |
| Laney | but it may be that it can figure it out itself now | 11:27 |
| cjwatson | You'll need to bump the version | 11:27 |
| pitti | but udev and systemd don't appear at all any more | 11:27 |
| cjwatson | They won't, because they're out of sync at the excuses level | 11:28 |
| cjwatson | Nothing shows up in output (global consistency checks) until it passes the excuses stage (package-by-package checks) | 11:28 |
| cjwatson | So don't worry about it, it'll sort itself in time | 11:28 |
| pitti | ok, thanks | 11:28 |
| infinity | systemd already migrated a couple of versions back anyway, unless it's changed again in a way that needs more hinting. | 11:28 |
| Laney | it needs NEWing this time | 11:29 |
| cjwatson | Yeah, I'm doing that now | 11:29 |
| pitti | yeah, I'm waiting for the arm and ppc builds, and will prod an archive admin when they are ready | 11:29 |
| cjwatson | No harm NEWing in advance of that | 11:29 |
| cjwatson | (done) | 11:31 |
| infinity | shadeslayer: Hey, is there an upstream bump of ktp-contact-applet on the way to match the rest of your uploads? | 11:32 |
| infinity | shadeslayer: And ktp-presence-applet too. | 11:33 |
| infinity | shadeslayer: Without those two, the rest can't migrate. | 11:34 |
| tseliot | cjwatson: I'm afraid upstream won't accept my fix for bug #1073062 . The maintainer says we should patch initramfs-tools instead but I disagree. Shall we keep the patch in Ubuntu? | 11:36 |
| ubottu | bug 1073062 in kmod (Debian) "modprobe: Assertion `kmod_module_get_initstate(m) == KMOD_MODULE_BUILTIN' failed" [Unknown,New] https://launchpad.net/bugs/1073062 | 11:36 |
| infinity | tseliot: Err, that has nothing to do with initramfs-tools. | 11:37 |
| infinity | tseliot: Which upstream maintainer? The Debian one, or upstream upstream? | 11:37 |
| * infinity goes to look at the Debian bug, hoping for context. | 11:37 | |
| * cjwatson happily defers to infinity since he's looking | 11:38 | |
| tseliot | infinity: the Debian one | 11:38 |
| tseliot | I thought he was upstream upstream... | 11:38 |
| infinity | Lucas is upstream, not Debian, yes. | 11:39 |
| infinity | Reading. | 11:39 |
| infinity | tseliot: He is right about one thing. Those aliases were only officially supported in modutils. So, a decade ago. | 11:41 |
| infinity | tseliot: I'm not sure if it was an accident or backward compat that they didn't break in m-i-t, but they weren't documented in m-i-t either. | 11:41 |
| infinity | tseliot: I don't see him saying we should patch initramfs-tools instead, unless that's in a private email? | 11:43 |
| tseliot | infinity: true but I believe it shouldn't error out like that | 11:44 |
| tseliot | infinity: yes, I don't know why that email didn't make it: "Then you should fix the initram update software. I suggest you to try the blacklist stuff instead of this off/null alias and if it doesn't work to tell me." | 11:44 |
| infinity | tseliot: Either way, breaking upgrades gratuitously seems like a bad idea, and initramfs-tools isn't the place for the fix. If upstream doesn't want the patch (and that's fine), we should carry it locally, make it also spit out a warning to stderr, and make sure we don't ship anything that creates aliases like that. | 11:44 |
| infinity | tseliot: And then, later, we can drop the patch (say, after 14.04). | 11:44 |
| tseliot | infinity: ok, it sounds like a plan | 11:44 |
| infinity | tseliot: Also, he's missing the point that this isn't about using different config options, it's about smooth upgrades for people who have the old config options. | 11:45 |
| infinity | tseliot: You might want to point that out. | 11:45 |
| infinity | tseliot: Yes, blacklisting might be the right thing, but we can't magically change people's systems. | 11:45 |
| tseliot | infinity: I will, even though I doubt it will change anything | 11:45 |
| infinity | tseliot: (And the reason blacklisting probably doesn't currently work with udev for us is that our udev doesn't use libkmod yet, his does) | 11:45 |
| infinity | At least, doesn't work the way he thinks it should. :P | 11:46 |
| infinity | Our udev just forks modprobe. | 11:46 |
| infinity | Probably without -b ... Though that would seem like a bug too. | 11:46 |
| infinity | If true. | 11:46 |
| infinity | (Are you sure blacklists don't work with our udev? They really should) | 11:47 |
| tseliot | infinity: udev in raring uses libkmod but, apparently, the one in precise doesn't | 11:47 |
| pitti | /etc/blacklist.d/ very much does work in raring | 11:47 |
| tseliot | I've just found out | 11:47 |
| infinity | tseliot: udev in raring doesn't use libkmod. | 11:47 |
| pitti | I wish it did, but it doesn't, yes | 11:47 |
| infinity | tseliot: Except via modprobe, of course. | 11:47 |
| infinity | tseliot: But that's not the codepath he was pointing out. | 11:48 |
| infinity | tseliot: And of course it doesn't in precise, we don't have kmod in precise. | 11:48 |
| tseliot | infinity: I can see #include <libkmod.h> in src/udev/udev-builtin-kmod.c | 11:48 |
| infinity | tseliot: Yes, but we don't build that bit. | 11:48 |
| tseliot | oh | 11:48 |
| pitti | tseliot: we still use the standalone old udev source | 11:48 |
| infinity | ldd /sbin/udevd is pretty conclusive. :P | 11:49 |
| tseliot | ok | 11:49 |
| tseliot | but does "alias module off" work in our udev? | 11:49 |
| pitti | but going back to blacklisting, that's supposed to always work, even with newer udevs | 11:49 |
| pitti | oh, I don't know that for sure | 11:49 |
| infinity | Anyhow, dumping core is a Bad Thing. I can see where upstream is coming from too, that supporting config options that haven't been documented as valid for over a decade is probably a complete waste of time. | 11:50 |
| infinity | tseliot: It's not up to udev for that to work, it just passes the mess to modprobe (in our case), so it'll fail the same as in initramfs-tools. | 11:50 |
| infinity | tseliot: Which is why the fix (for us) belongs in kmod. But I can see the argument for it not being upstreamable, and that's not world-ending. | 11:51 |
| tseliot | infinity: agreed | 11:51 |
| infinity | tseliot: I will probably amend your patch to be verbose, so people get some fair warning that they should update their configs. | 11:51 |
| infinity | tseliot: And maybe it'll teach nvidia/fglrx people to Stop Doing That. | 11:52 |
| tseliot | infinity: that's a leftover from precise (coming from bug #864149) | 11:52 |
| ubottu | bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released] https://launchpad.net/bugs/864149 | 11:52 |
| tseliot | infinity: so I'll more than glad to stop doing that ;) | 11:53 |
| tseliot | *I'll be | 11:53 |
| infinity | tseliot: Yeah, so those should be blacklists, not aliases. He's right. | 11:53 |
| infinity | tseliot: And, ideally, fixed in the next round of precise SRUs you do, so the problem eventually goes away. | 11:54 |
| infinity | tseliot: But we'll carry this patch until 14.04 to make sure upgrades don't go sideways. | 11:54 |
| infinity | (And I'll do the verbosity change today) | 11:54 |
| tseliot | infinity: why Precise? Wouldn't it reopen bug #864149 ? | 11:55 |
| ubottu | bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released] https://launchpad.net/bugs/864149 | 11:55 |
| tseliot | I'll change it in Raring for sure | 11:56 |
| infinity | tseliot: Erm, why would it reopen that bug? I didn't read the whole thing... | 11:56 |
| tseliot | infinity: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/864149/comments/3 | 11:56 |
| ubottu | Launchpad bug 864149 in nvidia-graphics-drivers-updates (Ubuntu Oneiric) "initrd doesn't set keyboard layout when nvidia drivers are installed (FRAMEBUFFER=n override)" [High,Fix released] | 11:56 |
| infinity | - set 'alias nouveau off' in the modprobe blacklist file, *not* 'blacklist nouveau'. (udev ignores module blacklisting by design!) | 11:57 |
| infinity | Hrm. | 11:57 |
| infinity | Now I see where you got that idea from. | 11:57 |
| tseliot | yep | 11:57 |
| infinity | That seems like it shouldn't be true. But maybe it is. | 11:57 |
| tseliot | I'm not willing to take that risk in Precise ;) | 11:58 |
| infinity | You could also do the install foo /bin/true thing. But this probably needs more investigation. | 11:58 |
| infinity | tseliot: Hold off on changing things in raring too, I think we'll need to dig deeper into ACTUAL behaviours, instead of relying on conjecture. | 11:58 |
| tseliot | infinity: fine by me. Are you going to deal with it? (I don't see any problems with the change in raring) | 11:59 |
| infinity | Well, the change in raring may regress this too. (I mean, changing nvidia/fglrx, the kmod change is fine). | 12:00 |
| infinity | tseliot: I'll have to dig a big into how this all interacts, so I have decent warning text to throw to stderr to tell people how to fix their config files. | 12:00 |
| infinity | tseliot: And once I've sorted that a bit, I'll also have a good idea of what things should look like in both precise and raring (if the former should change at all) | 12:01 |
| tseliot | infinity: ok, good, I'll leave it in your hands then. Thanks | 12:02 |
| * infinity shudders at the idea of turning on the nvidia GPU in his laptop again to test all of this. | 12:03 | |
| infinity | Bye, bye battery life. :) | 12:03 |
| tseliot | :) | 12:07 |
| === MacSlow is now known as MacSlow|lunch | ||
| === tvoss is now known as tvoss|lunch | ||
| seb128 | @pilot out | 12:37 |
| === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion 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: | ||
| === _salem is now known as salem_ | ||
| pitti | tjaalton: libudev1-udeb is published now, so we can rebuild xorg-server and -evdev | 13:09 |
| pitti | tjaalton: do you have some actual changes, or want you or me to upload no-change rebuilds? | 13:10 |
| tjaalton | pitti: hmm, not really, rebuilds are fine.. | 13:15 |
| infinity | cjwatson: *blink* at 1061909 | 13:15 |
| cjwatson | odd, isn't it | 13:15 |
| infinity | cjwatson: Clearly a Chrome rendering bug, but. Uhm. Wha? | 13:15 |
| cjwatson | web team have been trying to reproduce it | 13:15 |
| infinity | cjwatson: I give 20-to-1 odds that if you move the "32-" to the middle of a line it goes away, but I don't have a machine I can reproduce on. | 13:16 |
| cjwatson | if removing line breaks really fixes it, I'll (a) cry (b) sort it out with the Python rewrite | 13:16 |
| cjwatson | since the reason the line breaks are there is that it makes the code neater in shell :) | 13:16 |
| infinity | Well, you could just move the variable expansion up a line, or whatver. | 13:16 |
| infinity | (Or whatever's generating that, I didn't look) | 13:17 |
| infinity | If it's just a block text, same story. | 13:17 |
| pitti | tjaalton: do you want to upload them (as you mentioned it earlier), or shall I do it now? | 13:17 |
| cjwatson | it's cat <<EOF at the moment | 13:17 |
| infinity | Maybe I can install Chrome on a Windows VM and reproduce. | 13:17 |
| tjaalton | pitti: if you have them ready then go ahead .) | 13:19 |
| tjaalton | :) | 13:19 |
| infinity | cjwatson: Yup, reproduced on Windows. | 13:20 |
| infinity | cjwatson: Gut feeling would be that it's seeing the "^32-" as a multibyte char. | 13:21 |
| pitti | tjaalton: done | 13:21 |
| cjwatson | infinity: ... wow? | 13:21 |
| tjaalton | pitti: thanks | 13:21 |
| cjwatson | er, "how" | 13:21 |
| cjwatson | but "wow" works too | 13:21 |
| cjwatson | I mean, in what encoding is that possibly multibyte? | 13:21 |
| infinity | cjwatson: Effed if I know. But let me move the line break to test the theory. | 13:23 |
| infinity | cjwatson: http://lucifer.0c3.net/~adconrad/wtfchrome/ | 13:25 |
| infinity | cjwatson: Verified that 1.html renders wrong, 2.html renders fine. | 13:25 |
| infinity | cjwatson: Could have something to do with the files being \n-only and Chrome on Windows perhaps behaving crappily without \r\n? I dunno. That's pretty far-fetched, given all the UNIX-generated content on the interwebs. | 13:26 |
| infinity | cjwatson: Either way, not starting a line with 32- fixes it. | 13:26 |
| === MacSlow|lunch is now known as MacSlow | ||
| shadeslayer | infinity: those sources have been dropped, I might have missed something, so I'll have a look tonight | 13:46 |
| infinity | shadeslayer: If they've been dropped, we need to remove them. | 13:47 |
| infinity | shadeslayer: Which I can do for you. Is there a migration/upgrade path there? | 13:47 |
| shadeslayer | infinity: ktp-desktop-applets now replaces those two packages | 13:48 |
| shadeslayer | the upgrade path seems clean ( I tested it before uploading ) | 13:48 |
| infinity | shadeslayer: kde-telepathy-desktop-applets has a Breaks/Replaces for plasma-widget-telepathy-presence but not plasma-widget-telepathy-contac | 13:50 |
| infinity | t | 13:51 |
| infinity | shadeslayer: Also, is Breaks/Replaces really enough to remove the old package entirely? You're sure that test worked? :) | 13:51 |
| infinity | shadeslayer: Anyhow, once you've confirmed that both those sources can go away, let me know, and I'll remove them so the rest can migrate. | 13:53 |
| shadeslayer | infinity: doesn't replace the contact widget because it doesn't overwrite files from that, and I always thought that autoremove will remove packages that nothing depended on ? | 13:53 |
| === wedgwood_away is now known as wedgwood | ||
| infinity | shadeslayer: Oh, if there's no reason to forcefully remove it, sure, it'll just autoremove on its own iff it wasn't installed manually or a direct dep of a metapackage. | 13:54 |
| shadeslayer | yeah, there's no reason to forcefully remove it :) | 13:54 |
| infinity | Kay. | 13:54 |
| infinity | I'll bounce them both out of the archive for you, then. | 13:55 |
| shadeslayer | awesome thanks :) | 13:55 |
| infinity | shadeslayer: Before I hit <enter>, this look right?: http://paste.ubuntu.com/5616555/ | 13:57 |
| mterry | bryce, I have an xorg stack trace I'd like you to look at if you have some time. It's from a jenkins run | 13:58 |
| * infinity takes shadeslayer's silence as a "yes, and I've found better things to do already." | 14:00 | |
| shadeslayer | no wait | 14:00 |
| * shadeslayer is looking | 14:00 | |
| infinity | ... | 14:00 |
| infinity | Too late. :P | 14:00 |
| shadeslayer | hahaha | 14:00 |
| infinity | ALL GONE. | 14:01 |
| shadeslayer | I'm a bit distracted since we have a Kubuntu meeting starting in 2 minutes | 14:01 |
| shadeslayer | lol :) | 14:01 |
| shadeslayer | okay :) | 14:01 |
| pitti | hey mterry | 14:01 |
| mterry | pitti, hi! | 14:01 |
| pitti | mterry: I bounced the systemd MIR back to you FYI, as I believe I addressed most of the concerns (except not having a py3 package; patches/help appreciated..) | 14:01 |
| hallyn | jamespage: ok, just dput the new qemu (was waiting on debian-devel discussion). *should* fix your issues when it's built. phew | 14:02 |
| mterry | pitti, sure, that's not as urgent | 14:02 |
| jamespage | hallyn, great - thanks for letting me know | 14:02 |
| shadeslayer | infinity: thanks, looks good to me | 14:02 |
| hallyn | i'll have to sru those for sure | 14:02 |
| === kentb-out is now known as kentb | ||
| === tvoss|lunch is now known as tvoss | ||
| cjwatson | infinity: All right, thanks. I'll sort it out in a bit | 14:19 |
| cjwatson | infinity: Can you try collapsing the whole paragraph onto one line and make sure that works too? | 14:20 |
| infinity | cjwatson: It should, but sure. | 14:21 |
| cjwatson | (Which should be obviously true, but the whole thing is non-obvious.) | 14:21 |
| infinity | cjwatson: All one line works too. | 14:22 |
| cjwatson | Good, thanks. | 14:23 |
| infinity | cjwatson: I'd be willing to bet that \r\n works too, but too lazy to bother checking. | 14:23 |
| infinity | (Cause that's a crap solution for us) | 14:23 |
| infinity | Though I'd look into it if I had the energy to file a Chrome bug upstream. | 14:23 |
| Laney | Does libudev0-udeb need to be NBS removed for britney to start considering udev? | 14:23 |
| cjwatson | No | 14:24 |
| infinity | No. | 14:24 |
| infinity | Damn my insistence on puctuation. | 14:24 |
| cjwatson | proposed-migration does its consideration on the assumption that any to-be-NBSed binaries don't exist | 14:24 |
| Laney | what does the excuses entry for udev mean then? | 14:24 |
| cjwatson | i.e. it assumes that the new suite looks like (old suite) - (all contents of old source package) + (all contents of new source package) | 14:24 |
| infinity | It means there a libudev0-udeb in proposed. | 14:25 |
| infinity | I'll remove it. | 14:25 |
| cjwatson | Oh, right. Yeah, maybe it does then :) | 14:25 |
| cjwatson | Forgot that it needs NBS removal to pass the excuses stage. | 14:25 |
| Laney | :-) | 14:25 |
| infinity | Fixed. | 14:25 |
| Laney | merci | 14:26 |
| infinity | NBS removal in -release isn't required, but it has a bit of a tizzy if there's NBS in -proposed. | 14:26 |
| cjwatson | Yeah. NBS removal in release pre-migration is kind of a bad idea in case the migration fails for a reason you haven't thought of, anyway. | 14:28 |
| * Laney nods | 14:29 | |
| Laney | At least excuses is pretty clear about NBS in proposed | 14:29 |
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| Laney | pitti: Looks like you missed xwiimote. I'll upload a rebuild there. | 15:09 |
| infinity | pitti: xwiimote might need an O_BLOCK change. | 15:10 |
| infinity | Laney: ^ | 15:10 |
| dobey | aww, infinity didn't review my fix for twisted last night. sad cupcakes :( | 15:10 |
| infinity | dobey: No, I had a bit of a crisis here. I'll look now. | 15:11 |
| Laney | infinity: Not familiar with the problem. You do it if you like. | 15:11 |
| dobey | infinity: oh ok. thanks :) | 15:11 |
| infinity | dobey: ... if I can find that browser window again. | 15:11 |
| infinity | Ah-ha. | 15:12 |
| dobey | heh | 15:14 |
| infinity | dobey: Looks plausibly correct. Uploaded. | 15:16 |
| === salem_ is now known as _salem | ||
| dobey | thanks | 15:17 |
| === greyback is now known as bzoltan-smells | ||
| === bzoltan-smells is now known as greyback | ||
| === Ursinha_ is now known as Ursinha | ||
| === rsalveti_ is now known as rsalveti | ||
| === _salem is now known as salem_ | ||
| === Sweetsha1k is now known as Sweetshark | ||
| ogasawara | @pilot in | 16:02 |
| === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion 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 | ||
| Laney | seb128: amd64 retracers dead again? | 16:04 |
| seb128 | Laney, yes, for 2 days :-( | 16:05 |
| * seb128 removes lock | 16:05 | |
| seb128 | <html><body><h1>504 Gateway Time-out</h1> | 16:06 |
| Laney | hmm, I just came across a bug I filed on 2013-02-28 | 16:07 |
| Laney | which isn't retraced yet | 16:07 |
| seb128 | Laney, is it tagged need-<arch>-retrace ? | 16:10 |
| Laney | yes, and ~apport is subscribed | 16:11 |
| seb128 | maybe we didn't get any run that managed to clear the backlog since | 16:12 |
| seb128 | we keep restarting them but they hit launchpad timeouts regularly | 16:12 |
| seb128 | Laney, what's the bug numbeR? | 16:12 |
| Laney | #1134468 | 16:12 |
| Laney | er, #1135568 | 16:12 |
| seb128 | Laney, it's in the retracing pool | 16:13 |
| seb128 | last run had a backlog of 350 bugs :-( | 16:14 |
| seb128 | Laney, I will try to watch for timeouts and keep restarting until we clear the backlog | 16:14 |
| * seb128 shakes fist at launchpad | 16:14 | |
| pitti | Laney: err, I did? that doesn't depend on libudev | 16:29 |
| pitti | Laney: not on amd64 at least | 16:29 |
| Laney | does here | 16:30 |
| Laney | Depends: libc6 (>= 2.14), libudev0 (>= 147) | 16:30 |
| Laney | (libxwiimote1) | 16:30 |
| pitti | Laney: ah; thank you! | 16:30 |
| pitti | not sure how it slipped through | 16:30 |
| Laney | np - I didn't upload it because of ∞'s comment | 16:31 |
| xnox | infinity: add a new highlight for ∞ | 16:34 |
| Laney | that was specifically intended not to highlight | 16:34 |
| === salem_ is now known as _salem | ||
| infinity | pitti: Yeah, at a quick glance, it might need a similar-but-different NOBLOCK fix (in fact, their internal wrapper function already has a "bool blocking" argument, but then they call it with false...) | 16:36 |
| infinity | pitti: I'm trying to sort out if that's valid, or if they've misunderstood what they want and it accidentally worked before. | 16:36 |
| infinity | pitti: Not having a clue what any of it's meant to do, it's a bit of a crap shoot trying to follow the code and guess their intent. :P | 16:36 |
| infinity | pitti: And happy to hand it off to you, since it's your transition. I got distracted by chromium on ARM anyway. And Jono's G+... | 16:37 |
| infinity | jono_: Grr. | 16:37 |
| pitti | yeah, making a note; thanks | 16:38 |
| jono_ | infinity, the G+ post? | 16:38 |
| jono_ | lol | 16:39 |
| infinity | jono_: Yes. I wish this wasn't something I felt so passionately about, so I could just sit back and laugh instead of being grumpy. | 16:40 |
| lifeless | which one ? | 16:40 |
| pitti | Laney, infinity: hm, I did upload chromium -- another hardcoded dep? | 16:41 |
| * ogra_ opens G+ in curiosity | 16:41 | |
| Laney | chromium is armhf out of sync fail | 16:42 |
| micahg | I thought someone forced through the last version, so it shouldn't matter | 16:42 |
| pitti | kipped: udev (0 <- 451) | 16:43 |
| pitti | got: 108+0: i-108 | 16:43 |
| pitti | * i386: chromium-browser, [...] | 16:43 |
| pitti | http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt only complains about i386, not amd64 or arm | 16:43 |
| ogra_ | Laney, the eternal one :/ | 16:43 |
| infinity | pitti: chromium isn't your problem. I'll work on the armhf FTBFS and, if it stumps me, force the rest. | 16:43 |
| micahg | pitti: that's because i386 still used libudev0, must not have published in time or something | 16:44 |
| * pitti likes not owning chromium problems as well at this point and goes back to puzzling together a Frankenudev | 16:44 | |
| pitti | micahg: hm, I uploaded that yesterday already | 16:44 |
| micahg | pitti: if CHromium needs a rebuild, I want to fix an RC bug | 16:44 |
| micahg | pitti: see the build log yourself :) https://launchpadlibrarian.net/134067999/buildlog_ubuntu-raring-i386.chromium-browser_25.0.1364.160-0ubuntu1b1_UPLOADING.txt.gz | 16:45 |
| micahg | oh, hrm, nevermind, it's in the base system | 16:45 |
| infinity | micahg: Want to bounce me the fix? I'll incorporate it into my armhf-fixing upload, if I manage to sort that today, or just sponsor it if I don't. | 16:45 |
| infinity | micahg: To avoid back-to-back builds. | 16:45 |
| pitti | micahg: yeah, and those debs use libudev1 | 16:46 |
| micahg | infinity: it's to drop the recommends here to suggests: bug 1153137 | 16:46 |
| ubottu | bug 1153137 in chromium-browser (Ubuntu Raring) "Please remove recommends on webaccounts-chromium-extension and unity-chromium-extension" [High,Triaged] https://launchpad.net/bugs/1153137 | 16:46 |
| infinity | pitti: The chromium-browser output in output.txt is a red herring, just due to britney not updating chromium at all from the armhf out-of-date. Ignore it. | 16:47 |
| infinity | micahg: ^ | 16:47 |
| pitti | infinity: ack | 16:47 |
| infinity | micahg: And yeah, I can do that fix while I'm in there. | 16:47 |
| micahg | infinity: thanks | 16:47 |
| micahg | pitti: sorry for the noise | 16:47 |
| chrisccoulson | infinity, armhf build fix? note, i've got fixes local here which make it build on armhf (12.04 though) | 16:56 |
| chrisccoulson | oh, different version though ;) | 16:57 |
| chrisccoulson | ha | 16:57 |
| === _salem is now known as salem_ | ||
| infinity | chrisccoulson: Oh, if this is a solved problem, I'll happily let you fix it in raring so I don't have to. | 16:58 |
| chrisccoulson | infinity, it looks like the raring issue is a new one, as with every new version ;) | 16:58 |
| chrisccoulson | infinity, i suspect that if you fix it, it won't start in any case | 16:59 |
| slangasek | jodh: ping | 17:00 |
| jodh | slangasek: hi | 17:00 |
| infinity | chrisccoulson: That's rather optimistic of you. | 17:01 |
| chrisccoulson | infinity, i'm a positive thinking guy | 17:01 |
| slangasek | jodh: heya! apparently I didn't manage to actually submit my review comments on https://code.launchpad.net/~jamesodhunt/upstart/file-bridge-MP/+merge/152767 before it got merged :) Most of my comments are cosmetic manpage stuff that I can just fix up, but there was one point I wanted to discuss | 17:01 |
| slangasek | jodh: why 'FEVENT', 'FPATH' instead of just 'EVENT', 'PATH'? The latter seems much more idiomatic to me | 17:01 |
| jodh | slangasek: because PATH is going to be set in the user session. | 17:02 |
| jodh | slangasek: we could change it to 'file FILE=/some/path' maybe. | 17:02 |
| slangasek | oh right | 17:02 |
| slangasek | jodh: I think I would prefer either 'FILE' or 'FILE_PATH'; I find the 'F' prefixing less than pretty :) | 17:03 |
| infinity | chrisccoulson: Oh, wow, I hadn't even looked at the raring FTBFS. That's a big WTF. | 17:03 |
| chrisccoulson | infinity, yeah, i just thought exactly the same thing ;) | 17:04 |
| jodh | slangasek: agreed - I vote for FILE then :) | 17:04 |
| infinity | chrisccoulson: And not filesystem corruption or something, the previous build was the same. | 17:04 |
| infinity | chrisccoulson: These people aren't doing silly -nostdinc things and then constructing an incorrect include path themselves, are they? | 17:04 |
| jodh | slangasek: EVENT is a bit generic though too I thought. | 17:04 |
| pitti | Laney: ah, so you didn't upload xwiimote yet, right? | 17:04 |
| infinity | pitti: Nope, he didn't, because of my concerns. | 17:05 |
| infinity | pitti: Which I was tracing through until I handed it off to you. | 17:05 |
| infinity | pitti: <3 | 17:05 |
| pitti | ah, ok | 17:05 |
| jodh | slangasek: maybe CHANGE=...? | 17:05 |
| pitti | I'll test my franken-udev now, and if that works I'll call it a (long enough) week, so somethign for Monday | 17:06 |
| pitti | _sbin_udevd.0.crash | 17:06 |
| pitti | meh | 17:06 |
| pitti | Monday it is | 17:06 |
| slangasek | jodh: I think 'EVENT' is fine, honestly | 17:07 |
| slangasek | jodh: it's a bit recursive since upstart events are also events, of course | 17:07 |
| jodh | slangasek: :) | 17:08 |
| chrisccoulson | infinity, i can take a look at this. i should probably try the latest version to make sure it's still got the same v8 problem that i've been looking at | 17:08 |
| * chrisccoulson reluctantly rm's my current build tree to free up space | 17:08 | |
| slangasek | jodh: maybe it would be better to make it part of the event name itself? i.e., file_create, file_modify, file_delete? That makes jobs more cumbersome if you want to watch for all three though | 17:09 |
| chrisccoulson | hmmm, i'm sad now. it took me long enough just to get that tree to build on my sad panda ;) | 17:10 |
| slangasek | jodh: upstart itself doesn't use $EVENT anywhere, just $UPSTART_EVENTS. Maybe INOTIFY_EVENT? | 17:10 |
| xnox | slangasek: omit FEVENT, and just listen for file FPATH=/foo, that will give you all three. and just test. | 17:10 |
| slangasek | xnox: yes, but I'm arguing against 'FEVENT' | 17:11 |
| xnox | udev events use these semantics.... and it's nice =) | 17:11 |
| slangasek | xnox: thinking out loud about whether it should be part of the actual /upstart/ event name, but that has the mentioned drawback | 17:11 |
| infinity | chrisccoulson: Cool, if you're on it, can you also fix the bug micahg pointed out? | 17:12 |
| slangasek | actually, 'file-create', 'file-modify' would certainly be closer in spirit to the existing upstart bridge ('net-device-added', 'net-device-removed', ...) | 17:12 |
| chrisccoulson | infinity, which one? | 17:13 |
| infinity | chrisccoulson: https://launchpad.net/bugs/1153137 | 17:13 |
| ubottu | Launchpad bug 1153137 in chromium-browser (Ubuntu Raring) "Please remove recommends on webaccounts-chromium-extension and unity-chromium-extension" [High,Triaged] | 17:13 |
| infinity | chrisccoulson: Just dropping those to Suggests will do the trick. | 17:14 |
| slangasek | jodh, xnox: what do you think about file-create/file-modify/file-delete events, rather than a generic 'file'? | 17:15 |
| jodh | slangasek: MP raised for FPATH -> FILE et al. | 17:18 |
| jodh | slangasek: We've already got examples of both approaches - the udev bridge follows your proposal but the socket bridge the current file bridge way. I guess by splitting file into 3 separate events we offload the burden of filtering the correct one from the job to the bridge itself. But you can of course already specify individual events using (now) EVENT='...'. | 17:20 |
| jodh | slangasek: the current approach does allow a mix of behaviours though - if you care about all the event types, just don't specify EVENT (oddly :). Whereas, if you only care about a single type, specify it explicitly. | 17:22 |
| stokachu | hi, could i get someone to approve precise nomination for bug 1155157 | 17:33 |
| ubottu | bug 1155157 in unity-greeter (Ubuntu Raring) "[FFe] Allow custom indicators" [Undecided,New] https://launchpad.net/bugs/1155157 | 17:33 |
| stokachu | and Quantal nomination as well | 17:36 |
| mitya57 | dholbach: pt_BR 74% :) | 17:36 |
| dholbach | mitya57, yes - did you see the bug report I added? | 17:37 |
| dholbach | it FTBFS | 17:37 |
| ScottK | stokachu: We don't generally allow new features in SRUs. Why precise? | 17:37 |
| dholbach | and I was too busy to look into anything at all regarding the packaging guide | 17:37 |
| dholbach | still too busy | 17:37 |
| mitya57 | no, I didn't | 17:37 |
| stokachu | ScottK: mind if i pm you? | 17:37 |
| ScottK | No | 17:38 |
| ScottK | I won't have anything different to say in private, but as you prefer. | 17:38 |
| * mitya57 is looking | 17:39 | |
| mitya57 | dholbach: bug 1154087 fixed now | 17:48 |
| ubottu | bug 1154087 in Ubuntu Packaging Guide "building pt_BR FTBFS" [Undecided,New] https://launchpad.net/bugs/1154087 | 17:48 |
| mitya57 | re the sphinx versions, that build-dep was needed for debian; I'm going to backport the required versions in my test ppa and then copy to packaging-guide ppa | 17:49 |
| dholbach | mitya57, perfect - feel free to merge the other branch then | 17:49 |
| dholbach | mitya57, you're a hero | 17:49 |
| dholbach | mitya57, once the package built correctly I'll make the necessary changes to developer.u.c | 17:50 |
| dholbach | but this day was long enough already and I need to rush out to meet somebody for dinner | 17:50 |
| stokachu | seb128: hey do you mind taking a look at bug 1155583 | 17:50 |
| ubottu | bug 1155583 in gnome-screenshot (Ubuntu Precise) "gnome-screenshot does not display accented characters correctly" [Low,Triaged] https://launchpad.net/bugs/1155583 | 17:50 |
| dholbach | so let's take care of the other bits via mail :) | 17:50 |
| mitya57 | developer.u.c uses quantal packages, so this will wait until I backport sphinx | 17:51 |
| dholbach | mitya57, are you merging the ptbr branch I did or shall I do it? | 17:51 |
| mitya57 | dholbach: will do one more test build and merge | 17:52 |
| dholbach | ok thanks | 17:52 |
| * dholbach hugs mitya57 | 17:52 | |
| dholbach | have a great weekend everyone! | 17:52 |
| mitya57 | dholbach: you too! | 17:53 |
| seb128 | stokachu, that patch looks fine to me | 18:03 |
| stokachu | seb128: sweet, do you think we could get that in motion? | 18:05 |
| stokachu | :) | 18:05 |
| seb128 | stokachu, you should ask for upload rights at some point ;-) | 18:06 |
| stokachu | seb128: hah i did but didn't have enough upstream collateral | 18:06 |
| seb128 | ok, I will avoid starting a DMB rant today :p | 18:07 |
| stokachu | lol | 18:07 |
| stokachu | seb128: thanks man | 18:09 |
| seb128 | stokachu, yw | 18:09 |
| ScottK | seb128: I see the fonts-tlwg package you sync'ed two weeks ago is still dep-wait. Did you have a plan to address that? | 18:11 |
| seb128 | ScottK, will do now that I know about it, I wish launchpad would email the uploader about those or something | 18:11 |
| seb128 | ScottK, how/where did you notice that it's depwaiting? | 18:12 |
| * seb128 would like a list of depwait packages | 18:12 | |
| ScottK | Let me find the link | 18:12 |
| ScottK | seb128: Found it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 18:12 |
| seb128 | ScottK, ah, thanks | 18:13 |
| ScottK | seb128: It's also on http://qa.ubuntuwire.com/ftbfs/ | 18:13 |
| stokachu | jamespage: ping | 18:15 |
| pitti | there, Frankenudev working, have a nice weekend everyone! | 18:16 |
| seb128 | pitti, great work systemd/udev/logind this week | 18:17 |
| pitti | *phew* | 18:17 |
| seb128 | pitti, have a nice w.e! | 18:17 |
| pitti | seb128: you too! | 18:18 |
| micahg | seb128: Debian has a new libgsf and I TIL, I'm happy to merge as it looks like bug fix only, but I wanted to check with you first | 18:18 |
| seb128 | micahg, would be good, thanks for working on that! | 18:19 |
| micahg | sure, thanks | 18:19 |
| stokachu | xnox: ping :D | 18:20 |
| seb128 | stokachu is looking for extra sponsoring/uploads :p | 18:21 |
| stokachu | haha | 18:21 |
| stokachu | this time im just looking for information on why autofs5 is still being built without dbgsym | 18:25 |
| stokachu | or if it is i can't find them on lp | 18:25 |
| seb128 | stokachu, look at the build log I guess? | 18:27 |
| seb128 | https://launchpadlibrarian.net/118514564/buildlog_ubuntu-precise-i386.autofs5_5.0.6-0ubuntu5.1_BUILDING.txt.gz has | 18:28 |
| seb128 | "autofs is already stripped, ignoring | 18:28 |
| seb128 | autofs-ldap is already stripped, ignoring | 18:28 |
| seb128 | autofs-hesiod is already stripped, ignoring" | 18:28 |
| stokachu | but they get built as far as i can tell | 18:28 |
| stokachu | dpkg-deb: building package `autofs5-hesiod-dbgsym' in `../autofs5-hesiod-dbgsym_5.0.6-0ubuntu5.1_amd64.ddeb'. | 18:29 |
| seb128 | stokachu, they are on http://ddebs.ubuntu.com/pool/main/a/autofs5/ | 18:29 |
| seb128 | it seems? | 18:29 |
| stokachu | ah there we go | 18:29 |
| seb128 | 5.1 seems to be missing for amd64/i386 though | 18:30 |
| seb128 | maybe the collector job failed to run | 18:30 |
| seb128 | you should nag infinity about finishing proper ddeb support in soyuz :p | 18:30 |
| stokachu | lol maybe ill save that for another day | 18:31 |
| pitti | Laney, infinity: xwiimote fix uploaded, FTR; so please feel free to hint away chromium :) | 18:38 |
| pitti | and good night for real | 18:38 |
| ogra_ | pitti, enjoy | 18:38 |
| infinity | pitti: Curious. If you decided that was necessary, why not just s/false/true/ to the call to the wrapper that sets up the monitor? | 18:49 |
| hallyn | cjwatson: hey, when talking about how to package openbios-ppc in ubuntu, stgraber suggested (iiuc) that signed kernels are being done by building on the native arch, then having other arches take binaries from the native compiled package. Is that so? | 19:18 |
| hallyn | (I looked at linux-meta, and see it's amd64-only, but don't see any packages for other arches) | 19:19 |
| hallyn | (sorry if you're the wrong person to ping, it just seems like your bag of chips :) | 19:19 |
| stgraber | hallyn: -signed actually uses binaries for the same arch but generated earlier on | 19:21 |
| hallyn | ah | 19:21 |
| stgraber | hallyn: (or so is my understanding) | 19:21 |
| hallyn | so it can just grab them from debian/tmp ? | 19:21 |
| * hallyn checks | 19:21 | |
| stgraber | hallyn: no, it grabs them from the archive because they are two different sources | 19:22 |
| hallyn | stgraber: what source package is this happening in? the -signed packages seem to source from linux-meta, but i don't see it there | 19:22 |
| stgraber | hallyn: basically for the kernel, the "linux" sourcei s uploaded, builds on all architectures. Then the "linux-signed" source is uploaded (containing just a script) which at build time, grabs the binary generated earlier on by the "linux" source, signs it and produces another binary package with it | 19:23 |
| stgraber | hallyn: apt-get source linux-signed | 19:23 |
| hallyn | d'oh. i didn't see that in my aptitude query. sorry. | 19:24 |
| hallyn | heh. so i should be bugging apw if anyone :) thanks stgraber | 19:25 |
| stgraber | hallyn: well, poking cjwatson is still a good idea just to make sure that it'll be allowed to do such a trick in the Ubuntu archive ;) | 19:26 |
| hallyn | i assume he's done for the day, | 19:26 |
| hallyn | so I'll just stare at this awhile, let it sink in over the weekend, then talk to him/them on monday | 19:26 |
| ogra_ | he tends to read backlog :) | 19:26 |
| hallyn | thanks! | 19:26 |
| hallyn | ogra_: I figure | 19:26 |
| stgraber | cjwatson: to clarify, we're talking about having openbios build for all supported architectures, then have another source package (qemu or something) grab the binaries from the earlier openbios build and dump them into an arch:all package to be used by qemu-system-* | 19:27 |
| hallyn | stgraber: "build for all supported architectures"? I actually thought we were going to only have openbios-ppc-real build on ppc (we can't have it build on sparc :) and then on other arches grab the binaries (from openbios-ppc) | 19:28 |
| hallyn | (from oepnbios-ppc-real, into openbios-ppc, that is) | 19:29 |
| stgraber | hallyn: "all supported architectures for openbios-pcc" == powerpc ;) but yeah, I guess I could have said just ppc | 19:29 |
| hallyn | oh ok :) | 19:29 |
| hallyn | is it possible to get a ppa to build packages for ppc? | 20:01 |
| slangasek | hallyn: only a devirtualized ppa | 20:04 |
| slangasek | which are a scarce resource and should be used sparingly | 20:04 |
| hallyn | slangasek: ok, not sure it's needed - it would be to test the ping-ponging of openbios-ppc pkg as described above ^ will wait to look more into that, thanks. | 20:08 |
| arges | bdmurray: slangasek: re bug 1059592, verification was never completed because the test case is fairly undeterministic. I'm not sure a regression was introduced by this issue as you posted, but if you'd like to drop the patch you can because I haven't verified it. | 20:09 |
| ubottu | bug 1059592 in rsyslog (Ubuntu Quantal) "Message and memory corruption in rsyslog" [High,Fix committed] https://launchpad.net/bugs/1059592 | 20:10 |
| slangasek | arges: well, lack of verification means it'll get dropped out anyway at some point, but having reviewed the diff + the new bug report I'm confident in asserting it's not a regression | 20:10 |
| arges | slangasek: agreed thanks | 20:11 |
| bdmurray | there's also bug 1097920 although that is regarding the quantal-proposed package | 20:16 |
| ubottu | bug 1097920 in rsyslog (Ubuntu) "rsyslog SEGFAULT " [Undecided,New] https://launchpad.net/bugs/1097920 | 20:16 |
| chrisccoulson | infinity, the chromium build system is passing a bogus --sysroot argument to the compiler, pointing to a non-existant path | 20:16 |
| bdmurray | oh, that's unlikely related too | 20:16 |
| chrisccoulson | removing that fixes the error on the one object i've tried it on ;) | 20:17 |
| chrisccoulson | (now to figure out how to fix the build system properly) | 20:17 |
| infinity | chrisccoulson: Ugh. Sounds like some gifted child has decided that ARM == cross-building. | 20:17 |
| infinity | chrisccoulson: I can't think of any other reason to pass --sysroot, especially only on one arch. | 20:18 |
| chrisccoulson | infinity, that's exactly what they're doing. in common.gypi: | 20:19 |
| chrisccoulson | ['OS=="linux" and target_arch=="arm" and chromeos==0', { | 20:19 |
| chrisccoulson | 'sysroot%': '<!(cd <(DEPTH) && pwd -P)/arm-sysroot' | 20:19 |
| chrisccoulson | yay! | 20:19 |
| infinity | Brilliant. | 20:19 |
| chrisccoulson | anyway, i'm off to do some exercise for now. will fix it when i get back :) | 20:19 |
| ogra_ | does that mean chromium 25 in raring on arm ? | 20:20 |
| infinity | ogra_: Assuming he's also fixed the old FTBFS too, yes. | 20:20 |
| chrisccoulson | ogra_, don't get your hopes up ;) | 20:20 |
| infinity | ogra_: This was a new bug on top of the old. | 20:21 |
| infinity | (Plus, even if it builds, it may still fail to, like, do browser stuff) | 20:21 |
| chrisccoulson | chromium 24 doesn't start on arm, even when it does build | 20:21 |
| chrisccoulson | i was still investigating that when i decided i might be better off building the latest version now ;) | 20:21 |
| infinity | There needs to be a testcase for that. do_browser_stuff() || echo "Iz not browzer." | 20:22 |
| chrisccoulson | infinity, yeah, we pretty much have that sort of testcase for firefox already https://jenkins.qa.ubuntu.com/job/raring-ppa-adt-ubuntu_mozilla_daily_ppa-firefox-trunk/ARCH=i386,label=adt/ ;) | 20:23 |
| ogra_ | well, i'd really like to run something newer than 22 | 20:23 |
| ogra_ | but i wouldnt minf FF either if it would be usably fast | 20:23 |
| chrisccoulson | ogra_, it's fine on !arm ;) | 20:23 |
| ogra_ | i know | 20:24 |
| infinity | ogra_: FF is probably fast if you disable recording history. | 20:24 |
| ogra_ | make gecko use GLES and it will fly on arm too | 20:24 |
| infinity | ogra_: The constant read/writes to that sqlite DB are hell on machines with mediocre storage I/O. | 20:24 |
| ogra_ | infinity, scrolling in websites is unusabley slow | 20:24 |
| infinity | Oh. | 20:24 |
| infinity | That's a different kettle of fish. | 20:25 |
| ogra_ | yeah | 20:25 |
| ogra_ | its definitely the rendering itrelf | 20:25 |
| chrisccoulson | if you make me do all of my work on an arm machine, i'd probably end up fixing it ;) | 20:25 |
| ogra_ | specifically if there is any javascript in the pages it seems | 20:25 |
| === mnepton is now known as mneptok | ||
| * ogra_ ponders paying chrisccoulson a crhomebook if he promises to not use anything else until its fixed | 20:26 | |
| chrisccoulson | heh | 20:26 |
| ogra_ | you would even get along with that insane kezboard | 20:27 |
| * ogra_ never had a £ sign before | 20:27 | |
| ogra_ | its actually the only kbd i ever had that has three currency keys | 20:28 |
| infinity | Mine only has one. | 20:28 |
| infinity | I feel so underprivileged. | 20:28 |
| infinity | And I have no idea how to make GBP or EUR with compose... If there's a way. | 20:29 |
| ogra_ | likely ... | 20:29 |
| ogra_ | never needed it ... so i'm the wrong one to ask :) | 20:29 |
| ScottK | infinity: Find a web page with the symbol and copy/paste. | 20:29 |
| infinity | The obvious attempt at Compose+EUR did nothing useful. | 20:29 |
| ogra_ | poor mans compose | 20:29 |
| infinity | Oh well. All I really need is ☭ | 20:29 |
| ogra_ | heh | 20:29 |
| ScottK | In ☭, ☭ ☭ you. | 20:30 |
| JanC | you can always define your own compose combinations (if you work around GNOME's braindead US-only compose) | 20:31 |
| infinity | All, L- for £ | 20:31 |
| infinity | And E= for € | 20:31 |
| infinity | Those are fairly memorable. | 20:31 |
| * infinity stores that away. | 20:31 | |
| pitti | infinity: because AFAICS it's the polling in lib/monitor.c itself which relies on blocking semantics, not the event based loop in ./tools/xwiikeymap.c; ICBW, of course, it's late | 20:38 |
| infinity | pitti: Fair enough. I didn't trace the code very far before I stopped caring because you popped up. | 20:40 |
| shadeslayer | can someone update the packageset? | 20:43 |
| shadeslayer | s/update/refresh/ | 20:43 |
| ogasawara | @pilot out | 20:50 |
| === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion 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: | ||
| xnox | JanC: one can have us keyboard and euro & pound signs? HOW?! | 20:56 |
| * xnox is only US keybaord user and constantly copy-pastes those two symbols..... | 20:56 | |
| sarnold | xnox: compose, e, = -> € compose, L, - -> £ | 20:59 |
| xnox | sarnold: wow, also turns out i had compose disabled. | 21:00 |
| xnox | today I learned something new =)))) | 21:00 |
| xnox | however sad it is ;-) | 21:00 |
| sarnold | hehe :) | 21:00 |
| cjwatson | hallyn: I was thinking that an alternative workaround for that kind of thing might be to have openbios-ppc be Architecture: powerpc and Multi-Arch: foreign; then at least you could use it via multiarch | 21:05 |
| robru | sarnold, xnox ... what is "compose"? is that a key? | 21:06 |
| hallyn | cjwatson: I think stgraber had suggested that too | 21:06 |
| hallyn | cjwatson: then it would build on ppc, and amd64 qemu-system-ppc could recommend it? | 21:07 |
| sarnold | robru: yes; under standard unity you can configure it via the configure thingy, keyboard layout, options, "compose key location" | 21:07 |
| cjwatson | Or something. It's all a workaround for an in-principle-fixable Soyuz bug anyway ... | 21:07 |
| sarnold | s/location/position/ | 21:07 |
| cjwatson | So feels a bit weird to introduce new package names as part of the workaround. Those tend to be stickier than other workarounds. | 21:08 |
| hallyn | cjwatson: ok, lemme make sure the debian pkg builds in a chroot, and then ping you if it feels like time to push to the archive | 21:08 |
| robru | sarnold, ha, it seems I also have it disabled... | 21:08 |
| cjwatson | hallyn: Don't expect me to be around any longer this evening :) | 21:09 |
| sarnold | robru: I gave up my right control key for it, which is _sometimes_ annoying when I try to navigate tags in vim with ^]. Apparently 1/3rd the time I try to use right-control. (I never knew that. :) | 21:09 |
| robru | € ooooh | 21:09 |
| robru | sarnold, I feel that 'Pause' was the obvious choice. I don't think I've ever used that key in my life. | 21:09 |
| sarnold | robru: oh yeah, that's a good one. :) | 21:09 |
| hallyn | cjwatson: no no, i'm thinking monday :) thx - good night | 21:09 |
| robru | æ wizardy! | 21:10 |
| Sarvatt | xnox: http://cgit.freedesktop.org/xorg/lib/libX11/tree/nls/en_US.UTF-8/Compose.pre | 21:11 |
| infinity | cjwatson / hallyn: Enabling an entire new arch via multiarch just to be able to install one package feels a bit icky, though. | 21:21 |
| hallyn | ppc isn't multiarch right now? | 21:22 |
| micahg | not on x86 (by default) | 21:23 |
| slangasek | hallyn: point is it's quite expensive to enable an additional arch on the client for a single package | 21:24 |
| hallyn | i see | 21:24 |
| hallyn | then maybe i need to look at bug 217427 again after all | 21:25 |
| ubottu | bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged] https://launchpad.net/bugs/217427 | 21:25 |
| cjwatson | That's the real proper fix | 21:25 |
| cjwatson | And I'd far prefer that :) | 21:26 |
| micahg | that'll clear some of the FTBFS list as well that's broken due to missing affinity | 21:26 |
| hallyn | all right, i'll try to get a clue about that one later. gotta run. thanks all. | 21:27 |
| cjwatson | It's I think ~4 packages | 21:28 |
| jtaylor | someone know if I need to wrap python socket.send/recv into EINTR loops? | 21:41 |
| jtaylor | google is not helpful, some say python handles it, some don't ._. | 21:41 |
| jtaylor | oh well trying showed yes | 21:44 |
| stgraber | infinity: right, multiarch ppc was my first suggestion when I heard of openbios, but indeed having to add the architecture and have users change the sources.list to support both archive and port, just for a single package seemed a bit more complex and resource hungry than it should be. bug 217427 would definitely be ideal to fix that and until then, some kind of cross/compile of binary copy from ppc to arch:all will have to do. | 21:53 |
| ubottu | bug 217427 in Launchpad itself "Please support arbitrary arch/buildd affinity for arch:all builds" [High,Triaged] https://launchpad.net/bugs/217427 | 21:53 |
| ScottK | Why not just make it arch: powerpc? | 21:57 |
| ogra_ | because you need to jump through hopps to install it on x86 | 21:58 |
| ogra_ | *hoops | 21:58 |
| stgraber | ScottK: it's the rare case where we want a powerpc binary to be shipped on x86 (bios for qemu system emulator). So if it was arch:powerpc, you'd need to enable powerpc multiarch on x86 to be able to get it | 21:59 |
| ScottK | Oh. Right. | 22:00 |
| slangasek | option #3 of course is to build a ppc cross-compiler just to build the bios on x86 :) | 22:05 |
| stgraber | slangasek: well, we appear to have gcc powerpc on x86 but I have no idea whether it's actually usable to build that bios. | 22:09 |
| slangasek | oh, do we? | 22:09 |
| infinity | We do. | 22:09 |
| slangasek | oh, then we could totally use that | 22:09 |
| slangasek | (if we want) | 22:09 |
| infinity | I've never looked at the openbios build. | 22:09 |
| infinity | If it's just GCC and no fanciness, it should cross trivially. | 22:09 |
| slangasek | it's not like it should need anything fancy, it's a bios | 22:09 |
| stgraber | so yeah, that was another suggestion I made during the session to try and use that cross compiler to build the openbios binary on x86 | 22:10 |
| infinity | stgraber: That may well be the least messy path for now, while I work on a proposal and implementation for 217427 (thanks for reminding me). | 22:10 |
| infinity | We really need a solid proposal for that for Debian anyway, or we can never, ever, ever have source-only uploads, and I'll be a sad Panda. | 22:10 |
| * stgraber tries a cross compile of openbios | 22:11 | |
| slangasek | stgraber: so I think I just had a really clever idea (upstart-devel); please poke holes in my theory :-) | 22:12 |
| infinity | stgraber: If it needs -m64, remember to install the multilib variant of the cross. | 22:12 |
| slangasek | seems to only use -m32 | 22:14 |
| stgraber | slangasek: interesting proposal. Obviously depends on all the jobs on your system being properly designed, but well, we already pretty much depend on that nowadays (you can basically hang everything by making a job "starting" and not returning) | 22:17 |
| stgraber | slangasek: hmm, libc6:powerpc doesn't appear to be installable through multiarch | 22:20 |
| slangasek | interesting | 22:20 |
| stgraber | libc6:powerpc : Depends: debconf:powerpc (>= 0.5) but it is not installable or | 22:20 |
| stgraber | debconf-2.0:powerpc | 22:20 |
| slangasek | stgraber: mm, debconf is Multi-Arch: foreign | 22:21 |
| slangasek | so something else is amiss there | 22:21 |
| infinity | Oh, bah. That's right, our cross-compilers can't be installed on buildds. | 22:21 |
| infinity | Cause they need the MA libc. | 22:21 |
| stgraber | infinity: they only do if you have any library dependency | 22:22 |
| ogra_ | rolliing buildds ! | 22:22 |
| infinity | stgraber: Eh? Doesn't the compiler itself have the dep? Oh, maybe it was just cross-build-essential that does. | 22:22 |
| stgraber | infinity: nope, I installed the compiler just fine without enabling powerpc multiarch | 22:22 |
| infinity | Okay, cool. It's just cross-build-essential. | 22:23 |
| stgraber | infinity: the problems started because of another build-dep of openbios-ppc | 22:23 |
| infinity | Which you don't need for this. | 22:23 |
| slangasek | what's the other build-dep? | 22:23 |
| slangasek | fcode-utils? | 22:23 |
| stgraber | yeah | 22:23 |
| infinity | Erm, but the other build-deps should be used natively, not cross. | 22:23 |
| slangasek | is that ppc-only? | 22:23 |
| stgraber | maybe it can just go foreign | 22:23 |
| stgraber | nope, I have it on x86 too | 22:23 |
| slangasek | yeah, 'utils' is usually a good sign that you want foreign | 22:23 |
| infinity | How is any of this about foreign or not? | 22:23 |
| infinity | This isn't a dpkg-cross build. | 22:24 |
| infinity | You're building *on* i386. | 22:24 |
| slangasek | rather, that you want the build arch version, which in this case doesn't require any foreign-ness | 22:24 |
| infinity | And build-depending on the cross-compiler explicitly. | 22:24 |
| infinity | If you're testing this as an sbuild/dpkg-cross cross-build, you're not testing a scenario that works on buildds anyway. | 22:25 |
| * infinity tries this locally. | 22:26 | |
| stgraber | infinity: hmm, indeed, let me do something closer to what we can do on a buildd :) | 22:26 |
| * infinity testbuilds. | 22:29 | |
| infinity | Oh, bah, these people use kernel scemantics for HOST. | 22:30 |
| * infinity inverts his patch. | 22:30 | |
| infinity | Or, no. It's just broken in general for cross, maybe. | 22:32 |
| infinity | There we go. | 22:35 |
| infinity | All fixed. | 22:35 |
| infinity | stgraber: I've got it building happily here. | 22:36 |
| stgraber | infinity: cool! | 22:36 |
| stgraber | hallyn: ^ I guess you can just crossbuild then :) | 22:37 |
| * infinity uploads. | 22:37 | |
| infinity | Or, I will once I diff with Debian and make sure the double-delta didn't make us wonkier than we should be. | 22:38 |
| slangasek | That was Easy™ | 22:38 |
| * micahg hands slangasek some staples... | 22:38 | |
| slangasek | :-) | 22:39 |
| === Ursinha-afk is now known as Ursinha | ||
| * infinity tests on i386 instead of amd64 to avoid embarrassment later. | 22:42 | |
| infinity | http://paste.ubuntu.com/5617896/ <-- Our tiny Debian delta to make this work. | 22:43 |
| infinity | Who knew that PPC cross compiler would be useful for anyone other than the kernel team? :P | 22:43 |
| stgraber | infinity: I suspect you want to change the Architecture field too | 22:44 |
| infinity | stgraber: I did. | 22:45 |
| infinity | stgraber: That's the diff from Debian, not from raring. | 22:45 |
| infinity | (And uploaded( | 22:46 |
| infinity | ) | 22:46 |
| stgraber | infinity: ah, I should have read the changelog, that'd have explained it ;) | 22:46 |
| ScottK | I knew that package sounded familiar for a reason. | 22:46 |
| infinity | ScottK: Heh. | 22:47 |
| infinity | ScottK: Congrats on losing TILM. | 22:47 |
| ScottK | \o/ | 22:47 |
| infinity | hallyn: openbios-ppc is arch:all again, feel free to depend on it all you want. | 22:47 |
| infinity | Now, this will have the entertaining side-effect of pulling the powerpc cross-compiler into main, unless we drop qemu-system-ppc to universe by twiddling a bunch of seeds and deps. | 22:51 |
| infinity | But we probably want to do that anyway, since stuff like nova-compute-kvm really wants to depend on qemu-system-x86, not qemu-system. | 22:52 |
| infinity | (Or maybe promoting cross-compilers that are built from the same sources as our supported toolchain really isn't a bit deal) | 22:53 |
| infinity | s/bit/big/ | 22:53 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha-afk is now known as Ursinha | ||
| === salem_ is now known as _salem | ||
| === Ursinha-afk is now known as Ursinha | ||
| hallyn | infinity: awesome, thanks! So, I should wait until qemu-system-ppc is demoted right? | 23:40 |
| === wedgwood is now known as wedgwood_away | ||
| === Ursinhal is now known as Ursinha | ||
| infinity | hallyn: We should probably sort out a plan to demote all the qemu-system-* bits we don't want in main, yeah. | 23:43 |
| hallyn | infinity: drat, i see qemu-system-ppc explicitly added to the server seed, so maybe that's not acceptable. Daviey ? | 23:47 |
| === Ursinha-afk is now known as Ursinha | ||
| infinity | hallyn: You're the one who added it. ;) | 23:51 |
| infinity | hallyn: Anyhow, there's more to fix than just seeds, since things in main depend on qemu-system. | 23:52 |
| infinity | hallyn: But maybe we shouldn't fuss over it, and just do an MIR for openbios-ppc. | 23:52 |
| infinity | hallyn: *shrugs* | 23:52 |
| hallyn | infinity: meanwhile just making it Suggest should be fine right? | 23:55 |
| infinity | hallyn: Yeahp, suggests can cross components. | 23:56 |
| hallyn | just the mere fact that ppl can install it will be novel :) thx again | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!