[00:10] <nigelbabu> lool: ping
[00:11] <nigelbabu> whats your take on bug 525512?
[00:18] <hyperair> bah ccache generates a different hash each time.
[00:20] <hdon> hi all. what jaunty package supplies gnome-desktop-2.0?
[00:20] <hdon> and is there a way to search for filenames in packages not installed?
[00:21] <RAOF> hdon: apt-file
[00:21] <hdon> RADF: thanks i'll try it
[00:41] <LinuxGuy2009> Ok I would like to get back into programming again.I havent really programmed anything since my high school days, I'm 30 years old. I know QBasic and Visual Basic. Is there any development environment or language that can get me up and running and making apps as easy as visualbasic used to do for me?
[00:43] <directhex> vb6 or vb.net?
[00:44] <RAOF> LinuxGuy2009: Python is excellent at getting up and running quickly; it lacks an awesome IDE (mainly because IDEs are hard to write for dynamic languages).
[00:46] <directhex> RAOF, surely gambas for someone who mostly knows vb/
[00:46] <directhex> ?
[00:46] <LinuxGuy2009> RAOF: Ok. I did find a bunch of python tutorial videos that got me started with python. I didn't know where to go to make an app that runs in an actual window instead of just a basic CLI app. Any tips?
[00:47] <LinuxGuy2009> gambas pretty good to use?
[00:47] <directhex> gambas is a sort of "inspired by vb6" affair. i've never used it in anger, but some people swear by it
[00:48] <RAOF> directhex: I've never used or looked at gambas, so I can't offer a useful comment.
[00:49] <RAOF> LinuxGuy2009: The pygtk tutorials are reasonable; they show how to build a gui app with GTK+
[00:50] <directhex> or there's MD. no gui designer for vb.net in it, but c# is a reasonable route from vb knowledge. ish.
[00:50] <jdong> LinuxGuy2009: also consider PyQT and the QT4 toolkit, in my opinion it's easier to understand coming from a Windows Forms perspective.
[00:50] <LinuxGuy2009> directhex: I want to really make a cd ripper app that combines all the best features of apps already out there. Think gambas could allow me to do this?
[00:51] <jdong> LinuxGuy2009: I'd personally recommend using either Python or Mono/C#
[00:51] <directhex> LinuxGuy2009, with enough effort, anything can
[00:51] <LinuxGuy2009> ok cool
[00:51] <LinuxGuy2009> Ill just try to find some good documentation and go from there I suppose.
[00:51] <directhex> LinuxGuy2009, my weapon of choice is c#, but everyone's tastes are different. python is very popular in ubuntuland, but as noted, there's no gui designer
[00:51] <directhex> well. integrated one
[00:52] <LinuxGuy2009> right
[00:52] <directhex> you can use a gui designer tool like glade, then hook the gui design file into your code by hand
[00:52] <LinuxGuy2009> that sounds complicated.
[00:52] <jdong> yeah and QT has similar tools as well, slightly more streamlined IMO
[00:52] <jdong> LinuxGuy2009: not complicated at all, actually....
[00:52] <LinuxGuy2009> hmm ok
[00:53] <jdong> LinuxGuy2009: you basically use a form designer just like your VB designer and save a form.xml
[00:53] <LinuxGuy2009> Ill add glade to my tools to learn
[00:53] <LinuxGuy2009> Oh thats easy enough.
[00:53] <jdong> LinuxGuy2009: and then you just call some load("form.xml") and then you can start referring to Button1 on the form and so on
[00:53] <LinuxGuy2009> Oh nice thats what Im after
[00:53] <jdong> yeah
[00:53] <LinuxGuy2009> Ok ill stick with python.
[00:54] <jdong> it also separates UI code from UI design (data) which is nice.
[00:54] <LinuxGuy2009> cool
[00:54] <jdong> LinuxGuy2009: if you're using Python, look at both GTKBuilder/Glade (GTK) and the PyQT4 equivalent feature....
[00:54] <jdong> you might find you like one toolkit over the other
[00:55] <LinuxGuy2009> ok good tips
[00:55] <jdong> I feel QT4's API is a bit more "modern" and shiny than GTK, but again, everyone has his opinions
[00:55] <jdong> LinuxGuy2009: there's also a great book on Python and PyQt4, http://www.qtrac.eu/pyqtbook.html
[00:56] <LinuxGuy2009> yeah that was my next question.
[00:56] <jdong> I've skimmed that book before and found it really nice
[00:56] <jdong> you can start from it with zero knowledge of python or QT4
[00:56] <jdong> and quickly become productive
[00:57] <LinuxGuy2009> nice
[00:57] <jdong> and as you go deeper into the book even advanced QT4 users learn something new
[00:57] <jdong> if you don't like buying books, I'm sure you can orient yourself with online tutorials for either GTK or QT (I tend to do that), but books tend to be a lot more coherently organized
[00:57] <LinuxGuy2009> I guess I would really benefit from a few good books.
[00:58] <directhex> i always like a good book
[00:58] <LinuxGuy2009> yeah
[00:58] <directhex> sadly they're in short supply for c# on linux
[00:59] <jdong> directhex: agreed :( but I do respect GTK# a lot for how much they "cleaned up *puts on flamesuit*" GTK's API
[00:59] <LinuxGuy2009> C looks pretty intimidating to me.
[00:59] <jdong> LinuxGuy2009: C would definitely not be my recommendation to someone from a VB background trying to write his first Linux GUI app :)
[00:59] <LinuxGuy2009> ok thats comforting
[00:59] <directhex> LinuxGuy2009: C would definitely not be my recommendation to someone from any background  trying to write any  Linux GUI app :)
[01:00] <hdon> hi all. anyone know how to add gnome panel applets installed in /usr/local to the bonobo activation path?
[01:01] <LinuxGuy2009> Ok so i think my plan is to start with python and make basic apps like i did with VB back in the day. Build a GUI calculator etc. With python and glade. Then Ill just build as I go.
[01:01] <LinuxGuy2009> Thanks a bunch guys!
[01:02] <Aquina> Blinken ,Umbrello and Smb4K (among other applications) depend on kdesktop and it's packages. These apps also depend on Qt3/4. Is it common to remove the whole KDE-Desktop stuff and though run dozens of applications which use Qt or should I *finally* switch over to GTK+?
[01:02] <Aquina> I mean from a performance and DRY point of view.
[01:28] <ScottK> Aquina: umbrello is a KDE app, so I don't understand what you are trying to do?
[03:05] <hyperair> i finally solved my sbuild+ccache problem!
[03:05] <hyperair> well at least, i know what's going on now
[03:05] <lifeless> ...
[03:05] <hyperair> http://paste.debian.net/72238/
[03:05] <hyperair> that took me all of two days, i think
[03:06] <lifeless> ouch
[03:06] <hyperair> well, the first day was without patching ccache
[03:06] <hyperair> the second day involved sticking printfs everywhere in ccache
[03:07] <hyperair> and finally, removing the unlink
[03:07] <hyperair> hmm
[06:40] <dholbach> good morning
[06:41] <dholbach> Development and MOTU Q&A Session in #ubuntu-classroom in 20m
[06:51] <maco> ccheney: do OOo patches get forwarded to OOo-proper or Go-OOo?
[06:51] <ccheney> maco: ubuntu patches are located in go-oo git tree
[06:52] <ccheney> maco: for patches that are useful to upstream generally they are attached to related bug reports in official OOo issue tracker
[06:52] <maco> ok
[06:52] <ccheney> maco: they require copyright assignment though so for anything more than trivial fixes you probably have to do that first to get into official OOo
[06:53] <maco> ccheney: https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/512395
[06:54] <ScottK> maco: I've avoided copyright assignment requirements in the past by describing in words what the patch has to do to make it trivial to create one, but not actually provide it.
[06:54] <ccheney> maco: yea i need to apply that to ubuntu version, that particular patch isn't even in go-oo (one of the only ones like that)
[06:55] <maco> ccheney: but it should end up in go-oo or ooo at some point too right? not just stay in ubuntu?
[06:55] <ccheney> maco: well it is adding just: +X-Ubuntu-Gettext-Domain=ooo-build
[06:55] <ccheney> so i think that is sorta Ubuntu specific
[06:55]  * maco re-reads
[06:55] <maco> oh hey the word ubuntu is in there
[06:56] <ccheney> i thought this was something specific to just our use of rosetta but maybe i misremember
[06:56] <persia> That is Ubuntu-specific.
[06:56] <persia> (and yes, related to rosetta)
[06:56] <maco> yes i just fail at reading
[06:57] <maco> i thought it was X-Gettext-Domain
[06:57] <ccheney> maco: the rest of the patch is Ubuntu specific as well, so i will be adding that, it just wasn't high priority in the past since we don't use rosetta in OOo atm
[06:57] <maco> and this is why i shouldnt try to review patches after midnight!
[06:58] <ccheney> if anyone that is familar enough with rosetta wants to help fix OOo's bugs relating to that i would welcome it, i think i will probably be very short on time to fix it for maverick :-\
[07:01]  * ccheney headed off to bed now, bbl
[08:00] <persia> it's Patch Day!  Anyone with time to help review patches, please come to #ubuntu-reviews and join in!
[08:19] <tkamppeter> Anyone around who knows about upstart?
[08:35] <anon^_^> Had a question. Is there a good possibility that this bug will be fixed in 10.04?
[08:35] <anon^_^> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/563878
[08:36] <gord> anon^_^, depends if the ati graphics driver starts supporting kms
[08:36] <anon^_^> You can just barely make out the pass field if you need to enter it
[08:36] <anon^_^> it affects both ati and nvidia
[08:37] <anon^_^> after you install a proprietary driver the boot screen changes from native res to 640x480
[08:37] <persia> anon^_^: I suspect the chances are low, as it doesn't meet the criteria for a normal Stable Release Update: it's more likely to be fixed in maverick.
[08:38] <ogra> and its nothing that can be fixed in ubuntu, its up to the driver manufacturers
[08:38] <persia> The issue isn't that the driver ir proprietary, it's that it only provides a 640x480 framebuffer before X starts.
[08:38] <persia> ogra: We could provide a special alternate image, but that's really just hiding the issue.
[08:40] <anon^_^> wish i had a camera around, text is all over when you run LUKS and you're required to enter a passphrase to unlock partitions
[08:40] <persia> anon^_^: You might be able to avoid that by using the text theme.
[08:41] <anon^_^> i was hoping not to :x
[08:42] <anon^_^> the new bootsplash is purty, or it was..
[08:45] <persia> The issue is the balance of risk and benefit.  I'm not a person who makes those decisions, but since it's installed for *everyone*, it's hard to know that someone else's system won't break if different graphics are added.  See comment #5 for the rationale applied by the release team.  I imagine a similar rationale would be at least considered by the SRU team.
[08:54] <arand_> Speaking of boot sru, there's a patch for two fsck/mountall/plymouth issues, with positve prelimiary testing, the problem is affecting quite a few users, quite badly. At this stage, is there anything more that could be done to facilitate a possible SRU? Bug #553745  and Bug #571707
[08:59] <anon^_^> persia on the flipside of that argument, if the bug effects all users of proprietary graphics and you leave everyone to fend for themselves, you're going to end up with a lot of people offering different solutions.  This could be good or bad depending on how you look at it
[09:00] <persia> arand_: I think someone just has to do the SRU process.  Since you put it in a PPA, you seem a reasonable candidate :)
[09:00] <persia> !sru
[09:00] <anon^_^> The faster an official solution gets out there the less likelyhood of people messing around in configuration files and causing havoc
[09:00] <persia> anon^_^: Indeed.  This is why I'm glad I'm not one of the folks that makes that decision :)
[09:00] <persia> But I'm not convinced there exists a current solution, which gets in the way.
[09:01] <anon^_^> there was one offered on softpedia of all places
[09:01] <anon^_^> I hadn't tried that yet
[09:01] <ogra_cmpc> persia, there is a very bad one
[09:01] <anon^_^> http://news.softpedia.com/news/How-to-Fix-the-Big-and-Ugly-Plymouth-Logo-in-Ubuntu-10-04-140810.shtml
[09:01] <persia> ogra: Hrm?
[09:01] <ogra_cmpc> persia, proposing to edit the grub config
[09:01] <anon^_^> I started out with editing grub's config file
[09:01] <anon^_^> that didn't work
[09:01] <persia> That's not the right way to do it.
[09:01] <ogra_cmpc> we have about 100 open grub bugs atm
[09:02] <anon^_^> editing the grub header didn't work either
[09:02] <persia> The right way to do it is to provide alternate artwork, and a fallback model.
[09:02] <ogra_cmpc> that are caused by it
[09:02] <anon^_^> it worked for some nvidia users
[09:02] <anon^_^> supposedly
[09:02] <persia> Yeah, but it's in the category of "works for a couple people and breaks everyone else".
[09:02] <ogra_cmpc> the prob is that one of the blogs this solution is on uses some weird css that replaces " with backticks
[09:02] <ogra_cmpc> and people copy paste the code lines
[09:03] <persia> It needs a fix that is actually a fix, rather than a workaround.  This either is a fix in the drivers (up to the driver providers), or a workaround by providing alternate artwork.
[09:03] <ogra_cmpc> right
[09:03] <anon^_^> where's sabdfl when you need him?
[09:03] <anon^_^> lol
[09:03] <persia> anon^_^: Until a fix like I've described exists, nobody can do anything useful with the bug.  Doesn't matter whom.
[09:03] <ogra_cmpc> but that doesnt solve the issue with people blogging bloken solutions and sheep following them
[09:04] <ogra_cmpc> \*broken
[09:04] <arand_> persia: Should I try to ping Steve L about it? I'm guessing the next step is to try to push it into -proposed, no?
[09:04] <RAOF> uvesafb is not necessarily going to be a good idea.  Is that going to break suspend for people?
[09:04] <persia> arand_: You shouldn't have to ping anyone specific: just follow the procedure, and if you need a sponsor to upload somewhere, use the sponsoring process.
[09:04] <persia> !sponsor
[09:05] <persia> !sponsorship
[09:05] <ogra_cmpc> !botcomeback
[09:05] <persia> https://wiki.ubuntu.com/SponsorshipProcess
[09:05] <ogra_cmpc> :)
[09:05] <persia> No, the bot's here.  I'm just trying to get it to talk about stuff it doesn't understand
[09:05] <ogra_cmpc> ah
[09:06] <ogra_cmpc> nice that it doesnt error into the channel
[09:06] <persia> Depends.  If you log into the bot, you can make it error into the channel when you tell it to do things, which can be useful for e.g. bot brain discussions, but yeah, most of the time it tries to be quiet.
[09:25] <sebner> didrocks: hoi, did you already hear something about an empathy regression/bug in lucid?
[09:30] <didrocks> sebner: not really, I guess kenvandine is following more than I empathy. Do you have any bug report to point me to?
[09:31] <sebner> didrocks: not yet, I just wanted to confirm, I haven't found one and you are the last uploader but I'm opening one
[09:31] <didrocks> sebner: sure :)
[09:38] <sebner> didrocks: hmm, a little bit short, please tell me what debug info you need, (seems like an regression as there is an old bug report about something similar (only jabber though), Fix Released), https://bugs.edge.launchpad.net/ubuntu/+source/empathy/+bug/576290
[09:53] <didrocks> sebner: oh, there is a, upstream change to take the gconf key about not showing unconnected people by default on that upload
[09:53] <didrocks> sebner: let me grab the key to check with you, one sec
[09:54] <didrocks> sebner: /apps/empathy/ui/show_offline
[09:54] <didrocks> sebner: should be on by default btw
[09:54] <didrocks> sebner: (upstream is off by default)
[09:56] <sebner> oh
[09:57] <sebner> didrocks: ah, right sorry.
[09:57] <sebner> didrocks: at least it doesn't respect my configs :P
[09:57] <didrocks> sebner: no pb ;) it was an upstream bug to not take the value into account ;)
[09:57] <didrocks> sebner: "doesn't respect"? do you have the gconf value set to false and it behaves differently?
[09:58] <sebner> didrocks: well, I configured empathy to show my offline contacts, the update yesterday changed it evidently
[09:59] <didrocks> sebner: right, but normally it respects your gconf value. I don't have a setup running right now, but I'll check again
[09:59] <sebner> didrocks: then we have found a bug anyways ^^
[09:59] <didrocks> sebner: I guess so :)
[10:00] <sebner> didrocks: should I comment on the bug or will you?
[10:00] <didrocks> sebner: let me first perform some check on a clean install
[10:00] <sebner> aye aye
[10:10] <didrocks> sebner: what version do you have btw, 2.30.1 or 2.30.0.1?
[10:15] <sebner> didrocks: 2.30.1-0ubuntu1
[10:16] <didrocks> sebner: ok, just to ensure :)
[10:16] <didrocks> sebner: btw, I mixed up, it's off by default for us, and on for upstream
[10:16] <didrocks> (still dist-upgrading on my netbook ;))
[10:17] <sebner> didrocks: :)
[10:18] <sebner> didrocks: it isn't karmic -> lucid though, I used lucid before, It's just the empathy update
[10:19] <didrocks> sebner: yeah, I just wanted to ensure that it was related to the update. So, just to ensure, yourggconf  value is true or false?
[10:19] <sebner> didrocks: true
[10:20] <sebner> didrocks: update changed it to false
[10:20] <didrocks> sebner: that's intended, it's the default and the old default was true (but not taken into account). The value changed, but not the result in the ui
[10:21] <sebner> didrocks: shouldn't it _not_ overrule my settings?
[10:22] <didrocks> sebner: it's just distro default. Your setting (in ~/.gconfd) shouldn't have changed
[10:22] <joaopinto> good morning
[10:22] <Tm_T> K'day
[10:48] <l3on> Hi all... I'm trying to packaging a lib for ubuntu (karmic) but I have some problems with SHLIB in amd64 (i386 is fine). There are knowd issue for SHLIB in amd64?
[10:49] <l3on> s/knowd/known/
[10:49] <joaopinto> l3on, #ubuntu-motu is probably a better channel for packaging
[10:49] <l3on> ok tnx :)
[11:07] <hyperair> zyga: i've solved it!
[11:08] <zyga> hyperair: tell me about it
[11:08] <zyga> :-)
[11:08] <slangasek> joaopinto: where do you see "update-manager -d" in the release notes?
[11:08] <hyperair> zyga: i commented out an unlink line in ccache, hence stopping ccache from cleaning up its things. then i ran one build, copied away the tempdir, and ran another build. then i diff'd the .i files
[11:08] <hyperair> zyga: the difference was.... -g stuffed the full path into the files
[11:09] <hyperair> zyga: so i've gotten around that by patching sbuild to stop randomizing build directories.
[11:09] <zyga> zyga: oh
[11:09] <zyga> hyperair: oh :D
[11:09]  * zyga talks to himself
[11:09] <hyperair> hehehe
[11:09] <zyga> sbuild is naughty!
[11:10] <joaopinto> slangasek, http://www.ubuntu.com/getubuntu/releasenotes/1004overview,  do-release-upgrade -d, sorry. it's do-release* not u-m
[11:10] <hyperair> zyga: i think sbuild randomizes the build directories for its fallback mode (i.e. no chroot) to work
[11:10] <joaopinto> oh wait, yes, it's also on the u-m instructions: "Alt+F2 and type in "update-manager -d""
[11:11] <slangasek> arand: bug #571707> yes, I'm looking at it, though I'm also only intermittently connected to the network right now so it's a bit slow going - if you can give me until the weekend I should be able to get that staged for SRU
[11:11] <joaopinto> isn't changing /etc/default/apport sufficient to enable apport ?
[11:12] <slangasek> joaopinto: oh - could you please correct this in the source document at https://wiki.ubuntu.com/LucidLynx/TechnicalOverview and maybe review that for other bugs, and prod me again when it's done?
[11:13] <joaopinto> ok
[11:16] <joaopinto> I supposed those 'rc's on the iso links must be renamed to 'release'
[11:26] <joaopinto> slangasek, https://wiki.ubuntu.com/LucidLynx/TechnicalOverview updated: Removed the "-d" from update-manager, and all the RC/Release Candidate references
[11:29] <mr_pouit> pitti: any idea why libhal_ctx_init uses dbus_bus_name_has_owner()? This fails here, and leads to Bug #546992 (I just subscribed you to it, see last comment for more info ;).
[12:13] <lool> nigelbabu: Hadn't got time to look into this MIR; was promoting backuppc to main discussed somewhere?  I didn't see this spec
[12:13] <lool> nigelbabu: it might make sense to look for another reviewer for the MIR if you can find one  ;-)
[12:25] <zul> backuppc is already in main
[12:34] <nils_> are there build logs for the precompiled packages?
[12:36] <apw> do we expect to be able to upload to maverick in PPAs ?
[12:36] <zyga> kirkland: ping
[12:57] <persia> nils_: Yes.  https://launchpad.net/ubuntu/+source/${SRCPACKAGE} will have links to each build on each architecture.
[12:58] <nils_> persia: great, thanks
[13:04] <ari-tczew> jdong: could you review sru for bug 574262 as soon as possible? I found a tester, so I don't want waste his time.
[13:36] <soren> ogra: I'm glancing at bug 532733..
[13:36] <soren> ogra: If you just install iso-codes directly, does it also hang?
[13:36] <ogra> no
[13:36] <soren> ogra: Ok.
[13:36] <ogra> it only hangs under load
[13:36] <ogra> and its not always iso-codes
[13:37] <soren> ogra: Oh, ok, I thought you said it was.
[13:37] <ogra> *for me* its nearly always iso-codes though
[13:37] <ogra> others see hangs on different packages
[13:37] <ogra> and i have seen different packages hang too
[13:37] <soren> ogra: Ok.
[13:38] <soren> ogra: What sort of disk controller does it emulate? Do you know?
[13:38] <ogra> there is definately a race somewhere
[13:38] <ogra> nope
[13:39] <soren> Ok.
[13:39] <soren> The I/O handling was changed a couple of years ago. It caused me some grief right around hardy's release.
[13:39] <persia> Doesn't the same hang happen with qemu-user-arm?
[13:40] <soren> Oh.
[13:40] <soren> Oh, that's what rootstock uses?
[13:41] <soren> persia: That would change things fr sure.
[13:41] <soren> s/ fr / for /
[13:41] <persia> I thought rootstock used qemu-system-arm: I just thought it was replicable in both.  I may be mistaken.
[13:42] <ogra> rootstock uses both
[13:42] <ogra> the hang only happens in the real VM
[13:43] <soren> Ok. Then I can make sense of it again :)
[13:43] <persia> Ah.
[13:43] <ogra> and it only happens since about mid of lucid
[13:43] <soren> ogra: guest or host?
[13:43] <ogra> we have dug through the upstream changes (we being asac and me) but havent found anything obvious
[13:43] <ogra> guest indeed
[13:44] <ogra> (since it happens at unpacking of packages inside the VM)
[13:44] <soren> Er..
[13:45] <soren> Yeah, but that doesn't necessarily mean that another Ubuntu version on the host didn't make it go away.
[13:46] <persia> Other folks reported the same problem around the same time on karmic hosts.
[13:46] <ogra> right, its the lucid guest being at fault
[13:47] <soren> Well, it's probably QEmu's fault, but it only happens with guests newer than karmic+½ or so. :)
[13:47] <ogra> and the fact that enabling error reporting in the kernel alignment or using dbgsym packages of apt and dpkg both fix it point very clearly to a race of some kind
[13:48] <persia> It may be worth noting that lucid saw a transition in armel from ARMv6 to ARMv7a+Thumb2 for lots of core packages.
[13:48] <ogra> zyga's traceback shows some mmu stuff though
[13:48] <persia> Dunno how that might affect emulation.
[13:48] <ogra> it obviously does :)
[13:50] <persia> ogra: I'm sure it affect it: I just have no idea *how* :)
[13:50] <ogra> yeah, nobody has
[13:50] <zyga> soren: ping
[13:51] <jae> I have a "lucid" process still running (presumably that's the 10.04 updater).  I managed to kill X, so I don't have the window... it does have a socket open, so is there a way to reconnect to it?
[13:51] <soren> zyga: No need to ping... I'm right here :)
[13:51] <zyga> soren: ogra asked me to point you at https://bugs.edge.launchpad.net/qemu/+bug/532733
[13:51] <soren> Heheh :)
[13:51] <zyga> soren: I have two processes crashed with gdb attached
[13:51] <soren> zyga: Scroll up a few pages or so.
[13:51] <zyga> soren: one has ... okay, le me read
[13:52] <zyga> soren: okay done
[13:52] <soren> Ok, go on :)
[13:53] <soren> zyga: So, you're seeing a segfault, but ogra's seeing a hang. Is that right?
[13:53] <zyga> soren: so I have two crashed qemu-kvms with gdb attached
[13:53] <zyga> soren: yeah but I'm doing a slightly different thing
[13:53] <soren> Aha.
[13:53] <zyga> soren: I have a hanged version ctrl+z around too
[13:53] <zyga> in the same package as ogra
[13:54] <zyga> one qemu is from stock lucid with debug symbols
[13:54] <zyga> the other is built locally without optimize
[13:54] <zyga> I posted backtraces from both to the bug report
[13:54] <zyga> if you have any hints as what to inspect please tell me
[13:54] <soren> A good start would be the output of "thread apply all bt full"
[13:55] <zyga> both have just one thread IIRC but let me check
[13:55] <zyga> hmm, lovely
[13:56] <nigelbabu> lool: I dunno, the bug was assigned to you, I wanted your take on it
[13:57] <zyga> ogra, soren: added to the bug report
[13:58] <soren> zyga: ta
[13:59] <zyga> soren: hmm? ambiguous command for my gdb
[13:59] <soren> zyga: "thanks" :)
[13:59] <zyga> :D
[14:00]  * zyga was hoping to learn some arcane gdb feature
[14:02] <soren> Nothing jumps out at me. I didn't really expect it to.
[14:03] <soren> If I'd have to guess (without having looked at code /at all/), it's an interrupt the gets lost somewhere. It's trying to read something, and due to a race, the interrupt from the emulated disk controller gets lost or otherwise ends up not being handled, and then it gets stuck.
[14:03] <soren> It's the exact sort of problem I had in the i386 and x86-64 code two years ago.
[14:04] <ogra> so just apply your fix for us to arm then :P
[14:04] <soren> The only reason we saw those was because of kvm being "a bit" faster than plain qemu.
[14:04] <zyga> soren: is there any internal structure that we could look at to see pending interrupts? I'm not really sure how qemu works internally
[14:04] <ogra> i'll pay you a beer
[14:04] <soren> :)
[14:04] <nh2> how to nicely set the email address created by dch -i? is it possible without an environment variable, maybe a configuration file?
[14:05] <persia> it needs an environment variable (DEBEMAIL), but many folks set that in .bashrc or similar.
[14:05] <soren> nh2: ~/.devscripts
[14:06] <persia> soren: That works for you?  It never worked for DEBEMAIL for me :(
[14:06] <soren> nh2: Oh, persia's right.
[14:06] <soren> persia: No, my bad.
[14:06] <persia> Oh well.  I was prepared to be excited.
[14:07] <soren> ogra, zyga: I'd really love to stare at this for a few hours, but I'm really tied up these couple of days. I was just looking at the bug while taking a break from the stuff I /ought/ to be doing :)
[14:07] <zyga> soren: ack
[14:08] <nh2> soren, persia: hmm, my email in the shell configs is somewhat ugly (I share all of them automatically)
[14:09] <persia> nh2: Feel free to investigate *why* DEBEMAIL doesn't work in ~/.devscripts, and make it work.  I suspect the reason it doesn't work is more philosophical than technical, but I've never investigated.
[14:10] <nh2> persia: I found it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241939
[14:10] <nh2> persia: "I don't intend to implement this patch: the DEBEMAIL variable is recognised by scripts in several other Debian-related packages and is not devscripts-specific"
[14:12] <persia> nh2: RIght, so you could do .bashrc.debian (as suggested), or find all the tools that use DEBEMAIL, and come up with some universal way to manage that configuration.
[14:12] <persia> The latter is bundles of work, mind you, especially the part about convincing everyone to converge :)
[14:14] <bigon> ma10: /wi1
[14:14] <bigon> ark
[14:14] <bigon> mako: are you around?
[14:17] <ogra> soren, we'll use you for fallback staring then :)
[14:17]  * ogra stares at this bug since several months now ... it didnt move !
[14:18] <ogra> (it grows slowly though)
[14:18] <nh2> persia: well, although I don't like that, you are right, and this is already layer 4 of my task stack (I actually want to work with my computer -> fix touchpad -> patch gnome -> create package -> fix devscripts?) Lost in recursion ;-)
[14:19] <persia> Yeah, I started because I wanted to play vegastrike :)  Several years later I still don't play vegastrike (and it's not even in the archives in a useful form anymore).
[14:19] <nh2> by the way, is ubuntu-devel the right place to ask people for testing such changes?
[14:20] <persia> If you're patching GNOME, you may find #ubuntu-testing or #ubuntu-desktop more targeted channels for test requests.  #ubuntu-bugs can help with some stuff (verification of the issue in another environment, etc.) and #ubuntu-reviews with others (helping test a patch, ensuring the right folk notice it, etc.)
[14:20] <nigelbabu> lool: backuppc has been in main since forever according to https://launchpad.net/ubuntu/+source/backuppc, so the MIR might be worth looking into
[14:31] <jae> Hmm, is there any documentation (more readable than the actual code) on what the karmic->lucid updater does?  So I can check what it missed due to X crashing.
[14:31] <joaopinto> jae, no
[14:32] <aLeSD> hi all
[14:32] <jae> Ah, it's the old "it won't crash, so we don't need that" reiserfsck stance, right?  (Me?  Cynical?)
[14:32] <aLeSD> why CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y in the 10.04 kernel ?
[14:37] <ogra> aLeSD, because it boots a lot faster with it ...
[14:38] <ogra> aLeSD, its switched to ondemand after booting
[14:38] <aLeSD> ogra: there's a lot of people saying that 10.04 use more energy of W7
[14:38] <ogra> aLeSD, see /etc/init.d/ondemand
[14:38] <aLeSD> ok
[14:38] <ogra> thats called immediately if the boot is done
[14:39] <ogra> so ubuntu still uses ondemand by default, just not for the first few seconds
[14:40] <soren> Showing CPU speed in bootcharts would be fun.
[14:40] <ogra> heh
[14:40] <ogra> i think plars works on showing RAM consumption
[14:40] <ogra> could be a funny followup task :)
[14:44] <joaopinto> jae, there is a log on /var/log related to the update process I don't remember the exact filename right now
[15:16] <fleebailey33> Hello, I have a macbook 7,1. And ubuntu, and no other linux works
[15:16] <fleebailey33> mid 2010, non of them boot. I think it has to do with initrid and the sata controller
[15:17] <fleebailey33> which is just mcp89 as far as i know
[15:17] <fleebailey33> figured I would come here to mention to developement team
[15:17] <fleebailey33> and willing to get any info your need to me to get or test
[15:17] <fleebailey33> it is 100% not user error
[15:18] <persia> Older software boots, or nothing at all?
[15:19] <fleebailey33> persia: nothing
[15:19] <persia> Hm.  I wouldn't even know how to suggest you file a bug that would contain the right information then :(
[15:19] <fleebailey33> persia: i think its initrid, persia want my reasoning?
[15:20] <fleebailey33> exactly, i don't even know whats needed
[15:20] <persia> Well, does it boot when you don't use an initrd?
[15:20] <Chipzz> persia: is that even supported?
[15:20] <fleebailey33> well how do i boot without it?
[15:20] <persia> Chipzz: Yes.
[15:20] <fleebailey33> persia: and opensolaris boots
[15:20] <fleebailey33> i am not concerned with installing
[15:20] <fleebailey33> it wont boot even
[15:20] <persia> fleebailey33: Don't add an initramfs on your kernel commandline.
[15:21] <fleebailey33> persia: will try
[15:21] <fleebailey33> also friends with z00dax from centos. so im trying a suggestion from him as well
[15:43] <soren> ogra: Mine hangs at iso-codes as well. :(
[15:43] <ogra> soren, we should just remove that package from the distro !
[15:44] <ogra> and then every subsequent one where it hangs ... at some point the hanging *will* stop
[15:44] <soren> ogra: Oh.. Logging in on tty2 made it segfault.
[15:44] <ogra> sweet
[15:44] <ogra> thats a normal VM then i get it ?
[15:45] <ogra> not rootstock or some other wrapper around it
[15:45] <soren> Normal vm.
[15:45] <ogra> using rootstock i have no access to the VM
[15:45] <ogra> no ttys or anything
[15:46] <soren> I used rootstock like you said in the bug report. that created an fs image with ubuntu-standard in it. Then I booted it and went to install ubuntu-netbook.
[15:46] <ogra> i captured another backtrace btw
[15:46] <ogra> ah, right
[15:46] <ogra> its attached to the bug
[15:49] <soren> ogra: ok.
[15:55] <soren> ogra: There's no way to use more than 256 MB of RAM? It segfaults for me if I go higher than that.
[15:55] <ogra> yes, known limitation of the emulated HW
[15:55] <ogra> in rootstock i use a swapfile mounted in tmpfs to work around that
[15:55] <pitti> al-maisan, StevenK: do you have some minutes to look into gcc-4.5 binNEWing for maverick? (I'm in talks at somehands, sorry)
[15:56] <soren> ogra: Any chance that could be our problem? It seems odd that it'd happen with iso-codes. It's a very simple package, after all.
[15:56] <soren> ogra: Oh, right, it doesn't happen on real HW.
[15:56] <ogra> others saw the issue with other packages
[15:57] <ogra> its really not bound to iso-codes
[15:57] <ogra> its just the most common one
[15:57] <ScottK> pitti: Do you have any problem with us pre-promoting boost1.42 so it'll be in Main and stuff can build-dep on it?
[15:57] <ogra> it seems to vary with the speed of your host
[15:57] <ogra> or RAM or whatnot
[15:57] <zyga> ogra, soren: I have a ULV laptop doing this (it's sloow) but my package is same
[15:57] <zyga> (iso-codes)
[15:58] <ogra> i think on faster HW it stops on a later package
[15:58] <zyga> ogra: odd
[15:58] <zyga> if fast cpu == program "lasts" longer then it's related to what? wall clock time?
[15:59] <soren> ogra: No no, I'm not saying it's bound to iso-codes. I was just thinking it might be caused by running out of memory, and I realised that that was unlikely to happen while dealing with iso-codes, whose install is unlikely to be memory intensive.
[15:59] <ogra> i have seen it several times stopping at iputils-tracepath myself
[16:00] <zyga> soren: it should not crash the host though
[16:00] <soren> zyga: The host never crashed for me.
[16:00] <ogra> it doesnt crash the host
[16:00] <soren> zyga: The VM has crashed.
[16:00] <ogra> right
[16:00] <soren> zyga: Which also shouldn't happen, of course :)
[16:00] <zyga> crash the host == crash the VM running on the host
[16:00] <zyga> if memory was low the installer should crash
[16:00] <ogra> welll, it hasnt even crashed when i tried it in a real VM
[16:00] <zyga> not the vm
[16:00] <ogra> i could run commands on the second tty
[16:01] <ogra> but had no dbgsym packages installed back then
[16:01] <zyga> I'm running the process again, the last backtrace was unfortunate as the frame stack was corrupted and I could not see anything interesting
[16:01] <ogra> i think i mentioned that in the bug
[16:01] <ogra> when i installed dbgsym for apt and dpkg the hang vanished
[16:06]  * al-maisan looks at https://wiki.ubuntu.com/ArchiveAdministration
[16:25] <fbond> I see a lot more ads at the top of the screen when I search using the 10.04 Google start page than I do searching from the Google home page.  The ads actually take up about 75% of my netbook's Firefox screen real estate.  Does anyone know if this is this deliberate?  I mostly just want to make sure folks are aware of it...
[16:30] <fbond> (Specifically, if the intent is to drive revenue, the current situation might very well have the opposite effect.  I find it much less usable than searching with the standard Google home page.)
[16:33] <fbond> Maybe a screenshot is helpful: http://www.alittletooquiet.net/media/priv/google-fail.png
[16:33] <fbond> Otherwise, sorry for the noise.
[16:33] <persia> fbond: You may find that you get a more useful response by filing a bug.  IRC has poor state tracking.
[16:33] <fbond> persia: What do I file a bug against?
[16:34] <fbond> This seems more like a Canonical business issue of some kind.
[16:34] <al-maisan> pitti: done
[16:34] <persia> I *think* the bit that controls that is ubufox, but I might be wrong.
[16:34] <fbond> persia: Seems like it would be server side...
[16:35] <persia> fbond: Right, but the issue that *can* be reported as a bug is that the selected start page has usability issues.  That the issue might happen to be with the server that provides that start page, or the configuration behind it is a matter of the implementation of the bugfix.
[16:35] <fbond> persia: Okie dokie.
[16:35] <persia> Otherwise, I can't suggest how to report it in a way that lets normal bug tracking tools be used.
[16:36] <persia> fbond: Good luck.  I'm sure it will get reassigned N times, but at least it can be discussed.
[16:36] <ogra> fbond, did you try buying that lingerie ? probably it goes away then ;)
[16:36] <fbond> ogra: Heh. I swear I was just after documentation. ;)
[16:38] <fbond> Anyway, I thought Canonical would care about the threat to their revenue stream.  My instinct was to just change my FF home page.
[16:38] <fbond> But I'll file a bug. ;)
[16:38] <persia> Canonical may care, but this isn't necessarily the best place to reach those who care.
[16:40] <fbond> persia: Ah.
[16:40] <ogra> right
[16:40] <ogra> bugs are golden :)
[16:40] <persia> I'm not sure the ubuntu-mozillateam (who will receive the bug first) cares either, but at least they're likely to know the right folks.
[16:45] <fbond> persia: #576467
[16:45] <micahg> persia: actually, it's not the mozilla team, but the ubuntu-websites, since we don't control the custom search
[16:46] <persia> micahg: Could you move the bug?  Sorry: ubufox was my best guess.
[16:46] <micahg> persia: yep, np
[16:46] <persia> Thanks.
[16:49] <micahg> persia: actually, it's ubuntu-start-page and I moved it :)
[16:51] <persia> Great.  I knew it belonged somewhere :)
[16:56] <pitti> ScottK: boost> not at all, it's just a new version
[16:56] <pitti> al-maisan: danke!
[16:56] <al-maisan> keine Ursache :)
[16:59] <ScottK> pitti: Nevermind.  I got ahead of myself, it seems we don't have it yet ....
[17:00] <pitti> ScottK: need it synced?
[17:00] <ScottK> pitti: It'll need to be merged in any case to drop the openmpi stuff, so let me put that on TODO.
[17:01] <pitti> ah, right
[17:17] <lool> nigelbabu: libtime-modules-perl doens't seem to be a dep of backuppc anymore; do you think the bug can be closed?
[17:31] <persia> lool: It's not a rdep because it got dropped, but that causes a crash with one of the backupppc scripts.
[17:31] <persia> lool: So the choices are to 1) patch backupppc to really not use it (rather than just not depend on it), or to process the MIR.
[17:32] <persia> lool: On a completely different topic, it was suggested you might be a good person from whom to solicit an opinion about bug #570908
[18:06] <jdstrand> pitti: hi!
[18:06] <jdstrand> pitti: did you happen to see my question regarding firefox?
[18:06] <jdstrand> pitti: if not I can paste
[18:06] <jdstrand> pitti: (from 2 days ago)
[19:06] <ari-tczew> "Archive: toolchain freeze, but uploads work": is it about maverick?
[19:08] <ScottK> Yes
[19:08] <ScottK> Uploads will be held in the queue until the toolchain is ready.
[19:17] <ccheney> is launchpad down?
[19:18] <ccheney> i can't seem to connect to bugs.launchpad.net
[19:19] <astraljava> ccheney: Doesn't load here either.
[19:19] <persia> ccheney: Other reporters in #launchpad with the same issue (and fails here), so probably.
[19:19] <ccheney> ok
[19:25] <persia> And it's reported working again :)
[21:11] <Pretto> why gwibber shows two entries on memenu?w
[21:13] <zyga-nc10> is it just me or is anyone else hitting corrupted archive.ubuntu.com
[21:15] <ScottK> zyga-nc10: There are transient cases where that happens, try it again in a few minutes.
[21:15] <ScottK> Pretto: Help is in #ubuntu.
[21:15] <Pretto> ScottK: ok
[21:28] <jeandaniel> hello, my Lucid system can't reboot following a system upgrade including an upgrade of grub. The upgrade was done from a console, and I could read a big scary message about grub on gpt being unreliable (in capital)
[21:28] <jeandaniel> my laptop is a macbook with gpt and bootcamp
[21:30] <jeandaniel> I think it is a common setup, are there other users impacted? is there a bug I could subscribe to?
[21:33] <jeandaniel> i would say this is quite a critical bug since I can not use my computer anymore after this upgrade. What would be your best advice?
[21:43] <persia> jeandaniel: In general, #ubuntu-bugs is a better place to ask about bugs.  Bug #527833 sounds like it might be similar to your issue, but you might hunt around in other reports.
[21:46] <jeandaniel> persia: thanks
[22:03] <robertzaccour> i reported a bug a while back, and it seems there is no activity on it
[22:03] <robertzaccour> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/574406 thats the bug i reported
[22:08] <arand> If preparing an SRU from version 2.14 (of mountall), should the version number be 2.14-0ubuntu1? -0ubuntu0.1? just 2.14.1?
[22:09]  * persia suggested 2.14.1, as mountall is ubuntu-local, and refuses the "ubuntu" string in the version, but was kinda guessing.
[22:10] <joaopinto> arand, what's the bug nr for which that SRU applies to ?
[22:11] <ScottK> arand: I'd go with persia's suggestion just because it's mountall and that's they approach keybuk prefers.  The policy compliant answer would be the -0ubuntu0.1 one.
[22:11] <arand> joaopinto: Same old Bug #571707 and Bug #572786 that I'm always on about :)
[22:11] <ScottK> There's a they/the in there somewhere.
[22:11] <persia> ScottK: Well, 2.14ubuntu0.1, as it's native.
[22:12] <arand> Oh, sorry second should be 553745
[22:12] <ScottK> RIght, of course.
[22:19] <arand> Well the ubuntu0.1 scheme would break with all prior versioning in the package, I'm not sure if that is a good thing just in order to distinguish the SRU, or bad because it doesn't conform...
[22:55] <robertzaccour> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/574406 thats the bug i reported
[22:55] <robertzaccour> i did the apport-collect, what else can i do to try to get it fixed?
[22:57] <persia> Probably best to wait a bit, in hopes one of the two triagers catches it.  If you don't hear anything in a few more days, try catching maco or JFo in #ubuntu-bugs
[23:05] <robertzaccour> oh ok thanks
[23:06] <robertzaccour> whats triangers?
[23:13] <persia> robertzaccour: "triagers" are those who triage the bugs.  triage is the process by which we ensure we understand the bugs and can provide a steady queue to those best able to fix them
[23:15] <persia> cjwatson: Any suggestions on what information would be useful for bug #576662?  data collection is (currently) limited to that available in OS X.
[23:23] <persia> Rereading the SRU procedure: HALP!  I need someone with a MacBook who is willing to potentially be unable to boot Ubuntu to verify bug #576662
[23:26] <persia> Right.  No volunteers.
[23:26] <persia> ping slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, lool, pgraner, davidm, cody-somerville, jdong
[23:27] <mdeslaur> persia: it sounded like such an attractive offer :)
[23:27] <ajmitch> sorry, I don't have the $$ to get a macbook
[23:27] <persia> mdeslaur: Well, it's not that hard to make it bootable again if one has an install CD.
[23:28] <persia> But I think we ought care that we're potentially making ~1/20th of all installs unbootable.
[23:28] <mdeslaur> :)
[23:28] <mdeslaur> zul: persia needs you
[23:28] <persia> (assuming that there is any correlation between reported Apple market share and use of Ubuntu on Apple hardware)
[23:30] <mdeslaur> persia: zul has a macbook, maybe he'll be back later
[23:30] <persia> mdeslaur: Thanks.
[23:32] <ebroder> Does anybody know of a good way for a script to detect if it's being run on a particular release of Ubuntu or some distribution that's derived from that release?
[23:32] <ebroder> I need this to work with older releases, so dpkg-vendor doesn't help me
[23:32] <persia> lsb_release
[23:32] <ebroder> persia: Do derivative releases not change the lsb_release information?
[23:32] <jdong> (for each package, hash all files, if hashes match Ubuntu's... errr this sounds like iPhoneOS...)
[23:32] <persia> If they don't, that's poor practice on their part.
[23:33] <jdong> persia: I'll take a look at that verification procedure after I get back later tonight
[23:33] <jdong> ping me again if I forget.
[23:33] <persia> jdong: Hey!  You're on the magic ping-the-important-SRU-folk list.  What's the next step for this grub2 update issue?
[23:33] <ebroder> persia: Right - I want something where I can pick out if I'm running on, say, Jaunty or anything derived from Jaunty (like Mint or whatever)
[23:33] <ebroder> And I can't pick out the derivatives with just lsb_release
[23:34] <persia> ebroder: No reliable way to do that.
[23:34]  * ebroder nods. That's too bad
[23:34] <persia> ebroder: Because derivatives can change anything they like when deriving.
[23:34] <ebroder> Well, sure, but there could be best practices
[23:34] <lool> persia: Pong
[23:34] <jdong> persia: can you clarify what happened? Is the newest GRUB2 update making Macs unbootable?
[23:34] <jdong> is the cause known?
[23:35] <ebroder> persia: (e.g. right now I tie where I'm running to a Debian version by comparing the version of base-files)
[23:35] <persia> lool: SRU procedure says I should ping you when there's a reported SRU regression: bug #576662
[23:35] <lool> persia: Which grub2 is this?
[23:36] <persia> 1.98-1ubuntu6
[23:36] <lool> I have 1.98-1ubuntu6 installed at home, and I'm not 100% I booted from a hard disk with that grub2, but quite likely so
[23:36] <lool> (with gpt)
[23:36] <persia> lool: On a MacBook?
[23:36] <lool> No
[23:36] <persia> My understanding is that Apple has a special, and odd, implementation of GPT.  I may be misinformed.
[23:37] <lool> That might be
[23:37] <jdong> persia: ok, if this is being widespread reported then the archive managers should probably be pinged to pull/403 the update until we can identify the cause
[23:37] <lool> persia: What indicates a regression over the final lucid version?
[23:37] <jdong> lool: lucid boots but lucid-updates doesn't boot :)
[23:37] <persia> That the reporter was using 10.04 fine until they upgraded.
[23:37] <jdong> that seems to be the reported regression here
[23:37] <jdong> and it sounds painfully serious
[23:37] <jdong> I'll attempt to reproduce it on my hardware in a few minutes
[23:37] <jdong> (I've got two macs sitting here)
[23:37]  * persia will wait for zul (or someone) to confirm before setting Critical and asking for update blocks.
[23:38] <persia> jdong: Thanks!
[23:38] <lool> jdong: Oh it's you, great
[23:38] <jdong> persia: thank *you* for being on top of this!
[23:38] <lool> jdong: Could you take a backup of /var/cache/debconf as the first thing when you boot your system again?
[23:39] <persia> *before* the grub2 update :)
[23:39] <lool> There's actually a .old version of the debconf files
[23:39] <lool> so it should have the version prior to the update *hopefully*
[23:39] <persia> RIght, but it might be hard to recover if he can't boot :)
[23:39] <jdong> ok, will do
[23:39] <lool> (config.dat versus config.dat-old)
[23:39] <lool> jdong: You can boot from CD I guess?
[23:40] <jdong> lool: eh probably :)
[23:41] <lool> I'm pretty sure cjwatson is sleeping right now
[23:41] <lool> it was published on 2010-05-03, and the bug was reported today
[23:42] <persia> I thought he'd be sleeping, but sbeattie suggested I ping him
[23:42] <lool> persia: It's part of the process
[23:44] <lool> So my gut feeling on urgency is that it's the class of bug we should immediately tend to, but because the regression was "only" discovered 3 days after its publication, I suspect it wont hurt too much if I let cjwatson sleep over it (I do consider solving it myself, but it would probably involve spending the next 4 hours trying to understand the bug and then being too tired to be confident in the fix  :-)
[23:44] <lool> What I could do right now is revert the diff in an ubuntu7
[23:45] <persia> Well, based on bug #508172, I think that breaks for other folks.
[23:45] <lool> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/508173 seems equally problematic though
[23:45] <lool> persia: Yes
[23:45] <persia> Err, bug #508173
[23:45] <lool> persia: We are on line
[23:46] <lool> So reverting the change would just flip back to affecting another use case
[23:46] <persia> So I think it needs to get sorted right, even if that takes a while.  I just wanted to make sure it got verified and escalated properly.
[23:46] <jdong> ok, booted, upgrading
[23:46] <jdong> (backed up debconf already)
[23:51] <jdong> ok rebooting
[23:52] <lool> persia, jdong: So, after thinking this through, I certainly dont think it's reasonnable for me to try to fix grub2 for both use cases overnight, I find it much more reasonnable to raise this to cjwatson tomorrow morning (in 8 hours-ish); Dell actually shipped volumes of preinstalled system in this configuration, while the number of macbook systems running Ubuntu is probably lower; hence I dont want to return to ubuntu5 either
[23:52] <jdong> 1.98-1ubuntu6 appears to boot for me.
[23:52] <persia> lool: I agee.
[23:52] <lool> NB: The goal of the SRU regression process is to remove the regression, but in this case, the fix seems more valuable than the regression
[23:53] <lool> jdong: It's the one which didn't boot though?
[23:53] <persia> jdong: Thanks for double-checking.
[23:53] <jdong> lool: ok can you document the circumstances and your decision on either the original SRU or one of the regression bugs?
[23:53] <jdong> lool: I don't know which one isn't supposed to boot. my system booted before, I dist-upgraded, and it still boots
[23:53] <persia> jdong: I think you failed to replicate 576662, which is a good thing.
[23:54] <jdong> hehe
[23:54] <jdong> at least on one system :)
[23:54] <persia> Right, but that reduces the severity from *ALL GPT SYSTEMS* to "some folks have issues"
[23:55] <persia> Since the prior state was "some folks have issues", I'm not as wildly excited as I was earlier.
[23:55] <lool> jdong: I will do that, yes
[23:55] <jdong> thank you
[23:55] <jdong> and yeah, indeed, it doesn't APPEAR as drastic
[23:56] <lool> jdong: Note that this is valid and will be addressed, just defered further analysis to the best person
[23:56] <jdong> understood. Sounds great
[23:56] <lool> jdong: So you reinstalled ubuntu6 and now it works
[23:56] <lool> ?
[23:57] <jdong> 1ubuntu6 is what aptitude chose for me, and it boots
[23:57] <jdong> I've never experienced the unbootable bug
[23:59] <lool> jdong: Oh so you have a similar system as in the bug, but you cant reproduce?
[23:59] <lool> jdong: Could you document this in the bug please?