[13:55] <larsdues1ng> short question, what to do with bug, which are 3+ years old, and depend on ubuntu 8.04?!? I cannot set "won't fix"...
[13:57] <larsdues1ng> -> https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/296036
[13:58] <larsdues1ng> oh, ok  8.10 :)
[13:58] <dupondje> Release has reached EOL
[13:58] <dupondje> If the specific release has reached EOL per https://wiki.ubuntu.com/Releases and there is not enough information to work on the bug, then you can set to Incomplete and use the following response (Note RELEASE and DATE are placeholders):
[13:59] <dupondje> https://wiki.ubuntu.com/Bugs/Responses#Release_has_reached_EOL
[13:59] <larsdues1ng> oh... ok
[13:59] <larsdues1ng> thanks
[14:47] <sivang> hi all
[14:47] <sivang> There are some nice scrollers (that look suspiciously suitable for touch interface) in Unity 2D, it is using Qt right?
[14:48] <sivang> (sorry of this question is offtopic here..)
[15:05] <cjwatson> broder: as far as I'm concerned, lintian.uw.o would be a lot more useful pointed at quantal
[15:21]  * sivang just noticed there's an u-d-d list. /me looks for the same irc channel
[15:24] <sivang> is it okay to ask general devel discussions here?
[17:09] <balhau> Hi guys. Is someone here able to speak about bluetooth troubleshooting?
[17:09] <balhau> Or can someone point me a irc channel to speak about that?
[18:17] <melodie> hello
[18:19] <melodie> I wonder if the core version can be used to make a spin. is there a how to for that purpose somewhere ?
[18:19] <melodie> https://wiki.ubuntu.com/Core
[18:31] <mterry> cjwatson, hello!  if you're actually able to get this on the uds wifi, I'd like to chat with you about a proposed change in update-manager.  If you see me in the halls, stop me!  :)
[18:33] <cjwatson> mterry: OK, though not entirely a relevant expert
[18:33] <maco> wouldnt that be mvo's territory?
[18:34] <mterry> cjwatson, well, it involves package metadata, not UI stuff (the ability to know if a package will want a restart ahead of installing it)
[18:35] <cjwatson> mterry: Mm, that is actually mostly mvo - currently it's a script that postinsts can run, IIRC
[18:36] <mterry> cjwatson, oh, OK.  I'll bug mvo instead.  Yeah, it's a postinst thing right now, but I need to find out whether it's even possible to add it to package metadata somehow.
[18:36] <mterry> mpt is writing checks that Ubuntu can't cash  :)
[18:36] <cjwatson> mterry: Right, I'm not sure of the answer
[18:37] <mpt> mterry, we had a session on it at UDS Lucid
[18:37] <mterry> cjwatson, OK!  Well, are there any packages you know that conditionally call that script?  Like only sometimes want a reboot?
[18:37] <mterry> mpt, oh good.  I'll try to find the notes
[18:37] <mpt> mterry, https://blueprints.launchpad.net/ubuntu/+spec/upgrading-running-software
[18:38] <mpt> hm, not that helpful
[18:38] <mpt> ah, https://wiki.ubuntu.com/UpgradingRunningPrograms
[18:38] <mterry> mpt, that still looks like it only deals with finding out about the need after the fact?
[18:38]  * mterry reads
[18:39] <mpt> mterry, I remember there was discussion of a flag for each update representing whether it require restart ... Maybe it got lost in the mists of time
[18:40] <mterry> mpt, yeah in the whiteboard, there's a link to a more relevant spec that is superceded by this one....  so it must have gotten folded in
[18:41] <cjwatson> mterry: dbus.postinst
[18:41] <cjwatson> mterry: gconf2.postinst, initscripts.postinst, libc6:i386.postinst
[18:42] <mterry> mpt, it looks like the goal was to avoid the need for most restart packages by just having them magically update at next program start
[18:42] <cjwatson> mterry: libpam0g:i386.postinst, libssl1.0.0:i386.postinst
[18:42] <mterry> mpt, maybe the Software Update spec needs to be updated to drop that bit of the UI?
[18:42]  * mterry looks at all these postinsts
[18:42] <cjwatson> in fact, the majority of packages on my system that do this are conditional in sosme way
[18:42] <mpt> mterry, maybe
[18:43] <mpt> cjwatson, are you saying that determining whether an update will require a restart is equivalent to solving the Halting Problem? :-)
[18:43] <mterry> cjwatson, yeah...  mostly around whether the package is in use at the time it seems
[18:44] <mterry> mpt, is UI that says "this package *may* cause a reboot" awful?
[18:44] <mpt> mterry, no, that would be fine
[18:44] <mpt> imo
[18:44] <mpt> Then if it doesn't, yay, bonus
[18:44] <maco> hang on
[18:44] <maco> cause or require
[18:44] <mterry> maco, require
[18:44] <mterry> sorry
[18:45] <maco> k, cuz the way you wrote before sounds like microsoft's reboot-whether-you-want-or-not
[18:45] <mterry> maco, :)
[18:45] <mterry> mpt, I'll talk to mvo about the possibility of adding metadata for any package that can possibly flip the reboot required flag
[18:45] <mterry> cjwatson, thanks for the investigation!
[18:46] <mpt> In an ideal world that would be another step, i.e. "we're updating the sort of stuff where trying to use Ubuntu during the update process would be an absolute misery"
[18:46] <mterry> mpt, didn't we have an "updating on shutdown" plan at one point?
[18:47] <mpt> mterry, yes, it didn't go anywhere <https://wiki.ubuntu.com/FoundationsTeam/Specs/KarmicUpdatesOnShutdown>
[18:47] <mterry> mpt, your spec involves grouping packages.  Did you have ideas about the boundaries of that grouping?  (like, group packages from the same source?)  And throw anything without a .desktop into "Ubuntu Core"?
[18:49] <mterry> mpt, also the spec has a "to think about section" about how it would involve dropping the distinction between security and regular updates (and 3rd party).  Didn't know if that had rattled around in your brain since the spec was last updated
[18:50] <mpt> mterry, I didn't write it down, but by "Ubuntu Core" I meant "anything that's a dependency of ubuntu-desktop, but neither (a) a graphical application nor (b) only there because it's a dependency of one graphical application"
[18:51] <mpt> mterry, I haven't rattled recently, but yes, probably we should retain the security distinction somehow
[18:51] <mterry> mpt, does the phrasing of "Ubuntu Core" perhaps change now that we have a distinct spin of Ubuntu called Ubuntu Core?
[18:52] <mpt> mterry, probably
[18:52] <mterry> mpt, OK well, commence rattling when you get a chance.  :)
[18:52] <mpt> sure thing
[18:53] <melodie> hi again
[18:53] <melodie> cjwatson, I would like to ask you if you remember a patch you did on a program having for name "openbox-xdgmenu" ?
[18:53] <slangasek> we have a distinct spin of Ubuntu called Ubuntu Core?
[18:54] <slangasek> oh, you're talking about the one we already have ;P
[18:54] <melodie> slangasek, yes
[18:54] <jussi> slangasek: https://wiki.ubuntu.com/Core i think
[18:55] <melodie> https://wiki.ubuntu.com/Core
[18:55] <slangasek> so yes, there's a conflicting definition of Ubuntu Core, which is definitely not compatible with mpt's definition above
[18:55] <melodie> can that be used to make a spin ?
[18:55] <slangasek> there's very little spinning involved with https://wiki.ubuntu.com/Core ;)
[18:55] <melodie> I am looking for an elegant solution and for a howto if there is one.
[18:56] <mpt> It's a well-known fact that velocity of spinning increases as you get more distant from the core
[18:56] <slangasek> mpt: hah
[18:56] <mpt> I'll get me coat
[18:56] <melodie> and perhaps not that much the velocity of the final product ? or do I mistake
[18:56] <melodie> ?
[18:57] <melodie> else, can a Mini Ubuntu be used for that purpose ?
[19:17] <dholbach> ivoks, congratulations! :)
[19:17] <ivoks> dholbach: yay :)
[19:22] <broder> kicked off initial quantal lintian build. first report eta: 3 days
[19:23] <broder> for bonus points, it has a patch that should prevent it throwing unknown-field-in-control original-maintainer on any package we've modified
[19:23] <broder> s/any package we've modified/all packages/, actually
[22:14] <xnox> doko: i have a solution pointer on how to check packages in *all* ongoing transitions.
[22:15] <doko> xnox, already solved for my purposes
[22:16] <xnox> doko: ok. The transition tracker repository has a trasition, collision python script which can be trivially changed to print all packages in transitions which are good/bad/unknown
[22:16] <xnox> doko: that is all.
[22:17] <doko> xnox, I was pointed to http://release.debian.org/transitions/export/packages.yaml
[22:18] <xnox> doko: ok. that works as well ;-)
[22:19] <xnox> doko: would it be useful to add a script/program to query packages in transition in the `[ubuntu-]devscripts' ?
[22:20] <doko> xnox, I don't think so. there's always nbs, which you can consult
[22:20] <xnox> doko: ok.
[22:34] <Bluefoxicy> Does Ubuntu have an option to load the CD to RAM?
[22:34] <Bluefoxicy> or even better, auto-loading of the CD to RAM if you have more than, say, 2GB of RAM
[22:35] <Bluefoxicy> hmm how would that be done
[22:35] <ogra_> no ... patches accepted :)
[22:35] <Bluefoxicy> no I mean this is actually tough I just realized
[22:36] <Bluefoxicy> because in theory the ideal situation is to start copying everything to RAM, compressed, even after boot
[22:36] <ogra_> not as tough as you might think
[22:36] <ogra_> but it would be slow since you would have to copy the squashfs from CD to a tmpfs
[22:36] <Bluefoxicy> You don't want to wait 15 minutes for the whole CD to copy the SquashFS to RAM
[22:36] <broder> cat /cdrom/casper/filesystem.squashfs >/dev/null will probably get you some percentage of the way there :)
[22:36] <Bluefoxicy> ogra_: modprobe zram
[22:37] <ogra_> how does that help the IO ?
[22:37] <Bluefoxicy> zram makes a block device in RAM that's compressed :)
[22:37] <ogra_> zram only gets you more ram
[22:37] <Bluefoxicy> see the problem is if you copy the squashfs to a tmpfs, it stays compressed BUT you can't mount it through before it's done copying
[22:37] <ogra_> i know i use it on most of the arm images by default
[22:37] <broder> copy the squashfs from CD to a tmpfs> why would you do that instead of just using buffer cache?
[22:38] <lifeless> broder: well, I had a case where that woul dhave been useful
[22:38] <Bluefoxicy> broder:  remove the CD, cache everything ahead of time, etc
[22:38] <Bluefoxicy> and, if you say ... load X
[22:38] <lifeless> broder: I was shuffling partitions around, TB of data, pushed the CDROM right out of page cache
[22:38] <Bluefoxicy> the files that are mapped in are on the CD, and you can't swap that under
[22:38] <lifeless> so every time I moved the mouse it spun up
[22:38] <broder> fair enough
[22:38] <Bluefoxicy> the next computer I build is going to have 16GB of RAM and 2 open slots ready for another 16GB
[22:38] <Bluefoxicy> a CD is 700MB
[22:39] <Bluefoxicy> this is turning into a thing
[22:39] <Bluefoxicy> It's not a bad idea to arbitrarily say, "Well, we can load the CD to RAM, if the system has [8GB] then let's eat 2/3 of a gig for that"
[22:39] <Bluefoxicy> but anyway zram
[22:40] <ogra_> what about it ?
[22:40] <Bluefoxicy> you can make an ext2 fs on /dev/zram0, mount the squashfs, and copy its contents into the zram0
[22:40] <ogra_> we have support for it in all kernels and zram-config is in the archive
[22:40] <ogra_> +8providing the upstart job to initialize it)
[22:40] <ogra_> oh, i see what you are saying, you dotn use the zram device for swapping
[22:41] <Bluefoxicy> a modified unionfs would be able to copy the underlying file being read to the zram fs automatically, while also copying the entire contents of the base fs in as a background task (say on an ioctl)
[22:41]  * ogra_ didnt get that before, sorry
[22:41] <Bluefoxicy> that way you'd be able to use the target memory-based mount point as your root device immediately, and have it remain compressed in RAM
[22:41] <Bluefoxicy> albeit, CPU intensive
[22:41] <ogra_> well, machines with 16G should hve an equally powerful CPU
[22:42] <Bluefoxicy> but you could start booting immediately, you could wait until the desktop comes up to trigger the background copy or make it a low-priority task or whatnot
[22:42] <Bluefoxicy> yeah
[22:42] <Bluefoxicy> a 16G machine might have a Core I5 or I7 with 4 cores
[22:42] <Bluefoxicy> or it might be a server with 8 or 16 cores
[22:42] <ogra_> a server would probably rather use a netinst image though
[22:42] <Bluefoxicy> anyway what got me is I realized I can spend $60 on an OCZ SATA3 SSD 60GB
[22:42] <ogra_> (which isnt live)
[22:42] <Bluefoxicy> or buy two of those
[22:42] <Bluefoxicy> and stripe them
[22:43] <Bluefoxicy> at 6Gb/s theoretical (768MB/s, a whole CD in 1 second) and a little more than half a gig per second practical, doubled by striping
[22:43] <Bluefoxicy> you could install Ubuntu in under a second
[22:43] <Bluefoxicy> ... no, you're going to be waiting for the CD to spin that whole time.
[22:43] <Bluefoxicy> so during the entire boot process, if you have ridiculous amounts of RAM, the CD could be caching everything to RAM
[22:43] <ogra_> right, as i said, on such a device a local mirror and netinst would be cleverer
[22:44] <Bluefoxicy> ogra_:  I did say an SSD costs about $60 :P
[22:44] <Bluefoxicy> home users might not have local mirror/netinst but might have some ridiculously fast system with $100 of DDR3 in it
[22:45] <ogra_> (and indeed your argument stands and falls with the existance of a server livecd install :) )
[22:45] <ogra_> (which doesnt exist yet)
[22:45] <Bluefoxicy> well
[22:45] <Bluefoxicy> I'm talking about desktops
[22:47] <Bluefoxicy> I mean like
[22:47] <Bluefoxicy> http://www.amazon.com/Corsair-Vengeance-1600MHz-Memory-CMZ16GX3M2A1600C10/dp/B006EWUO22/
[22:48] <Bluefoxicy> http://www.amazon.com/gp/product/B004Z0S6RU/
[22:48] <Bluefoxicy> $120 + $70
[22:48] <Bluefoxicy> that's going to turn into "Common use case" :P
[22:48] <lifeless> Bluefoxicy: you can install Ubuntu extremely fast by mounting the iso over NFS w/netboot.
[22:48] <Bluefoxicy> lifeless:  if you have a second PC up yeah.
[22:48] <lifeless> Bluefoxicy: and syslinux's netboot mode.
[22:49] <lifeless> Bluefoxicy: there are some very very small PC's around these days... like android tablets ;)
[23:22] <stgraber> balloons: ping
[23:22] <stgraber> balloons: you've a session in grand ballroom a
[23:22] <stgraber> balloons: https://blueprints.launchpad.net/ubuntu/+spec/qa-q-iso-testing-process