[00:22] <sistpoty> crack, finally finding the details, the mksh build failuer is actually caused by a false positive (gcc) of a non-reproducible false-positive (LP buildd). :(
[00:28] <RoAkSoAx> hey guys I was wondering if i can create a temp file in an apport hook and then attach it to the report with attach_file?
[00:29] <RoAkSoAx> or we should not be creating temp files in apport hooks
[01:00] <hdon> hmm, i think 2.6.31-20 broke my nic
[01:20] <RoAkSoAx> cjwatson, do apport hooks have to be under both binary-{arch,indep}
[01:33] <micahg> kees: ping re firefox
[02:06] <RoAkSoAx> is apport already running hooks via attach_related_packages?
[02:15] <lamont> sistpoty: does this mean it will actually bootstrap this time?  because it didn't the last time I was told it would... (fpc)
[02:28] <m4t> i'm trying to do a make-kpkg build of 2.6.33, and at the end it fails with: The UTS Release version in include/linux/version.h "" does not match current version: 2.6.33
[02:29] <ion> I’m reading the topic.
[02:31] <m4t> works fine if i change $fh->sysread to $fh->read
[02:31] <m4t> even with the eof
[02:31] <kees> micahg: hi! sup?
[02:34] <m4t> oh, it was moved to generated/utsrelease.h?
[02:34] <m4t> from 2.6.33 changelog:     kbuild: move utsrelease.h to include/generated
[02:36] <persia> m4t: You may find that the folks in #ubuntu-kernel are more likely to have individual knowledge about this sort of thing (although some folk here do as well)
[02:37] <m4t> persia , i found a existing bug on debian, http://osdir.com/ml/debian-bugs-dist/2010-02/msg09866.html
[02:38] <persia> m4t: That works too :)
[02:38] <m4t> http://launchpadlibrarian.net/37497839/kernel-package-2.6.33.patch
[02:38] <persia> although the syntax "Debian bug #571716" tends to be more informative with our channel bots.
[02:39] <m4t> ah cool
[02:39] <m4t> i mostly idle ;/
[02:41] <persia> For ports architectures, we use the ports.ubuntu.com mirror, even for arch:all packages.  Is there a way to construct a sources.list file that would pull arch:all packages from a local mirror, and arch:any packages from ports.ubuntu.com ?
[02:45] <m4t> make-kpkg patch per launchpad seems to fix issue.
[02:48] <micahg> kees: do you have the daily prism build installed?
[02:48] <kees> micahg: since I don't know what that is, no. :)
[02:49] <micahg> kees: when I removed prism, I was able to start your profile again
[02:49] <persia> lamont: How didn't fpc bootstrap?  It really worked for me.
[02:50] <kees> $ apt-cache policy prism
[02:50] <kees> prism:
[02:50] <kees>   Installed: (none)
[02:50] <kees>   Candidate: 1.0~b2+svn20090813r49078-0ubuntu2
[02:50] <kees> micahg: were you able to start it twice in a row?
[02:50] <micahg> ugh, no, not after reinstalling greasemonkey, sorry
[02:50] <micahg> but prism seems to exhibit the same issue
[02:51] <persia> lamont: On an unrelated note, do you happen to know when the ia64 and hppa ports were first introduced on ports.ubuntu.com?
[02:52] <lamont> ia64: warty
[02:52] <lamont> or maybe hoary
[02:53] <lamont> though ISTR it was live for warty - thanks to some incredible effort by Thibaut
[02:54] <persia> I put warty in the code I used, so I think I'll leave it there in case you remember correctly (not that I expect anyone is actually planning an upgrade from a warty install any time soon)
[02:54] <lamont> hppa/sparc showed up in hoary, but didn't get into the DC until we got hardware in - ISTR hppa was there for breezy/dapper (or not in dapper - don't recall when LP started building everything), and then back in feisty IIRC
[02:55] <persia> Was sparc on p.u.c for hoary?  I know it was on archive by dapper.
[02:55] <lamont> amusingly, I just nuked the hoary archive of hppa off of people.u.c within the last 9 months or so - finally noticed it was chewing up space
[02:55] <persia> heh
[02:55] <lamont> we bootstrapped both architectures together, using hoary
[02:55] <lamont> but not sure when sparc actually landed in the archive - hppa was way late landing for hoary, so it came in with breezy
[02:56] <lamont> and even that was broken when we shifted to LP
[02:57] <lamont> and on that note, I think it's time for me to sleep
[02:57] <persia> Right.  Seems like I do have to adjust the code after all.  Do you know if there exists an authoritative resource, or is it all just left in human memory now?
[02:57] <persia> lamont: tell me about your fpc issue first :)
[02:57] <lamont> old-releases.ubuntu.com comes to mind...
[02:58] <lamont> persia: with the best understanding of which packages to grab from sid, it was FTBFS - I wasn't actually the one flying that, so not sure what the actual error was.
[02:58] <persia> Doesn't differentiate ports vs. archive, but I'll take a look there.  Thanks.
[02:58] <lamont> a clearer "install the following packages from sid and it _WILL_ build from source" would be wonderful
[02:59] <persia> I'll retry, and go chase Ng then.  Do you have a preferred format, or would another entry like "Installing fp-compiler, fp-units-base, fp-utils, and fp-units-rtl from Debian sid on a lucid machine permitted this build" work.
[02:59] <lamont> I have dapper/sparc and {warty-dapper}/powerpc as non-ports, ia64 and hppa as ports regardless of release
[03:00] <lamont> bonus points if you include version numbers
[03:00] <persia> I'll do that.  Thanks.  Have a good night.
[03:01] <lamont> see also bzr brnach lp:~lamont/launchpad-buildd/chroot-scripts
[03:01] <persia> I also have edgy powerpc as non-port, and edgy/feisty/gutsy sparc.
[03:01] <persia> Oh excellent!
[03:01] <lamont> ah, well... to be fair, that script kinda went lalalalala DO NOT CARE when it comes to edgy-gutsy
[03:01] <lamont> corrections welcome
[03:03] <lamont> persia: and yeah, Ng was pilot testing my instructions for doing the bootstrap, so he would be the right one to push on
[03:03] <persia> Assuming it makes sense to me, I'll send a patch.  I'm hoping to have both python-apt and mk-sbuild be correct.
[03:03] <persia> And I'll probably want to try to encourage you to use mk-sbuild for future chroot scripts :)
[03:03] <lamont> that code is how I build lp and non-lp chroots, fwiw
[03:04] <persia> (assuming I can bring it to feature parity)
[03:04] <lamont> pretty sure you don't want to grow all the limbs that scriptage has
[03:04] <lamont> no sane coder would
[03:04] <lamont> but yeah, I'd definitely be interested
[03:04] <persia> But I do want to have a tool in-archive that lets developers mimic the buildd chroots for local builds, so ... :)
[03:05] <lamont> that's part of why I published the branch...
[03:05] <lamont> didn't feel up to packaging it though
[03:05] <persia> Oh my!  That is a lot of limbs.
[03:05] <lamont> yes, it very certainly is
[03:06] <lamont> the debian and xdebian swtiches are probably the most bizarre
[03:06] <wgrant> persia: Why not grab the real buildd chroots for local builds?
[03:07] <lamont> wgrant: sometimes it's quicker to just build new ones based on a local mirror
[03:07] <persia> wgrant: I don't know how.  Is there a stable way to pull them from an API and shove them somewhere for sbuild to eat?
[03:07]  * lamont sleeps
[03:08] <wgrant> persia: Retrieving them from LP was convoluted until a week ago, when I exported the URL on the API. The URL to the current tarball is now available at https://launchpad.net/api/devel/ubuntu/lucid/i386/chroot_url
[03:09] <persia> wgrant: I get an error loading that page.
[03:09] <persia> error on line 1 at column 1: Document is empty
[03:09] <wgrant> persia: Yeah, LP for some reason serves it as XHTML when it's actually plain text.
[03:09] <wgrant> View the source.
[03:09] <wgrant> Although I guess that tarball will have internal hosts in sources.list, and stock sbuild won't override them, so it's not that easy.
[03:10] <persia> Oh excellent.  So I should be able to construct a script that discovers the current URL, pulls it, unpacks/repacks/renames as needed for the local build tool, etc. ?
[03:10] <wgrant> Yep.
[03:10] <wgrant> Previously you had to dig through build logs and use an undocumented librarian search feature to get the real tarball.
[03:11] <persia> That's fine.  It oughtn't be hard to use some sane defaults.  I only wish pbuilder-dist and mk-sbuild were written in the same language: it makes it easier for them to share code.
[03:11] <wgrant> And I've had to do that a few times in the past, so I thought I'd make it easy.
[03:11] <persia> Thanks!
[03:11] <persia> I know we've had lots of issues in the past with stuff building fine locally and not in LP, and being able to do local tests to hunt down why helps.
[03:12] <persia> Mind you, we do have to make in-distro schroot/sbuild have the necessary features for them to be useful/used on the buildds, but that's presumably less painful.
[03:13] <wgrant> And a while away.
[03:14] <persia> Why?  It's too late for lucid, but is there a structural reason for the delay, or is LTS+1 sensible?
[03:14] <wgrant> It's Soyuz/buildd stuff. It will take forever.
[03:15] <persia> Ah.  I like to assume that's a factor of the number of available developers, rather than an axiom, but I'll take your word for it, as you're surely more informed.
[03:17] <wgrant> It is indeed a function of the number of available developers, but that is itself near to an axiom.
[03:17] <persia> 0^n == 0 kinda thing?
[03:18] <wgrant> Something like that.
[03:24] <Keybuk> less1: feel free to fire any questions at me, I'll answer when I'm by the computer
[04:06] <dehqan>  /var files permission , all have been 644 with my bad , is there anyway to restore permissions to default ?
[04:08] <dehqan> any opinion ?
[04:20] <jdong> is it intended that the empathy client be separate from the presence menubar [in lucid]?
[04:21] <jdong> I set up a chat client (jabber/gtalk) using the presence menu and afterwards it seems to have signed me into google talk
[04:21] <jdong> but it was not immediately obvious that for me to start a chat, I had to start Empathy separately to get my buddy list
[04:23] <ion> The panel item that looks like a snailmail letter provides a menu item for the Empathy main window.
[04:24] <jdong> ah, you're right.
[04:24] <jdong> but that seems a little bit unintuitive
[04:24] <jdong> the menu that I set my presence status seems like where I should be able to do other chat-related things
[04:24] <jdong> especially since AIUI the little textbox is for tweeting and such
[04:31] <persia> jdong: You're probably seeing rough edges.  indicator-me *should* abstract the client entirely, so that an arbitrary (set of) client(s) can use it effectively.  There may be a need for a richer feedback mechanism to ensure that things work as expected.
[04:40] <jdong> persia: *nods* ok, just want to make sure that is the case, and there's not some philosophical usability disparity
[04:41] <persia> jdong: There *is* a philosophical usability disparity, which needs changes to the underlying code in order to bring into alignment :)
[04:41] <persia> jdong: The difference being "We recommend this by default", and "This is how this is done".
[04:41] <jdong> ah :)
[04:42] <persia> jdong: So, if something doesn't work, please try to extend the flexibility inherent in the system so that it *does* work.  While this may have little apparent impact at the current time, it will significantly ease the adoption of new technologies as they become available.
[04:44] <jdong> with that said, is it intended that Lucid is going to ship without further improvements to indicator-menu?
[04:44] <jdong> and/or the presence menu
[04:46]  * persia suspects it to be the same as any other package: fix it if it's broken, but hope it works so that it doesn't need to be fixed
[04:47] <jdong> lovely
[04:48] <jdong> I just am concerned that this is going to confuse novice users
[04:51] <persia> Well fix it then.
[05:01] <ScottK> Depends on your definition of fix.
[05:01]  * ScottK suspects jdong's would collide with someone else's definition of feature removal.
[05:02] <jdong> what I don't understand is what "fix" means for the people who actually care about this new presence stuff.
[05:03] <persia> See, that's why I talked about the architecture.  If the DBus communication is extended, that doesn't affect user-perceived features, but it allows one to enable other use cases.
[05:03]  * persia actively works to separate presence from use of any given device, so is perhaps not an authority on what "fix" means in that context
[06:57] <less1> Keybuk: I am working on Internet booting for Ubuntu, and I want to find out if there is any work going on? and where and whom to contact for details and help for this work.  any pointers about this will be helpful.
[08:38] <persia> cjwatson: I end up referencing your packagesets reference often, but don't mean to highlight you with every reference.  Is that something that could be moved to ~ubuntu-archive (or do you have scripts that ignore highlights in URIs)?
[08:44] <cjwatson> persia: the fact that you highlight me serves as a periodic reminder to me to move it somewhere more sensible
[08:45] <persia> cjwatson: OK :)
[10:26] <geser> slangasek: re vim: I've updated the debdiff, added a comment why it IMHO doesn't need a FFe (and also a diffstat between the current version and the merged one). Let me know if I should add something else to improve the chances to get it sponsored.
[11:50] <kitallis> Ubuntu not applying for GSoC'10?
[12:58] <geser> cjwatson, slangasek: I gave a bzr merge of vim a try again and it worked this time (with bzr 2.1.0). A merge proposal is attached to the bug.
[14:00] <Keybuk> less1: I don't know what "Internet booting" is?
[14:00] <ogra_cmpc> Keybuk, boot through http ?
[14:01] <Keybuk> IP over Facebook!
[14:01] <ogra_cmpc> hehe
[14:02] <Nafallo> IPv6 over Facebook actually...
[14:02] <ogra_cmpc> wait until you have to maintain the ubuntuone initramfs hook for booting a shared image and make it boot in 10sec
[14:03] <Keybuk> Nafallo: why not go for IPv6 over Myspace; then you have double the irrelevance to the real world :p
[14:03] <Nafallo> Keybuk: lol. good one :-)
[14:05] <sebner> Keybuk: better you tell me how to get this shiny new bootsplash :P
[14:05] <ogra_cmpc> what for ... its gone before it can even be displayed ...
[14:05] <ogra_cmpc> we boot way to fast now
[14:06] <Keybuk> ogra_cmpc: ironically, that's one of the main bugs
[14:06] <Keybuk> the "Enter kills X" thing is because Plymouth hasn't switched to VT7 yet
[14:06] <Keybuk> because YOU BOOTED TOO DAMNED FAST
[14:06] <ogra_cmpc> yeah
[14:07] <ogra_cmpc> why dit we switch to plymouth again instead of just dropping usplash without replacement ?
[14:07] <sebner> ogra_cmpc: shiny animations \o/
[14:07] <ogra_cmpc> lol
[14:07] <sebner> Keybuk: nah, really. I still have the blue progress bares (yeah 2 of them) :\
[14:07] <Keybuk> ogra_cmpc: still needed something to deal with asking for passphrases, doing fsck progress, etc.
[14:07] <ogra_cmpc> i agree they make sense for livecd boots
[14:08] <Keybuk> sebner: stop using nvidia-glx? :P
[14:08] <ogra_cmpc> Keybuk, ah, yes ... silly encryption stuff and fsck ...
[14:08] <sebner> Keybuk: ahaha, right. Especially since the driver b0rkens the cards
[14:09] <Nafallo> is my santa rosa based lenovo actually allowed me to use the full bus, maybe I could boot fast too :-/
[14:10] <Nafallo> s/is/if/
[14:11] <Keybuk> sebner: you're not using glx?
[14:12] <sebner> Keybuk: As it doesn't seem to break my card, yes I'm still using it because as a MOTU I have the responsibility to perform deep checks on FFe packages (especially on games) *muahaha* :P
[14:13] <Keybuk> sebner: tseliot is working on the fix for you
[14:13] <Keybuk> which is to draw the splash in 16-color low-res vga mode
[14:14] <sebner> Keybuk: hmm correct me if you want but do we have 2010 now or 1990? :P
[14:14] <ogra_cmpc> ask your HW vendor :)
[14:15] <Keybuk> sebner: correct me if you want but are you using a non-free driver which we don't have the source to, so can't do anything about? :p
[14:15] <Keybuk> want decent graphics, kernel mode setting, etc.?  stop hating freedom <g>
[14:16] <sebner> Keybuk: want proper 3D, stop loving freedom :P
[14:16]  * Keybuk hides the face he's using nvidia-glx here
[14:16] <Nafallo> heh. I remember when infinity hex hacked the ati driver to use the correct Xorg paths ;-)
[14:17] <Nafallo> so clearly, we can do things with the closed source drivers :-P
[14:17] <sebner> Keybuk: hahah! :P
[14:17] <Keybuk> sebner: though I actually do intend to test nouveau/gallium stuff
[14:17] <Keybuk> I just only dist-upgraded my desktop to lucid yesterday
[14:17] <Keybuk> so haven't had a chance yet
[14:19] <sebner> Keybuk: I'm using lucid since ever but I really love to play games to I need the blob. It's just crazy that the blob drivers have 3D and much more but are not capable of doing that plymouth stuff. Maybe it's the other way round. plymouth intentionally uses technologies these don't have :P
[14:20] <ogra_cmpc> funny, every linux 3D game i ever tried worked fine on intel
[14:21] <Keybuk> sebner: oh, I don't care about the blob
[14:21] <Keybuk> the only reason I was using glx before is that nv didn't support the 7800
[14:21] <Keybuk> nouveau apparently does
[14:21] <Keybuk> enough basic 3D to run mutter or compiz is fine for me
[14:21] <Keybuk> if I want to play games I use a non-free operating system on a different partition ;)
[14:21] <sebner> Keybuk: nexuiz ftw! :P
[14:21] <sebner> uuhhh
[14:21] <sebner> Even worse :P
[14:21] <Keybuk> actually
[14:22] <Keybuk> mostly if I want to play games, I use the non-free operating system on the non-free hardware plugged into the TV downstairs :p
[14:22] <ogra_cmpc> ++
[14:22] <Keybuk> I'd hug my PS3 if it wasn't for the risk of burning
[14:26] <sebner> Keybuk: at least you don't have a XBOX so it's fine :D
[14:26] <Keybuk> no, I have some standards
[14:27] <ogra_cmpc> hey, the first gen xbox was fully sponsored by MS
[14:28] <sebner> heh
[14:30] <Nafallo> Keybuk: probably a non-free TV as well? ;-)
[16:11] <ScottK> Not if he's paid his license fees
[16:11] <ScottK> Oops, just notice how long ago that was ...
[16:14] <xnox> =)
[16:34] <bigon> when patching debian native packages should I use a diff system?
[16:41] <less1> Keybuk: its an attempt to boot ubuntu without having Ubuntu image on cd or usb, you boot ubuntu using the image over Internet using http.  Initial boot is done by gpxe
[16:42] <Chipzz> less1: that actually has 0 to do with the /boot/ process
[16:42] <Chipzz> or very little
[16:43] <ogra_cmpc> i thought that exists since quite a wile anyway
[16:43] <Chipzz> Keybuk is the maintainer of upstart, which is not what you want to work on
[16:43] <less1> Chipzz: humm.. so may I know where can I get more links about it?
[16:44] <Chipzz> less1: you need a way to get a root filesystem (which you may for example get over NFS), and make sure you don't write to i
[16:44] <ogra_cmpc> there was someone regulary posting to ubunt-devel-discuss about the implementation ... it exists since a while ... hardy i think
[16:44] <Chipzz> t
[16:44] <less1> thanks, I will try and search in their archive
[17:16] <lamalex> Is there a wiki page with a process of how to get a patch applied to a package?
[17:16] <lamalex> I've filed a bug and attached the patch
[17:18] <geser> there are several wiki pages that describe parts of the process
[17:18] <geser> does the package in question use a patch system?
[17:20] <lamalex> yeah, and I've used it to create the patch that I've posted on lp
[17:22] <geser> so you are at the step to create a debdiff (https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff) or doing the same with bzr (https://wiki.ubuntu.com/DistributedDevelopment/Documentation/WorkingOnAPackage and https://wiki.ubuntu.com/DistributedDevelopment/Documentation/SeekingSponsorship)?
[17:28] <lamalex> cool
[17:28] <lamalex> thanks genii
[17:28] <lamalex> er
[17:28] <lamalex> geser
[17:41] <cjwatson> bigon: no, don't use patch systems with native packages
[17:42] <cjwatson> lamalex: contrary to popular belief, any sort of patch is fine, since any self-respecting person with upload privileges can mangle it into the right form trivially - anyone who makes you reformat it into a debdiff is bureaucratically wasting your time :)
[17:43] <lamalex> I mean, a diff is a diff imo, I guess I'm mostly asking "how do I get my patch noticed/sponsored"
[17:44] <cjwatson> http://wiki.ubuntu.com/SponsorshipProcess and wait :-/
[17:45] <cjwatson> (obviously if you're seeking upload privileges yourself then you need to be able to put the patch in exactly the right form)
[17:47] <lamalex> yeah, I'm not at this time although I may try to get motu later
[17:51] <lamalex> proposed for merging, thanks cjohnston
[17:51] <lamalex> erg, cjwatson
[18:32] <crimsun> lamalex: which source package?
[18:33] <lamalex> crimsun, gnome-control-center
[18:33] <lamalex> lp 533888
[18:36] <Sarvatt> Keybuk: you might be a little disappointed because nouveau in lucid is not going to have any 3D acceleration support with the archive packages. lucid+1 will though and I already have it working in xorg-edgers
[18:39] <Sarvatt> but its in flux since we're changing how nouveau is brought into lucid yet again and blacklisting nouveau so lbm-nouveau continues working will be needed once the -16 kernel hits
[18:39] <Sarvatt> (for xorg-edgers nouveau 3D support that is)
[18:49] <crimsun> lamalex: merged, thanks for your contribution
[18:49] <lamalex> crimsun, thanks for yours :)
[22:03] <crimsun> unimatrix: apologies for the delay; applied and uploaded. Thanks for your contribution!
[22:13] <lamalex> Will gstreamer be updated to the new upstream release that was pushed out a day or two ago? we've got a prerelease version currently so I assume yes, but is there any way to get confirmation?
[22:14] <TheMuso> lamalex: I suspect so, but you'd best ask the desktop package maintainers, who are not around at the moment.
[22:14] <TheMuso> lamalex: They are in Europe for the most par.
[22:15] <TheMuso> part
[22:15] <lamalex> there seems to be a bug in the current packages which breaks dvd playback, so I'm hoping the new release fixes it
[22:15] <lamalex> TheMuso, thanks for the info though
[22:16] <TheMuso> lamalex: np
[22:33] <andreasn> anyone happens to have the template for mpt's "dotted paper"?
[23:52] <jibel> cjwatson, hey, did you talked with guillem about the fsync patch for bug 512096 ?
[23:52] <jibel> cjwatson, there was an important performance loss.
[23:56] <cjwatson> jibel: no, please point me to the thread