[00:00] <broder> doko: looks like a doxygen issue. doxygen creates a doxygen.sty with \RequirePackage{xcolor}, but to get the \rowcolor command, you have to do \RequirePackage[table]{xcolor}
[00:01] <broder> http://www.tug.org/pipermail/macostex-archives/2009-May/040402.html
[00:03] <broder> doko: and the \RequirePackage directive is hard-coded into /usr/bin/doxygen
[00:04] <broder> doko: debian bug 611656
[01:50] <sladen> slangasek: ScottK: please could you accept the minimal change for 'ubuntu-mono' after cyphermox tracked it down (bug #741387)
[01:50] <ScottK> sladen: Not until after beta 1 is out.
[01:54] <sladen> ScottK: is it actually building yet?  This introduces no new files, changes no files but allows a cache build on install to succeed
[01:55] <ScottK> sladen: With very limited exceptions we don't accept seeded packages after the images are frozen so that they are current with what's in the archive when the beta is released.
[01:59] <sladen> ScottK: thought the build didn't start until 02:45 ?
[01:59] <ScottK> What build?
[02:00] <ScottK> We have candidte ISOs almost fully tested.
[02:16] <ohsix> cnd: thanks re: 742213, the instructions to do it myself are a bonus :D
[02:17] <ohsix> i tried co'ing the version then generating the patch against HEAD^ but it didn't want to go
[02:36] <ohsix> cnd: is there a way to keep a note of the proper way to fix it for the next release? or is the patch being present good enough, and the person looking at them in the future can figure it out from the bug number?
[02:41] <sladen> ohsix: milestone it against 'later'
[02:44] <ohsix> sladen: well theres a workaround for this release, it needs ui to adjust "minw", or a way to arrive at a usable number by itself for the next release
[04:10] <cnd> ohsix, it's really a matter of working with the upstream projects to get things right
[04:11] <cnd> that may be asking about it on xorg-devel for the synaptics driver
[04:11] <cnd> or wherever the gnome mouse preferences dialog is maintained
[04:11] <ohsix> ah
[04:11] <cnd> we're reverting the change here merely cause we're so close to release
[04:11] <cnd> that we don't have time to work things out with upstream
[04:11] <ohsix> right
[04:12] <cnd> but yes, something should be done with upstream
[04:12] <cnd> I'm hesitant to say that the mouse preferences should have a new option
[04:12] <cnd> partly because I'm not sure it would help (many people may be confused by it)
[04:13] <cnd> and as a corollary, gnome doesn't like to take changes like that
[04:13] <ohsix> yea i wasn't advocating it or anything, but i dunno if it can be enabled at all without a way to adjust it
[04:13] <cnd> yeah
[04:13] <cnd> I think maybe some common ground could be found by merely increasing the default threshold in synaptics
[04:13] <ohsix> since it's very arbitrary, probably even down to the laptop model; and i know environmental changes affect it
[04:14] <cnd> yeah, it's hard
[04:14] <cnd> the real fix may be to report your usage to xorg-devel requesting that the patch be reverted
[04:14] <cnd> because it just doesn't work uniformly for everyone
[04:15] <cnd> are you comfortable trying to work with upstream, either gnome or xorg?
[04:16] <cnd> I don't really want to add another issue to my plate if I can help it :)
[04:16] <ohsix> not at the moment
[04:16] <ohsix> i'll probably talk to whot about it sometime, he's the one that pointed out the patch & the person that works on it
[04:17] <ohsix> he said i should adjust it so it works well on my touchpad but not how, there might be a quirk list or something that isn't as bad as it sounds
[04:17] <cnd> ohsix, well, that's working with upstream :)
[04:17] <cnd> it doesn't have to be on the xorg-devel mailing list
[04:18] <cnd> he's the same person I would be talking to about the issue
[04:19] <ohsix> ah
[05:54] <linux-noob> what is the default FS in Natty ?? btrfs or EXt4
[05:59] <RAOF> ext4
[07:54] <dholbach> good morning
[08:05] <pitti> Good morning
[08:58] <pitti> tseliot, didrocks: should bug 685682 be closed with the new fglrx that we landed yesterday?
[08:59] <didrocks> tseliot: pitti: it seems that cnd still have that issue with the driver and workarounded compiz
[08:59] <didrocks> pitti: anyway, there is still a need for a compiz upload which will come with other fixes (probably Monday)
[08:59] <pitti> ah, thanks
[09:00] <tseliot> pitti, didrocks: the fix should be available in the next upload of compiz (it's already available in a daily PPA)
[09:00] <pitti> so I guess for now the fglrx tasks should be closed then?
[09:00] <didrocks> tseliot: yeah, but as told, it's not working on cnd's machine, I asked him to check with you and jay
[09:01] <tseliot> didrocks: sure, we definitely need more feedback
[09:01] <didrocks> pitti: I think we can close the fglrx task and reopen if needed :)
[09:01] <didrocks> yeah
[09:21] <poolie> hi pitti?
[09:22] <pitti> hello poolie, how are you?
[09:22] <poolie> good thanks, how are you?
[09:22] <poolie> iirc you're a good person to talk to about apport?
[09:23] <pitti> poolie: I am I guess :)
[09:23] <poolie> i was just thinking, ahead of UDS, about filing a bug or starting a spec for the issue of making it better at holding on to crash reports, if it's not able to file them right at the time they're noticed
[09:23] <poolie> for instance if you have no net connection or lp is offline
[09:24] <poolie> it seems like at the moment they're easily lost
[09:24] <poolie> i don't think i'll get to actually work on this though
[09:24] <pitti> poolie: it's mostly there already, though, with the --save option
[09:24] <pitti> (for bug reports)
[09:24] <pitti> for crashes it has always worked, the reports are in /var/crash/
[09:24] <pitti> so I guess there's just a little UI missing here
[09:26] <poolie> oh, if it fails to file they're left in /var/crash?
[09:26] <pitti> poolie: yes
[09:26] <pitti> for 7 days, then they get auto-cleaned
[09:27] <pitti> so if you want to keep them around longer, you need to copy them somewhere else
[09:27] <pitti> you can run ubuntu-bug foo.crash to report it again
[09:27] <poolie> ok
[09:27] <poolie> so there's no gui but perhaps anyone advanced enough to do this should be happy to run this command
[09:29] <pitti> poolie: it's even mentioned in man ubuntu-bug
[09:29] <pitti> (OMG documentation)
[09:30] <pitti> poolie: so, there could be some UI improvements still; e. g. if the UI doesn't have network, it currently just fails with an error message; it could isntead give you a file save dialog
[09:30] <pitti> poolie: btw, you can also double-click on a crash file in nautilus, that works too
[09:31] <poolie> right, that sort of thing
[10:11] <dholbach> Laney, thanks
[10:13] <Laney> dholbach: no worries
[10:14]  * Laney lights a candle for the MOTU Council
[10:14] <soren> Laney: hm?
[10:15] <Laney> soren: it's being decommissioned finally
[10:15] <soren> Laney: How can you tell?
[10:15]  * soren doesn't see any news on MOTU council in his inbox
[10:16] <Laney> it's been dead for some time, we're just cleaning up the remaining Launchpad privileges
[10:16] <ajmitch> killing it with fire?
[10:16] <soren> Laney: Ah, ok.
[10:17]  * ajmitch didn't know it still had any privileges to clean up
[10:19] <Laney> one or two. :-)
[10:23] <doko_> broder: thanks!
[11:29] <seb128> jhunt_, hi
[11:30] <jhunt_> seb128: hi
[11:30] <seb128> jhunt_, is https://bugs.launchpad.net/ubuntu/natty/+source/gdm/+bug/436936/comments/20 ready for upload to natty?
[11:30] <seb128> jhunt_, the comments you got seem to indicate it is?
[11:31] <doko_> seb128: what did happen to python-gobject-doc? b-d of pygoocanvas?
[11:32] <Riddell> jhunt_: and if so is there a patch for KDM?
[11:32] <jhunt_> seb128: not yet, for 2 reasons. Firstly, not enough testing from users (IMHO) and secondly apw snuck in and changed gdm.conf under me :)
[11:33] <seb128> doko_, it was merged back like 3 years ago?
[11:33] <seb128> jhunt_, ok
[11:33] <doko_> seb128: https://launchpadlibrarian.net/67723807/buildlog_ubuntu-natty-i386.pygoocanvas_0.14.1-1ubuntu4_MANUALDEPWAIT.txt.gz
[11:33] <jhunt_> Riddell: the whole DM issue need discussion at UDS I feel. SpamapS and myself have a plan for "abstract jobs" to avoid all this configuration duplication.
[11:33] <seb128> doko_, well, drop it, it's shipped with the other python-gobject binaries
[11:33] <seb128> lunch, bbl
[13:13] <tbf> Failed to fetch http://de.archive.ubuntu.com/ubuntu/pool/universe/libk/libkate/libkate1_0.3.7-3_amd64.deb  Hash Sum mismatch
[13:13] <tbf> Failed to fetch http://de.archive.ubuntu.com/ubuntu/pool/universe/libm/libmimic/libmimic0_1.0.4-2build1_amd64.deb  Hash Sum mismatch
[13:13] <tbf> Failed to fetch http://de.archive.ubuntu.com/ubuntu/pool/universe/libd/libdca/libdca0_0.0.5-3_amd64.deb  Hash Sum mismatch
[13:14] <tbf> → shall i/we be worried?
[13:55] <pitti> rbelem: hello, how are you?
[13:56] <pitti> rbelem: should the kubuntu mobile arm images (or a subset) be published for beta-1? or does bug 712061 break them all?
[13:56] <janimo> lamont, slangasek some of the newly filed armel FTBFS bugs are those that time out because of insufficient resources on the build servers, and mentioned here https://bugs.launchpad.net/launchpad/+bug/705344
[13:58] <Riddell> pitti: not worth publishing them, they don't do anything
[13:58] <pitti> Riddell: ok, thanks
[14:02] <ogra_> Riddell, that bug is pretty confusing btw
[14:05] <Riddell> ogra_: how so?  it is a fairly broad bug covering several issues we've had
[14:05] <rbelem> hi pitti :-)
[14:05] <rbelem> hi Riddell ogra_
[14:05] <ogra_> Riddell, well, the initial description clearly rules it out for armel
[14:06] <ogra_> since we dont produce any live images
[14:06] <ogra_> the last comment makes it so broad then that it could match everything
[14:07] <rbelem> i ran a snapshot from some days before beta and it worked fine, but currently seems to be not
[14:08] <Riddell> rbelem: on i386?  what plasma workspace was running?
[14:08] <rbelem> Riddell, on i386
[14:08] <rbelem> Riddell, i was unable to test on my beagleboard
[14:08] <rbelem> no keyboard, mouse
[14:08] <rbelem> there is a bug for that
[14:09] <rbelem> usb otg support is missing
[14:09] <ogra_> must be an old beagle then
[14:09] <rbelem> yup
[14:09] <ogra_> (i dont think we test on anything older than XM anymore)
[14:10] <ogra_> though with the new headless images we might start that again
[14:10] <rbelem> but it is omap3
[14:10] <ogra_> yeah, but it has 256M
[14:10] <ogra_> not suitable for running a desktop on it
[14:10] <rbelem> yeah... too slow
[14:12] <rbelem> Riddell, the image that i tested is from http://cdimage.ubuntu.com/kubuntu-mobile/daily-preinstalled/current/
[14:12] <Riddell> rbelem: well that's ARM not i386
[14:12] <rbelem> ops
[14:12] <rbelem> that i test on beagle
[14:13] <rbelem> brb
[14:21] <Riddell> mvo: hmm, maybe we should revert the workaround for bug 656876
[14:22] <mvo> Riddell: if that works fine now, I'm happy to do it
[14:24] <Riddell> mvo: well we'd need to test to be sure, let's leave it disabled for beta 1 and enabled it next week and test, I've filed bug 746431
[14:24] <mvo> thanks Riddell
[14:31] <seiflotfy> hey guys
[14:32] <seiflotfy> any1 successfully using an external monitor with natty
[14:32] <Riddell> how's this https://help.ubuntu.com/community/NattyUpgrades/Kubuntu ?
[14:32] <pitti> seiflotfy: I do that all the time (laptop in dock)
[14:32] <seiflotfy> pitti, its not working here
[14:32] <seiflotfy> when i request to change to an external monitor
[14:32] <seiflotfy> the external monitor keeps flickering
[14:33] <RoAkSoAx> seiflotfy: Intel Video card?
[14:33] <seiflotfy> yeah
[14:33] <RoAkSoAx> seiflotfy: that's a known bug
[14:33] <seiflotfy> crap
[14:34] <RoAkSoAx> seiflotfy: you have two options. 1. don't disable LVDS
[14:34] <RoAkSoAx> seiflotfy: or turn off LVDS with xrandr
[14:34] <seiflotfy> how do i turn off lvds
[14:35] <pitti> seiflotfy: ah, I have that effect as well -- I can't use gnome-display-properties ATM
[14:35] <pitti> seiflotfy: xrandr --output LVDS1 --off
[14:35] <pitti> seiflotfy: that's what I have in my "session setup" script
[14:35] <pitti> seiflotfy: presumably like you I don't want the internal monitor to be on all the time while hte laptop is closed in the dock
[14:35] <RoAkSoAx> bug #737891
[14:35] <pitti> hah, that's my chipset
[14:35] <pitti> oh, I'm on DVI
[14:36] <RoAkSoAx> pitti: I guess that's the same issue as with VGA then
[14:36] <pitti> it worked fine until maverick, and broke at some point in natty :(
[14:36] <RoAkSoAx> yeah
[14:36] <RoAkSoAx> same happened to me
[14:36] <pitti> I just tend to forget, as I have that xrandr thing
[14:37] <RoAkSoAx> hehe yeah eventually I ended up using the same approach
[15:02] <pitti> cjwatson: I just committed http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/natty/apport/ubuntu/revision/1763 for bug 745455; but then it came to my mind that this might actually be too much? Should we just read a subset of files as root?
[15:03] <pitti> (aside from the leftover print, just removed)
[15:04] <pitti> cjwatson: or perhaps just do the root thing on the live system, but not on the installation?
[15:17] <cjwatson> pitti: I vaguely remember it's just syslog that needs root
[15:17] <cjwatson> let me check
[15:17] <pitti> cjwatson: that bug was about casper.log
[15:17] <pitti> cjwatson: (that one I could reproduce easily on the live system)
[15:17] <cjwatson> ah, no, it's all installer logs
[15:18] <pitti> cjwatson: I was just wondering if we coudl potentially expose passwords where we shouldn't
[15:18] <cjwatson> that is a problem, but won't they be marked private?
[15:18] <pitti> so instead of reading them we could also ignore htem
[15:18] <pitti> cjwatson: crashes yes, but not bug reports (ubuntu-bug ubiquity)
[15:18] <cjwatson> passwords shouldn't generally end up in the log (unless people are running in debug mode) - making the logs private was just an extra safety measure
[15:18] <pitti> (we can tell them apart in the hook if necessary)
[15:19] <cjwatson> not having the logs would make the reports useless, for the most part
[15:19] <pitti> right, that's what I thought
[15:19] <pitti> but I wondered if there was one file which we shouldn't attach, or perhaps pre-process
[15:19] <pitti> cjwatson: e. g. for the debug log we could use "grep -v password" instead of "cat" or similar
[15:19] <cjwatson> the file that might contain passwords if several other things simultaneously go wrong is also the most useful file to have
[15:20] <cjwatson> and I'd be worried about preprocessing making it difficult to diagnose certain bugs
[15:20] <soren> "Please enter your password, so that we can filter it out of your bug report"
[15:20] <cjwatson> there's already a visible warning in debug mode saying that you shouldn't use a valuable password
[15:20] <cjwatson> so to be honest I think it's OK to do as you did
[15:20] <pitti> soren: I literealy meant "password", i. e. usually there's some debugging context around
[15:20] <pitti> cjwatson: ok, thanks
[15:20] <pitti> cjwatson: sounds fine, but better to have a second pair of eyes on it
[15:20] <soren> pitti: I know, I'm just joking around :)
[15:21]  * pitti just notices that his literally typo was an interesting morphing of that and "really"
[15:29] <highvoltage> Edubuntu currently doesn't have an amd64+mac spin. Should it?
[15:30] <cjwatson> I suspect IS would kill me for the extra gigabytes of disk on cdimage
[15:31] <highvoltage> I would not like you to be killed
[15:31] <highvoltage> (and to be honest I'm not /that/ fond of having another image to test)
[15:32] <highvoltage> What should we do though? Tell mac users "sorry we don't support you"?
[15:32] <ohsix> tell them to install ubuntu then edubuntu-desktop :D
[15:32] <charlie-tca> Can they install the Ubuntu image and then upgrade?
[15:33] <pitti> OOI, does the amd64+mac image also work on "normal" amd64 machines?
[15:33] <ohsix> what does +mac involve, just some efi bits? couldn't there be one volume?
[15:33] <pitti> i. e. could we just have that?
[15:33] <charlie-tca> That is what Xubuntu tells them. Just install the mac/ppc image from Ubuntu and then install xubuntu-desktop
[15:33] <highvoltage> charlie-tca: mostly. some of the biggest edubuntu features are installer related, so it might miss the point though
[15:34] <ohsix> highvoltage: like the stuff that picks the different meta packages for grade levels?
[15:34] <highvoltage> ohsix: yep, and the LTSP installer and LTSP live, and the Unity session stuff, and more language options
[15:35] <ohsix> hmm
[15:36] <ohsix> shrug
[15:36] <highvoltage> I wonder if the standard amd64 iso will work with refit
[15:37] <highvoltage> it would be an easy enough workaround if it does, which we could just include in the release notes
[15:38]  * highvoltage should've bought his mac mini to the office today
[15:38] <ohsix> is there something that precludes all volumes being +mac besides space?
[15:39] <highvoltage> if space is the issue then the default edubuntu 64bit iso could just be +mac
[15:39] <pitti> DVDs should certainly not have much of a problem with that
[15:39] <pitti> on CD images it's got a bigger impact; e. g. the ubuntnu desktop amd64+mac has been oversized for ages
[15:40] <pitti> it's not any more, but there are only very few languages on it now
[15:40] <highvoltage> the edubuntu DVD is 2.5G, so a few extra 100K won't kill it :)
[15:41] <pitti> highvoltage: at least the description on http://cdimage.ubuntu.com/daily-live/20110330/ makes it sounds like it should _also_ work on mac, not _only_
[15:41] <cjwatson> pitti,ohsix> the normal amd64 can boot on UEFI-only machines, but not on Macs; amd64+mac is vice versa
[15:41] <cjwatson> because Apple screwed up their firmware
[15:41] <ohsix> weird
[15:41] <highvoltage> :/
[15:41] <pitti> ah, thanks; so it's not really a hybrid, it's an either-or
[15:42] <cjwatson> at least many common versions of Mac firmware refuse to boot from a multi-catalog ISO9660 image
[15:42] <ohsix> so i couldn't use the amd64 image on my main computer which isn't uefi but has 64bit gear in it?
[15:42] <cjwatson> and multi-catalog is necessary to support UEFI
[15:42] <cjwatson> ohsix: unless it's a Mac, you should be fine
[15:42] <cjwatson> it's multi-catalog, so in general it should work with either BIOS and UEFI; Mac firmware is just useless
[15:43] <cjwatson> s/ and / or /
[15:43] <ohsix> so the +mac spin just has the one catalog with the mac files on it
[15:43] <cjwatson> +mac actually means "no UEFI bits"
[15:43] <cjwatson> but I thought it would be confusing to call it +noefi or something because Macs do have EFI
[15:44] <ohsix> hm
[15:44] <ohsix> oh right, they call efi uefi now huh
[15:44] <highvoltage> if refit (http://refit.sourceforge.net/) works, would it be fine for Edubuntu to recommend it as a workaround on Mac systems? this also only seems to affect 64 bit, so we could also suggest using 32 bit on macs, right?
[15:44] <cjwatson> UEFI is a newer version that has a multi-vendor standard
[15:44] <cjwatson> EFI 1.x was AIUI proprietary
[15:44] <ohsix> it doesn't just mean the old stuff they called uefi which was an efi firmware that did nothing but run legacy stuff with a bios stub
[15:44] <cjwatson> (in the sense of being specific to a particular vendor)
[15:45] <ohsix> being intel on ia64? that's the rub, it was specified
[15:45] <cjwatson> highvoltage: sure, I'm pretty sure on the machines I remember, refit didn't work
[15:45] <highvoltage> cjwatson: ok
[15:45] <cjwatson> ohsix: some x86 machines too.  and if you read what I said carefully I didn't say it wasn't specified
[15:45] <cjwatson> anyway, this is beside the point
[15:46] <ohsix> well i was speaking to proprietary
[15:46] <cjwatson> proprietary doesn't mean unspecified
[15:46] <ohsix> the uefi stuff i'm familiar with doesn't even try to be ufi-e, it just boots the bios thing, the and the boot time setup is a native efi application that touches the config pages
[15:47] <ohsix> that was to say apple didn't just come up with something else called EFI independently
[15:47] <cjwatson> there are different classes specified with different levels of compatibility
[15:47] <cjwatson> I didn't say they did, but they did break various bits of the spec
[15:47] <cjwatson> such as it was
[15:47] <ohsix> alright well don't let me distract you, i was the one that was confused
[15:47] <cjwatson> I would love amd64+mac not to need to exist, but I don't know of a way to avoid it right now, short of not supporting Mac hardware which I figure wouldn't be popular
[15:48] <ohsix> so suffice it to say uefi says a bit more about where a vendor should stay in the lines
[15:48] <cjwatson> I'm pretty sure Apple also violate EFI 1.x, FWIW - their partitioning strategy is not as specified there
[15:49] <cjwatson> (as one example)
[15:49] <ohsix> right
[15:49] <ohsix> afaik it's only used for dropping firmware updates and running them at boot time, and otherwise barren (the system partition)
[15:49] <cjwatson> that's not the bit I'm referring to
[15:50] <cjwatson> I mean legacy MBR vs. protective MBR
[15:50] <ohsix> ah
[15:51] <ohsix> re: refit, i wonder if some little cd image or something that ran in osx then rebooted into the install couldn't be used
[15:54] <ohsix> to do firmware updates they drop the update in the system partition and bless it; then the firmware blesses the main thing when it's done, it'd be ugly but it could be done ;]
[15:56] <cjwatson> feel free to try to produce something portable - it's not something I'm likely to do
[15:57] <ohsix> i don't have the hw to even begin to be messing with stuff
[16:02] <highvoltage> "Choose this to take full advantage of computers based on the AMD64 or EM64T architecture (e.g., Athlon64, Opteron, EM64T Xeon). If you have a non-64-bit processor made by AMD, or if you need full support for 32-bit code, use the Intel x86 images instead. This image is adjusted to work properly on Mac systems.
[16:02] <highvoltage> "
[16:02] <highvoltage> that sentence on http://cdimage.ubuntu.com/daily-live/20110330/ sounds a bit bogus imho, since it's irrelevant whether AMD made the CPU or not
[16:03] <highvoltage> (and it's otherwise very unhuman)
[16:05] <ohsix> highvoltage: "amd64" is the actual arch name
[16:05] <ohsix> em64t is what intel calls it
[16:07] <ohsix> and they mention the one confusing case of an amd processor that doesn't support 64bit, which is doubly confusing because its in the arch name _and_ some model names :P
[16:14] <highvoltage> It would be better in my opinion to have something like "This image is similar to the 64bit installer above, but exclusively supports Intel-based Macs that aren't supported by the default the Ubuntu installer."
[16:15] <ohsix> that's something other than your original comment, no?
[16:17] <highvoltage> yes. my original comment was that the paragraph is bogus, and my last statement was a suggestion on how it could be improved.
[16:18] <ohsix> file a bug :P
[16:19] <cjwatson> (bugs welcome on https://bugs.launchpad.net/ubuntu-cdimage)
[16:21] <charlie-tca> How will people know if their processor is supported by the default Ubuntu installer?
[16:24] <hallyn> Daviey: well, open-vm-dkms compiles fine with the new version, but my clipboard doesn't work with it.  A new version was released two days ago :)  I'm going to try that, bc i'm a glutton for punishment.
[16:28] <Daviey> hallyn, oh joy!
[16:30] <pitti> (IOW, beta freeze lifted)
[16:30] <pitti> didrocks, seb128 ^
[16:31] <didrocks> nice :)
[16:31] <seb128> pitti, I noticed the stack of accepted email,, thanks ;-)
[16:32] <pitti> buildds are still busy with various gc* packages, though
[16:33] <hallyn> hm, i'm being hit by bug 494445
[16:33] <hallyn> cjwatson: did you have to work around that, or was it really fixed for you?
[16:33] <hallyn> (i'm on uptodate natty)
[16:37]  * hallyn goes the non-udd way for now
[16:39] <steveire> pitti: ping?
[16:39] <pitti> !ping
[16:40] <pitti> bah
[16:40] <pitti> steveire: pong (but busy); please don't ping, just ask your question :)
[16:41] <steveire> pitti: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/680088 Your comment there seems irrelevant to me because you talk about going from 10.10 to 11.04 and the issue was originally about 10.04 to 10.10 upgrades. You request for testing is irrelevant to the original issue, right?
[16:42] <steveire> pitti: Ah, I think Riddell clarified.
[16:42] <pitti> steveire: it shouldn't be; a 10.04->10.10 upgrade will use update-manager from 10.10
[16:43] <pitti> steveire: (we do that because it's easier to fix stuff in the later release)
[16:44] <cjwatson> hallyn: I don't think I ever rechecked following James' fix, so I probably worked around it
[16:44] <pitti> steveire: so if you want to test a 10.04->10.10 (with proposed) upgrade, that'd be much appreciated
[16:44] <cjwatson> IIRC I just committed the same deltas by hand
[16:44] <pitti> steveire: that's "update-manager --proposed"
[16:44] <steveire> pitti: Ok, will do
[16:44] <pitti> steveire: thanks!
[16:45] <hallyn> cjwatson: do you recall how you worked around it?  Did you just create that tag?
[16:45] <hallyn> i'm wondering if it'll break something if i tag the '-0ubuntu1' release with the 'upstream-' tag
[16:45] <cjwatson> 16:44 <pitti> steveire: that's "update-manager --proposed"
[16:45] <cjwatson> err
[16:45] <hallyn> it certainly seems wrong
[16:45] <cjwatson> 16:44 <cjwatson> IIRC I just committed the same deltas by hand
[16:45] <cjwatson> I don't remember any more than that, sorry
[16:45] <hallyn> oh there i see it :)
[16:45] <hallyn> thanks
[16:46] <cjwatson> I don't think I gave a monkey's about the upstream-* tags
[16:46] <hallyn> all right, i'm just doing it without bzr for now.  thanks :)
[16:46] <cjwatson> all I wanted was to get the PPA uploads represented in bzr somewhere
[16:46] <cjwatson> hallyn: oh, I did it in bzr, I just didn't use bzr import-dsc to do it.  you can just successively apply diffs, add files, and commit ...
[16:46] <cjwatson> (assuming you're starting from an existing branch)
[16:47] <hallyn> existing branch, but huge delta.
[17:04] <Daviey> mvo, does squid deb proxy work with extras.ubuntu.com?  Someone is reporting to me that it is 403'ing
[17:06] <mvo> Daviey: let me double check
[17:06] <mvo> Daviey: its in the default config, but maybe this user decided to use a custom one?
[17:07] <mvo> Daviey: when the conffile prompt hit him? it was left-out in early versions. or is he using lucid/maverick on the server?
[17:08] <Daviey> mvo, checking
[17:56] <barry> @pilot in
[18:01]  * dholbach hugs barry
[18:03] <zul> ev: ping for the samba bug, couldnt ubiquity do something sensible and not allow more that 16 characters in a hostname?
[18:04] <ScottK> Why is a 16 character hostname limit sensible?
[18:04] <ev> zul: this is a limitation in netbios, not linux.
[18:05] <ev> ScottK: indeed
[18:06] <ev> I think this is best solved where the problem arises, in Samba.  I can talk to another machine with more than 16 characters in its hostname using every other network protocol I can think of.
[18:06] <ev> equally, you can set the hostname outside of the installer, so even if we did this in ubiquity, the problem would remain.
[18:07] <zul> ev: right its a problem with netbios...so something like print a warning or something
[18:08] <ScottK> RFC 1123 says "Host software MUST handle host names of up to 63 characters and SHOULD handle host names of up to 255 characters."
[18:08] <zul> ScottK:  right ill get on changing the netbios protocol
[18:09] <ScottK> I understand the problem.
[18:09]  * ScottK imagines a netbios equivalent for hostnames of 8.3 long/short filenames.
[18:15] <ogasawara> cjwatson: hi, I just tried to upload a new linux-backports-modules-2.6.38 but it was rejected.  I assume it's due to the fact it still needs added to the proper ACL's first before I can pull the trigger.
[18:17] <cjwatson> sure, I'll do that
[18:18] <bdmurray> glatzor: it looks like bug 707490 might not be fixed
[18:18] <cjwatson> ogasawara: try now
[18:18] <Daviey> ScottK, Your quote of RFC 1123, is that in regards to zul's suggestion of ubiquity limiting the hostname to 16 chars - or a bug in the netbios protocol?
[18:18] <ScottK> Yes.
[18:19] <Daviey> ScottK, it was a xor question.
[18:19] <ScottK> Sorry, that's how the result parsed.
[18:19] <soren> Daviey: How do you pronounce "xor"?
[18:20] <Daviey> soren, I'm not exclusive either way, but usually x-or
[18:20] <soren> Daviey: Just wondering since you said "a xor" and not "an xor".
[18:20] <soren> Daviey: Nice pun, though :)
[18:21] <Daviey> soren, I'll make sure i check my grammar before making comment next time, thanks for the hint :).
[18:21]  * soren has his red marker ready
[18:22] <soren> Daviey: Seriously though, I was genuinely curious if there was a way to pronounce it that would make it an "a" word rather than an "an" word :)
[18:22]  * soren wanders off again
[18:23] <Daviey> :P
[18:23] <ogasawara> cjwatson: thanks, I'm able to upload now
[18:23] <cjwatson> soren: I've been known to say something like a hard "zor"
[18:23] <cjwatson> I can pronounce initial-consonant "x"
[18:26] <barry> soren, cjwatson i've always pronounced it ecks-or
[18:27] <zul> http://dictionary.reference.com/browse/xor
[18:27] <barry> of course, i realize that people pronounce __init__ as "dunder-init" instead of the way i say it: "under under init"
[18:43] <dpm> hi cjwatson, could you approve my e-mail on appdeveloper week on the ubuntu-devel moderation queue? thanks!
[18:44] <pitti> dpm: done
[18:48] <dpm> thanks pitti :)
[19:24] <broder> hmm...is grub going to change the tty setup enough that it would break the kernel's "you're using a 64-bit kernel on a 32-bit system" message?
[19:28] <cjwatson> broder: it may actually bypass it altogether
[19:29] <cjwatson> broder: that check seems to be on the 16-bit boot path
[19:30] <Daviey> cjwatson, it's looking more like we will need the isc-dhcp patch... Would you nack the idea of me uploading it now, and submitting it upstream concurrently?
[19:30] <broder> cjwatson: can grub theoretically do that detection? :)
[19:31] <cjwatson> Daviey: as long as you're on the hook for dealing with any regressions ...
[19:32] <cjwatson> broder: GRUB can certainly detect CPU capabilities ('cpuid -l'); what I'm not sure if it can do is detect what the kernel it's booting needs, since I'm not seeing it in the kernel header
[19:32] <broder> cjwatson: for my use case, i'm ok with hard-coding "is this a 32-bit cpu"
[19:33] <cjwatson> 'if cpuid -l' or 'if ! cpuid -l' as appropriate
[19:33] <SpamapS> whoa.. ubuntu-docs bzr branch is a little bit ridiculous ..
[19:33] <SpamapS> 376844kB   136kB/s \ Fetching revisions:Inserting stream:Estimate 56124/56188
[19:33] <micahg> doko: I believe we can drop gcc-4.1, but gpc-4.1 has an rdepends of gpc, is this needed
[19:33] <Daviey> cjwatson, yup.
[19:34] <Daviey> SpamapS, What docs are you working on?
[19:34] <broder> cjwatson: awesome, thanks
[19:34] <SpamapS> Daviey: the server guide
[19:36] <SpamapS> I'm guessing there are a lot of screenshots in this bzr branch
[19:41] <Daviey> SpamapS, Great!
[19:41] <SpamapS> Hrm.. I don't see the server guide there at all
[19:46] <Ampelbein> hi. does http://paste.ubuntu.com/587929/ (from https://launchpadlibrarian.net/67807729/buildlog_ubuntu-natty-i386.checkstyle_4.4%2Bdfsg-5_FAILEDTOBUILD.txt.gz) look like it could be a serious problem on the builders/in gcj-4.4-jre-headless?
[20:16] <broder> cjwatson: is there something like a panic command in grub script?
[20:16] <slangasek> cjwatson: patch archaeology question; do you know why in pam, the RLIMIT_NICE defaults are being set to what they are?  They don't match the kernel, and I can't find any way that this ulimit has any effect at all on setpriority() behavior
[20:17] <slangasek> cjwatson: this is debian/patches-applied/ubuntu-rlimit_nice_correction, formerly debian/patches-applied/061_pam_rlimits_nice_rtprio, added to fix bug #17348
[20:17] <slangasek> (... in 2006)
[22:15] <hallyn> skaet: Daviey: on bug 727342, testing (on the new package I've referenced there) is good.
[22:20] <skaet> hallyn,  good to know.   Thanks for flagging.
[22:30]  * RoAkSoAx made it to DFW. Austin here i come
[22:37] <seb128> slangasek, hi
[22:38] <seb128> slangasek, you might want to review https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/libxklavier/natty-201103311620/+merge/55787 since you did the upload
[22:43] <slangasek> seb128: <blink> ok
[22:43] <seb128> slangasek, dunno what's going on, james_w opened a bunch of those
[22:44] <seb128> slangasek, btw was the patch forwarded upstream? there is no bug reference in the upload
[22:44] <slangasek> james_w: https://code.launchpad.net/~ubuntu-branches/ubuntu/natty/libxklavier/natty-201103311620/+merge/55787 - seems to be something the importer should fix up on its own?
[22:45] <slangasek> (and why am I not allowed to reject UDD merge requests?)
[22:46] <slangasek> seb128: I upstreamed it to Debian as Debian bug #620110, I don't know how to find the right place to send such things to upstream directly
[22:47] <TheMuso> lol at the bug title.
[22:49] <seb128> slangasek, https://bugs.freedesktop.org/enter_bug.cgi?product=libxklavier
[22:49] <seb128> slangasek, if you have a fdo account
[22:51] <slangasek> seb128: I don't think I do... :)
[22:51] <seb128> slangasek, ok, well we will forward it for you when we merge on debian next cycle if they didn't do it by then ;-)
[22:52] <slangasek> ok :)
[22:54] <TheMuso> GrueMaster: Are patches being worked on for OMAP4 etc for alsa-lib and/or pulseaudio? Or, are there patches you can point me to? I have to upload revisions of both pulse and alsa-lib in the coming few days, so I'd like to encorporate all the fixes into one upload for each package.
[22:55] <ogra_> TheMuso, we are still waiting for TI, i will ask in tomorrows call
[22:55] <TheMuso> ogra_: Ok thanks.
[22:55] <ogra_> slas-lib should be a trivial config file for omap4 UCM
[22:55] <ogra_> *alsa-lib
[22:56] <ogra_> i'm not sure how heavyweight the pulse ones are though
[22:56] <doko> micahg: yes, I know. will care about it tomorrow
[22:56] <TheMuso> ogra_: Ok cool.
[22:57] <micahg> doko: ok, thanks, I still hope to clean up gcc-4.3 before beta 2
[23:22] <barry> @pilot out
[23:45] <slangasek> broder: you don't happen to understand the build system of root-system, do you?  I see you touched it in lucid...
[23:46] <slangasek> it's been removed from Debian pre-squeeze though, so maybe we should just drop it