[00:58] <cjwatson> LaserJock: we already have a way to launch the installer without going into the desktop, even though it's hidden. Boot with the 'only-ubiquity' boot option
[00:59] <LaserJock> cjwatson: what does that do?
[00:59] <LaserJock> I remember there being discussion about it
[00:59] <cjwatson> wasabi: you can argue against a text-based UI for ubiquity if you like, but it's mostly already done ...
[00:59] <LaserJock> does it start X and then run ubiquity without any WM?
[00:59] <cjwatson> LaserJock: starts X, metacity, gnome-settings-daemon, and ubiquity
[01:00] <LaserJock> ah, so you still have metacity
[01:00] <cjwatson> it needs a WM, but not the full desktop furniture
[01:00] <LaserJock> right
[01:00] <cjwatson> ubiquity uses dialog boxes - you can't do that without a WM
[01:00] <LaserJock> right
[01:00] <LaserJock> what does that do for the RAM requirements?
[01:00] <wasabi> cjwatson: What are the plans regarding d-i?
[01:00] <wasabi> I'd be very sore if d-i vanished.
[01:00] <cjwatson> wasabi: data.tar.gz can't achieve the same level of compression as squashfs because the blocks can't possibly be as big: squashfs blocks can span multiple packages
[01:00] <cjwatson> wasabi: d-i isn't going away, don't worry
[01:01] <cjwatson> LaserJock: knocks a good chunk off, but I don't have the numbers to hand
[01:01] <cjwatson> we may well switch to that by default in hardy
[01:03] <cjwatson> and the d-i X frontend has never been good enough for my satisfaction, which is why we don't build or ship it
[01:03] <cjwatson> (though I put a lot of work into it myself in the early days)
[01:03] <wasabi> Yeah, I remember that.
[01:03] <StevenK> cjwatson: What's lacking that doesn't make it good enough?
[01:04] <cjwatson> StevenK: plugins for all the complex UI
[01:04] <cjwatson> like the partitioner
[01:04] <StevenK> Oh, right. It's in X, but still uses the horrible menu partitioner. Ew.
[01:04] <cjwatson> the facilities are there (er, mostly; there's still a little bit of libd-i and anna work that needs to be done), but nobody's sat down and written code to make it better than the generated UI
[01:04] <wasabi> That's generally something which is simply lacking mostly in debconf
[01:04] <cjwatson> wasabi: no
[01:04] <wasabi> Good integration with task specific UI
[01:04] <cjwatson> that's simply not true
[01:04] <wasabi> Oh
[01:05] <wasabi> ?
[01:05] <cjwatson> cdebconf supports plugins
[01:05] <cjwatson> I wrote the code
[01:05] <wasabi> plugins for specific UI modules for specific toolkits?
[01:05] <cjwatson> yes
[01:05] <wasabi> Huh. So what is lacking in it then?
[01:05] <cjwatson> somebody actually writing the plugins
[01:05] <wasabi> Why the push for ubiquity instead of that?
[01:05] <wasabi> Simply because of the LiveCD requirements?
[01:06] <cjwatson> partly that it was much harder to do the plugins in d-i than the way ubiquity does it, and partly because we needed to be able to ship an installable live CD for other reasons
[01:06] <cjwatson> being able to ship just a live CD instead of install+live cuts Canonical's shipit costs down to a third of what they were ...
[01:07] <cjwatson> and there was the speed thing too
[01:07] <wasabi> Yeah.
[01:07] <wasabi> So, wonder if there could be an optimization in d-i to use preexisting package source instead of actually doing the work? :)
[01:07] <cjwatson> "preexisting package source"?
[01:07] <wasabi> "oh, you're trying to install foo.deb, how about I just grab these files from /, put them in the right place, and pretend you did install foo.deb"
[01:08] <cjwatson> somebody wrote a live-installer udeb for d-i in Debian
[01:08] <wasabi> What I like about d-i is the ability for me to build my own pieces in it. I do it for large installations.
[01:08] <wasabi> Custom installers for different organizations, that integrate their own UI pieces, and/or apt soruces and package lists.
[01:08] <cjwatson> it doesn't really belong at the level of installing individual .debs though; you won't get a meaningful speedup out of that
[01:08] <wasabi> Usually netbooted, etc.
[01:09] <cjwatson> sure, that's a large chunk of the reason we support d-i
[01:09] <cjwatson> ubiquity's a great desktop installer but I don't expect it ever to be customisable on the fly to the same extent
[01:10] <cjwatson> effort on converting more packages over to triggers would be appreciated
[01:10] <cjwatson> a lot of that will be fixed in Debian as soon as triggers get merged there
[01:10] <cjwatson> Joey is champing at the bit to delete huge wodges of debhelper
[01:12] <StevenK> I can't wait for texlive to get trigger support. That would make upgrades even faster.
[01:12] <cjwatson> I will probably slow them down a bit again with man-db ;-)
[01:13]  * StevenK chuckles
[01:13] <cjwatson> (but doing so fixes an ancient bug so I think it's worthwhile)
[01:13] <StevenK> That's the manual pages encoding one, right?
[01:13] <ion_> Also enhancing linux-images’ trigger support would be nice.
[01:13] <cjwatson> StevenK: no, having the database updated automatically after package installation so that apropos and whatis work immediately
[01:14] <StevenK> Ahh
[01:14] <cjwatson> encoding is nearly all fixed now
[01:14]  * StevenK notices the time and runs off to lunch with his sister in law
[01:14] <cjwatson> modulo a few bugs (fixed upstream) you can use UTF-8 manual pages
[01:14] <cjwatson> need to get the exact layout agreed though
[01:15]  * cjwatson -> bed
[01:15] <ion_> Btw, the version of openssl in gutsy-{security,updates} is greater than the version in hardy.
[05:16] <emgent> heya
[10:23] <beewee> Can anybode tell me whether the browsers in K/Xubuntu send K/Xubuntu or just "Ubuntu" inside the HTTP_USER_AGENT? Nobdody in #ubuntu and #ubuntu-de was able to answer this :/
[10:23] <beewee> *anybody
[10:26] <persia> beewee: I don't know offhand, but I suspect you'll do well to either check the source or with https://answers.launchpad.net/ubuntu/
[10:36] <beewee> ok, I created a question in launchpad
[10:37] <persia> beewee: Thanks.  Sometimes it takes a while to get a response, but that's the best escalation point when #ubuntu doesn't know.  Frequently the developers don't know offhand either, and are working on other things.
[10:40] <beewee> ok :)
[12:54] <shodges> hey, does anyone know of good documentation for packaging a *new* project? The packaging guide on the wiki seems to imply that you are repackaging an existing project...?
[12:57] <IntuitiveNipple> lol yeah, it is a bit mean like that isn't it!
[12:57] <persia> shodges: How do you mean a "New" project?
[12:58] <shodges> well, i'd like to build a deb package for a project i've been working on, but instead of using checkinstall i want to do it properly, so i learn how to package at the same time
[12:58] <IntuitiveNipple> There's one in the 6.10 Wiki, showing how to create a package from scratch, based on simple 'hello' example: https://help.ubuntu.com/6.10/ubuntu/packagingguide/C/basic-scratch.html
[12:59] <persia> IntuitiveNipple: That's a good resource, but it's a little out of date.
[13:00] <persia> shodges: https://wiki.ubuntu.com/PackagingGuide/Basic tries to cover new packaging.  Is there something else you think is missing there?
[13:00] <IntuitiveNipple> persia: no kidding... trying to find anything was hard though, so have to make do
[13:01] <shodges> IntuitiveNipple, persia, thanks i've got that guide in front of me at the moment. The problem i'm having is it seems to imply i want to "apt-source" my project from the repos, but its not there because i made it from scratch
[13:02] <persia> shodges: Aha!  Thanks for pointing that out.  I'll update the docs to be more clear.  If you have a tar.gz, and you rename it to an .orig.tar.gz, you can proceed: the apt-get source hello is only to grab an example.
[13:03] <IntuitiveNipple> Yes, that was my issue when I started with packaging. It all assumes someone else created the code
[13:03] <IntuitiveNipple> It would be good to have a link-out to actually creating a new package from original source-code
[13:04] <persia> IntuitiveNipple: Do you mean including instructions on how to generate an orig.tar.gz from a source tree?
[13:04] <IntuitiveNipple> I wanted to know things like, best-practice in naming directories, common directories to use ( for things like po, etc.,)
[13:04] <shodges> ah ok, i'll give that a try, thanks. just for clarification, i should tar up my code and rename it to *.orig.tar.gz, in the same dir structure that the guide instructs?
[13:05] <IntuitiveNipple> persia: If that requires more than just a simply tar -cxf package.tar.gx ./package-1.0   then yes
[13:06] <IntuitiveNipple> I wanted to create a project template directory I could use as the basis for creating a new ubuntu/debian packages at will... that'd be cool
[13:06] <persia> IntuitiveNipple: That's about it.  I tend to prefer 'tar czf mypackage_1.0.orig.tar.gz ./mypackage-1.0`. :)
[13:06] <IntuitiveNipple> so it'd have the debian/ directory and templates of control changelog and all other required files ready to go
[13:07] <IntuitiveNipple> Spelling it all out is the important thing, because so much of existing docs assumes you understand the nuances of packaging in many ways.
[13:07] <IntuitiveNipple> like the po issue I had, for example.
[13:07] <persia> IntuitiveNipple: There's a package called dh-make that includes templates for most things.
[13:07] <IntuitiveNipple> ahhh see? nuance!
[13:08] <shodges> IntuitiveNipple, persia, i used dh-make to build my template debian dir, glad to hear i'm not going in the wrong direction :)
[13:08] <persia> shodges: You'll want to wrap your code so that the tarball expands with a single top-level directory, and calling the build rules from that directory builds the software.
[13:09] <persia> shodges: You will want to not put debian/ in your orig.tar.gz, to make things easier if the software later also gets distributed in other distributions.
[13:09] <shodges> ok, makes sense
[13:10] <persia> IntuitiveNipple: If you have more suggestions for dh-make, I'd recommend submitting patches.  The more that can be easy to learn, the better.
[13:10] <IntuitiveNipple> I seem to recall using dh_make for the debian bits.
[13:10] <IntuitiveNipple> persia: My main issue was just lack of clear documentation on creating a brand new source project and packaging.
[13:11] <persia> IntuitiveNipple: Hrm.  The lack of documentation on making a brand new project (which would later be packaged) seems separable to me, but it would be nice to have something.  I'm adding the bit about generating an orig.tar.gz from scratch to the packaging guide now.
[13:12] <IntuitiveNipple> Thanks.
[13:12] <persia> IntuitiveNipple: I've never actually created a project from scratch: I don't suppose you'd be willing to author a first draft for that document?
[13:13] <IntuitiveNipple> Yes, a separate recommendation on best-practice in creating a new software project that will not cause issues with debian packaging later, along with the pros and cons of the various patch-management systems, would be ideal
[13:14] <persia> Just basic things like supporting a variable to tell it where to install (for /usr vs. /usr/local), and putting everything in a source tree, and not including debian/, and copyright/licensing for everything, and source for everything, etc.
[13:15] <IntuitiveNipple> persia: I could try, but I'm not sure myself, thats part of the problem! For internationalisation there's all the po stuff. I'm still trying to understand that. Then there's gnome-specific stuff like the glade file (where best to put it/them), having a ./src/ directory, when to use a separate ./include/ directory. How to integrate with what autoconf requires!
[13:15] <persia> IntuitiveNipple: Right,  It's lots of stuff.  I'd suggest putting a big WIP on the top of the page, but if you can get enough started that others contribute, soon we'll have a good reference.
[13:16] <IntuitiveNipple> I end up actually not bothering to package my stuff because I end up wasting time trying to get the packaging sorted out
[13:16] <IntuitiveNipple> I've been flowcharting the entire process, including every patch system, in order to understand it
[13:17] <persia> IntuitiveNipple: That seems a bit extreme.  There's so many different ways to package, that trying to map it all is a huge effort.  Personally, I tend to focus on the couple I know well, and only learn more when I'm working on a package that requires it.
[13:19] <IntuitiveNipple> Well, I'm writing an automated packaging tool for myself so when I'm bug-hunting, actually providing the fixed package debdiff becomes trivial! You saw what happened with my KVM/QEMU packaging :)
[13:19] <IntuitiveNipple> So the flow chart is proving extremely useful because it captures every possible path and makes it easy for me to check my understanding with people who know, simply by showing them the flowchart
[13:21] <persia> IntuitiveNipple: Interesting.  As you get closer to completion, I'd like to see the tool.  There's definitely a gap between checkinstall (easy and produces broken packages) and dh_make (requires lots of understanding, and tries to do too much).
[13:24] <IntuitiveNipple> I was debating whether to write it for Eclipse (where I do all my development) or Gnome (so it can be used by others) I've decided on gnome so I'm working up the GUI now. I can then have a python back-end that can also link into Eclipse
[13:25] <IntuitiveNipple> persia: If you're willing to review/amend the .dia document I use then I'm sure it could be quite bullet-proof
[13:26] <persia> IntuitiveNipple: I'm swamped now.  If you email it to me, I'll take a look when I can, but I suspect you'd do as well to push a couple more revs first (depending on your update rate).  Also, I can't promise complete understanding: I just learned about another packaging tool last week.
[13:27] <IntuitiveNipple> persia: Yes, I can imagine. I know the feeling well :)
[13:27] <persia> shodges: Does the addition of the tar call in  https://wiki.ubuntu.com/PackagingGuide/Basic help, or is it still unclear?
[13:27] <IntuitiveNipple> Once I get my new web-app front-end up and running it'll be online
[13:30] <soc> hi
[13:30] <soc> looks like breakage arrived today :-)
[13:30] <soc> i get /dev/null: permission denied, does someone have an idea?
[13:35] <shodges> persia, the tar call addition clarifies what you both have explained - just one thing, should the command say "tar -zcf hello-2.1.1.tar.gz hello-2.1.1" ?
[13:36] <shodges> it currently says "tar xzf ..."
[13:36] <persia> shodges: I always use "czf", but it the order doesn't matter, so it could be "zcf".
[13:36]  * persia thought that was fixed before the URL announcement, but was perhaps too slow
[13:36] <shodges> cool, good to know
[13:37] <persia> shodges: Thanks for the feedback.  Good luck with packaging.  If you have questions, I'd suggest asking in #ubuntu-motu, as this channel is usually much busier with developer coordination during the week.
[13:39] <shodges> thats great, thanks for your help - i'll switch to ubuntu-motu next time
[13:39] <IntuitiveNipple> while I think about it. Does anyone have any ideas as to what could be keeping a loop-mount busy after chroot-ing into it, or running a chroot shell?
[13:41] <IntuitiveNipple> I've created an automated script that builds  UML Ubuntu file-systems, but after it has run "sudo chroot ./root apt-get install ubuntu-minimal" umount reports it is still busy, although lsof doesn't show anything using it.
[13:41] <persia> IntuitiveNipple: It may be that you've started a daemon?
[13:42]  * Spads suspects dbus
[13:42] <Spads> that's what always holds my chroots open
[13:42] <IntuitiveNipple> Spads: really?
[13:42] <Spads> IntuitiveNipple: statistically, yeah.  You can check yourself though
[13:43] <persia> IntuitiveNipple: You might want to look at schroot: I think there's a patch to that that kills everything when closing the chroot.
[13:43] <IntuitiveNipple> hmmm, I saw mention in my searches of avahi having a chroot helper but stopping avahi didn't help. I can't really stop dbus :)
[13:43] <Spads> do an lsof
[13:43] <IntuitiveNipple> persia: Thanks, that might help, although it would be good to know what is managing to hold it busy and yet not show up
[13:44] <IntuitiveNipple> Spads: Thats the thing, lsof shows nothing at all
[13:44] <IntuitiveNipple> I've tried stracing it too, so far no luck
[13:44] <Spads> there's a +c0 trick you can do that I never had fully explained to me
[13:44] <IntuitiveNipple> with lsof?
[13:44] <Spads> yeah
[13:45] <Spads> lsof +c0 | grep /my/chroot/path
[13:45] <Spads> or something
[13:45] <Spads> you'll want to kill stderr
[13:45]  * Spads vanishes
[13:45] <IntuitiveNipple> " +c w     This  option  defines  the  maximum  number  of  initial characters of the name"
[13:46] <IntuitiveNipple> " If w is zero (’0’), all command characters supplied to lsof by the UNIX dialect will be printed."
[14:03] <IntuitiveNipple> Suggestions for a trivial package to install using apt-get to test this chroot issue - my mind has gone blank!
[14:04] <persia> IntuitiveNipple: hello
[14:04] <IntuitiveNipple> lol
[14:04] <IntuitiveNipple> doh
[14:04] <IntuitiveNipple> grrr, now I can't get it to fail!
[14:23] <Lutin> fabbione: would you mind testing linuxtv-dvb-apps 1.1.1-3 from debian and see if it works for you ?
[14:42] <seb128> Lutin: the checkinstall changes look like things that should be sent to debian, could you do that since you did the package update?
[15:14] <Protheus> Hi all
[15:15] <Protheus> I am looking for ubuntu PS3 development channel. does anyone know its name?
[15:19] <persia> Protheus: https://help.ubuntu.com/community/InternetRelayChat has the channel list.  You might try the powerpc channel.
[15:19] <persia> Protheus: Also, it's the weekend in many places, so the developers may not be around.
[15:24] <Protheus> Thx persia ...
[15:46] <fabbione> Lutin: yes i do because my media box is "stable" and i just disconnected 3 hours ago to mount the new fornitures for the living room that will arrive this week :)
[15:46] <Lutin> fabbione: ok :)
[15:47] <fabbione> if you asked yesterday i might have done it
[15:47] <fabbione> also.. what is the problem that needs testing?
[15:47] <fabbione> the merge or what?
[15:47] <fabbione> because IIRC the only delta was the DK DVB-T channels I added
[15:48] <Lutin> fabbione: yeah, that's it. there are also frequencies for dk in the debian package, but quite different from yours
[15:48] <Lutin> so I wanted to know if that worked, so that we can sync
[15:48] <fabbione> do you have a diff handy? mine were "guessed" and did work..
[15:48] <fabbione> the ones from Debian might be better
[15:49] <fabbione> anyway just sync.. we can always fix it later
[15:49] <Lutin> ok
[15:49] <fabbione> it's in universe AFAIR.. right?
[15:50] <Lutin> fabbione: indeed
[15:51] <fabbione> Lutin: take the ones from Debian. They are good and better than mine
[15:51] <Lutin> fabbione: ok
[15:52] <fabbione> ++# Created from http://www.digi-tv.dk/Indhold_og_tilbud/frekvenser.asp
[15:52] <fabbione> mine was "sniffing" on dk-Copenhagen .. you don't want to know how ;)
[15:52] <Lutin> lol :)
[16:20] <Protheus> can someone point me to a linux kernel source packe? I cannot find the package ... I don't know what do look after.
[16:21] <pochu> Protheus: linux-image-*
[16:21] <Protheus> lol. I did a new approach ... and go through the linux-kernel package ... there it was in the dependencies .... linux-source is it.
[18:02] <jdong> is there any way to extend the sudo password cache for a particular terminal session?
[18:04] <Protheus> hmmm ... I think this is a global setting.
[18:06] <jpatrick> jdong: -v extends to 15 minutes (or whatever the timeout is set as in sudoers)
[18:06] <jdong> interesting....
[18:07] <jdong> I'm looking for something for a continually-pbuildering shell
[18:07] <jdong> because pbuilder invokes sudo to become root and that almost always yields an annoying password prompt
[18:07] <jpatrick> sudo -s?
[18:07] <jdong> jpatrick: is it really safe to be fetching and mangling source archives as root :-/

[18:08] <jpatrick> err, probably not
[19:42] <so1> hi
[19:42] <so1> does someone know why pulseaudio needs an internet connection to work?
[20:41] <superm1> during the debian autosync, do NEW packages (that are in the debian archive but not in Ubuntu) automatically come?
[20:44] <Kmos> superm1: if they're at unstable (main), they'll come
[20:45] <Kmos> for example:
[20:45] <Kmos> !info vodovod hardy
[20:45] <Kmos> is a new one =)
[20:45] <ubotu> vodovod: lead the water from the house to the storage tank. In component universe, is optional. Version 1.10-1 (hardy), package size 419 kB, installed size 916 kB
[20:46] <geser> superm1: "automatically" as in an archive admins needs to start a script
[20:47] <superm1> geser, okay just making sure i didn't need to requestsync it.  there is no urgency to it right now, so whenever they run said script and grab it will be fine
[21:36] <saman> are there any Ubuntu open projects and how do we join
[21:44] <ivoks> ubuntu open projects?
[21:44] <ivoks> ubuntu is an open project :)
[23:32] <Le-Chuck_ITA> Hi there, may I draw your attention to bug #132583? It seems to have a one-line fix
[23:32] <ubotu> Launchpad bug 132583 in openoffice.org "python-uno can't be imported" [Low,Confirmed] https://launchpad.net/bugs/132583
[23:35] <Le-Chuck_ITA> and it's low priority, but it really breaks an important part of openoffice
[23:37] <somerville32> Le-Chuck_ITA, Did you provide a patch?
[23:38] <Le-Chuck_ITA> the quick way
[23:39] <Le-Chuck_ITA> there's a path missing from ld.so.conf, so the patch is to create a single-line file in /etc/ld.so.conf.d
[23:39] <Le-Chuck_ITA> I wrote that in a comment but didn't create a debdiff
[23:41] <Le-Chuck_ITA> somerville32: ping :)
[23:42] <somerville32> Le-Chuck_ITA, Ok. I'm sure someone will get to it. :)
[23:42] <somerville32> Thanks for the help!
[23:42] <somerville32> You might mark it triaged btw
[23:43] <Le-Chuck_ITA> I didn't do anything actually, the merit is due to other commenters
[23:43] <Le-Chuck_ITA> but will mark it as triaged
[23:46] <Le-Chuck_ITA> it's already triaged! :) so my task ends here
[23:46] <Le-Chuck_ITA> thanks and bye