| scientes | libreoffice is a beast | 00:10 |
|---|---|---|
| scientes | why is libreoffice in universe in quantal? | 00:11 |
| infinity | BenC: I might fix it later. | 00:12 |
| stgraber | scientes: the libreoffice meta package seems to be in universe, the actual components (libreoffice-core, libreoffice-writer, ...) are in main | 00:14 |
| phillw | BenC ping | 00:48 |
| BenC | phillw: pong | 00:48 |
| BenC | phillw: I think you're confused…supporting old Mac hardware is not a destiny that will lead to powerpc being around very long | 00:49 |
| phillw | Hi BenC we have a rather stubborn bug, and ubuntu-release have suggested that you may be better placed to look at it? | 00:50 |
| BenC | phillw: I'm trying to get kernel support for newer ppc32 architectures like e500mc | 00:50 |
| BenC | phillw: I assume that was your comment on my blog post... | 00:50 |
| BenC | phillw: Sure, what's up? | 00:50 |
| phillw | nope, it was there to support the work that is done to continue supporting older kit, but that's a different matter | 00:51 |
| phillw | bug 1007394 | 00:51 |
| ubottu | Launchpad bug 1007394 in mdadm (Ubuntu) "Quantal daily fails to complete installation" [High,Confirmed] https://launchpad.net/bugs/1007394 | 00:51 |
| BenC | phillw: I don't want to support older hardware…I want to support newer hardware :) | 00:51 |
| BenC | phillw: Checking the bug (cooking dinner, so might be slow) | 00:52 |
| phillw | thanks, it's a killer bug for alternate release. | 00:52 |
| BenC | phillw: Does this happen on differing ppc platforms, or one specific machine? | 00:54 |
| phillw | both of the ppc testers that lubuntu have have experienced it | 00:55 |
| BenC | phillw: what is their hardware? | 01:06 |
| BenC | G3, G4, ?? | 01:08 |
| phillw | I'm not 100% sure. apport didn't pull the information in. | 01:09 |
| phillw | As they get desktop up okay, it shouldn't be too hard for them to provide the system data from their Macs onto that bug if it will help. | 01:11 |
| phillw | it's only alternate that fails. | 01:11 |
| BenC | Ok | 01:12 |
| BenC | phillw: That's an odd bug…mdadm doesn't hang on my quantal system... | 01:49 |
| BenC | I'm not running the standard kernel though | 01:49 |
| phillw | BenC it sure is, even more weird as one of the testers got the alternate install to install when selecting encryption! | 01:50 |
| phillw | BenC, it is 3 am here & I've been up since 6 am. If there is anything more you want in terms of information, please do feel free to update the bug report :) | 02:01 |
| BenC | phillw: ok | 02:02 |
| === Pendulum_ is now known as Pendulum | ||
| === cpg is now known as cpg|away | ||
| pitti | Good morning | 03:46 |
| NCommander | Ping, any archive admins around? I need a patch pushed from out of the proposed unaccepted queue | 03:46 |
| * NCommander tackles pitti | 03:46 | |
| pitti | rbasak: FWIW, I don't have a strong opinion whether add-apt-repository should be on the server images; so far it has been, so I was pointing out that in order to keep this, the seeds need to be changed to software-properties-common, as the script got moved there | 03:48 |
| pitti | NCommander: you want SRU team members, not archive admins for that | 03:48 |
| NCommander | pitti: it'sbeen awhile since Ididan SRU, but I thought it was from proposed->updates that need a SRU ack (and this is a bit ofa special case; this is the highbank hardware enablement. I can't properly test build d-i until the udebs are built) | 03:50 |
| pitti | no, the SRU team reviews stuff in the -proposed queue | 03:51 |
| pitti | well, they also promote verified packages to -updates, yes | 03:51 |
| NCommander | crap | 03:52 |
| NCommander | pitti: know any SRU team members awake atthi hour? | 03:52 |
| pitti | RAOF should be | 03:52 |
| pitti | probably infinity as well | 03:52 |
| * RAOF is indeed awake | 03:52 | |
| NCommander | RAOF: infiping? | 03:52 |
| pitti | I'm not sure whether they have a kind of roster these days, there was some talk about it | 03:53 |
| RAOF | pitti: Yup, see https://wiki.ubuntu.com/StableReleaseUpdates#Publishing | 03:53 |
| pitti | ah, there we go | 03:54 |
| RAOF | NCommander: What's up, dawg? What do you need accepted? | 03:54 |
| RAOF | *: actual acceptance gated on review. | 03:55 |
| NCommander | RAOF: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1004018 - libdebaininstaller,base-installer,flash-kernel | 03:55 |
| ubottu | Launchpad bug 1004018 in libdebian-installer (Ubuntu Precise) "Add highbank images" [High,In progress] | 03:55 |
| NCommander | RAOF: hrm, seems one of the patches have fallen off the bug, I'll fish out the debdiffs if you need them individually | 03:56 |
| RAOF | NCommander: If they're all in the queue then I'll grab them from theer. | 03:56 |
| RAOF | We haven't actually reviewed debdiffs from bugs for as long as I've been in the SRU team :) | 03:57 |
| NCommander | RAOF: they are, thanks for the look. These need to go into proposed so I can builda non-hacked up d-i and uload that,and all four must then progate to updates :-) | 03:57 |
| NCommander | RAOF: I think the last time I SRU'ed something was in Dapper :-/ | 03:57 |
| RAOF | You'll need a real, live archive admin to do the acceptance; d-i requires manual fiddling with cocoplum access. (or did last time I checked) | 03:58 |
| RAOF | NCommander: So, we hit the first question: *which* upload of flash-kernel in the precise-proposed unapproved queue should go in? :) | 03:58 |
| NCommander | RAOF: d-i isn'tuploaded, these are its build-deps (d-i is a bit of a monster when we have to add new code) | 03:58 |
| * NCommander looks atthequee | 03:58 | |
| RAOF | Ba baw. | 03:59 |
| RAOF | Would you kindly upload a flash-installer that has both fixes in it? :) | 03:59 |
| * NCommander hitshis head repeatively | 04:00 | |
| NCommander | Standby, downloadingand reviewing what the other fix is | 04:01 |
| NCommander | hr | 04:01 |
| RAOF | It's a fix for linaro kernels, apparently. | 04:01 |
| NCommander | clickingthe difflink sends meto a.internalwesite | 04:01 |
| NCommander | RAOF: I'll roll both together, but obviouslythen they havetobe ACK'ed together. I'msuprised LP allows multiples of the same package versions ina queue | 04:02 |
| RAOF | Time to scream in #launchpad. | 04:02 |
| NCommander | RAOF: easy enough tomerge, butIhave no way of testing this patch | 04:03 |
| RAOF | I'm happy to assume that it does what the uploader says it does, after reviewing it for sanity. | 04:03 |
| RAOF | They'll have to do the verification, obviously. | 04:04 |
| RAOF | 12.04.1 is approaching; both these fixes seem reasonably easy to verify, so folding them into the same SRU should get both of them into precise-updates faster than splitting them up. | 04:05 |
| NCommander | RAOF: merged together | 04:06 |
| NCommander | RAOF: looks good from here,uploading, NACK the two existing uploads as soon as this pops in | 04:07 |
| RAOF | Ta. I'll review that diff manually, then. Rejected both the previous ones. | 04:07 |
| NCommander | RAOF: and uploaded | 04:08 |
| NCommander | RAOF: got the pending email. I needtorunthe corner store, brb in 5 | 04:13 |
| RAOF | Thanks. | 04:13 |
| StevenK | NCommander: In AK? Isn't it more like 35? | 04:17 |
| NCommander | StevenK: depends where in AK you are | 04:31 |
| RAOF | NCommander: That should be everything. While these diffs were all nice and trivial, please include the information requested in https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template in future ☺ | 04:46 |
| === cpg|away is now known as cpg | ||
| TheMuso | ls | 05:27 |
| TheMuso | whoops | 05:27 |
| dupondje | https://launchpad.net/ubuntu/+source/libreoffice/1:3.6.0~rc2-0ubuntu1 seems to contain alot of spam changelog from ppa's. | 05:36 |
| === d1b_ is now known as d1b | ||
| ScottK | dupondje: If the PPAs were used by a significant number of end users, I think that's not unreasonable. | 05:49 |
| ScottK | (I don't do it that way, but I think it's not unreasonable) | 05:49 |
| ScottK | and I think the LO PPA qualifies. | 05:50 |
| === cpg is now known as cpg|away | ||
| === cpg|away is now known as cpg | ||
| Sweetsha1k | seb128: the i386 breaker is new to me. since the amd64 build succeeded I uploaded a 3.6.0~rc2-0ubuntu2 which disables running these kind of tests (subsequentchecks) an only do the basic tests so we get a i386 package in ASAP. | 07:46 |
| seb128 | Sweetsha1k, hey, thanks, on chinstrap as well? | 07:47 |
| Sweetsha1k | on chinstrap. still building locally. | 07:47 |
| cjwatson | RAOF: d-i no longer requires any such manual fiddling on cocoplum; in fact, there are no remaining packages that require that, since I got them all fixed recently | 07:47 |
| cjwatson | RAOF: (and actually, it was never on accept that there was a problem, it used to be on copying from -proposed to -updates) | 07:48 |
| RAOF | cjwatson: Hurray! | 07:48 |
| RAOF | cjwatson: That's what I meant, if not what I said ;) | 07:48 |
| Sweetsha1k | seb128: ETA for the build to finish: 20 minutes. ETA for the deb-packaging to finish ~1 hours. | 07:49 |
| cjwatson | RAOF: I like being able to delete documentation ;-) | 07:49 |
| seb128 | Sweetsha1k, deb-packaging? | 07:49 |
| seb128 | Sweetsha1k, is that on i386? were you able to reproduce the issue from the builder? | 07:50 |
| Sweetsha1k | seb128: the issue on the i386 builder was likely a fluke -- it we restart that build, Id assume it to complete. | 07:51 |
| Sweetsha1k | seb128: so its just a instable test. | 07:51 |
| seb128 | Sweetsha1k, what about the arm* build issues? | 07:51 |
| Sweetsha1k | seb128: quoteth infinity: "build-conflicting against the default compiler is no winning move" | 07:52 |
| seb128 | hehe | 07:52 |
| seb128 | that's true I guess ;-) | 07:53 |
| Sweetsha1k | seb128: that sneaked in from debian very early in the cycle so I didnt see it. in the upload I simply removed the build-conflict. If there was a reason that is still valid today for it the build will break, but not worse than what we have right now. | 07:54 |
| seb128 | Sweetsha1k, right | 07:54 |
| Sweetsha1k | so with this upload i386 should be fine, arm/ppc might be fine. | 07:54 |
| hrw | tkamppeter: hi, bug 932882 strikes back in quantal ;( | 08:36 |
| ubottu | Launchpad bug 932882 in gutenprint (Ubuntu) "Update of a printer driver package does not update the PPD files of the existing queues for this driver" [High,In progress] https://launchpad.net/bugs/932882 | 08:37 |
| === ejat- is now known as ejat | ||
| === cpg is now known as cpg|away | ||
| jml | did anything unusually big happen to the archive in the last couple of days? | 09:35 |
| seb128 | hum, stupid question but is the quantal-proposed->quantal copies process documented somewhere? | 09:35 |
| seb128 | jml, you mean? | 09:36 |
| seb128 | jml, there was a freeze in effect for some days early in the week to test the new queue handling script cjwatson has been working on | 09:36 |
| jml | seb128: I don't know :) My package scanner is taking way longer than usual, but I've got no actual access to the running copy, so I'm looking for as many sources of clues as I can get. | 09:36 |
| seb128 | jml, libreoffice and webkit got uploaded, if you consider those as big things that can happen to an archive ;-) | 09:37 |
| cjwatson | I'm not aware of anything particularly weird | 09:37 |
| cjwatson | seb128: process> no, because it's crap | 09:37 |
| cjwatson | seb128: gtk+3.0 I assume? | 09:37 |
| seb128 | cjwatson, ok, so I want gtk copied from proposed to quantal | 09:37 |
| seb128 | cjwatson, ... yes :p | 09:37 |
| seb128 | cjwatson, should I do that myself or should I rather ping about it? | 09:37 |
| === Sweetsha1k is now known as Sweetshark | ||
| cjwatson | As an archive admin, you're welcome to do it once it's built on all architectures and http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html is clean | 09:38 |
| cjwatson | (At least regarding that package) | 09:38 |
| cjwatson | Use sru-release (*cough* name) | 09:39 |
| jml | seb128, cjwatson: thanks. | 09:39 |
| seb128 | cjwatson, ok, thanks | 09:39 |
| cjwatson | With -r, obviously | 09:40 |
| cjwatson | So e.g. I just ran 'sru-release -r quantal libfm' | 09:40 |
| seb128 | cjwatson, done it for gtk, thanks ;-) | 09:41 |
| === MacSlow is now known as MacSlow|lunch | ||
| tseliot | infinity: are you around? | 11:59 |
| === hrw is now known as hrw- | ||
| === hrw- is now known as hrw | ||
| === _salem is now known as salem_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| smoser | any one know where /etc/dpkg/dpkg.cfg.d/multiarch went to in quantal ? | 13:08 |
| tumbleweed | into a database (accessible via dpkg --print-foreign-architectures) | 13:10 |
| tumbleweed | /var/lib/dpkg/arch, presumably | 13:10 |
| smoser | right. i see that. notably i can add and remove now with: sudo dpkg --remove-architecture i386 | 13:11 |
| smoser | tumbleweed, thanks. | 13:11 |
| tumbleweed | yup | 13:11 |
| === mnepton is now known as mneptok | ||
| pitti | offli | 13:45 |
| pitti | erk, focus fail, sorry | 13:45 |
| seb128 | pitti, that's not a strong password you got there :p | 13:46 |
| pitti | in terminals this expands to offlineimap :) | 13:47 |
| seb128 | ;-) | 13:47 |
| === Quintasan_ is now known as Quintasan | ||
| seb128 | shrug | 14:00 |
| seb128 | webkit from quantal-proposed failed to build on armel :-( | 14:00 |
| seb128 | nothing useful in the build log | 14:01 |
| seb128 | the build seems it got killed after 16 hours | 14:01 |
| seb128 | let's retry it.. | 14:01 |
| micahg | seb128: does it still have --no-keep-memory? | 14:03 |
| seb128 | micahg, depending of the arch it builds on, the debian guys enabled it only for 32bits I think | 14:04 |
| seb128 | micahg, but the log doesn't suggest it ran out of memory or that ld got killed | 14:04 |
| seb128 | like it was happening | 14:04 |
| seb128 | it just seems the build environment was wipped out while building | 14:04 |
| cjwatson | seb128: as if it were rm -rf'ed? | 14:06 |
| cjwatson | seb128: if so, that's the standard ops method of killing a build | 14:06 |
| seb128 | cjwatson, in fact ignore that | 14:06 |
| seb128 | the log has a "Build killed with signal 15 after 180 minutes of inactivity" | 14:07 |
| seb128 | I wonder if the linking was at work for 3 hours?! | 14:08 |
| seb128 | webkit is slightly insane | 14:08 |
| seb128 | the previous build took 1 day 4 hours on armel, so I wouldn't be surprised if ld was taking some hours | 14:08 |
| cjwatson | ah, well that's just the inactivity timeout | 14:08 |
| seb128 | yes | 14:11 |
| seb128 | I wonder if it was really unactive | 14:11 |
| seb128 | or if ld takes over 3 hours | 14:11 |
| seb128 | and if ld takes over 3 hours I wonder what's the way out | 14:11 |
| micahg | seb128: well, on arm, you're going to run into memory issues fast as there's not much available (even if it doesn't fail on that) | 14:12 |
| micahg | as in you'll start swapping like mad | 14:13 |
| seb128 | micahg, that doesn't tell me what to do though ;-) | 14:13 |
| micahg | --reduce-memory-overheads might be a good idea on arm* | 14:14 |
| seb128 | is that a real option? | 14:15 |
| seb128 | ;-) | 14:15 |
| micahg | if there were a working porter box, you could try it :) | 14:15 |
| micahg | yes, indeed | 14:15 |
| seb128 | well, porter box wouldn't kill my build after 3 hours of unactivity | 14:15 |
| seb128 | so that wouldn't really reply to my question | 14:15 |
| micahg | well, it shouldn't be 3, but 10 or 12 | 14:16 |
| micahg | at least on arm* | 14:16 |
| cjwatson | Using the memory reduction options is probably the right thing to do | 14:21 |
| cjwatson | 2012-02-10.log:14:12 <cjwatson> seb128: try ld --no-keep-memory | 14:21 |
| cjwatson | 14:13 <cjwatson> seb128: possibly --reduce-memory-overheads too | 14:22 |
| cjwatson | 14:15 <seb128> cjwatson, ok, thanks, I will have a look to --no-keep-memory and --reduce-memory-overheads | 14:22 |
| micahg | seb128: also, they're building with -01 on armhf, maybe that should be done on armel as well | 14:22 |
| micahg | cjwatson: sorry for not quoting you | 14:22 |
| seb128 | cjwatson, yeah, I did that in precise which worked fine | 14:22 |
| seb128 | cjwatson, Debian modified it to "only add -Wl,--no-keep-memory for 32 bits architectures" | 14:23 |
| micahg | arm* is 32 bit AIUI | 14:23 |
| micahg | isn't it? | 14:23 |
| cjwatson | Yeah, but maybe they got the test wrong? | 14:23 |
| cjwatson | ifeq ($(DEB_HOST_ARCH_BITS),32) | 14:24 |
| cjwatson | LDFLAGS += -Wl,--no-keep-memory | 14:24 |
| cjwatson | endif | 14:24 |
| cjwatson | Hm, that should be OK | 14:24 |
| seb128 | LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,--no-keep-memory" \ | 14:24 |
| seb128 | in the armel build log | 14:24 |
| seb128 | so it's already used | 14:25 |
| cjwatson | OK, in that case try adding -Wl,--reduce-memory-overheads | 14:25 |
| seb128 | will do | 14:25 |
| seb128 | is it worth trying a retry first? | 14:25 |
| cjwatson | not sure; it would probably only help if it's incredibly marginal | 14:25 |
| cjwatson | it's not like the buildds are typically doing more than one thing at once | 14:26 |
| seb128 | ok, let me try -Wl,--reduce-memory-overheads then | 14:26 |
| seb128 | cjwatson, micahg: thanks | 14:26 |
| cjwatson | --no-keep-memory => don't cache symbol tables in memory; --reduce-memory-overheads => change link map generation space/time tradeoff, decrease hash table size | 14:26 |
| seb128 | well --no-keep-memory helped to not reach the 32 bits memory limit at linking time | 14:28 |
| seb128 | cjwatson, I'm not sure the issue we have there is memory overhead | 14:29 |
| seb128 | it's mostly "c++ linking takes ages on complex code" | 14:29 |
| seb128 | will -Wl,--reduce-memory-overheads help linking speed? | 14:29 |
| micahg | seb128: well, chromium takes 9.5 hrs on armel now, and they're using both of those flags last time I checked, so building twice, you should end up with ~19 hrs | 14:30 |
| micahg | although it might not be a fair comparison as chromium is still way faster on x86 than webkit is for some reason, even accounting for building twice | 14:30 |
| micahg | oh, right --parallel helps :) | 14:32 |
| cjwatson | seb128: On memory-constrained systems, keeping the working set down may well make a big difference. | 14:33 |
| cjwatson | It's entirely plausible that the slow link speed is because it's thrashing itself to death. | 14:33 |
| cjwatson | Definitely worth trying at least. | 14:34 |
| seb128 | cjwatson, right, I'm about to upload with that, let's see how it goes, thanks again | 14:35 |
| seb128 | crap | 14:47 |
| seb128 | I pushed webkit to quantal and not quantal-proposed | 14:47 |
| seb128 | 3 minutes before the queue run | 14:47 |
| seb128 | cjwatson, is there anything I can do to undo that? | 14:48 |
| mdeslaur | seb128: time-travel? | 14:48 |
| seb128 | mdeslaur, well it's not end of the world, it's not any worth that what we had for years | 14:48 |
| NCommander | RAOF: ping? | 14:50 |
| micahg | NCommander: if you're looking for an SRU member, you might want to try someone in a more awake TZ | 14:52 |
| NCommander | micahg: recommendations? | 14:52 |
| * micahg checks the rotation | 14:52 | |
| seb128 | bdmurray | 14:53 |
| seb128 | it's his day today | 14:53 |
| micahg | yeah, he may or may not be up yet though | 14:53 |
| seb128 | well, he's closer from being up that RAOF in any case ;-) | 14:53 |
| micahg | very true :) | 14:53 |
| seb128 | otherwise try SpamapS or slangasek | 14:54 |
| micahg | they're all in the same TZ | 14:54 |
| cjwatson | seb128: Probably not | 14:54 |
| cjwatson | seb128: Archive admins don't have access to the queue any more, it's webops only. Though it was always a bit of a race anyway. | 14:55 |
| seb128 | cjwatson, yeah, queue has been running now anyway, sorry about that ... oh ok, well not worth bothering them | 14:56 |
| bdmurray | NCommander: Hi, what do you have? | 14:57 |
| NCommander | bdmurray: I'm doing highbank hardwareenablement, and I have a flash-kernel SRU accepted into proposedjust to find a typo breaks the installer on armhf+highbank. Need 42.2 pushed throughsoI can re-testd-iand finish the SRU | 15:00 |
| ogra_ | NCommander, didnt you have it reviewed before the accept ? | 15:01 |
| NCommander | ogra_: code was fine, and worked. I forgotto escapea$ though which causdissues Ididn'tcatch | 15:01 |
| ogra_ | ah, evil ! | 15:02 |
| bdmurray | NCommander: for precise? | 15:02 |
| NCommander | bdmurray: yeah. | 15:03 |
| NCommander | ogra_: flash-kernel is exceptionally annoying to test because the udeb and deb getpulled from different places (if you bake the udeb right into the initrd which is how I usually test) | 15:03 |
| ogra_ | NCommander, yeah, i'm happy i didnt have to touch d-i yet ... though i will soon | 15:04 |
| ogra_ | f-k on live images is exceptionally easy to hack up :) | 15:04 |
| NCommander | ogra_: eh, could be worse | 15:04 |
| * NCommander beatsorga with a spork | 15:04 | |
| ogra_ | what the heck is a spork ? | 15:04 |
| ogra_ | oh. a göffel ! | 15:04 |
| ogra_ | heh | 15:04 |
| cjwatson | http://en.wikipedia.org/wiki/Spork | 15:05 |
| ogra_ | yeah | 15:05 |
| cjwatson | Fantastic, the German word is formed in the same way | 15:06 |
| ogra_ | hehe, yeah | 15:06 |
| ogra_ | NCommander, eeep ! | 15:15 |
| ogra_ | NCommander, can you use -v in -proposed uploads so the bugs get closed from the changelog ? | 15:16 |
| ScottK | NCommander: And so the bug's verification status shows up in the tools that the SRU team uses to see if stuff should be copied (i.e. this is not just cosmetic) | 15:16 |
| NCommander | ogra_: er, thebug already got closed, I forgotto reopen it >.>; | 15:19 |
| ogra_ | NCommander, my bug ? | 15:20 |
| NCommander | ogra_: er, wrong bug >.>; | 15:20 |
| * NCommander whisltesquietly and dives out a window | 15:20 | |
| ogra_ | pfft, on a one storey house thats lame | 15:20 |
| === akgraner` is now known as akgraner | ||
| bryceh | @pilot in | 16:08 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh | ||
| dupondje | Anyone an idea how I can debug foomatic driver? Getting the following on page when I print: "SPL-C ERROR : Including corrupted data" | 16:10 |
| bryceh | anyone around who can set merge proposal statuses to merged? | 16:43 |
| bryceh | well if anyone pops up that can close merges, these ones are done and can be set to Merged: http://paste.ubuntu.com/1100394/ | 16:48 |
| stgraber | bryceh: doing, feel free to ping directly ;) | 16:53 |
| stgraber | bryceh: done | 16:54 |
| bryceh | stgraber, thanks! | 16:55 |
| mterry | Does anyone here understand how gcc treats NANs very well? I've got a FTBFS that seems to be due to gcc adjusting the bits in a NAN as it is passed around | 16:57 |
| slangasek | "NAN"? as in NaN? | 16:57 |
| mterry | slangasek, yeah | 16:57 |
| slangasek | do you mean that when gcc passes it around, it ends up with something that's no longer NaN? | 16:58 |
| mterry | There's a package that uses a union of an int and a float, sets the int, then passes the float around, assigns that float to another similar union and reads back the int. And the bits are different. Still NaN when a float, but different bits | 16:59 |
| mterry | This only affects i386 | 16:59 |
| slangasek | sounds to me like a valid thing for the compiler to do | 17:00 |
| slangasek | and a possibly invalid use of a union :) | 17:00 |
| cjwatson | Uh, I'd have to check chapter and verse, but that sounds awfully like undefined behaviour, yes | 17:00 |
| mterry | Bummer. Do you think there is a compiler flag to make that more reasonable? Like "-no-mangle-nans" or something? | 17:00 |
| mterry | Else I can just disable the test that's failing. It doesn't seem like a super important aspect of the package | 17:01 |
| * penguin42 seems to remember that the Intel x86 manual explicitly suggests doing things with different NaN encodings for your code to do different stuff | 17:01 | |
| mterry | (it's trying to detect the difference between signaling NaNs and quiet ones, but doing so with its own goofy union strategy) | 17:02 |
| cjwatson | -fno-strict-aliasing perhaps | 17:02 |
| cjwatson | have a look at gcc's docs on -fstrict-aliasing; it has some explicit examples of invalid uses of unions | 17:02 |
| * mterry reads | 17:03 | |
| cjwatson | And I guess you could try lowering optimisation to see if that makes a difference | 17:03 |
| === zyga is now known as zyga-afk | ||
| smoser | anyone have thoughts on this or point to doc? | 17:44 |
| smoser | if i have an initramfs module that has confgiuration that can be done. it can install a file into /etc/initramfs/conf.d | 17:44 |
| smoser | then, that will get copied to the initramfs. | 17:45 |
| smoser | for this module, from inside the initramfs i can see the "real root" filesystem | 17:45 |
| smoser | if there is a config file in the rootfs, should i allow that to override the settings in the initramfs? | 17:45 |
| smoser | to me it seems like /etc/initramfs/conf.d/$MODULE.conf should override the copy in the initramfs (if possible). | 17:46 |
| astraljava | Hi gang! I'm running quantal Studio ATM. I have after installation installed -generic kernel, for testing the performance and all that. My question is: should I file a bug against update-manager when a recent update to 3.5.0-5 on -generic makes it suggest a reboot, when I'm in fact running the -lowlatency kernel, which is the default for Studio? | 17:53 |
| micahg | astraljava: that's usually triggered in the package itself | 17:55 |
| astraljava | micahg: Ok, so there's nothing intelligent happening to detect the flavor of the kernel running currently? | 17:55 |
| micahg | astraljava: seemingly | 17:56 |
| astraljava | Right, so no bug. Thanks! | 17:56 |
| micahg | astraljava: well, that depends on your perspective | 17:57 |
| micahg | astraljava: could be a wishlist | 17:58 |
| * micahg -> #ubuntustudio-devel | 17:58 | |
| scientes | astraljava, check if it made itsself the default | 18:01 |
| scientes | in /boot/grub/grub.cfg | 18:01 |
| scientes | if not, then there is no point in rebooting, if it did, then thats a differn't bug | 18:01 |
| astraljava | scientes: Yeah, after installing -generic, -lowlatency is where I'm getting booted at if I don't have any actions while grub is loading. | 18:04 |
| scientes | astraljava, you might just want to remove linux-image-generic metapackage | 18:05 |
| micahg | scientes: the point is it should DTRT regardless of what's installed, it just isn't very severe since it's a non-default case | 18:06 |
| scientes | indeed | 18:06 |
| astraljava | scientes: I won't, as I'll keep testing the performance differences throughout the cycle. The point behind the question was that whether update-manager should tell me to reboot when the kernel I'm actually currently running was updated or not. | 18:06 |
| scientes | micahg, i wonder if it does this if you install the amd64 kernel on i386, thats a little more critical of a case | 18:06 |
| scientes | astraljava, its probably lack of being able to get information back from "update-grub" trigger | 18:07 |
| scientes | and not wanting to manually parse /boot/grub/grub.cfg | 18:07 |
| infinity | We do nothing to try to detect which flavor you want if you install multiple. The answer is "don't do that". | 18:07 |
| astraljava | infinity: Okay, I find that totally understandable, and quite on mark of what I needed to know. Thanks! :) | 18:08 |
| infinity | astraljava: As for the reboot trigger, it could PERHAPS be made more clever to try to detect if the flavour/arch combination matches the currently-running kernel, but that's a bit sketchy. | 18:09 |
| infinity | (Would fail in the case of flavour renames, for instance, which we do from time to time) | 18:10 |
| micahg | infinity: there are usually transitional packages with flavor renames, right? the transitional postinst could do the handoff so to speak | 18:11 |
| infinity | micahg: Maybe, but that feels like overengineering for a corner case. | 18:11 |
| micahg | infinity: isn't that the fun part? | 18:12 |
| infinity | :P | 18:12 |
| micahg | :) | 18:12 |
| astraljava | infinity: What flavor renames has there been? I don't recall any for Studio, but I haven't really been looking for others. | 18:13 |
| micahg | generic-pae -> generic | 18:15 |
| infinity | astraljava: powerpc -> powerpc-smp, generic-pae -> generic, server -> generic, virtual -> generic | 18:15 |
| infinity | I might be missing a few. | 18:15 |
| astraljava | infinity: Okay, I got the point, thanks. :) | 18:15 |
| === dpb_ is now known as Guest78961 | ||
| === cpg|away is now known as cpg | ||
| === yofel_ is now known as yofel | ||
| === salem_ is now known as _salem | ||
| shadeslayer | hallyn: mterry opencv still needs transitioning to new tiff it seems, digikam won't get packaged until opencv depends on the new tiff | 21:07 |
| shadeslayer | want me to do that? | 21:07 |
| mterry | shadeslayer, ah sure. Presumably just needs a rebuild? | 21:08 |
| mterry | thanks | 21:08 |
| shadeslayer | mterry: deps in control file need to be changed | 21:08 |
| shadeslayer | libopencv-highgui-dev had a hard dep on libtiff4-dev | 21:08 |
| mterry | shadeslayer, then maybe change them to a versionless libtiff-dev and pass the patch on to Debian. Makes future transitions easier | 21:09 |
| shadeslayer | ok | 21:09 |
| infinity | micahg: Say, webkit just started pulling in half of universe via recommends. | 21:09 |
| infinity | micahg: Care to make that not the case? | 21:09 |
| micahg | infinity: was just about to tell seb128 about it :) | 21:10 |
| * shadeslayer rebuilds opencv with modifications | 21:10 | |
| seb128 | well, I don't care, I don't want to maintain stupid webkit... | 21:10 |
| infinity | seb128: That's the spirit! | 21:11 |
| seb128 | whoever cares enough can fix it, I just updated because nobody does and the current version was broken | 21:11 |
| micahg | infinity: seb128: I'm not supposed to be maintaining it in the dev release either :) | 21:12 |
| infinity | Bah. I'll fix it, it's just a Recommend. | 21:12 |
| infinity | But TILM really should belong to the desktop team. | 21:13 |
| seb128 | infinity, it's a f**** package that takes over a day to fail to build on arm* | 21:13 |
| shadeslayer | lol | 21:13 |
| seb128 | where fail to build is because ld takes over 3 hours and the buildd kills it thinking it's stucked | 21:13 |
| seb128 | I'm not touching that stuff again :p | 21:13 |
| mterry | TIL that seb128 has been forever scarred by webkit | 21:14 |
| seb128 | mterry, ;-) | 21:14 |
| seb128 | mterry, want to maintain webkit for us? ;-) | 21:14 |
| infinity | seb128: Yes, I've been down that road before too. | 21:14 |
| * shadeslayer makes a mental note never to touch webkit | 21:14 | |
| * mterry shuts up again | 21:14 | |
| seb128 | mterry, see!!! | 21:14 |
| infinity | Anyhow, in this case, just dropping all the new gst-* Recommends to Suggests would probably be sane. | 21:14 |
| seb128 | mterry, I was just only too nice^Wstupid to try to fix it | 21:15 |
| infinity | If we want gst-* plugins installed on the default system, pulling them in from webkit is the wrong answer anyway. | 21:15 |
| seb128 | infinity, yeah, I want to see if the arm* build fails first though | 21:15 |
| micahg | infinity: well, just bad and ffmpeg | 21:15 |
| seb128 | infinity, just to avoid resetting an 1.5day build counter | 21:15 |
| infinity | micahg: I see no reason to recommend the ones in main either. | 21:15 |
| infinity | micahg: That should be a suggests either way, IMO. | 21:15 |
| infinity | micahg: (In Debian too) | 21:15 |
| micahg | infinity: why not, they add functionality to the library? | 21:15 |
| infinity | micahg: But that's just one man's opinion. | 21:15 |
| micahg | infinity: the idea is that webkit portal can use media content | 21:16 |
| infinity | Lots of things add functionality, it doesn't mean they should "always be installed, except in exceptional circumstances". | 21:16 |
| micahg | infinity: yes, but video and audio are important for a browser engine | 21:17 |
| infinity | micahg: Maybe? I dunno. We lived without webkit recommending those up until now. | 21:18 |
| shadeslayer | oh while there's some activity over here, is there a spec against the mac ISO builds? | 21:18 |
| shadeslayer | because the 3.5 kernel supposedly supports everything | 21:18 |
| micahg | although, technically, it should be the browser recommending them if it implements the audio/video API (unless that's not necessary in which case the recommends are correct) | 21:18 |
| infinity | micahg: The point is probably moot, since gstreamer0.10-plugins-good is in every *-desktop seed anyway. | 21:19 |
| infinity | micahg: But I still think that a library pulling in half the world as a default behaviour is wrong. | 21:19 |
| micahg | sure | 21:19 |
| infinity | micahg: Recommending gst-* fun from a user-facing application is one thing, but if you have some random dohickey that depends on libwebkit to do HTML rendering, that shouldn't pull in all of the gst madness. | 21:20 |
| infinity | Cause, well, webkit is used all over the place for non-multimedia things. | 21:20 |
| infinity | (So, I'd argue the "normal" use-case for libwebkit doesn't actually include that functionality at all) | 21:20 |
| micahg | well, that's probably happening in a lot of libraries | 21:22 |
| micahg | doesn't make it right though, so go ahead :) | 21:22 |
| infinity | micahg: gst has a plugin architecture for a reason. Blindly pulling in all the plugins when they're not used defeats the whole point. ;) | 21:22 |
| infinity | (And yeah, for our desktop seeds, it's meaningless, we already install it all, but I'm just arguing packaging correctness) | 21:23 |
| micahg | infinity: well, makes sense for a browser, you want to play everything | 21:23 |
| infinity | Plus, the delta's super easy to maintain if we just s/Recommends/Suggests/ :P | 21:23 |
| micahg | heh, right | 21:23 |
| infinity | micahg: Absolutely makes sense for a browser. libwebkit isn't a browser. | 21:23 |
| bryceh | @pilot out | 21:48 |
| === udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| shadeslayer | mterry: https://launchpad.net/~rohangarg/+archive/experimental/+builds?build_state=building < could you sponsor those once they're built? | 22:02 |
| mterry | shadeslayer, sure. I'll leave a tab open, but if you notice before I do, ping me again | 22:03 |
| mterry | I'm about to sign off though, so may get to it tomorrow | 22:03 |
| shadeslayer | nah, I'm going to sleep in a couple of minues :P | 22:03 |
| shadeslayer | sure, no rush | 22:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!