[01:21] <jdong> who do I beg for new bcmwl-kernel-source crack?
[01:22] <jdong> oh never mind... I am 5 days late to the party.
[02:30] <coolrave143> hi
[02:30] <coolrave143> i am trying to add iwconfig to initramfs
[02:30] <coolrave143> but it doesnt work
[02:30] <coolrave143> i tried to build it using static option
[02:30] <coolrave143> still i get error
[02:30] <coolrave143> /bin/sh: iwconfig: not found
[02:36] <slangasek> coolrave143: please see #ubuntu for support
[03:09] <ubuntu> bugs
[03:19] <ccheney> can we use deb v3 yet?
[03:20] <sistpoty> ccheney: yes
[03:21] <ccheney> sistpoty: ok
[03:21] <sistpoty> (actually uploaded a v3 package today ;))
[03:21] <ccheney> OOo just switched in debian today
[03:22] <ccheney> sistpoty: is lucid the first ubuntu version to support it?
[03:22] <ccheney> i'm wondering due to sometimes doing backports for OOo if i need to make sure to special case anything for them
[03:23] <sistpoty> ccheney: afaict there's (limited) support in karmic already, but lp couldn't handle it back then... you'd need to check dpkg changelogs for what works and what doesn't though
[03:23] <ccheney> sistpoty: ok
[03:24] <sistpoty> persia might now more details
[03:24] <persia> There's a couple oddities with that.  LP now has a backported dpkg that can support 3.0, but it also appears to have filters that block uploads of 3.0 packages to releases prior to lucid.
[03:25] <persia> I don't know all the details, but that's what I've garnered from backscroll.
[03:25] <persia> (and if more bugs are found in dpkg 3.0-handling, someone needs to merge, backport, etc., so some packages may be wonky)
[03:26] <ccheney> ok
[03:26] <persia> I *think* the best option is to try to convert packages to 3.0, and push them.  If they don't work, try against dak/Debian (you may have to hunt someone if you don't want to set this up locally).  If they don't work there, get it fixed, and get the fixes into lucid.
[03:27] <persia> I understand that the servers that run Launchpad are supposed to upgrade to lucid at some point (perhaps not right after release), so this saves later backport messiness (or should do so, at least)
[03:28] <ccheney> can you convert between debian versions in the same upstream version number?
[03:28] <ccheney> it seems debian is doing this for OOo between 3.2.0-1 and 3.2.0-2, but he hasn't actually uploaded -2 yet
[03:38] <persia> ccheney: I believe the only restriction on source format changes is that if your new .dsc references some original file it must carry the same checksums.
[03:38] <persia> So, for instance, if you have foo.orig.tar.gz, you need to use the same foo.orig.tar.gz, and not re-upload it.
[03:39] <persia> But otherwise, it should all be fair game (for the same reasons you can do things like convert from native to non-native or non-native to native with such a version)
[03:41] <persia> (but I could be wrong: I haven't actually ever played with archive acceptance code)
[03:55] <aburch> ccheney: You can.
[03:58] <ccheney> aburch: ok
[06:09] <zubin71> hi, im working on a small script which can helps programmers work at the linux terminal. its a work in progress and its hosted at code.google.com/p/pyautorun
[06:09] <zubin71> id like to have the script i wrote added to the ubuntu repository; what should i do?
[06:16] <persia> !newpackages
[06:16] <persia> zubin71: The NewPackages link there talks about the process, but we've just passed FeatureFreeze for the current release cycle.
[06:17] <persia> At this point, your best bet would be to work at getting it included in Debian, and Ubuntu will pull it from there to include it in the next release.
[06:19] <zubin71> persia : is getting a package accepted into debian similar to the procedure followed in ubuntu?
[06:20] <persia> zubin71: At a high-level, yes.  At a low-level not so much.
[06:21] <zubin71> persia : ok... thankx a lot! :)
[06:21] <persia> So, one still needs to have it packaged (either oneself, or by someone else), and get it reviewed, and sponsored by a developer (unless it is packaged by a developer who uploads themselves).
[06:21] <zubin71> i see...
[06:21] <persia> But one files a different kind of bug in a different bug tracker to request it, and uses a different upload site to get reviews, etc.
[06:22] <zubin71> hmm, so in order to get it reviewed by a developer should i just upload the project smwhere and post the link to the mailing list?
[06:23] <zubin71> would that do?
[06:24] <zubin71> !backports
[06:24] <persia> zubin71: There may be better documentation (you might want to ask in #debian), but http://www.debian.org/devel/wnpp/ may provide some hints.
[06:25] <zubin71> sure, will do...
[06:25] <zubin71> persia : thank you
[06:26] <persia> zubin71: Good luck.
[06:33] <wgrant> persia, ccheney: LP supports 3.0 (quilt) and 3.0 (native) in Lucid fine, with all current known fixes. If somebody manages to get the few remaining issues fixed in karmic-updates, we can permit it for Karmic too. And yes, you can change format at any time, as long as you don't try to change a file's content.
[06:35] <persia> wgrant: What are the remaining issues with Karmic?  Daviey wanted to upload something to a Karmic PPA earlier, and was unhappy that it was blocked.
[06:38] <wgrant> persia: There is at least that quilt compatibility issue that was just fixed in hardy-cat, but IIRC there are others too.
[06:38] <wgrant> I'm not sure of the details, though.
[06:38] <persia> Oh, so someone would have to backport dpkg to fix the various 3.0-related bugs?
[06:39] <persia> Would it be possible to permit uploads to Karmic with the recent hardy-cat changes, and have them end up as potential build-failures if the target archive didn't have a dpkg that supported whatever 3.0 features were required?
[06:40] <wgrant> At least the patches would have to be backported, yes.
[06:40] <wgrant> That would indeed work.
[06:41] <wgrant> Since Karmic's should be good for most packages, and the chroot's dpkg should be upgraded to the target's anyway.
[06:41] <wgrant> Upgraded before the unpack, that is.
[06:42] <wgrant> So maybe we should just go ahead and enable it.
[06:43] <persia> And whatever happens to be supported will work, and what doesn't can be made to work by pushing a fixed dpkg.
[06:43] <persia> Does that need a bug, or is it something where you can just turn off the rejection filter easily?
[06:44] <wgrant> Just needs somebody to execute a trivial INSERT on the production DB. A poke from a distro person in the direction of bigjools would achieve it pretty quickly.
[06:45] <wgrant> (the filter is just a (series, source format) whitelist table in the DB)
[06:46] <persia> Oh, that's easy.  Since bigjools and Daviey (mostly) share a timezone, I'll pass info around :)
[06:47] <lifeless> anyone run into 'GLib-WARNING gwpudi_r failed due to unknown user id(0)
[06:47] <lifeless> on boot
[06:48] <lifeless> bah, getpwuid_r I mean
[06:48] <lifeless> and boot splash staying up, no login prompt
[06:49] <persia> Just to make sure, root has uid 0 on that system, right?
[06:49] <lifeless> I sure hope so
[06:49] <lifeless> its my laptop
[06:49] <lifeless> also getty not running at this point, so can't debug
[06:50] <lifeless> also appears to be a heisenbug ><
[07:27] <coolrave143> hi
[07:27] <coolrave143> may i know which option to ./configure is used to specify custom lib path
[07:27] <coolrave143> --prefix would do ?
[07:31] <persia> coolrave143: You would probably do better asking in an autotools forum.  We generally receive configure scripts from various upstreams, and simply use whatever is documented in the upstream build instructions.
[07:32] <lifeless> [and we don't need custom lib paths]
[07:34] <stefanlsd> coolrave143: ./configure --help may help
[07:35] <coolrave143> okay
[07:40] <persia> lifeless: Well, it depends on the defaults :)  I've seen several packages that needed customised lib paths to follow FHS :)
[07:55] <chirag> hi
[07:59] <chirag> join
[07:59] <chirag> quit
[10:51] <dan4dm> hi - lintian stuff, I'm getting "debian-watch-file-in-native-package" but the package is not 'native' - the .orig.tar.gz has no watch file in it - any suggestions?
[10:52] <azeem_> dan4dm: ask in #ubuntu-motu
[10:52] <dan4dm> azeem_: k thanks
[10:54]  * persia isn't sure why this is specifically a -motu question, but it's being answered there, so it's not worth dicussing here in parallel.
[10:55] <azeem_> persia: sorry, I thought general packaging questions are more on-topic in #ubuntu-motu then here
[10:55] <azeem_> than*
[10:57] <persia> Used to be that way, but not anymore.  With the new plans for archive reorganisation, *all* the development teams are expected to participate in training new folk.
[10:57] <persia> So it's precisely the same amount on topic.
[10:57] <azeem_> ok, thanks
[10:58] <persia> (although people are more likely to get help from teams working in their area, so kubuntu-devel for KDE stuff, and ubuntu-desktop for GNOME stuff and xubuntu-devel for XFCE stuff, and ubuntustudio-devel for pro audio/video/graphics stuff, etc.)
[13:03] <Damascene> empathy is broken in Lucid
[13:06] <persia> Damascene: Have you filed a bug?  If not, please do.  If you think the issue may be local, please ask in #ubuntu+1
[13:14] <Damascene> it's working now after update
[13:14] <Damascene> I mean empathy
[14:22]  * iulian is looking for an SRU member to unsubscribe motu-sru from bug#525116.
[15:42] <ion> bryceh: xserver-xorg-video-all → xserver-xorg-video-nouveau → linux-backports-modules-nouveau-lucid-generic → linux-backports-modules-nouveau-2.6.32-14-generic → linux-image-2.6.32-14-generic dependency chain causes my box to have a -generic image in addition to the -generic-pae one i actually want to use. xserver-xorg-video-nouveau should probably have an alternative dependency on linux-backports-modules-nouveau-lucid-generic-pae.
[16:07] <bdrung> hi, persia told me to complain about the main sponsors queue. there are currently 122 bug in the queue. so every core-dev should pick at least one. i have done my job and the universe queue is empty.
[16:08]  * persia only redirected from -motu to here
[16:08] <persia> bdrung: What did you do with the cowsay patch that didn't actually fix the bug?
[16:08] <persia> Also, kudos to the kubuntu and server teams for having a relatively small set of bugs in queue.
[16:09] <bdrung> persia: subscribed ubuntu-reviewers (that's the team for converting patches into debdiffs)
[16:09] <persia> bdrung: You noticed that it had just been sent from reviewers to sponsors two days ago?
[16:10] <LaserJock> main sponsoring is tricky because there's quite a bit more sense of "ownership"
[16:10] <bdrung> persia: ups, no. didn't noticed that.
[16:10] <persia> bdrung: Maybe you just want to fix it :)
[16:10] <bdrung> LaserJock: is there a way for getting the "owner" of the package?
[16:11] <LaserJock> bdrung: there's a wiki page somewhere that kinda outlines some of it
[16:11] <LaserJock> but a lot of packages fall through the cracks (i.e. there's not really a defined owner or a very vague one)
[16:11] <persia> Note that the sense that there is a sense of "ownership" is as much of a problem as anything else.  Heaps of packages *don't* have an "owner".
[16:12] <persia> (and I've yet to encounter a package with an owner that didn't say "Thank you" for a fix, or even an upload (except in cases where there is a really complex upload process like the installer).
[16:12]  * micahg wishes someone would kick thunderbird out of NEW
[16:13] <LaserJock> I think there's probably a class of packages that are in Main because they are a dep of some package that people really care about, but the dep is not really as interesting
[16:14]  * bdrung wonders how long yofrankie will stay in NEW.
[16:16] <LaserJock> I found the risk of sponsorship in Main was also a decent bit higher
[16:17] <LaserJock> i.e. screwing up a Universe upload is often much less of a problem than say taking out gtk or xorg
[16:18] <Laibsch> There are ubuntu-10.04-beta-1 and ubuntu-lucid-alpha-1.  I guess that inconsistent naming got me a bit confused.  Is there a deeper meaning for using the numbers in one case and the release name in the other?
[16:18]  * Laibsch is talking about milestones in Launchpad
[16:19] <Laibsch> Alpha uses numbers, beta the release name and the final release again uses numbers.  Is that just coincidence?
[16:19] <LaserJock> could be but I'd guess it reflects the changing nature of the releases
[16:20] <LaserJock> the number version is the "official" naming scheme, whereas we use the codename more during development
[18:39] <EagleScreen> users really need a ncurses version of jockey
[18:39] <EagleScreen> overall when the graphics card is the matter
[19:23] <dupondje> asac: thx for thunderbird 3 :)
[19:48] <sebner> dupondje: I'd thank micahg ;)
[19:49] <micahg> what did I do?
[19:50] <nigelb> micahg: TB3
[19:51] <micahg> nigelb: ah
[19:51] <dupondje> yea its cool :)
[19:51] <dupondje> finally added
[19:51] <micahg> did someone finally release it from the NEW queue?
[19:52] <dupondje> seems so :P
[19:52] <dupondje> 3.0.1 is out btw :p
[19:52] <dupondje> rofl
[19:53] <micahg> dupondje: I know
[19:53] <micahg> and 3.0.2 is coming soon
[19:54] <dupondje> will you update it ? or will 3.0.0 stay the version in Lucid ?
[19:55] <micahg> dupondje: it'll be updated ...just not sure when
[19:57] <sebner> dupondje: one step after another is the motto here ;)
[19:57] <dupondje> yea true :)
[19:57] <dupondje> i'm already happy 3.0 is in lucid
[19:57] <dupondje> it was just a question ;
[19:57] <nigelb> micahg: in case I forget, thanks for the great work on TB :)
[19:58] <micahg> nigelb: you're welcome :)
[19:58] <dupondje> but seems there a some issues :(
[19:58] <dupondje> closing thunderbird, but doesn't seem to get killed .. :s
[19:59] <micahg> hmmm...I get that occasionally
[20:01] <dupondje> now it works :P strange
[20:02] <sebner> dupondje: let's hope for 3.0.x then :D
[20:05] <dupondje> 138 bugs fixed in 3.0.1 :p
[20:07] <micahg> dupondje: upload is ready whenever asac wants to release it :)
[20:08] <cjwatson> Laibsch: the difference is intentional - the intent is to use the codename through the alpha period (so that people don't get the impression that it's more solid than it is), and start using the numbers from beta.
[20:09] <cjwatson> Laibsch: so it's Lucid Alpha 1 but Ubuntu 10.04 Beta 1 - of course some confusion is to be expected but that's the standardised naming, since hoary/breezy or thereabouts
[20:09] <Laibsch> OK
[20:09] <dupondje> micahg: so we need to slap asac  ? ;)
[20:10] <Laibsch> cjwatson: thanks for clarifying. kind of confusing IMHO, but not a real issue.  I was just curious.
[20:10] <cjwatson> cf. the reason Debian uses codenames
[20:11] <micahg> dupondje: no, he has his own timetable :)
[20:11] <lifeless> cjwatson: why does debian use codenames?
[20:12] <cjwatson> http://www.debian.org/doc/manuals/project-history/ch-detailed.en.html#s4.1
[20:12] <cjwatson> the bit about the abortive Debian 1.0 non-release
[20:15] <lifeless> cjwatson: that talks about official cd rom image
[20:15] <lifeless> s
[20:15] <dupondje> micahg: you know if there is a ppa for thunderbird 3.0.1 / 3.0.2 ? mozilla-daily is to daily imo :)
[20:15] <lifeless> cjwatson: not about adoption of codenames; later on they are introduced with no explanation.
[20:16] <lifeless> cjwatson: I think you're saying 'after confusing a cd rom printer, Debian started getting codenames printed until releases happen'.
[20:17] <cjwatson> *shrug* that incident was the cause anyway
[20:17] <lifeless> thanks
[20:17] <cjwatson> even if it's not documented in the particular history I found :)
[20:17] <lifeless> I appreciate the pointer :>
[20:34] <micahg> dupondje: not yet, but soon
[20:35] <dupondje> creating one ? /P
[20:36] <micahg> dupondje: soon
[22:08] <tjaalton> how to find out why a package has been removed from the archive?
[22:25] <c_korn> tjaalton: search for the package launchpad.
[22:25] <tjaalton> c_korn: no bugs filed against it
[22:26] <cjwatson> if you look in the publishing history there'll be a removal comment from the archive admin who did it
[22:26] <tjaalton> oh
[22:27] <tjaalton> "mass removal of old and unpopular packages"
[22:27] <tjaalton> right :)
[22:28] <fale> in lucid, xserver-xorg-video-geode reccomends xserver-xorg-video-cyrix and xserver-xorg-video-nsc but they are not in the repo :(
[22:28] <c_korn> lol, what package was it ?
[22:28] <tjaalton> c_korn: vdr-plugin-skinsoppalusikka, and I admit that it hasn't changed since hardy
[22:28] <tjaalton> in ubuntu anyway
[22:29] <tjaalton> fale: file a bug
[22:30] <tjaalton> fale: preferably in the debian bugtracker
[22:30] <c_korn> I wonder how many packages were affected by this mass removal
[22:30] <fale> tjaalton: in debian? :|
[22:30] <tjaalton> fale: it was synced from there. having those recommends doesn't break anything though
[22:30] <fale> I see
[22:31] <persia> tjaalton: https://lists.ubuntu.com/archives/ubuntu-motu/2009-December/006412.html was the discussion about it.
[22:32] <persia> tjaalton: If you want to restore one, pull the source from an earlier release, get it updated to match lucid standards, and file an FFe citing a regression.
[22:33] <tjaalton> just upgraded my vdr box to lucid, and was wondering if I should just let the packages be synced from debian. most of the people are using 3rd party packages anyway, and I'm not doing a proper job keeping up with debian or e-tobi
[22:33] <tjaalton> persia: well, I don't think it's worth it
[22:34] <tjaalton> just was surprised to see it gone
[22:36] <mdz> has anyone else seen bug 522067?
[22:37] <fale> tjaalton: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568516
[22:39] <tjaalton> fale: thanks
[22:39] <fale> tjaalton: ;)
[22:42] <fale> in fedora main and universe have been unified some time ago... is planned something similar for ubuntu too?
[22:45] <cjwatson> fale: http://wiki.ubuntu.com/ArchiveReorganisation
[22:46] <cjwatson> (short answer: yes, it's just taking a while)
[22:46] <fale> cjwatson: awesome :) thankyou for the url
[22:46] <sebner> cjwatson: good feeling being back from holidays, hmm? *hrhr* :)