[00:53] <SpamapS> ScottK: around?
[01:59] <ScottK> SpamapS: Sort of
[01:59] <ScottK> hyperair: No.
[02:02] <hyperair> ScottK: nevermind, didrocks has uploaded it already =)
[02:02] <hyperair> thanks anyway
[05:28] <Rotund> can someone help me with packaging?  I want to build an updated package, but I don't understand all of this
[05:28] <Rotund> my debian folder has some .debdiff files in it
[05:50] <SpamapS> ScottK: I was looking for some clarification on the prerm script in mail-stack-delivery
[05:50] <ScottK> SpamapS: You realize I did that month's ago, right?
[05:50] <ScottK> It's nearly 1AM here, so I'm not likely to be very useful.
[05:51] <ScottK> I'm happy to take a shot at it, but ivoks-afk is probably a more likely victim.
[05:51] <SpamapS> ScottK: hah, understood. ;)
[05:53] <SpamapS> ScottK: among other things, I'm trying to figure out why it moves just one file from /var/backups/dovecot-postfix and then rmdir's that dir without checking to see if it is empty.
[05:53] <SpamapS> ScottK: there's definitely something going wrong out there..  https://bugs.launchpad.net/ubuntu/+source/dovecot/+bug/653362
[05:53] <ScottK> I vaguely recall believing that no other content in there mattered.  It may be though that I messed up and thought I'd removed it all and was wrong.
[05:54] <ScottK> Of course rmdir on a non-empty directory won't be very satisfying.
[05:54] <SpamapS> ScottK: I think, but I'm not sure, that people are only having problems if they started on an older version of dovecot-postfix
[05:54] <ScottK> If you don't get better information, I'd make sure all the contents are moved.
[05:54] <SpamapS> I'm doing a release upgrade from karmic -> lucid -> maverick to test this theory
[05:55] <SpamapS> as yet none of the people reporting have provided any listings of /etc/dovecot that might help me understand why they'd get permission denied errors. :-P
[05:55] <SpamapS> ScottK: it goes deeper than the backups dir.. but that particular bit was rather confusing.
[05:56] <SpamapS> ScottK: with all due respect, the lack of comments is maddening. ;)
[07:05] <pitti> Good morning
[07:05] <pitti> myrkraverk: hello
[07:12] <SpamapS> hmm.. how does dpkg determine that a conffile has changed? It seems to be broken in the dovecot-postfix/mail-stack-delivery packages .. they always thing things changed...
[07:13] <SpamapS> s/thing /think /
[08:13] <SpamapS> This should really be uploaded before maverick's isos are spun, if at all possible. Anybody care to sponsor it?  -- https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/dovecot/karmic2lucid2maverick-upgrade-fix/+merge/37707
[08:22] <dholbach> good morning
[08:28] <mvo> SpamapS: let me have a look
[08:31] <SpamapS> mvo: thanks! :)
[08:32] <SpamapS> I can't believe I stared at that code all day and didn't notice the lack of []'s
[08:33] <mvo> SpamapS: shell can do this to people ;)
[08:33] <mvo> SpamapS: looks good, uploading now
[08:34] <SpamapS> mvo: syntax checking is for wusses right? ;)
[08:34] <SpamapS> mvo: very much appreciated!
[08:35] <mvo> SpamapS: yw :)
[08:36] <SpamapS> woot, the last in the server-mrs tag.. https://bugs.launchpad.net/ubuntu/+source/dovecot/+bugs?field.tag=server-mrs
[08:37] <SpamapS> oh wait, thats just for dovecot.. darn.. still 3 others.
[10:00] <smb> cjwatson,  PCI: allocate space top-down, not bottom-up
[10:02] <robbiew> pitti: I see you are working on bug 648414 :)
[10:03] <pitti> robbiew: I just started to look at it
[10:03] <pitti> robbiew: it was marked oem-priority yesterday, and krafty asked about it
[10:03] <robbiew> I'm thinking maverick-updates given the crash isn't catastrophic
[10:03] <smb> https://bugzilla.kernel.org/show_bug.cgi?id=16228
[10:03] <smb> cjwatson, ^
[10:03] <pitti> robbiew: yes, it only crashes when there's a policykit error, but this should usually work
[10:03] <pitti> robbiew: and it auto-respawns at the next request
[10:04] <pitti> but from the stack trace it's relatively clear what happened
[10:04]  * pitti hugs apport
[10:04] <robbiew> :)
[10:04] <robbiew> cool
[10:05] <robbiew> pitti: is it actually a "Critical" bug?
[10:05] <robbiew> seems more like a High
[10:05] <pitti> I agree
[10:05]  * pitti updates
[10:06] <pitti> done
[10:07] <robbiew> pitti: thank you sir!
[10:07] <mvo> pitti: I remember we talked about b43-fwcutter and jockey, it appears its suggesting it for chips that don't work and then the ostinst fails (e.g. bug #655485). I would rather make this a message instead of a error
[10:08] <pitti> mvo: yes, it's evil that the package fails completely
[10:53] <tkamppeter> pitti, hi
[10:54] <pitti> hello tkamppeter, how are you?
[10:55] <tkamppeter> pitti, fine, it is about bug 160092.
[10:55] <tkamppeter> pitti, /etc/apparmor.d/usr.sbin.cupsd has only
[10:55] <tkamppeter> /usr/local/share/** r
[10:56] <tkamppeter> for /usr/local. Should it not have
[10:56] <tkamppeter> /usr/local/** rix
[10:57] <tkamppeter> as it has for /opt? This way arbitrary third-party drivers will work, as they do now when they are in /opt.
[10:58] <pitti> tkamppeter: that would mean that it could run arbitrary code in /usr/local/bin, too, though
[10:58] <myrkraverk> pitti% I wanted to ask, can I instuall and run the your PG9 packages along with my current 8.4?
[10:58] <pitti> myrkraverk: yes, that'll work fine
[10:59] <pitti> myrkraverk: see /usr/share/doc/postgresql-8.4/README.Debian.gz (or doc/postgresql-common/...)
[10:59] <myrkraverk> pitti% No extra configuration overhead, just "plug&play" ? ;)
[10:59] <pitti> myrkraverk: you can run both in parallel
[10:59] <myrkraverk> Great.
[11:04] <tkamppeter> pitti, OK, but in /opt also arbitrary code can be executed.
[11:05] <pitti> tkamppeter: right, we can't assume anything about the structure there
[11:06] <pitti> tkamppeter: /usr/local/lib/cups/** rix should get us a long way, though?
[11:06] <pitti> tkamppeter: ah, I remember that one; I was waiting for kern.log for ages, now we've got one
[11:06] <tkamppeter> pitti, yes this would already help.
[11:06] <pitti> tkamppeter: I'll commit that to trunk.
[11:09] <tkamppeter> pitti, at least CUPS-Raster style filters work then and most third-party filters are of that style. Perhaps one could open the rest of /usr/local at least for reading, so that the filter works if it has auxiliary files, libraries, ...
[11:10] <pitti> tkamppeter: committed that, too
[11:20] <tkamppeter> pitti, OK, thanks.
[11:27] <artnay> how does one reopen a bug on launchpad? I just witnessed something marked as "Fix released" making my computer unusable with up-to-date Maverick. see https://bugs.launchpad.net/ubuntu/+source/apt-xapian-index/+bug/363695
[11:35] <artnay> well, #64 makes it pretty clear
[11:42] <cjwatson> artnay: it's generally best to file a new bug, IME as a developer responding to them
[11:43] <cjwatson> artnay: all too often people think it's a reopening of a previous bug, and it's actually a new cause with similar symptoms - it's a lot less confusing when you have a new bug to work with
[11:44] <cjwatson> plus it's easier to mark bugs as duplicates than to split them up
[13:11] <kklimonda> jcastro: ping
[13:21] <Goodi> Ehlo, I did the 10.04 -> 10.10 upgrade and it went fairly well, except for the deskbar-applet & libdeskbar-tracker  (Bug #654392 )
[13:22] <Goodi> Some other oddities were mainly on the way the update-manager prompted for the "configuration file changes"
[13:23] <Goodi> On terminal you can see the "Y/n/D(iff)/.." questions but the popup won't still offer anything else but keep/replace
[13:23] <Goodi> except on Samba... Why is samba-configuration handled differently (?)
[13:24] <Goodi> Anyway.. so far it's looking pretty good. (Except for the deskbar-applet, which I hope gets fixed before the release)
[13:32] <robbiew> mvo: are you the "guy" who can disable kernel-oops before we release?
[13:34] <pitti> robbiew: we already did
[13:34] <pitti> robbiew: https://edge.launchpad.net/ubuntu/+source/kerneloops/0.12+git20090217-1ubuntu9
[13:34] <robbiew> pitti: cool...I thought so, but wanted to be sure ;)
[13:42] <jibel> Goodi, I can reproduce during an upgrade from Lucid, thank you.
[13:44] <Goodi> ok.
[13:45] <Goodi> Btw. when installing a new system the installer (or OEM-configurator) prompts for a new user. Is there any way to set the UID for the user? (hidden parameters, preseed-magick, etc)?
[13:49] <mvo> jibel: are you on it already or should I fix it? it appears that libdeskbar-tracker was removed from maverick, so the fix is simple (just conflict)
[13:50] <jibel> mvo, seb128 is trying to find a volunteer
[13:50] <seb128> bilalakhtar claimed it
[13:50] <seb128> bilalakhtar, ^ what mvo said
[13:50] <bilalakhtar> ah
[13:51] <bilalakhtar> mvo: yes I am doing it
[13:52] <mvo> excellent
[13:52] <mvo> bilalakhtar: just ping me when its ready, I'm happy to sponsor
[13:52] <bilalakhtar> mvo: I have upload rights :)
[13:55] <slashbeast> can anyone, please, help me found source for linux-alsa-driver-modules-2.6.35 from ubuntu audio dev team?
[13:56] <mvo> bilalakhtar: cool, even better \o/
[14:08] <cjwatson> Goodi: passwd/user-uid=1002 (or whatever)
[14:08] <cjwatson> (or 'd-i passwd/user-uid string 1002')
[14:10] <seb128> cjwatson, ev: bug #651064, who would be likely to work on that issue?
[14:10] <seb128> cjwatson, ev: design team?
[14:10] <seb128> cjwatson, ev: it's not a maverick target bug now but I would make the right people know about it
[14:11] <ev> seb128: traditionally this work was done by kwwii
[14:11] <ev> seb128: probably best to send to Iain and CC me in on it.
[14:12] <seb128> ok, so design, thanks
[14:12] <ev> indeed
[14:12] <ev> thanks
[14:15] <brettalton> I've been trying to get some numbers on what the most popular programming languages are in Ubuntu.
[14:15] <brettalton> GTK, Linux and some GNOME apps are written in C
[14:15] <brettalton> A lot of others use C++ and Python
[14:15] <brettalton> But some also use Mono/C#
[14:15] <brettalton> Are there any numbers on which are the most widely used?
[14:19] <jdstrand> cjwatson: hi! when you have a moment, would you mind accepting the email to the TB from fta regarding chromium? (sorry to bother you but iirc, kees couldn't moderate it for me last time)
[14:19] <cjwatson> brettalton: I'm not aware of any numbers
[14:20] <cjwatson> jdstrand: done
[14:20] <jdstrand> cjwatson: thanks :)
[14:21] <brettalton> cjwatson: figured, but if I'm to start a new application, which potentially could be a pretty large project, I'd like to have a talk around what language to use and why
[14:21] <cjwatson> brettalton: sloccount might be able to do it though you'd need a local mirror
[14:21] <cjwatson> brettalton: I think I'd be inclined to look for the right tool for the job rather than pure popularity (maybe excluding really obscure ones)
[14:22] <cjwatson> you might be influenced by library availability
[14:22] <brettalton> cjwatson: exactly, but I'd like to know what most programmers are using, and then find out why
[14:22] <brettalton> Most are using Python due to it's binding with GTK no?
[14:22] <cjwatson> I think that's jumping to conclusions
[14:23] <cjwatson> it may be true for a good chunk of the code written directly for Ubuntu, but there's plenty of code that uses Python and never goes near the desktop (or that uses Qt)
[14:25] <OdyX> brettalton: you should maybe consider the language you are most comfortable with
[14:26] <brettalton> cjwatson: very true again. But if I'm looking to develop a GTK-based app, what choices do I have in terms of languages? I have a few right? GTK as bindings for a lot of languages, such as C, C++, Python, Haskell, etc.
[14:26] <brettalton> But I have a web background and know JavaScript very well, so why not Seed?
[14:26] <brettalton> What I'm getting at is that I'm overwhelmed with the choices I have and am having a hard time narrowing them down
[14:30] <brettalton> OdyX: what I'm most comfortable with is PHP and JavaScript, but also know some C# and C but I have no experience with GTK
[14:30] <cjwatson> brettalton: I think it is fair to say that (a) many languages are indeed in use, and the GTK community in general is mostly divided between C C++ Python Vala Mono, or something like that; (b) Ubuntu generally recommends Python to application developers
[14:31] <brettalton> cjwatson: okay thank you, that was my assumption
[14:31] <brettalton> I'm really interested in that SLOCCount program. I think that'd be interesting if Launchpad released some statistics using that program
[14:31] <brettalton> cjwatson: so thank you
[14:33] <OdyX> brettalton: Ohloh has some stats if you want.
[14:34] <cjwatson> I don't know how well sloccount is maintained; I heard of it a while back
[14:34] <brettalton> OdyX: on the entire Ubuntu project though?
[14:34] <OdyX> brettalton: on the complete FLOSS ecosystem. :->
[14:36] <brettalton> OdyX: do you have a link? I can't find it
[14:37] <OdyX> brettalton: did you Google it ?
[14:38] <OdyX> http://www.ohloh.net/languages/compare <-
[14:38] <jibel> cjwatson, did you saw my update on bug 653134  ?
[14:38] <brettalton> I was looking at: http://www.ohloh.net/p/ubuntu/analyses/latest
[14:39] <cjwatson> jibel: I doubt there is anything else I can do now
[14:39] <cjwatson> loopback loop0 /ubuntu/disks/root.disk <- don't see how it could boot at all without that
[14:40] <cjwatson> lang=fr/lang=en> hmm
[14:41] <cjwatson> I guess I could try a non-English installation, since that sounds like a serious contributor to the problem
[14:41]  * cjwatson hates life
[14:41] <jibel> cjwatson, I must admit that I don't understand either, I commented the lines one by one until I've found the one that's blocking the boot.
[14:42] <cjwatson> wubi upgrades have never worked right before.  it would have been nice to say that they worked this time, but I have a hard time considering it a blocker
[14:43] <cjwatson> (this is not to say I don't appreciate efforts to get them to boot ...)
[14:43] <cjwatson> er, to work
[14:43] <cjwatson> wubi really needs a maintainer who isn't me.  Agostino has been mostly lacking in time
[14:44] <cjwatson> I'm only doing it by default
[14:46] <Goodi> wubi 10.04 -> 10.10beta worked fine. Something broke my wubi install  on rc
[14:47] <cjwatson> Goodi: *blink* for nearly everyone else it was broken to beta
[14:47] <cjwatson> bug 581760 hosed lots of people
[14:47] <cjwatson> also bug 617715 and bug 653134
[14:48] <cjwatson> in fact, without the fix for 617715 which wasn't in beta, I can't see how an upgrade to beta could possibly have worked
[14:49] <cjwatson> I think you must have upgraded to slightly post-beta
[15:00] <Goodi> cjwatson-  True.. I was bit worried on upgrading wubi to beta, but then I noticed all the warnings *after* I started the upgrade :)
[15:01] <Goodi> Anyway the beta upgrade went nicely and I was able to use it for a while.. Last weekend I noticed that it didn't boot anymore
[15:04] <Goodi> cjwatson-  that yes, that was quite late in beta. Probably something like week before rc
[15:04] <tkamppeter> apachelogger, hi
[15:04] <brettalton> cjwatson: is there a branch for the entire Ubuntu project? something like: https://code.launchpad.net/~ubuntu-branches/ubuntu/maverick
[15:05] <beuno> brettalton, there is not
[15:05] <brettalton> beuno: okay, I was just trying to get ohloh to do a code analysis of Ubuntu
[15:05] <brettalton> and trying to write a new enlistment: https://www.ohloh.net/p/ubuntu/enlistments
[15:06] <tumbleweed> brettalton: ohloh's bzr support isn't great, I've given up on them scanning my bzr branches
[15:07] <brettalton> tumbleweed: ahh okay, ya I heard such instances, I was just curious
[15:07] <tumbleweed> brettalton: it just stops working every now and then andyou have to get an admin to re-enable it
[15:13] <mvo> tseliot: do you mind if I make patch a real dependency of dkms instead of a recommends? it used in the script and e.g. #653899 is caused by it missing
[15:14] <tseliot> mvo: in what package?
[15:14] <mvo> tseliot: dkms itself
[15:14] <mvo> tseliot: the failure is in bcmwl
[15:15] <tseliot> mvo: sorry, I misread your message. I think it should be fine. You might want to ask superm1 too though
[15:16] <mvo> superm1: hello, do you mind if I make patch a real dependency for dkms instead of a recommends? dkms builds with patch may fail otherwise
[15:22] <mvo> superm1: hm, the "make|build-essential|dpkg-dev" is also a little bit odd, makebe "make, build-essential|dpkg-dev" instead?
[15:23] <mvo> superm1: hm, the last comment is not that important, it looks like the issue I was looking at is really just caused by a missing "patch"
[15:24] <superm1> mvo, i've been previously saying individual packages using dkms that use the functionality of patch should depend on 'patch', but this keeps cropping up every so often
[15:25] <superm1> so if it's gonna clean up this problem from happening from time to time, it's fine by me
[15:25] <mvo> superm1: great, thanks. I will do a upload then
[15:36] <dpm> hey all, could someone give me a hand? I'm trying to calculate translation stats for unity. I'd do it the same way as in Ubuntu: considering only the source packages from the default installation from the seeds. Could someone tell me which seeds I'd need to consider for unity?
[15:36] <pitti> dpm: presumably http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/netbook.maverick/ ?
[15:37] <pitti> dpm: (that's the entire netbook, which is what you need, I suppose?)
[15:37] <dpm> pitti, yeah
[15:43] <dpm> pitti, I usually take them from the germinate output. For Ubuntu I use ('boot', 'required', 'minimal', 'standard', 'desktop-common', 'desktop'), but I'm not sure which ones to use from http://people.canonical.com/~ubuntu-archive/germinate-output/netbook.maverick/
[15:44] <pitti> dpm: should be http://people.canonical.com/~ubuntu-archive/germinate-output/netbook.maverick/netbook
[15:46] <dpm> pitti, ah, cool, so that would represent all packages installed on a unity default installation?
[15:47] <pitti> dpm: right
[15:47] <pitti> dpm: hm, seems not quite -- there's a lot of stuff missing, such as xorg
[15:49] <cjwatson> you'll still need desktop-common
[15:50] <cjwatson> and all the stuff below
[15:50] <cjwatson> dpm's original list is correct, just substitute 'netbook' for 'desktop'
[15:51] <dpm> ok awesome, thanks cjwatson and pitti!
[16:16] <apachelogger> tkamppeter: ahoy ahoy
[16:44] <tseliot> superm1: any opinions on bug 655275 ? The patch seems to help here
[16:45] <mvo> pitti: re bug https://bugs.edge.launchpad.net/ubuntu/+bug/655111 - do you mind if I add code to jockeys b43 handler to check pci ids and select the right package?
[16:58] <pitti> mvo: no, that'd be great of course
[16:59] <pitti> mvo: alternatively we could just disable it entirely; wl should work much better
[16:59] <pitti> for me, b43 just freezes the computer
[17:03] <mvo> pitti: disabling is fine with me
[17:08] <mvo> pitti: is https://code.edge.launchpad.net/~mvo/jockey/b43-disabled sufficient or would you prefer that the entire file goes away?
[17:26] <ogra_ac> hmpf, where is Keybuk when i need him
[17:31] <superm1> tseliot, i think the patch is actually not correct though, it certainly would break rhel
[17:31] <superm1> which can support i386 and i686
[17:31] <tseliot> superm1: are you referring to the kernel?
[17:31] <superm1> yeah
[17:32] <tseliot> superm1: oh. Do you have better ideas?
[17:32] <tseliot> superm1: or maybe we can check the distro
[17:33] <tseliot> as we do in the template
[17:33] <superm1> well if it's passed in as argument to dkms already from dkms_common.postinst, that should be carried through the code i think
[17:34] <tseliot> superm1: the point is that dkms_common.postinst does pass it to dkms build
[17:35] <superm1> right, so that value that dkms_common.postinst passed is what should be sed'ed into place, not a case statement hardcoding to i386
[17:36] <tseliot> superm1: aah, so you're saying that we should pass i386 when we call the template. Good point
[18:22] <pitti> mvo: (just a quick drive-by) yes, that's fine; that, or don't install the file at all
[18:23] <pitti> mvo: but please fix the changelog to "UNRELEASED" and dch -r/debcommit -r separately when you merge into the ubuntu branch
[18:23] <pitti> mvo: thanks!
[18:23]  * pitti waves good night, Taekwondo time
[18:26] <achiang> superm1: please see my latest update to that bug. we definitely do *not* break RHEL
[18:31] <achiang> superm1: and your other suggestion of passing along whatever dkms_common.postinst detects won't work. the kernel Makefile doesn't understand "i686" as a valid argument for ARCH
[21:17] <lep-work> hello, I'm trying to find out where I can get the configure strings used to build the software in the repos ... ie, what compile time options the package maintainer passed when he built a particular package
[21:26] <smoser> anyone know why http://changelogs.ubuntu.com/changelogs/pool//main/l/lazr.restfulclient/lazr.restfulclient_0.9.11-1ubuntu1/ does not have a changelog ?
[21:34] <ari-tczew> smoser: https://launchpad.net/ubuntu/+source/lazr.restfulclient/0.9.11-1ubuntu1
[21:34] <smoser> ari-tczew, what are you telling me?
[21:35] <ari-tczew> smoser: I gave you changelog
[21:35] <smoser> well, unless i'm missing something, the i only see a diff that contains of a changelog versus the previous version
[21:36] <smoser> i'm sort of SOL in the case that i need more than that (well, without a lot more work)
[21:36] <smoser> but in general, i was trying to understand why some packages dont have changelogs on changelogs.ubuntu.com
[21:37] <lep-work> could anyone point me in the right direction...I'm looking for the compile time options passed to bins in the ubuntu repositores...ie, the ./configure lines used to build the packages
[21:39] <smoser> i think the answer my above question is that those releases were in -security
[21:40] <smoser> lep-work, well, nothing magical/terribly standardized. but its all controlled via debian/rules in the source package.
[21:41] <jcastro> other-kernel-n-misc is winning for best UDS session title so far.
[21:41] <lep-work> smoser, thank you...that's exactly what I was looking for
[21:41] <lep-work> :}
[22:14] <coz_> hey guys.. I was just reading the mailing list where it is suggested that png and svg files along with gz files be rencoded to save space... what is the possiblitly of just creating  a "minimal live cd"  any files needed diring live session can be quickly downloaded an cached  and of course during install pricedure ,, they would be downloaded and installed/
[22:14] <coz_> during not diring
[22:42] <cwillu> what's the generic tool to create a new patch for any given unpacked source package?
[22:43] <lep-work> diff?
[22:43] <lep-work> is that what you mean?
[22:43] <lep-work> diff creates patches
[22:44] <penguin42> debdiff?
[22:45] <penguin42> hmm no, that's just summary?
[22:49] <cwillu> I'm remembering a tool that uses dpatch or quilt or whatever as needed
[22:49] <cwillu> can't remember the name
[22:49] <micahg> cwillu: edit-patch
[22:49] <cwillu> that's the one
[22:49] <cwillu> thanks
[23:48] <ebroder_> In one of his e-mails, pitti mentioned bypassing GDM and running a user session directly on single-user machines. Anybody know how I would do that?
[23:53] <TheMuso> ebroder_: Turn on auto login?
[23:54] <ebroder_> TheMuso: Right, that's what I'm doing now. But gdm has disk/memory/boot time/etc overhead
[23:55] <TheMuso> No idea then.