[00:00] <kklimonda> manjo: it's pretty easy to change that
[00:01] <manjo> kklimonda, yeah edit files ..
[00:20] <penguin42> kklimonda: Careful, I've just noticed there are host specific peripheral settings in gconf
[00:21] <penguin42> (although bizarely the only thing under periphers->keyboard->host-major is the default seetting of numlock)
[00:29] <kklimonda> penguin42: but they should still work after hostname is changed.
[00:29] <penguin42> kklimonda: I just wonder what other settings are actually keyed off hostname
[00:30] <kklimonda> penguin42: It's not really a good idea to do that.
[00:30] <kklimonda> penguin42: if any application uses host in its settings then bug report should be filled imo
[00:30] <penguin42> kklimonda: It is in an envrionment with a networked home directory; you want peripheral config to be local to where you are logged in
[00:31] <kklimonda> penguin42: then they should be stored somewhere local imo
[00:31] <penguin42> admittedly those environments are rarer these days
[00:32] <kklimonda> penguin42: and in those environments you don't use a shiny graphical installer anyway.
[00:32] <penguin42> probably true
[01:29] <penguin42> can someone with a vague knowledge of gnome eyeball some code in mango-lassi for me - it looks broken to me, I just can't understand why it only segs on one of two machines
[03:32] <JakeTripplJ> hay
[07:36] <Kano> hi cjwatson
[07:42] <Kano> i would suggest executing dpkg-reconfigure -phigh console-setup in casper after setting the locale
[07:43] <Kano> and when you use your installer then too
[07:43] <Kano> otherwise the console font is incorrect for the locale
[07:43] <Kano> then you can not see umlauts for example when you boot with german settings live
[09:55] <mvo> doko: do you mind if I upload a python-central crash fix? or do you want to review first (is there a vcs to use?)
[09:56] <doko> mvo: no, please go ahead
[09:59] <mvo> thanks doko
[10:23] <cjwatson> kenvandine: libdbusmenu_0.3.13-0ubuntu1.dsc extracts fine for me.  can you help me get a test case so that I can understand your problem?
[10:23] <cjwatson> mneptok: btrfs /boot> no, held up on licensing
[10:25] <cjwatson> kenvandine: hm, well, somebody seems to have solved the problem since there's a libdbusmenu_0.3.13-0ubuntu1.dsc in the archive now
[10:29] <seb128> cjwatson, I think he remade the tarball
[10:30] <seb128> the one on https://edge.launchpad.net/dbusmenu/+download didn't work for him
[10:38] <cjwatson> ok
[11:09] <seb128> cjwatson, do you know how the ddeb service works?
[11:09] <seb128> ie where the collector is running?
[11:12] <cjwatson> not really
[11:12] <seb128> I think I figured it out
[11:12] <seb128> the service seems stucked since yesterday, could be due to the launchpad downtime
[11:12] <seb128> I will just restart it and see
[11:16] <cjwatson> enrico: it looks like apt-xapian-index 0.39 was never released.  should I just append my change to the 0.39 changelog, and mark it UNRELEASED in git?
[11:22] <mvo> cjwatson: I just commited the "apt-cdrom looks into .disk for calculating the ident string" change, do we need to worry about backward comatibility? I guess not as it was never really working with usb-sticks anyway?
[11:30] <cjwatson> mvo: can you point me at the commit and I'll have a look?
[11:31]  * Daviey screams.
[11:31] <Daviey> .. and sobs
[11:36]  * hyperair gives Daviey a strange look
[11:37]  * soren pats Daviey on the head
[11:37]  * davmor2 passes Daviey a cookie and tells him to eat it, life will be better afterwards
[11:38] <Daviey> \o/
[11:38] <soren> That's more like it.
[11:38] <davmor2> Daviey: now get back to work and fix that issue :P
[11:39] <Daviey> yes sir!
[11:39] <cjwatson> enrico: (I'm ready to commit a fix for the xapian api change as well, once I know the answer to that question :-) )
[12:13] <tkamppeter> mdz, hi
[12:14] <Kano> cjwatson: did you get my notice about the wrong fonts in console
[12:28] <mdz> tkamppeter: hi
[12:31] <mvo> cjwatson: here is the commit http://bazaar.launchpad.net/~ubuntu-core-dev/apt/ubuntu/revision/1796 (sorry for the delay, I was at lunch)
[12:31] <cjwatson> damn you for EATING
[12:31] <cjwatson> hm, is access() a reliable test for that then?
[12:33] <tkamppeter> mdz, it is about bug 633987.
[12:33] <mdz> tkamppeter: yes, I answered your question in the bug. did you and mvo talk further about it yesterday?
[12:33] <mvo> cjwatson: I'm not 100% sure, but in my tests it seems to be ok
[12:33] <mdz> tkamppeter: there were a few other people on IRC yesterday who confirmed the bug
[12:33] <mvo> mdz: no, sorry. but s-c/aptdaemon are uploaded now, so I have breathing space again for this
[12:34] <cjwatson> access("/mnt", W_OK)                    = -1 EROFS (Read-only file system)
[12:34] <cjwatson> apparently so.  neat
[12:34] <tkamppeter> mdz, I do not really understand why the update is not working for you. It probably works for many users as I did not get any duplicate.
[12:34] <cjwatson> mvo: you might want to e-mail the debian-live folks and ask, but given that it basically always breaks at the moment I think it should be OK
[12:34] <mvo> cjwatson: I tried with usb-stick (both rw,ro) and cdrom and got the answers I was expecting
[12:34] <mvo> cjwatson: good idea, I will do that
[12:34] <mdz> tkamppeter: mvo is our resident expert on this type of issue
[12:35] <tkamppeter> mdz, I can try to replace the Conflicts: by Breaks:, but this is simply a guess.
[12:35] <mvo> tkamppeter: give me some minutes, I will try to reproduce the setup that mdz has
[12:35] <tkamppeter> mvo, what exactly is the difference between Conflicts: and Breaks:?
[12:36] <cjwatson> enrico: looking at the history, I guess you don't normally use UNRELEASED, so I'll go ahead and put these changes in 0.39
[12:36] <mvo> tkamppeter: internally they are handled similar, but for breaks apt will try a little bit harder to upgrade the package before it gets moved to the remove-list
[12:36] <cjwatson> tkamppeter: the policy manual documents this clearly
[12:37] <cjwatson> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks
[12:37] <cjwatson> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
[12:37] <cjwatson> the latter has specific instructions for when each field should be used
[12:38] <Kano> cjwatson: did you fix the iso build tool to get hybrid iso images
[12:43] <tkamppeter> cjwatson, thanks.
[12:56] <penguin42> is launchpad broke at the moment? #launchpad seems pretty dead and I'm having problems reporting an oops with a 'sorry, there was a problem connecting to the launchpad server.' and a guy I was helping last night had the same problems
[12:59] <mvo> cjwatson: I updated the diff yet again (noticed another bit that needed fixing) and mailed debian-live. I guess its best to wait for feedback from debian-live before uploading so that the ident id does not change/become incompatible if we decide to change the code again. what do you think?
[13:00] <mvo> mdz: could you mail me a tarfile with /var/lib/dpkg/status and /var/lib/apt/lists please ?  I will dig into it then
[13:05] <cjwatson> mvo: seems reasonabe
[13:05] <cjwatson> +l
[13:05] <mvo> cool, thanks
[13:11] <mvo> mdz: nevermind, I can reproduce it here now
[13:14] <cjwatson> enrico: I've uploaded 0.39, and will sync that into Ubuntu
[13:15] <mvo> tkamppeter, cjwatson: the eaisest fix for the foomatic-db problem is to make foomatic-db a lower priority then foomatic-db-compressed. so swtichting foomatic-db to "Priority: extra" should do it. I belive this needs to be done by a archive-admin
[13:18] <enrico> cjwatson: excellent, thanks! (just came online, I was at a customer)
[13:21] <apparle_> Suggest a cross platform IDE,..... I know about eclipse and netbeans... tell me which is good or other if you know any other
[13:21] <cjwatson> mvo,tkamppeter: I've set the priority of foomatic-db to extra, as well as foomatic-db-engine
[13:22] <mvo> thanks cjwatson
[13:22]  * mvo updates the bug
[13:27] <mvo> cjwatson:  and thanks for the xapian fix for software-center :)
[13:29] <tkamppeter> mvo, thanks. So you have uploaded foomatic-db_20100906-0ubuntu2 now?
[13:30] <tkamppeter> s/mvo/cjwatson/ ^^^
[13:31] <mdz> tkamppeter: I think cjwatson meant that he changed the priority of -0ubuntu1
[13:32] <tkamppeter> mdz, where are these priorities set? How can I set them if I encounter a similar problem in the future?
[13:33] <mdz> tkamppeter: they are set centrally by archive administrators; it requires special privileges
[13:35] <tkamppeter> mdz, mvo, cjwatson, looks a little like a workaround for a shortcoming (bug?) in apt for me. In this case foomatic-db-compressed-ppds should get priority against foomatic-db as it solves the dependencies of the new ubuntu-desktop and so no artificial prioritizing is needed.
[13:38] <cjwatson> maybe so, but in this matter I bow to mvo's expertise :)
[13:38] <cjwatson> and yes, mdz is correct
[13:38] <mdz> tkamppeter: yes, I'm inclined to agree that it's a workaround, but we're not likely to try to fix this in apt for 10.10 ;-)
[13:40] <tkamppeter> mvo, mdz, cjwatson, are these package priorities somewhere visible in Launchpad?
[13:41] <mvo_> tkamppeter: it is, the resolver is not always the most smartest in the world. fortunately its very predictable. I look into a solution in code next, but for mav we can not really change the resolver anymore
[13:41] <mvo_> (too risky)
[13:41] <mdz> tkamppeter: yes
[13:42] <mdz> tkamppeter: though the easiest way to see them is to use apt-cache
[13:43] <mdz> mizar:[~] apt-cache show foomatic-db | grep Priority
[13:43] <mdz> Priority: optional
[13:43] <cjwatson> the top three priorities (required, important, standard) matter to varying degrees and are managed semi-automatically, but mostly we don't bother much with the distinction between optional and extra in Ubuntu
[13:43] <cjwatson> it's just useful to resolve occasional bugs like this one
[13:44] <tkamppeter> mdz, I have done
[13:45] <tkamppeter> sudo apt-get update
[13:45]  * cjwatson wonders how sudo got to be Priority: optional, and fixes it back to important
[13:45] <cjwatson> tkamppeter: it's not instant, you need to wait until the next publisher run.  give it an hour
[13:45] <tkamppeter> now and checked the priorities, both foomatic-db-compressed-ppds and foomatic-db have "optional".
[13:46] <tkamppeter> cjwatson, OK.
[13:46] <cjwatson> an hour> assuming you're using a mirror that's pushed fairly quickly that is
[13:46] <tkamppeter> cjwatson, mvo, mdz, thank you very much for the help on this.
[13:47] <tkamppeter> cjwatson, I am using the German mirror.
[13:58] <tjaalton> tkamppeter: hi, me again. trying to work around bug 612578 I tried to forward-port cups from jaunty, but the build fails http://pastebin.com/aMeWijTY
[13:58] <tjaalton> tkamppeter: ideas what makes it fail?
[14:29] <Laney> please can someone look at sponsoring the tar sru in bug 539814
[14:42] <rhlee> hi guys is this the right channel for packaging help?
[14:45] <penguin42> rhlee: There is a #ubuntu-packaging
[14:46] <rhlee> penguin42: cheers mate
[15:03] <bilalakhtar> tedg: hey! So is there any other problem with my merge(s) ?
[15:05] <bilalakhtar> tedg: Thanks for the comment on the bug, I'll be off now
[15:05] <tedg> bilalakhtar, No problems other than we need to figure out the symbolic/color part
[15:06] <tedg> Uhg, the IRC equivalent of starting a conversation as you're jumping out of the plane.
[15:07] <seb128> lol
[15:11] <smoser> cjwatson, around and have some time to talk about grub and that annoying ec2 ?
[15:12] <penguin42> anyone finding alt-sysrq-b is being ignored? s and u are both working but B is doing nothing
[15:16] <tkamppeter> mvo_, cjwatson, mdz, on my mirror priorities have changed to extra for foomatic-db and optional for foomatic-db-compressed-ppds. Is this OK? Can you try?
[15:17] <cjwatson> tkamppeter: please remove me from the list of people you're asking; all I did was the archive-side change
[15:17] <cjwatson> smoser: let me read through it all again; I'm having real trouble cramming all this into my head
[15:18] <smoser> cjwatson, ok. i've got a bout 45 minutes, then i need to be afk for 30.
[15:18] <smoser> so whichever hunk works better for you.
[15:20] <cjwatson> smoser: is there some way that I can try this out personally?  I'm never going to really understand it otherwise
[15:20] <cjwatson> both on EC2 and UEC
[15:20] <cjwatson> nb: must not involve having to set up a cloud in my house :)
[15:20] <smoser> cjwatson, i can get you an instance on ec2 easy.
[15:21] <smoser> euca is more difficult, but in general, euca almost "just works"
[15:21] <smoser> the only issue with it is that i'd like to be able to tell grub "don't worry about installing the bootloader anywhere"
[15:21] <cjwatson> can I please not have pre-specified solutions
[15:21] <cjwatson> I want to inspect the problem :)
[15:22] <smoser> comon.
[15:22] <smoser> ok. i'll get you an ec2 instance, and will work on getting you access to a uec also.
[15:23] <cjwatson> I mean, you *can* tell grub-pc.postinst not to install the bootloader anywhere, and I know this because d-i does it
[15:23] <cjwatson> but I'm not clear yet whether this is quite the right thing
[15:23] <cjwatson> in particular creating core.img is considered part of installing the bootloader
[15:23] <cjwatson> from grub-pc.postinst's point of view
[15:23] <cjwatson> (yes, within grub-install they're two separate steps)
[15:25]  * penguin42 is just testing afix for the lshw hang - I can see why it oops's, I just can't see why lshw manages to trigger it
[15:26] <smoser> cjwatson, ok, you can ssh to ec2-75-101-239-180.compute-1.amazonaws.com
[15:27] <smoser> and that system is "all yours" until you tell me to kill it. if you shut it down (/sbin/halt, it will go away).
[15:27] <smoser> your ssh keys from launchpad are installed on that host
[15:39] <cjwatson> smoser: so, if /dev/sda1 is really a disk image, then I wonder if it really makes sense for GRUB to regard it as a partition
[15:39] <cjwatson> (aside from whatever Xen is doing)
[15:39] <cjwatson> maybe we should go "huh, weird Xen thing, treat it as a disk"
[15:39] <smoser> grub should not regard it as a partition.
[15:40] <smoser> it is a disk for all purposes , just with a funny name.
[15:40] <cjwatson> right, good.  it's not as if there's any particular relationship between /dev/sda1 and /dev/sda2 here
[15:40] <smoser> note, also, that this disk is funny in that it has no partition table.
[15:40] <cjwatson> GRUB will be OK withthat
[15:40] <EdwinGrubbs> kees: ping
[15:40] <mdz> tkamppeter: confirmed, it works now
[15:42] <smoser> i poked trhough some of grub source, and hacked at trying to convince it that was a full disk.  my hack was to check if this 'name' existed in /sys/block, then it was a disk, not a partition.
[15:47] <lool> doko: Is i686 without cmov supposed to be supported in maverick or not?
[15:48] <lool> LP #632232
[15:51] <tkamppeter> mdz, OK. Thanks. I will close the bug then.
[15:52] <cjwatson> smoser: I'm thinking of instead simply observing that if the partition device exists but the disk device does not, then we might as well treat it as a disk since what else can we do?
[15:52] <barry> james_w: ping
[15:52] <james_w> hi barry
[15:53] <barry> james_w: hi.  have a few minutes to talk about a udd issue?
[15:53] <smoser> yeah. i can't imagine other scenarios where that would fail.
[15:53] <james_w> barry: of course
[15:54] <barry> james_w: cool.  so i'm working on an update to the gtimelog package.  it's been basically abandoned and i have upstream commit privs now.  marius released 0.4.0 and i'm redoing the packaging to more modern standards...
[15:55] <barry> james_w: upstream trunk is in bzr on lp.  so i 'bzr branch trunk packaging' and create a loom, add a thread for the debianization work...
[15:55] <barry> james_w: convert the patches i need (and the still relevant ones from the old packaging) to quilt, commit all that and 'bzr bd -S'
[15:55] <barry> james_w: but i get a lintian warning: patch-system-but-direct-changes-in-diff
[15:56] <ev> might I ask that anyone with a free moment run `sudo dmidecode` on their machine and pastebin me the output?  Thanks!
[15:56] <james_w> barry: what's an lsdiff -z of the .diff.gz say?
[15:56] <barry> james_w: now, the reason for that is that the trunk has moved a little bit from the released tgz.  it's got a bit of extra NEWS.txt and a version bump in the __init__.py
[15:56] <james_w> ah
[15:56] <barry> james_w: i can certainly ignore that, but i guess i'm looking for recommendations on how to handle this scenario in general
[15:57] <barry> (ignore the lintian warning)
[15:57] <james_w> then base your packaging on the revision corresponding to the tarball if available
[15:58] <barry> james_w: right, that's the direction i was thinking about, but my question is: what happens when a new version is released from trunk?  what will be the best way to take my existing packaging loom and update it?  just pull from trunk with a revision# or tag to the bottom thread?
[15:58] <james_w> barry: yeah
[15:58] <james_w> barry: it would be great if we could get the pristine-tar data in there too
[15:59] <barry> james_w: hmm, how could that be done?
[15:59] <james_w> if you can use bzr import-upstream/merge-upstream at some point
[16:01] <barry> james_w: yeah.  i think the scenario where the upstream is in bzr on lp is a weird corner case that actually makes things a little more difficult in several ways.  e.g. lp:ubuntu/gtimelog has no relationship to lp:gtimelog
[16:01] <james_w> barry: yeah, but e.g. the dx team have that, and we linked the branches
[16:02] <barry> james_w: ah, didn't know that could be done.  is that a manual request?
[16:02] <james_w> barry: it's something you can do yourself
[16:03] <barry> james_w: i'm probably just being dense.  it's obvious?
[16:04] <james_w> barry: you pass an upstream branch and revision to merge-upstream
[16:04] <barry> james_w: gotcha
[16:05] <barry> james_w: cool, thanks.  as always very helpful.  i'll work this out and see if i can write something up on the wiki
[16:05] <james_w> great, thanks
[16:05] <james_w> let me know if you have any trouble
[16:07] <barry> james_w: will do, thanks again
[16:11] <doko> lool: no
[16:23] <lool> doko: thanks
[16:23] <doko> there should be an email
[16:27] <Randall> Hey guys
[16:27] <Randall> rmemeber me?
[16:27] <brewmster> Randall: no.
[16:28] <Randall> Genesis 2
[16:28] <Randall> 1Thus the heavens and the earth were finished, and all the host of them.
[16:28] <Randall>  2And on the seventh day God ended his work which he had made; and he rested on the seventh day from all his work which he had made.
[16:28] <jY> i do.. you're the asshole
[16:28] <Randall> 3And God blessed the seventh day, and sanctified it: because that in it he had rested from all his work which God created and made.
[16:28] <Randall> 4These are the generations of the heavens and of the earth when they were created, in the day that the LORD God made the earth and the heavens,
[16:28] <Randall> 5And every plant of the field before it was in the earth, and every herb of the field before it grew: for the LORD God had not caused it to rain upon the earth, and there was not a man to till the ground.
[16:28] <Randall>  6But there went up a mist from the earth, and watered the whole face of the ground.
[16:29] <Randall> 7And the LORD God formed man of the dust of the ground, and breathed into his nostrils the breath of life; and man became a living soul.
[16:29] <Randall> 8And the LORD God planted a garden eastward in Eden; and there he put the man whom he had formed.
[16:29] <Randall>  9And out of the ground made the LORD God to grow every tree that is pleasant to the sight, and good for food; the tree of life also in the midst of the garden, and the tree of knowledge of good and evil.
[16:29] <Randall> 10And a river went out of Eden to water the garden; and from thence it was parted, and became into four heads.
[16:29] <Randall> 11The name of the first is Pison: that is it which compasseth the whole land of Havilah, where there is gold;
[16:29] <Randall>  12And the gold of that land is good: there is bdellium and the onyx stone.
[16:29] <Randall> 13And the name of the second river is Gihon: the same is it that compasseth the whole land of Ethiopia.
[16:29] <Randall>  14And the name of the third river is Hiddekel: that is it which goeth toward the east of Assyria. And the fourth river is Euphrates.
[16:29] <Randall> 15And the LORD God took the man, and put him into the garden of Eden to dress it and to keep it.
[16:29] <fagan> nice
[16:30] <jY> what a troll
[16:30]  * penguin42 can't imagine he would be good with daemons
[16:30] <brewmster> was i the only one reading that?
[16:30] <penguin42> brewmster: Yes
[16:31] <brewmster> i think he might be a slow adult
[16:32] <cjwatson> there is no need to cause further noise by discussing it further.,
[16:32] <cjwatson> particularly since I can see for myself that the two people who responded to Randall most quickly joined the channel immediately before him and haven't been here before ...
[16:33] <brewmster> cjwatson: there is no need to cause further noise by discussing it further.,
[16:34]  * jdong takes a pass through the SRU queue
[16:41] <jdong> Is LP behaving funky? https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text= has two identical looking php5 packages
[16:42] <cjwatson> jdong: that's permitted in queues
[16:42] <cjwatson> only one of them gets to be accepted, of course
[16:42] <jdong> cjwatson: oh, interesting; didn't know that
[16:42] <cjwatson> check that they have the same content?
[16:43] <kees> EdwinGrubbs: hola!
[16:44] <jdong> yep, the diffs look the same
[16:46] <EdwinGrubbs> kees: hi, Launchpad is discussing whether to switch to the apport (problem_report) format for its oops tool, which puts the python traceback, cgi variables, sql query times, etc. for a single failed request in one file.
[16:47] <EdwinGrubbs> kees: there are certain limitations to the apport format, and I wonder whether we would be better served by wrapping problem_report, pushing changes upstream, or just using another format.
[16:48] <EdwinGrubbs> kees: I haven't seen pitti in IRC. Who all would be good to CC our oops tool discussion?
[16:51] <EdwinGrubbs> one issue I see with problem_report is that it only really supports parsing a single level of field names and values, so parsing a complex value is nonstandard.  The other is that it doesn't seem to let you set the content-type for a file attachment.
[16:55] <kees> EdwinGrubbs: I think extending apport would be great.
[16:55] <kees> EdwinGrubbs: pitti is very responsive to patches. you could email ubuntu-devel and CC him, maybe
[16:56] <EdwinGrubbs> kees: ok, thanks, I'll do that.
[16:57] <kees> EdwinGrubbs: okay, cool.
[17:12] <achiang> EdwinGrubbs: pitti is on holiday currently
[17:15] <EdwinGrubbs> achiang: thanks for the info
[17:15] <achiang> sure
[18:03] <kees> hm, is umask anywhere in /proc for a process? doesn't seem to be.
[18:38] <superm1> cjwatson, this might be in the realm of 32-bit is undefined, but from my experiments of throwing the 64 bit grub efi on a 32 bit CD and making it multi-catalog, it looks like the 32-bit kernel doesn't load with efi, missing /sys/firmware/efi and all the accompanied dmesg listings about memory mapping with EFI
[18:47] <Chipaca> looks like I need python-gconf-dbg and it isn't built. Is that a bug, or am I missing something?
[18:48] <cjwatson> superm1: I looked into the kernel a bit.  It refuses to load EFI unless the boot loader signature passed to it says EL32 (for a 32-bit kernel) or EL64 (for a 64-bit kernel); grub's x86_64-efi build passes EL64
[18:48] <cjwatson> superm1: but that is not the worst problem
[18:49] <cjwatson> superm1: the EFI runtime services calls are just function pointers.  If you have a 64-bit EFI implementation, those functions are very likely to contain 64-bit code.  You can't call them from a 32-bit kernel
[18:49] <superm1> cjwatson, oh yikes- yeah that could be quite troublesome then
[18:49] <cjwatson> I don't see any way we can cope with this
[18:50] <cjwatson> if you have 64-bit EFI and want to boot a kernel in EFI mode, as far as I can see it has to be a 64-bit kernel and that's really all there is to it
[18:51] <cjwatson> so we'll need to be addressing whatever problems you have that make that difficult
[18:53] <cjwatson> indeed I just checked the UEFI spec and it requires this
[18:53] <cjwatson> "For an operating system to use any UEFI runtime services, it must:
[18:54] <cjwatson> [be] In long mode, in 64-bit mode
[18:54] <cjwatson> "
[18:54] <cjwatson> that's in the "x64 Platforms" section, 2.3.4
[18:54] <superm1> OK, i'll take that back to my team and see what we can come up with.
[19:02] <mneptok> cjwatson: thanks for the reply. i answered my own question with a VM yesterday.
[19:04] <mneptok> cjwatson: your late reply meant i could not be lazy, which creates a very interesting Slacker Feedback Loop. ;)
[19:45] <nemo> Does ubuntu have any way to extract an update priority in a similar fashion to Mint's update manager w/ its colour and number coding?  Even a commandline thing would be fine
[19:46] <nemo> I'd just like to know if that is a capability it has
[19:59] <sladen> nemo: I think it's on the list.  Eg. IIRC the colour was from some fairly simple heuristics (eg. is a core library)
[20:01] <nemo> sladen: oh...
[20:01] <nemo> sladen: I thought they were doing it based on "is this an exploit fix"
[20:01] <nemo> versus "is this a stability only issue" or "is an enhancement"
[20:02] <nemo> sladen: 'cause really, that's what our admins want to know - is this something crucial that has to be applied to the server right away
[20:02] <nemo> (and w/o reading each description to find them)
[20:02] <sladen> nemo: if it's post-release, it's a security fix.  If it's pre-release it's a bug-fix enhancement
[20:03] <sladen> bug-fix or enhancement
[20:03] <Chipzz> nemo: if your admins are blindly applyin security updates, I would have my concerns about their skills...
[20:05] <nemo> Chipzz: well, these are windows admins, so I don't know their minds
[20:05] <nemo> but my instinct is their thought process is "we should update as little as possible on running servers, unless there is a security issue"
[20:05] <nemo> but, sounds like what sladen is saying is all post-release updates should be considered security issues and thus must be applied.
[20:06] <nemo> odd, I'd swear I've seen post-release updates that wouldn't really fit that
[20:06] <Chipzz> sladen: you're ignoring SRU's
[20:06] <sladen> nemo: https://wiki.ubuntu.com/StableReleaseUpdates
[20:07] <nemo> sladen: heh. "Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel). "
[20:08] <nemo> sladen: but anyway, sounds like you're saying the only method to differentiate right now is read the description and linked LP and use your judgement
[20:09] <sladen> nemo: or get them to sign up to  http://www.ubuntu.com/usn
[20:10] <cjwatson> nemo: all security updates will come from RELEASE-security rather than RELEASE-updates
[20:10] <cjwatson> visible in apt-cache policy output, among others
[20:10] <nemo> cjwatson: thanks
[23:48] <YokoZar> what's the name of the program that pops the broadcast accounts dialog