[00:10] <scientes> libreoffice is a beast
[00:11] <scientes> why is libreoffice in universe in quantal?
[00:12] <infinity> BenC: I might fix it later.
[00:14] <stgraber> scientes: the libreoffice meta package seems to be in universe, the actual components (libreoffice-core, libreoffice-writer, ...) are in main
[00:48] <phillw> BenC ping
[00:48] <BenC> phillw: pong
[00:49] <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:50] <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:51] <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:52] <BenC> phillw: Checking the bug (cooking dinner, so might be slow)
[00:52] <phillw> thanks, it's a killer bug for alternate release.
[00:54] <BenC> phillw: Does this happen on differing ppc platforms, or one specific machine?
[00:55] <phillw> both of the ppc testers that lubuntu have have experienced it
[01:06] <BenC> phillw: what is their hardware?
[01:08] <BenC> G3, G4, ??
[01:09] <phillw> I'm not 100% sure. apport didn't pull the information in.
[01:11] <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:12] <BenC> Ok
[01:49] <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:50] <phillw> BenC it sure is, even more weird as one of the testers got the alternate install to install when selecting encryption!
[02:01] <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:02] <BenC> phillw: ok
=== Pendulum_ is now known as Pendulum
=== cpg is now known as cpg|away
[03:46] <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:48] <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:50] <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:51] <pitti> no, the SRU team reviews stuff in the -proposed queue
[03:51] <pitti> well, they also promote verified packages to -updates, yes
[03:52] <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: infi	ping?
[03:53] <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:54] <pitti> ah, there we go
[03:54] <RAOF> NCommander: What's up, dawg? What do you need accepted?
[03:55] <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:56] <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:57] <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:58] <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:59] <RAOF> Ba baw.
[03:59] <RAOF> Would you kindly upload a flash-installer that has both fixes in it? :)
[04:00]  * NCommander hitshis head repeatively
[04:01] <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:02] <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:03] <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:04] <RAOF> They'll have to do the verification, obviously.
[04:05] <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:06] <NCommander> RAOF: merged together
[04:07] <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:08] <NCommander> RAOF: and uploaded
[04:13] <NCommander> RAOF: got the pending email. I needtorunthe corner store, brb in 5
[04:13] <RAOF> Thanks.
[04:17] <StevenK> NCommander: In AK? Isn't it more like 35?
[04:31] <NCommander> StevenK: depends where in AK you are
[04:46] <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 ☺
=== cpg|away is now known as cpg
[05:27] <TheMuso> ls
[05:27] <TheMuso> whoops
[05:36] <dupondje> https://launchpad.net/ubuntu/+source/libreoffice/1:3.6.0~rc2-0ubuntu1 seems to contain alot of spam changelog from ppa's.
=== d1b_ is now known as d1b
[05:49] <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:50] <ScottK> and I think the LO PPA qualifies.
=== cpg is now known as cpg|away
=== cpg|away is now known as cpg
[07:46] <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:47] <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:48] <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:49] <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:50] <seb128> Sweetsha1k, is that on i386? were you able to reproduce the issue from the builder?
[07:51] <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:52] <Sweetsha1k> seb128: quoteth infinity: "build-conflicting against the default compiler is no winning move"
[07:52] <seb128> hehe
[07:53] <seb128> that's true I guess ;-)
[07:54] <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.
[08:36] <hrw> tkamppeter: hi, bug 932882 strikes back in quantal ;(
[08:37] <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
=== ejat- is now known as ejat
=== cpg is now known as cpg|away
[09:35] <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:36] <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:37] <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?
=== Sweetsha1k is now known as Sweetshark
[09:38] <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:39] <cjwatson> Use sru-release (*cough* name)
[09:39] <jml> seb128, cjwatson: thanks.
[09:39] <seb128> cjwatson, ok, thanks
[09:40] <cjwatson> With -r, obviously
[09:40] <cjwatson> So e.g. I just ran 'sru-release -r quantal libfm'
[09:41] <seb128> cjwatson, done it for gtk, thanks ;-)
=== MacSlow is now known as MacSlow|lunch
[11:59] <tseliot> infinity: are you around?
=== 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
[13:08] <smoser> any one know where /etc/dpkg/dpkg.cfg.d/multiarch went to in quantal ?
[13:10] <tumbleweed> into a database (accessible via dpkg --print-foreign-architectures)
[13:10] <tumbleweed> /var/lib/dpkg/arch, presumably
[13:11] <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
=== mnepton is now known as mneptok
[13:45] <pitti> offli
[13:45] <pitti> erk, focus fail, sorry
[13:46] <seb128> pitti, that's not a strong password you got there :p
[13:47] <pitti> in terminals this expands to offlineimap :)
[13:47] <seb128> ;-)
=== Quintasan_ is now known as Quintasan
[14:00] <seb128> shrug
[14:00] <seb128> webkit from quantal-proposed failed to build on armel :-(
[14:01] <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:03] <micahg> seb128: does it still have --no-keep-memory?
[14:04] <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:06] <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:07] <seb128> the log has a "Build killed with signal 15 after 180 minutes of inactivity"
[14:08] <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:11] <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:12] <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:13] <micahg> as in you'll start swapping like mad
[14:13] <seb128> micahg, that doesn't tell me what to do though ;-)
[14:14] <micahg> --reduce-memory-overheads might be a good idea on arm*
[14:15] <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:16] <micahg> well, it shouldn't be 3, but 10 or 12
[14:16] <micahg> at least on arm*
[14:21] <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:22] <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:23] <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:24] <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:25] <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:26] <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:28] <seb128> well --no-keep-memory helped to not reach the 32 bits memory limit at linking time
[14:29] <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:30] <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:32] <micahg> oh, right --parallel helps :)
[14:33] <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:34] <cjwatson> Definitely worth trying at least.
[14:35] <seb128> cjwatson, right, I'm about to upload with that, let's see how it goes, thanks again
[14:47] <seb128> crap
[14:47] <seb128> I pushed webkit to quantal and not quantal-proposed
[14:47] <seb128> 3 minutes before the queue run
[14:48] <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:50] <NCommander> RAOF: ping?
[14:52] <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:53] <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:54] <seb128> otherwise try SpamapS or slangasek
[14:54] <micahg> they're all in the same TZ
[14:54] <cjwatson> seb128: Probably not
[14:55] <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:56] <seb128> cjwatson, yeah, queue has been running now anyway, sorry about that ... oh ok, well not worth bothering them
[14:57] <bdmurray> NCommander: Hi, what do you have?
[15:00] <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:01] <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:02] <ogra_> ah, evil !
[15:02] <bdmurray> NCommander: for precise?
[15:03] <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:04] <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:05] <cjwatson> http://en.wikipedia.org/wiki/Spork
[15:05] <ogra_> yeah
[15:06] <cjwatson> Fantastic, the German word is formed in the same way
[15:06] <ogra_> hehe, yeah
[15:15] <ogra_> NCommander, eeep !
[15:16] <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:19] <NCommander> ogra_: er, thebug already got closed, I forgotto reopen it >.>;
[15:20] <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
=== akgraner` is now known as akgraner
[16:08] <bryceh> @pilot in
=== 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
[16:10] <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:43] <bryceh> anyone around who can set merge proposal statuses to merged?
[16:48] <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:53] <stgraber> bryceh: doing, feel free to ping directly ;)
[16:54] <stgraber> bryceh: done
[16:55] <bryceh> stgraber, thanks!
[16:57] <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:58] <slangasek> do you mean that when gcc passes it around, it ends up with something that's no longer NaN?
[16:59] <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
[17:00] <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:01] <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:02] <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:03]  * mterry reads
[17:03] <cjwatson> And I guess you could try lowering optimisation to see if that makes a difference
=== zyga is now known as zyga-afk
[17:44] <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:45] <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:46] <smoser> to me it seems like /etc/initramfs/conf.d/$MODULE.conf should override the copy in the initramfs (if possible).
[17:53] <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:55] <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:56] <micahg> astraljava: seemingly
[17:56] <astraljava> Right, so no bug. Thanks!
[17:57] <micahg> astraljava: well, that depends on your perspective
[17:58] <micahg> astraljava: could be a wishlist
[17:58]  * micahg -> #ubuntustudio-devel
[18:01] <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:04] <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:05] <scientes> astraljava, you might just want to remove linux-image-generic metapackage
[18:06] <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:07] <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:08] <astraljava> infinity: Okay, I find that totally understandable, and quite on mark of what I needed to know. Thanks! :)
[18:09] <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:10] <infinity> (Would fail in the case of flavour renames, for instance, which we do from time to time)
[18:11] <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:12] <micahg> infinity: isn't that the fun part?
[18:12] <infinity> :P
[18:12] <micahg> :)
[18:13] <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:15] <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. :)
=== 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
[21:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <micahg> infinity: yes, but video and audio are important for a browser engine
[21:18] <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:19] <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:20] <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:22] <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:23] <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:48] <bryceh> @pilot out
=== 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:
[22:02] <shadeslayer> mterry: https://launchpad.net/~rohangarg/+archive/experimental/+builds?build_state=building < could you sponsor those once they're built?
[22:03] <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