| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| infinity | Bah, why does linux-ac100-tools-3.1.10-6 have some bizarre binutils dep? | 00:22 |
|---|---|---|
| xnox | as soon as pykde4 builds and transitions, python3.2 pyside shiboken can be removed from the archive \0/ | 00:26 |
| === Ursinha is now known as Ursinha-afk | ||
| * xnox based on speculation that my other 5 uploads will be done and dusted before pykde4 | 00:26 | |
| doko | xnox, which pykde4 upload? | 00:30 |
| === Ursinha-afk is now known as Ursinha | ||
| === jdstrand_ is now known as jdstrand | ||
| === LordOfTime is now known as TheLordOfTime | ||
| === mmrazik is now known as mmrazik|afk | ||
| === doko_ is now known as doko | ||
| xnox | doko: well the one that is part of kde stack / and also in part, no-change rebuild to drop python3.2 (accidental timing coincidence) | 09:24 |
| === henrix_ is now known as henrix | ||
| ogra_ | Unpacking upower (from .../upower_0.9.17-1build1_armhf.deb) ... | 09:49 |
| ogra_ | dpkg-deb (subprocess): decompressing archive member: internal gzip read error: '<fd:4>: incorrect data check' | 09:49 |
| ogra_ | dpkg-deb: error: subprocess <decompress> returned error exit status 2 | 09:49 |
| ogra_ | hmpf | 09:49 |
| ogra_ | i wonder if we have a bad panda in our stack | 09:50 |
| ogra_ | (thats from the latest omap4 desktop build) | 09:50 |
| cjwatson | yay, giant stack of haskell packages migrated; that'll make the output easier to read | 10:08 |
| Laney | nice | 10:10 |
| Laney | without intervention? | 10:10 |
| xnox | Laney: "Trying easy from autohinter" SUCCESS (57/0) | 10:10 |
| Laney | I don't understand the subsequent hints | 10:17 |
| Laney | AFAICS they are all for a subset of packages it already decided it could migrate | 10:17 |
| xnox | Laney: no, it didn't. | 10:19 |
| xnox | Laney: first it did the rounds across packages and for each one of them decided that it can't do it "trying: haskell-unordered-containers\n skipped: haskell-unordered-containers" | 10:20 |
| Laney | I'm talking about the autohinter. | 10:20 |
| xnox | Laney: after doing all the rounds the autohinter suggested to try all skipped haskell-* packages that got skipped because of each other, to attempt migrating together. | 10:21 |
| Laney | look at the line immediately following the SUCCESS for example | 10:21 |
| xnox | "Trying each from autohinter", that got the uninstallable count to stay the same. | 10:21 |
| xnox | "start: orig: easy:" | 10:21 |
| xnox | hence it considered that result final. | 10:21 |
| xnox | and reported SUCCESS. | 10:22 |
| Laney | is this thing on? | 10:22 |
| xnox | Laney: that second one failed. | 10:22 |
| Laney | perhaps it is trying to find smaller hints | 10:23 |
| xnox | Laney: hmm.. autohinter is silly I guess and offered two ways to migrate, but only one of them worked =) | 10:23 |
| xnox | yeah. | 10:23 |
| cjwatson | Laney: yes, without intervention. I believe that the autohinter sometimes tries smaller sets if the first one fails, just in case the failure is due to some excess packages. It doesn't really matter since it tries the largest first. | 10:35 |
| cjwatson | (or else the bit that's supposed to avoid subsets is broken, but like I say it doesn't matter in practice, so ...) | 10:37 |
| cjwatson | (Also, it'll probably end up doing the same thing again to no effect since proposed-migration often doesn't quite run in time for the next publisher run) | 10:38 |
| Laney | sure, I get that it doesn't hurt. I was just wondering what it was trying to achieve. | 10:40 |
| cjwatson | It's probably a mistake | 10:41 |
| === mmrazik is now known as mmrazik|lunch | ||
| psivaa | Not sure if it's too early to test on raring (desktop) images but we see bug 1075631 on i386 where the installation seems to hang on user setup step | 11:56 |
| ubot2 | Launchpad bug 1075631 in ubiquity (Ubuntu) "Ubiquity hangs on Raring i386 desktop installation at Step_before = stepLanguage' for vm and at Step_before = stepWebcam for hw" [Undecided,Confirmed] https://launchpad.net/bugs/1075631 | 11:56 |
| cjwatson | It shouldn't be in theory, but you're probably the first ... | 11:57 |
| psivaa | cjwatson: right, we see that when trying to set up automatic test jobs for raring and since amd64 is not yet available we are kind of stuck | 12:00 |
| xnox | psivaa: plars was mentioning something about cd failing yesterday. Yeah very early indeed. | 12:00 |
| xnox | psivaa: hmm =( that's not nice. | 12:00 |
| cjwatson | Can't see why that'd be arch-specific off the top of my head anyway | 12:00 |
| xnox | hmm... amd64+mac images are built, but amd64 are not. | 12:00 |
| cjwatson | That's basically artificial weirdness | 12:01 |
| cjwatson | I wouldn't put too much thought into that :) | 12:01 |
| xnox | infinity: can we have amd64 desktop dailies or they are known to be broken? | 12:01 |
| === mmrazik|lunch is now known as mmrazik | ||
| cjwatson | If they were working they'd have been auto-built this morning. | 12:01 |
| cjwatson | So no point just asking for us to build them. | 12:03 |
| cjwatson | But I see the problem and I'll fix it now. | 12:04 |
| cjwatson | (Also why ask the cdimage guy who's asleep rather than the one who's talking? :-) ) | 12:05 |
| cjwatson | Also something odd with livefs builds; we only have logs from i386 this morning. That's independent of why we have amd64+mac but not amd64 though. | 12:06 |
| xnox | cjwatson: I'm reading the logs and they are interesting. | 12:07 |
| xnox | http://people.canonical.com/~evand/wubi/raring/stable: | 12:07 |
| xnox | 2012-11-07 08:21:33 ERROR 404: Not Found. | 12:07 |
| xnox | http://people.canonical.com/~evand/usb-creator/raring/stable: | 12:07 |
| xnox | 2012-11-07 08:21:33 ERROR 404: Not Found. | 12:07 |
| xnox | http://kapok.buildd/~buildd/LiveCD/raring/ubuntu/current/livecd.ubuntu.cloop: | 12:07 |
| xnox | 2012-11-07 08:21:33 ERROR 404: Not Found. | 12:07 |
| cjwatson | that's not interesting in the slightest :) | 12:07 |
| cjwatson | not worth lots of investigation anyway; respinning now. | 12:08 |
| xnox | hmm.... | 12:08 |
| xnox | you know better =) | 12:08 |
| cjwatson | we don't put wubi or usb-creator on the images any more, and cloop is long-obsolete. those are basically fallback paths of one kind or another that aren't worth cleaning up. | 12:09 |
| psivaa | cjwatson: xnox: thanks for looking into them | 12:10 |
| cjwatson | at any rate since that comes strictly after building the live filesystems it offers no insight into why this morning's Ubuntu desktop cron job only built an i386 livefs and did not even leave logs for an amd64 (or other architectures) build. | 12:10 |
| cjwatson | Oh, here, it actually did, this is just a log mirroring thing | 12:11 |
| cjwatson | So not desperately relevant | 12:11 |
| cjwatson | OK, so you should get amd64 images in a bit | 12:11 |
| psivaa | cjwatson: thanks and any estimate for the fixing of the bug above? :) | 12:12 |
| cjwatson | I was kind of hoping one of my esteemed colleagues on the installer team might have a look ;-) | 12:13 |
| xnox | cjwatson: can we drop ndisgtk from the desktop images pool ? | 12:13 |
| xnox | lol | 12:13 |
| cjwatson | xnox: I have no particular opinion on that; look through seed bzr history for the background and ask ubuntu-devel | 12:13 |
| cjwatson | xnox: the history indicates that ogra_ added it | 12:13 |
| ogra_ | heh | 12:14 |
| ogra_ | that was in like breezy or so | 12:14 |
| cjwatson | I'm syncing raring-desktop-i386.iso here, but no promises | 12:14 |
| cjwatson | ogra_: hardy | 12:14 |
| ogra_ | when we still had a policy to get the GSoC projects into main | 12:14 |
| ogra_ | that was the result of one | 12:15 |
| ogra_ | xnox, no idea if its still used or helpful, feel free to do a survey and remove :) | 12:16 |
| xnox | ogra_: well it's python2 & pygtk. And we kind of want to get rid of those on the CD. These days we have ubuntu-drivers-common and I don't know if ndiswrapper is used or not. | 12:16 |
| ogra_ | well, probably still for the cards that dont have linux drivers, but i bet they get rarer and rarer | 12:17 |
| ogra_ | point is that you want it on the CD since you cant download it without any network | 12:17 |
| xnox | ogra_: yeap I understand. That's for ndiswrapper-utils, not sure about ndisgtk though. | 12:19 |
| ogra_ | i'm not sure if ubuntu-drivers-common covers any ndiswrapper | 12:19 |
| ogra_ | to give the usert a non cmdline way to add his driver bits | 12:20 |
| ogra_ | i doubt it does though | 12:20 |
| xnox | ogra_: well ndisgtk depends on python-glade2, which is no longer on the cd... so I am failing to see how people use that =) | 12:23 |
| cjwatson | err, impossible | 12:23 |
| ogra_ | heh, ok | 12:23 |
| xnox | (the gui front-end) | 12:23 |
| cjwatson | the CD building process follows dependencies | 12:23 |
| xnox | cjwatson: true. python-glade2 is shipped in the pool. I was checking the squashfs manifest. | 12:23 |
| cjwatson | python-glade2 isn't in the squashfs, but it's shipped as a .deb to go with ndisgtk | 12:23 |
| ogra_ | as ndisgtk itself | 12:24 |
| ogra_ | its also only in ship or ship-live | 12:24 |
| ogra_ | (not sure which) | 12:24 |
| cjwatson | both | 12:24 |
| ogra_ | k | 12:24 |
| cjwatson | ship-live is the one that matters nowadays | 12:24 |
| xnox | right emailing ubuntu-devel. | 12:24 |
| ogra_ | i suspect there might be some howto pages on the wiki making use of it | 12:25 |
| ogra_ | https://help.ubuntu.com/community/WifiDocs/Driver/Ndiswrapper makes some use of it | 12:26 |
| cjwatson | um, so, the most obvious question that comes to mind upon looking at psivaa's bug above is "where did the partitioner go?" | 12:45 |
| * cjwatson copies ubiquity from quantal-updates to raring-proposed in the hope that that will help | 12:50 | |
| cjwatson | actually I suspect it just needs me to finish the NewReleaseCycleProcess bits for the installer | 12:51 |
| cjwatson | since it'll probably be failing to detect the image | 12:51 |
| * cjwatson goes to do that | 12:51 | |
| jdstrand | hey, so chrisccoulson uploaded a package to -partner for quantal | 13:04 |
| jdstrand | https://launchpad.net/ubuntu/+source/adobe-flashplugin | 13:04 |
| jdstrand | LP is now saying that it is in 'proposed (partner)' | 13:04 |
| cjwatson | haha, that's an amusing side-effect | 13:04 |
| cjwatson | you should probably file an LP bug about that | 13:04 |
| jdstrand | ok | 13:05 |
| cjwatson | it shouldn't be doing that for partner | 13:05 |
| cjwatson | well, arguably | 13:05 |
| cjwatson | there's the nice side-effect that this makes sure it's fully built before we give it to users | 13:05 |
| jdstrand | I should be able to just copy normally though, correct? | 13:05 |
| cjwatson | but we have no tracking for it | 13:05 |
| cjwatson | copy from proposed to release and delete from proposed, yes | 13:05 |
| jdstrand | right. ok, thanks | 13:05 |
| cjwatson | rather than changing LP, we could just add these to pending-sru, only without the aging period thing | 13:06 |
| cjwatson | jdstrand: you can probably use sru-release -r, in fact | 13:06 |
| jdstrand | I'll give it a shot. honestly, in thinking about it, seems allowing it to build is not such a bad thing | 13:07 |
| cjwatson | yeah, it's given directly to users after all | 13:07 |
| jdstrand | seems sru-release needs to learn about -partner: ERROR: No such package in -proposed, aborting | 13:08 |
| cjwatson | Ah, yeah, maybe not the right tool | 13:10 |
| cjwatson | Use copy-package with --partner then | 13:10 |
| === yofel_ is now known as yofel | ||
| jdstrand | ok, this looks like it will do it: ./copy-package -n -b --partner -s quantal-proposed --to-partner --to-suite quantal adobe-flashplugin | 13:13 |
| jdstrand | (minus the -n of course) | 13:14 |
| cjwatson | Yes, though you can drop --to-partner as that's the default | 13:14 |
| jdstrand | actually, I couldn't-- I got 'copy-package: error: cross-partner copies are not allowed' | 13:14 |
| cjwatson | (I mean, default is for destination to equal source unless otherwise specified) | 13:14 |
| cjwatson | Ah, that's a bug, let me fix that | 13:14 |
| jdstrand | cjwatson: shall I push now or do you need it for your fix? | 13:15 |
| cjwatson | jdstrand: update your u-a-t checkout and you shouldn't need --to-partner any more | 13:16 |
| jdstrand | that was fast | 13:16 |
| jdstrand | :) | 13:16 |
| jdstrand | well, no, didn't work | 13:17 |
| jdstrand | (same error) | 13:17 |
| jdstrand | 'options.destination.partner is None' is not right-- it defaults to False if I am reading this right | 13:20 |
| cjwatson | jdstrand: try now | 13:21 |
| cjwatson | (actually test-run this ime) | 13:21 |
| cjwatson | *time | 13:22 |
| jdstrand | yes, that works. thanks :) | 13:22 |
| cjwatson | Oh, you could have used --auto-approve to avoid that | 13:24 |
| cjwatson | Oh well | 13:24 |
| jdstrand | yeah, just realized that | 13:25 |
| jdstrand | I'll document this in ArchiveAdministration | 13:25 |
| mvo | could someone please review the upload of app-install-data-partner? its fixes a rather annoying bug for people who tried to install skype and end up with a invalid sources.list snippet | 14:58 |
| mvo | (the upload is in quantal-proposed) | 14:58 |
| === henrix_ is now known as henrix | ||
| cjwatson | hmm, britney is crashing again | 15:47 |
| * cjwatson will look into that modulo team meetings | 15:47 | |
| infinity | mvo: That upload removed two desktop files... | 15:50 |
| infinity | mvo: (Though, the debian/install change clearly shows they weren't being used before, at least vmware-view-client exists in Q...) | 15:51 |
| mvo | infinity: yeah,they where not used, just kept for reference | 16:02 |
| cjwatson | The shim sync is from quantal for bug 1075181; the reason this is a rather irregular with-binaries sync is that rebuilding shim would imply needing to resubmit the object to Microsoft for signing, which I'd prefer to avoid | 16:03 |
| ubot2 | Launchpad bug 1075181 in linux-signed (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,In progress] https://launchpad.net/bugs/1075181 | 16:03 |
| cjwatson | It has no dependencies, and it isn't used directly - I'd just like to have it there so that people aren't confused about where the source is when we upload (or copy?) shim-signed | 16:04 |
| slangasek | cjwatson: we might want to also check that the package builds with the gnu-efi in precise, else backport that too | 16:05 |
| cjwatson | I can do a quick test-build | 16:06 |
| cjwatson | Not sure I can tell whether it will produce identical results | 16:06 |
| cjwatson | slangasek: builds cleanly | 16:09 |
| cjwatson | well, "cleanly" - quite a few warnings due to EFI type insanity | 16:10 |
| cjwatson | successfully anyway | 16:10 |
| ogra_ | infinity, btw, there was a weird looking gzip error on todays omap4 desktop build | 16:26 |
| ogra_ | (not sure you saw it in the backlog) | 16:27 |
| infinity | ogra_: Nope, still waking up here. | 16:28 |
| ogra_ | Unpacking upower (from .../upower_0.9.17-1build1_armhf.deb) ... | 16:30 |
| ogra_ | dpkg-deb (subprocess): decompressing archive member: internal gzip read error: '<fd:4>: incorrect data check' | 16:30 |
| ogra_ | dpkg-deb: error: subprocess <decompress> returned error exit status 2 | 16:30 |
| ogra_ | dpkg: error processing /var/cache/apt/archives/upower_0.9.17-1build1_armhf.deb (--unpack): | 16:30 |
| ogra_ | infinity, ^^^ | 16:30 |
| ogra_ | that smells a bit like bad HW | 16:30 |
| infinity | ogra_: Fun. Pandas are, by definition, bad hardware. | 16:30 |
| ogra_ | lol | 16:30 |
| balloons | If I can briefly sidetrack everyone for a moment -- did we chat at all about what isos we want to target for 13.04? I would like to see amd64+mac go away for instance ;-) | 16:34 |
| cjwatson | We'd love to see amd64+mac go away but it's entirely dependent on figuring out how to supplant it in the amd64 image | 16:34 |
| cjwatson | slangasek said he was going to have a go | 16:34 |
| infinity | Here's hoping. | 16:34 |
| cjwatson | I tried last cycle and failed | 16:35 |
| slangasek | right, I guess I should follow up on getting the hardware then | 16:35 |
| infinity | balloons: I suspect, other than that one (possibly) going away, the list won't look much different from 12.10 | 16:35 |
| infinity | slangasek: Going to steal something from the kernel team? | 16:35 |
| slangasek | so I'm told | 16:35 |
| xnox | well there will be a whole bunch of nexus images added | 16:36 |
| balloons | yes, but we won't be releasing nexus 7 images right? | 16:36 |
| xnox | balloons: sure we will. | 16:36 |
| xnox | balloons: and flavours. | 16:37 |
| balloons | xnox, I've heard both ways on it | 16:37 |
| xnox | balloons: interesting. | 16:37 |
| balloons | I mean, sure we'll have to have images.. but are we going to go through the release process on it? | 16:37 |
| ogra_ | balloons, yes | 16:37 |
| ogra_ | as any other community image | 16:37 |
| infinity | We won't be supporting the Nexus7 kernel, so supporting "images" could be tough. :P | 16:37 |
| slangasek | "and flavours"? | 16:37 |
| ogra_ | slangasek, kubuntu and lubuntu asked | 16:38 |
| slangasek | ok | 16:38 |
| xnox | ogra_: slangasek: and edubuntu. | 16:38 |
| ogra_ | its only a change in /etc/default-arches | 16:38 |
| ogra_ | oh, indeed | 16:38 |
| ogra_ | QA and stuff have to be done by the teams as usual | 16:38 |
| infinity | ogra_: It's also a commitment of resources, so please do talk to me if suddenly the world desires a ton of nexus images. | 16:39 |
| ogra_ | infinity, well, the above is my list atm | 16:39 |
| infinity | (I'll probably have to dig up a second Panda for ARM images in the next week or two, at least) | 16:39 |
| ogra_ | ++ | 16:39 |
| ogra_ | we should have that anyway | 16:39 |
| xnox | infinity: 12 = 4 flavours x 3 nexus sizes =) | 16:39 |
| balloons | yikes | 16:39 |
| infinity | Well, I should finish livefs-in-soyuz, but I don't want to hold up the world on that either. :P | 16:40 |
| balloons | better get cross-compiling going ;0)( | 16:40 |
| infinity | It's a pretty high priority for me this cycle, though. | 16:40 |
| ogra_ | balloons, how would cross compile help with image builds ? | 16:40 |
| infinity | Well, cross-installing. But, uhm. No. | 16:40 |
| ogra_ | infinity, i dont thing we need to start with flavours immediately | 16:40 |
| ogra_ | *think | 16:40 |
| infinity | Not while I still have qemu segfaulting randomly on postinsts. | 16:40 |
| infinity | ogra_: No, we certainly don't. But I'd like capacity there before we do, so thanks for the heads-up. :P | 16:41 |
| balloons | True.. I was thinking some of the flavor packages wouldn't be built | 16:41 |
| * xnox ponders if kubuntu want normal kubuntu & kubuntu active images.... | 16:41 | |
| infinity | xnox: They'd almost certainly be after just active, but we'll wait for people to make the requests. | 16:42 |
| cjwatson | In general (a) we build packages for all architectures (b) packages usually aren't kernel-flavour-specific, so they're probably generally already built | 16:42 |
| infinity | xnox: Cause asking "do you want these new images" will always default to "heck yes". | 16:42 |
| xnox | infinity: to be honest none of their images fit the bill currently as they need to be ~700MB to be flashable. | 16:43 |
| xnox | so much for "unlimitted iso size" | 16:43 |
| infinity | Heh. | 16:43 |
| infinity | Easy come, easy go. | 16:43 |
| cjwatson | That's tremendously entertaining just after world+dog ganged up to get us away from 700MB | 16:43 |
| infinity | We could always go on a diet again. ;) | 16:43 |
| balloons | I can see the headlines now :-) | 16:43 |
| xnox | cjwatson: indeed. Kubuntu folks had a major disappointment as I think they wanted the full KDE SC on it.... | 16:44 |
| infinity | I say we remove English from the default images. | 16:44 |
| xnox | edubuntu says remove ed | 16:44 |
| infinity | If C was good enough for your parents, it's good enough for you. | 16:44 |
| * infinity goes to kickstart his brain with peanut butter. | 16:45 | |
| xnox | infinity: doesn't like dpkg or perl vomit on stderr with C locale?! =) | 16:45 |
| infinity | xnox: No. | 16:45 |
| infinity | xnox: Perl gets upset if you set your locale to something you don't have generated. | 16:45 |
| balloons | perl used to let you know about it | 16:45 |
| cjwatson | balloons: No, that was for non-existent locales | 16:45 |
| infinity | xnox: Which wouldn't be the case if you set it to C. | 16:45 |
| cjwatson | Still is, for that matter | 16:45 |
| cjwatson | The C locale exists by definition | 16:46 |
| micahg | xubuntu is still 700MB sized :) | 16:46 |
| infinity | And C.UTF8 too, in our fancy new world order. | 16:46 |
| ogra_ | xnox, they said active | 16:46 |
| cjwatson | Right, that's a slightly broader definition | 16:46 |
| cjwatson | (i.e. done in packaging, rather than hardcoded in the library) | 16:46 |
| * infinity nods. | 16:46 | |
| infinity | Hrm, front page of cnn.com: "Unity and job creation lead 'to do' list". Even Obama's concerned about improving our desktop environment. | 16:47 |
| cjwatson | infinity: also our init daemon, apparently | 16:48 |
| === barry` is now known as barry_ | ||
| === barry_ is now known as barry | ||
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik|otp | ||
| === mmrazik|otp is now known as mmrazik | ||
| SpamapS | I see a fully verified Unity SRU that has baked 7 days in quantal-proposed. Any reason to hold it back? | 18:08 |
| slangasek | should be good | 18:11 |
| SpamapS | slangasek: ty | 18:14 |
| === Ursinha-afk is now known as Ursinha | ||
| stgraber | cjwatson, infinity: Can you remember whether we actually need the API for the manifest feature on the tracker? I'm trying to find a use case for it and can't quite find one at the moment... | 18:44 |
| stgraber | cjwatson, infinity: as in, do we actually need to retrieve the manifest from nusakan? | 18:44 |
| stgraber | with the new code, sending all the builds to the Daily milestone will always do the right thing as the tracker will automatically copy a build to a "real" milestone based on the products listed on the manifest if any such milestone can be found in the "testing" state | 18:45 |
| cjwatson | I thought the use case was that the rewritten publish-image-set should get hold of the list of things to release from the tracker | 18:51 |
| * cjwatson fixes the proposed migrator | 18:52 | |
| cjwatson | (I'd not been handling binary-only migrations quite as well as I thought I was) | 18:53 |
| === Ursinha-afk is now known as Ursinha | ||
| === henrix is now known as henrix_ | ||
| === Ursinha_ is now known as Ursinha-afk | ||
| stgraber | cjwatson: yeah, that kinda rings a bell. Not sure we actually need to get the manifest to make publish-image-set work but I guess we may want to use the manifest to grab the list of to-publish but not yet ready builds | 19:26 |
| bdmurray | I just verified bug 1067993 and it has aged properly | 19:28 |
| ubot2 | Launchpad bug 1067993 in vim (Ubuntu Quantal) "Add 'raring' to the list of recognized Ubuntu release names" [Low,Fix committed] https://launchpad.net/bugs/1067993 | 19:28 |
| === Ursinha_ is now known as Ursinha-afk | ||
| infinity | SpamapS: Hrm, how did you do that ulogd sync? | 20:17 |
| infinity | ScottK: Same question for you on sip4? | 20:17 |
| === Ursinha_ is now known as Ursinha-afk | ||
| infinity | cjwatson: ^-- Both those syncs went straight to the release pocket. I'd like to think SpamapS and ScottK aren't intentionally abusing any power, so I can only assume (until told otherwise) that they've accidentally done so... | 20:19 |
| infinity | cjwatson / stgraber: Lists issues finally sorted, BTW, should stop getting mod nags. | 20:37 |
| xnox | filed bug 1076131 | 20:54 |
| ubot2 | Launchpad bug 1076131 in python3.2 (Ubuntu Raring) "Please remove python3.2 source+binaries on all arches from raring" [Medium,Confirmed] https://launchpad.net/bugs/1076131 | 20:54 |
| stgraber | infinity: yay! thanks | 21:00 |
| stgraber | infinity: I believe the old syncpackage targets the release pocket, so my guess would be some interaction of that and being queue admin that lets you bypass the automatic reject | 21:02 |
| stgraber | so in their case, if they're still on quantal, a simple syncpackage call might be causing the sync to directly land in the release pocket | 21:03 |
| stgraber | (that's just vague assumptions based on what I read of the -proposed implementation here) | 21:03 |
| tumbleweed | if an sru-team someone could promote the ubuntu-dev-tools in quantal-proposed, that'd certainly help | 21:06 |
| tumbleweed | (and then I can upload some bug fixes for it :P ) | 21:06 |
| SpamapS | infinity: syncpackage ulogd --force ... no bueno? | 21:07 |
| stgraber | SpamapS: on quantal I assume? | 21:07 |
| SpamapS | no, raring | 21:08 |
| tumbleweed | SpamapS: depends on the version of syncpackage you have... | 21:08 |
| stgraber | ah, that's odd, raring should always target -proposed... | 21:08 |
| SpamapS | 0.143 | 21:09 |
| tumbleweed | that's quantal | 21:10 |
| SpamapS | tumbleweed: right I thought you meant "syncing to quantal" | 21:14 |
| SpamapS | so, should I not be using syncpackage? | 21:15 |
| stgraber | nope, using syncpackage is fine, just use a newer version :) | 21:15 |
| micahg | or remember to do syncpackage -r raring-proposed | 21:16 |
| tumbleweed | updating isn't that hard | 21:16 |
| infinity | tumbleweed: Promoting. | 21:17 |
| SpamapS | Perhaps this is the release where I'll update at alpha1 | 21:18 |
| tumbleweed | infinity: ta, uploading another one :) | 21:18 |
| infinity | SpamapS: I updated at opening, that's how confident I am. :P | 21:20 |
| infinity | tumbleweed: Perhaps the default-to-proposed syncy bits might want to wander back to precise as well. | 21:21 |
| tumbleweed | the early days are fairly safe. it's when all the crazy stuff starts landing at FF that devel releases get dangerous | 21:21 |
| infinity | tumbleweed: I suspect lots of people (*shifty look*) run LTS systems and occasionally call devel tooly things from there. | 21:21 |
| === Ursinha_ is now known as Ursinha-afk | ||
| tumbleweed | infinity: yeah, I intend to do that | 21:21 |
| infinity | tumbleweed: Granted, it's not a big issue for people who aren't archive admins. But it looks like it's bitten slangasek, cjwatson, SpamapS, and ScottK so far. :P | 21:22 |
| infinity | (The second in that list being a bit of irony) | 21:22 |
| xnox | =) | 21:23 |
| SpamapS | once bitten, twice shy | 21:23 |
| cjwatson | syncpackage doesn't use auto-approve, so it should hit the unapproved queue even if you're an AA | 21:31 |
| cjwatson | Or maybe not, thinking about it ... | 21:32 |
| infinity | cjwatson: Which means the syncs this week that went straight to raring probably also had someone manually accept them afterward? :P | 21:32 |
| infinity | Seems unlikely. | 21:32 |
| cjwatson | No, I think I'm getting confused by us starting out frozen | 21:32 |
| * infinity nods. | 21:32 | |
| cjwatson | Which one did I get wrong? | 21:32 |
| infinity | cjwatson: Oh, you didn't. I used you name in vain. | 21:34 |
| infinity | s/you name/your name/ | 21:34 |
| infinity | The other three I mentioned all did direct syncs, though. | 21:34 |
| cjwatson | \o/ | 21:35 |
| tumbleweed | infinity: ^ there | 21:46 |
| infinity | tumbleweed: Impressive that it dragged along PHP and GCrypt at the same time. | 21:47 |
| infinity | SRU static cling? | 21:47 |
| tumbleweed | :) | 21:48 |
| infinity | Huh, look at that, my sketchy t38modem upload built everywhere. | 21:49 |
| infinity | I mean, uhm. Of course it did. | 21:49 |
| xnox | hmm... why/how did python3.2 get back into kubuntu?! | 22:10 |
| doko | xnox, there are still a lot of packages with Provides: python3.2-* | 22:11 |
| xnox | doko: *sigh* why?! provides should not be used in python3.... | 22:13 |
| doko | xnox, just re-upload for not building with 3.2 | 22:13 |
| xnox | doko: and there are no rdeps on binary packages built from python3.2 source package (apart from pyside) | 22:13 |
| * xnox filed removal request... | 22:13 | |
| xnox | along with shiboken & pyside. | 22:18 |
| xnox | doko: so all python3.2-* provides need to be dropped as well as any *.cpython-32mu.so | 22:59 |
| xnox | ? | 22:59 |
| doko | xnox, yes, just did upload the ones with the Provides | 23:04 |
| xnox | doko: thanks. that should solve a good bunch of *.cpython-32mu.so as well. | 23:12 |
| xnox | if not all. | 23:12 |
| cjwatson | xnox: back into kubuntu> that's a demotion from core to kubuntu, basically - "back into kubuntu" is a misreading of those changes | 23:17 |
| xnox | cjwatson: ah, I see. | 23:18 |
| xnox | cjwatson: but nothing in the archive depends on python3.2. I was expecting it to drop from all seeds and end-up in component missmatch... | 23:19 |
| xnox | oh wait. pyside. | 23:19 |
| xnox | nevermind =) | 23:19 |
| cjwatson | indeed. | 23:19 |
| xnox | and package-sets != seeds =) | 23:19 |
| xnox | thanks =) | 23:20 |
| doko | cjwatson, can I have a permanent overwrite for gcc-snapshot to migrate to -release, if at least one arch build succeeds? | 23:28 |
| cjwatson | Why? Surely anything that cares is using -proposed anyway. | 23:29 |
| doko | because I'd like to have people the latest build available. porter boxes don't use -proposed, and I don't like telling people enabling -proposed for that | 23:31 |
| cjwatson | Well, I'm not at all convinced that the promotion code will actually handle that | 23:31 |
| cjwatson | So no, not right now ... | 23:31 |
| cjwatson | It's probably possible but needs more thought than just whacking in a hint | 23:32 |
| doko | ok | 23:32 |
| cjwatson | Plus I haven't actually hooked up hints properly yet | 23:32 |
| doko | btw, should the porter boxes use -proposed, or not? | 23:32 |
| cjwatson | I'm not sure. I'd lean towards yes, I think | 23:33 |
| infinity | Probably. | 23:33 |
| cjwatson | Since we mostly want them to approximate build environments | 23:33 |
| doko | sounds fine. I'll add this to my recent ticket | 23:33 |
| * infinity tries to figure out why some compilers have spontaenously started producing what look like armel binaries on armhf. | 23:33 | |
| infinity | This is a bit disconcerting. | 23:34 |
| doko | ? | 23:34 |
| doko | it's called multilib | 23:34 |
| infinity | https://launchpadlibrarian.net/121716426/buildlog_ubuntu-raring-armhf.dozzaqueux_3.21-6_FAILEDTOBUILD.txt.gz <-- fpc producing armel binaries | 23:34 |
| infinity | https://launchpadlibrarian.net/122255799/buildlog_ubuntu-raring-armhf.cbmc_4.2-6ubuntu1_FAILEDTOBUILD.txt.gz <-- cbmc calling something in a way that doesn't define __ARM_PCS_VFP | 23:35 |
| infinity | I suspect both are related. | 23:35 |
| infinity | fpc hasn't changed at all since quantal, so it's obviously something else that broke. | 23:36 |
| doko | hmm, gcc-4.7 didn't change that much | 23:36 |
| infinity | Yeah, eglibc certainly did, mind you, but I'm unsure if I get to blame it yet. | 23:37 |
| infinity | Well, it wouldn't be GCC at all. | 23:38 |
| infinity | fpc doesn't call gcc. | 23:38 |
| * infinity does a local build to see what these binaries actually are... | 23:38 | |
| infinity | Actually, hrm. "not calling gcc" might be the hint I need here. | 23:39 |
| infinity | Since I bet it's gcc that sets __ARM_PCS_VFP ... | 23:40 |
| infinity | And eglibc seems to care more now than it used to about that being set. | 23:40 |
| doko | xnox, python3.2 removed and blacklisted | 23:50 |
| doko | infinity, please could you re-creating the raring buildd tarballs so that python3.2 isn't included? | 23:51 |
| doko | s/ing/e/ | 23:51 |
| infinity | doko: Done yesterday. | 23:51 |
| doko | cute | 23:51 |
| infinity | (Done one better, no python in the tarballs at all) | 23:51 |
| infinity | http://paste.ubuntu.com/1341320/ <-- Definitely something gone horribly wrong... | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!