[00:40] <Ekushey> how do i upload to the PPA? i can't find the option to do that :(
[00:41] <cprov> Ekushey: https://help.launchpad.net/PPAQuickStart
[00:48] <Ekushey> cprov, i checked that, but it didn't help. i activated my PPA earlier, but i can't see any option to upload.
[00:50] <cprov> Ekushey: are you familiar with debian/ubuntu upload systems and the tools (`debuild` & `dput`) ?
[00:51] <Ekushey> cprov, no i'm not... do i need to do it from shell?
[00:52] <cprov> Ekushey: yes, you have to install and configure the tools to build and upload a source package.
[00:52] <Ekushey> oh!
[00:53] <cprov> Ekushey: check the ubuntu-package-guide reference.
[00:53] <Ekushey> sorry cprov, i thought there will be an upload button somewhere
[00:53] <Ekushey> alright, thanks
[00:53] <cprov> Ekushey: np
[00:55] <poolie> thumper: ping?
[00:56] <poolie> thumper: re bug 239958, maybe the instructions should have a "help" link or somethnig which could give more detail
[00:56] <poolie> i'm not sure if it would really help
[01:03] <thumper> poolie: yeah, not sure
[01:13] <genii> How can I change my ppa to Hardy from the current Intrepid ?
[01:15] <cprov> genii: do you mean 'upload' to hardy  or just change the UI widget to render hardy sources.list entry ?
[01:16] <genii> cprov: Both would be informative, if possible
[01:17] <cprov> genii: set the right distroseries in the debian/changelog entry (man dch)
[01:17] <genii> cprov: I'm currently trying to update pdfedit from 0.3.2   to 0.4.1  but Intrepid has this already, would be for Hardy
[01:18] <cprov> genii: to see a different sources.list entry, select a new series in the first dropdown box in your PPA page.
[01:19] <cprov> genii: sorry, I don't understand exactly what you mean.
[01:22] <genii> cprov: 8.10 has version 0.4.1 (latest) of the application pdfedit, however it's only up to 0.3.2-something in general for 8.04 . So I already successfully built from source (i386) on my box here with checkinstall.
[01:23] <cprov> genii: okay, fine, but how is it related with PPAs ? Do you want to upload and build the intrepid source for hardy in your PPA ?
[01:25] <genii> cprov: Ideally to just upload the lates sources (0.4.1) but for Hardy. The confusion I'm having seems to be that by default it wants it to be Intrepid
[01:26] <cprov> genii: yes, that's what is pointed by the last entry in the debian/changelog
[01:27] <genii> OK, have git-buildpackage and examining the dch manpage now
[01:27] <cprov> genii: lot s of options for you.
[01:27] <genii> cprov: I think I need a "Launchpad for Dummies" book :)
[01:27] <cprov> genii: 1 )you can copy the source and binaries from intrepid to hardy in your PPA
[01:28] <cprov> genii: 2. you can create a new source package version of the same source pointing to hardy
[01:29] <genii> cprov: Number 2 looks most prudent
[01:30] <cprov> genii: probably.
[01:35] <genii> cprov: There pre-exists here a Changelog
[01:35] <cprov> genii: ?
[01:41] <genii> cprov: In reading the dch manpage it seems it examines the Changelog for naming which would be something like "PDF Editor 0.4.1" (likely with underscores added or so). But recommended naming for ppa seems to me would be along line of: PDFEditor_0.4.1-0ubuntu1~ppa1
[02:00] <cprov> genii: yes, that's the safest way to have a intrepid version rebuilt in hoary, because 0.4.1-0ubuntu1~ppa1 < 0.4.1-0ubuntu1, so your system would dist-upgrade fine.
[02:03] <persia> genii: Be warned that if you are working towards something that will become a backport, the official backport will be 0.4.1-0ubuntu1~hardy1, which is less than that string.  You might want to use ~0ppa1 so that if there is later an official backport, users are upgraded to the official backport.
[02:04] <genii> Hm
[02:06] <genii> Sorry for lag, currently reading https://wiki.ubuntu.com/PackagingGuide/Howtos/PackagingFromScratchHelloDebhelper to get a grasp on how to do a diff from orig.tar.gz kind of thing. Building locally doesn't usually require all this etc
[02:07] <genii> Quite dry reading I may add
[03:05] <genii> Whats an acceptable substitution for a tilde in the packagename?
[03:06] <genii> eg: dpkg-source: error: source package name `pdfedit-0.4.1-0ubuntu1~ppa1' contains illegal character `~'
[03:07] <jamesh> genii: perhaps it is only after the "pdfedit" bit?
[03:07] <jamesh> you can definitely have a "~" in the version number
[03:08] <genii> Perhaps I just need to remove it for now
[03:11] <jamesh> genii: you generally want just the source package name in the debian/control file, and the version number in debian/changelog
[03:13] <genii> jamesh: The original source name didn't have the -0ubuntu1~ppa1 ending, but then dh_make groaned and I renamed it to fit. In the control file may be the issue?
[03:14] <jamesh> genii: in the usual case, you should leave the package names in debian/control as is
[03:15] <jamesh> genii: include your suffix in the version number for the most recent changelog entry
[03:15] <jamesh> (that is where the package version is picked up from)
[03:17] <genii> OK. So If I have Package: namehere~ppa1  in control this reverts to same as source name?
[03:20] <jamesh> why do you want ~ppa1 in the package name?
[03:20] <jamesh> don't you want that in the version number?
[03:21] <genii> jamesh: I'm trying to understand this.
[03:22] <jamesh> genii: if you want the package in your PPA to upgrade whatever is provided in Ubuntu, you should use the same package name, but a higher version number
[03:26] <genii> jamesh: I've managed to successfully locally compile this app for Hardy (pdfedit-0.4.1) from the source at Sourceforge. There seems to be an earlier Hardy version (0.3.2) in the repos already. I'm painfully trying to understand step by step how to do the dh_make, debuild, dput  process. The ppaquick start suggests to name packages with an ending of ~ppa#
[03:27] <genii> (as detailed here https://help.launchpad.net/PPAQuickStart )
[03:28] <jamesh> genii: it recommends that as a suffic on the version number
[03:28] <jamesh> not the package name
[03:28] <genii> Hmm
[03:28] <jamesh> suffix, even
[03:29] <genii> So version number is only in Changelog?
[03:29] <jamesh> right.
[03:29] <jamesh> you can't actually produce a new version of a debian package without touching the changelog
[03:31] <genii> OK I'm gonna go delving in there again
[03:31] <jamesh> genii: https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <- this might help you
[03:32] <genii> jamesh: I've been working a bit from https://wiki.ubuntu.com/PackagingGuide/Howtos/PackagingFromScratchHelloDebhelper but it seems to give conflicting info compared to the ppa page
[03:33] <genii> If not conflicting then at least confusing
[03:33] <jamesh> genii: if you are updating a package to a new version, you probably don't want to do your packaging from scratch
[03:34] <jamesh> otherwise you're throwing away all the work others have done on it (as well as making a lot more work for yourself)
[03:35] <genii> jamesh: So if I just did something like dh_make in the original source code dir without doing the .orig  stuff likely would have worked?
[03:36] <genii> If nothing else I'm seeing how the debian/control   and so on functions anyhow :)
[03:41] <jamesh> genii: packaging from scratch is worth doing as a learning exercise, sure.
[03:42] <jamesh> [I should probably do it some day too ...]
[03:42] <genii> Heh
[03:42] <jamesh> but if you want a usable package, it is better to try and update an older packaging
[03:43] <jamesh> besides: upgrading packages is a more common operation than packaging something from scratch
[03:45] <genii> jamesh: So in this case, getting the source for 0.3.2 then doing some diff for 0.4.1 ?
[03:46] <jamesh> genii: right.  If you have the deb-src lines in your sources.list, you should be able to do "apt-get source pdfedit"
[03:46] <jamesh> download the newer tarball, and there is some command you can run to move the existing packaging over to it
[03:46] <genii> I think I'm gonna need more Advils
[03:47] <jamesh> The Debian packaging howto is worth reading if you haven't already
[03:48] <genii> I've been basically working off the packaging guide I mentioned earlier
[03:49] <genii> I think what may be giving me grief is that the original sources are not debian to begin with (that I've been working with)
[03:53] <genii> What eludes me is how something locally done like ./configure;make;sudo checkinstall  to end up with a deb package gets so convoluted when trying to get basically the same thing onto my PPA
[03:57] <lifeless> because checkinstall is fundamentally broken
[03:57] <lifeless> and it is giving you a very false idea of what packaging entails
[04:00] <genii> lifeless: Would the dh_make/debuild  method more educational to use when compiling sources if I wanted to get a better understanding ?
[04:01] <genii> (as well as dch I imagine)
[04:03] <lifeless> I recommend you use the MOTU teaching materials
[04:03] <lifeless> #ubuntu-motu is the IRC channel
[04:04] <lifeless> the team there are dedicated to teaching people about packaging as part of their tasks
[04:05] <genii> lifeless: Thanks.
[04:33] <genii> lifeless: They've actually ben pretty helpful there
[04:33] <genii> *been
[04:34] <persia> We aim to please :)
[04:36]  * genii slides persia a coffee
[04:36] <genii> Need to get back now to my usual channels :)
[07:30] <mpt> Gooooooooooooooooooood morning Launchpadders!
[07:33] <Hobbsee> afternoon mpt!
[07:35] <mpt> Hey, I got here before midnight this time
[07:41] <Hobbsee> \o/
[11:21] <\sh> moins
[11:22] <\sh> gmb: ping :)
[11:22] <\sh> gmb: you offered me some help regarding leonov and launchpad malone ;)
[11:23] <gmb> \sh: Sure! Just give me a few minutes; I'll ping you when I'm free.
[11:24] <\sh> gmb: cool...if you are free :) please join #leonov , thx :)
[14:08] <Dauerbaustelle> Hey guys, got a question: Why does code.launchpad.net need so long for displaying new revisions in preview (code.launchpad.net/~mytool/mybranch) ?
[14:09] <Dauerbaustelle> Also known as "recent revisions"
[14:13] <Dauerbaustelle> Anyone there?
[14:14] <jamesh> Dauerbaustelle: after you upload your changes via bzr+ssh or sftp, there are two processes that need to run
[14:15] <jamesh> the first does the equivalent of "bzr push" to transfer your changes to the publicly published area of the server (ensuring that it is a real bzr branch and that corrupt data isn't published)
[14:15] <jamesh> the second scans the data from the public location for use within Launchpad itself (e.g. for the code.launchpad.net pages)
[14:16] <jamesh> the delay should not be too long (usually just a few minutes), but can take longer if a lot of other data has also been pushed around the same time
[14:17] <Dauerbaustelle> oh, ok
[14:17] <Dauerbaustelle> is there a page where i can see new revisions after process #1?
[14:19] <jamesh> http;//bazaar.launchpad.net/~user/project/branch/changes should reflect it
[14:19] <jamesh> (that'll be loggerhead running against the published version of your branch)
[14:19] <jamesh> this is the "browse revisions" link from the code.launchpad.net page
[14:20] <Dauerbaustelle> Oh
[14:20] <Dauerbaustelle> yeah, you're right
[14:20] <Dauerbaustelle> thank you!
[14:52] <\sh> dear lp admins, what do I need to do to get a mailing list approved? :)
[18:34] <doctormo> I'm trying to intergrate with launchpad for our loco website using the openid system
[18:35] <doctormo> If I direct people to login to launchpad, how can I get them back onto our site? is there a redirect?
[18:40] <doctormo> Does anyone frequent here?
[18:47] <beuno> doctormo, that's not how openid works
[18:48] <beuno> people don't have to login into Launchpad
[18:48] <beuno> doctormo, http://en.wikipedia.org/wiki/OpenID#Logging_in
[18:51] <doctormo> beuno: People don't have to log into my website either, but if I know they are logged into launchpad I can identify them.
[18:54] <doctormo> Thanks for the link btw
[18:54] <beuno> :)
[18:55] <beuno> I don't follow what you want/need then
[18:58] <doctormo> beuno: A website, run by a LoCo team, where the intity management is tied to launchpad. We don't really want people with users on the website that are not on launchpad.
[18:58] <doctormo> Perhaps I will just create a link to the logon openid and feed it the login.launchpad.net address
[19:01] <beuno> doctormo, well, if people are using their LP openid, then it means they have a LP account
[19:01] <beuno> so they should just login with their LP openid into your site
[19:02] <beuno> and you can avoid going through LP itself
[19:14] <doctormo> beuno: that is the hope...
[19:24] <schierbeck> hi guys
[19:24] <schierbeck> is there any kind of authentication of revision committers as shown on the code pages, or do you simply match by the committer email address?
[19:25] <schierbeck> as far as i can see, only the pusher is authenticated
[19:25] <schierbeck> eh, the one pushing the revisions...
[19:26]  * beuno bets on the "only matching email theory"
[19:26]  * schierbeck agrees, but sees potential spoofing issues
[19:27] <beuno> in fact, if you upload revisions with an email that's not in LP, it doesn't recognize it
[19:27] <schierbeck> that sounds like a clear sign to me :)
[19:27] <beuno> that's true, although, I suppose you already trust the people you allow to upload to the branch
[19:28] <schierbeck> true
[19:28] <beuno> sounds like a bug that will get some discussion  :)
[19:28] <schierbeck> you *could* however match by their gpg signature to be sure :)
[19:29] <beuno> *if* people sign their commits
[19:29] <schierbeck> they probably would if it added any real benefit
[19:29] <schierbeck> currently, the semantics seem ill-defined
[19:29] <beuno> and, I'm not sure, but I think you can't really verify the signed commits, can you?
[19:29] <schierbeck> well, undefined
[19:29] <schierbeck> beuno: you can
[19:30] <beuno> ah, cool. I don't know why I thought that you couldn't currently
[19:30] <schierbeck> you can verify the signature itself and compare the signature owner's name and email against the commit's
[19:30] <beuno> nobody from codebrowse seems to be around  :/
[19:31] <beuno> it'll be a few hours before mwhudson wakes up, and I don't know who else works on it.  abentley maybe?
[19:31] <schierbeck> beuno: i'm actually doing it in bzr-gtk, although it's disabled right now -- we still need to match the signed text against the revision to avoid spoofing
[19:31] <schierbeck> perhaps
[19:32] <schierbeck> i'll add a bug for it
[19:32] <beuno> cool, let me know what # so I can subscribe  :)
[19:32] <abentley> beuno: I don't do lots on codebrowse, but I'm reasonably familiar with it.
[19:33] <beuno> abentley, do you happent to know if what schierbeck is saying is true?  It uses a simple email matching on the committer's email?
[19:35] <abentley> beuno: I can't say offhand.  I would imagine the performance hit of doing so would be unpleasant.
[19:36] <beuno> abentley, ok, thanks. We'll see what comes out of the bug
[19:36] <schierbeck> beuno, abentley: i've filed bug #240756
[19:36] <beuno> it does seem like a potential security problem
[19:39] <abentley> schierbeck: Are you talking about the loggerhead-style view or launchpad-styled view?
[19:40] <beuno> lp-style view which links to the user's page
[19:41] <beuno> which is what would make it a LP security issue I suppose
[19:42] <abentley> beuno: It would be a security issue if it allowed someone to do something with the permissions of that user.  I don't think that's the case.
[19:44] <beuno> abentley, right. Spoofing risk then. If I upload a revision of bzr as<EMAIL_ADDRESS>then LP will show it as you would have made that revision
[19:44] <abentley> beuno: We also, for example, don't require authentication when commenting on bugs.
[19:45] <beuno> abentley, you do have to have a LP account to comment on bugs. And that user is attached to that comment. Not so for revisions
[19:45] <beuno> bzr's nature will make this a tricky one
[19:45] <beuno> but gpg sounds like one solution
[19:47] <abentley> beuno: The mail interface does not require a GPG signature for commenting.
[19:47] <beuno> ah, then that's not so good either   :)
[19:47] <cr3> how can I have a ppa for multiple releases? must I create different branches and have the build release in the changelog?
[19:47] <abentley> Sure it is.
[19:47] <abentley> It would be worse if we required every message to be GPG signed.  Would prevent lots of people from participating.
[19:48] <beuno> agreed. Make it optional, and clear that the specific revision hasn't been verified
[19:48] <abentley> Similarly, many people don't bother signing their revisions.  But where they are signed, we ought to be able to verify the signature.
[19:50] <schierbeck> beuno, abentley: i think the verification indeed should be optional -- i'm not sure how to do that in the ui, though
[19:52] <abentley> schierbeck: One option is to specially mark verified revisions, like browsers specially mark SSL web sites.
[19:53] <abentley> But even if you have a signed revision, you don't know that the author is accurate, only that the committer really does claim that to be the author.
[19:53] <schierbeck> abentley: this is kind of what i've been working on in bzr-gtk
[19:54] <schierbeck> my idea is that if the signature email matches the committer email, then we regard that revision as being signed by its committer, i.e. authenticated
[19:54] <abentley> btw, I've looked at the code now, and I'm reasonably certain we're doing no testament verification.
[19:54] <schierbeck> the testament also needs to match, of course
[19:55] <schierbeck> abentley: yeah, that's our main issue with the verification code -- i'm not quite sure if there's an easy way to solve it
[19:55] <schierbeck> i would be very interested if there was
[19:56] <abentley> What's the problem?
[19:58] <schierbeck> abentley: well, i can get the cleartext from the signature, which is the testament, but i need to get a testament from the repository, too
[19:59] <schierbeck> couldn't find anything in the docs, although it's been a while since i worked on it
[19:59] <abentley> It's not hard  to generate a testament.
[19:59] <schierbeck> abentley: please enlighten me :)
[20:00] <abentley> from bzrlib import testament; testament.Testament.from_revision(repository, revision_id)
[20:01] <schierbeck> abentley: i feel a bit foolish now...
[20:02] <abentley> Sorry.
[20:02] <schierbeck> not your fault
[20:02] <abentley> You'll want to invoke as_short_text, I believe.
[20:02] <schierbeck> ok
[20:02] <abentley> The result of that should match the signed text.
[20:03] <schierbeck> i think we just didn't make it for the release, and i lost focus
[20:05] <schierbeck> hmm, someone broke the seahorse integration bits in the meantime
[20:07] <abentley> schierbeck: Only fair.  The seahorse integration bits broke lots of other things :-)
[20:09] <schierbeck> abentley: yup :)
[20:09] <schierbeck> guess it's karma
[21:44] <johan> mwhudson: ping
[21:45] <mwhudson> johan: hi
[21:45] <johan> mwhudson: remember the vcs-import issue I mentioned two weeks ago?
[21:45] <mwhudson> johan: yes
[21:45] <mwhudson> i fixed the bug, but we haven't had a roll out yet
[21:45] <johan> ah, excellent
[21:45] <johan> not even on on edge or staging?
[21:45] <mwhudson> there is a rollout next weekend
[21:45] <johan> [or perhaps vcs-imports isn't running there]
[21:46] <mwhudson> next week, rather
[21:46] <mwhudson> johan: there is a staging, but for boring reasons it's hard to test there
[21:46] <bdmurray> gmb: I'm still seeing "couldn't connect to OpenOffice.org issue tracker" with some openoffice.org bugs
[21:46] <mwhudson> the staging environment doesn't have access to the existing production import
[21:46] <mwhudson> so it starts from the beginning again
[21:47] <johan> mwhudson: sure, I'll just wait until the next rollout then.
[21:47] <mwhudson> johan: i _can_ test it on staging, but it's a fiddle
[21:47] <mwhudson> we can also cherrypick the fix onto production
[21:47] <mwhudson> but yeah, waiting a week is the easiest approach if you're not in a hurry
[22:35] <gmb> bdmurray: Yeah, it looks like the Bugzilla XML interface has been disabled on the OO.o bugtracker, so we're not able to fetch any bugs.
[22:35] <gmb> I've contacted the admins to see what the situation is.
[22:36] <bdmurray> gmb: they have an rpc interface?
[22:39] <gmb> bdmurray: Nope. Even if they did, the basic Bugzilla XML-RPC interface doesn't actually provide what we need to pull bug statuses in.
[22:40] <bdmurray> gmb: oh, okay.  are they any rpc interfaces that you do use?  I'm curious about other bug tracking systems.
[22:41] <gmb> bdmurray: Not at the moment. But we've done the work to enable working with Trac over an RPC interface (provided by a plugin on the Trac side) and I'm currently working on the same kind of functionality for Bugzilla (again provided by a plugin).
[22:42] <gmb> bdmurray: For most bugtrackers we either use XML (or CSV) exports.
[22:42] <bdmurray> gmb: I've heard about the plugins, thanks.
[22:43] <bdmurray> I've been thinking of ways to make it easier to setup bug watches.
[22:49] <gmb> bdmurray: If you've got any ideas, I'm all ears :)
[22:51] <bdmurray> gmb: I'll keep that in mind. I've been playing with the debbugs SOAP interface recently and searching bug bodies for strings.
[22:58] <gmb> Cool.
[23:14] <YokoZar> hmm launchpad ssl seems down
[23:14] <YokoZar> for the launchpad librarian I mean
[23:14] <mwhudson> YokoZar: the production machines are being upgraded to hardy
[23:15] <YokoZar> Yeah, I figured it was part of that.  seemed odd that librarian was still up for a moment though


[12:41] <mpt> cevizoglu, GNUstep
[12:42] <mpt> tracks Cocoa pretty much
[12:42] <mpt> Try #gnustep
[12:51] <whiprush> man, what's with jdub's orange jumpsuit
[12:52] <whiprush> the inmate look in or something?
[12:52] <ajmitch> it's jdub. need you ask more?
[12:53] <ajmitch> surely not
[12:53] <whiprush> the flickr box on fridge picked up magicfab's photos
[02:27] <lupusBE> some packages depending on libnspr4 in dapper are broken because they require a lower version
[02:27] <lupusBE> anyone fixing this?
[02:37] <bob2> lots of things are broken in dapper
[02:50] <zul> heylo
[04:18] <fernando> hi all
[04:18] <fernando> E: Build-dependencies for mutt could not be satisfied.
[04:19] <fernando> my sources.list and apt-get update, http://paste.ubuntulinux.nl/3911
[07:52] <whiprush> jdub: dude ... what channel was I just on talking to you ... (busted terminal)
[07:58] <robitaille> whiprush,  on ubuntu-sounder?
[07:58] <whiprush> robitaille: I was talking to jdub about 5 minutes ago, and my terminal died, and I have no idea what channel it was on.
[07:58] <whiprush> heh
[07:59] <robitaille> whiprush,  it was on #ubuntu-sounder
[07:59] <whiprush> not that one, I seem to be missing 5 minutes of conversation on some channel.
[07:59] <whiprush> thanks
[08:00] <robitaille> humm..it wasn't on any channel i'm on.  Too many of them...
[08:00] <zakame> hi all
[08:00] <zyga> morning
[08:58] <pef> hello
[09:46] <bob2> is /etc/ld.so.conf supposed to be non-existent on fresh breezy systems?
[09:47] <bob2> (now X stuff is in /usr)
[11:10] <mdke> geez no one replies to list on -devel
[01:49] <hunger> Any chance of seeing xen in ubuntu soon, now that redhat commited to pushing it into the vanilla kernel?
[01:51] <dholbach> hunger: the easiest thing is to write a specification and offer help with it
[01:53] <hunger> dholbach: Xen is pretty "invasive". I can try to write up something, but this is nothing someone can do without serious backup from "management".
[01:53] <dholbach> the first thing is to write a spec and gather people around it
[01:54] <hunger> dholbach: Either it is adding a new architecture for the kernels or it is changing the default kernel to be a xen kernel and use xen everywhere.
[01:54] <hunger> dholbach: Is there a spec-writting howto?
[01:55] <dholbach> http://launchpad.net/distros/ubuntu/+specs has quite a bunch of already good-looking specs - https://wiki.ubuntu.com/SpecTemplate has a template
[01:59] <kent> will there be videos or audiorecordings from UBZ?  It would be fun to listen/watch..
[02:00] <dholbach> morning sabdfl
[02:00] <Mez> there are videos from the lightning talks... dont know about anything else.
[02:00] <Mez> dont know if the videos will be shared either
[02:00] <dholbach> treenaks is the video master
[02:01] <sabdfl> video's for everybody!
[02:02] <hunger> zyga: Yeap... nobody is producing debs anymore;-)
[02:02] <zyga> hunger: no, I'm excited about some new things coming to ubuntu and no-one is here to talk about them :-)
[02:02] <zyga> everyone is out there *g*
[02:03] <hunger> zyga: Yes, I do feel somewhat out of the loop, too.
[02:03] <hunger> zyga: Of course I'm just a curious bystander with no need to be in the loop but anyway:-)
[02:04] <the--dud> the ubuntu-devel mailinglist is terribly quiet now under UBZ
[02:04] <the--dud> quite freaky hehe
[02:04] <zyga> hunger: I'm out of the loop but I run across the road from time to time
[02:07] <hunger> zyga: You are in montreal (or where was UBZ?)
[02:07] <hunger> zyga: Lucky you... canada is *NICE*.
[02:13] <zyga> hunger: no I'm faar away from canada
[02:14] <zyga> hunger: I'm from Poland and I run across the loop virtually
[03:03] <pitti> carstenh: ah, firewall is today 1430
[03:04] <Yagisan> pitti: firewall ?
[03:04] <pitti> Yagisan: https://launchpad.net/distros/ubuntu/+spec/firewall
[03:08] <pitti> slomo: ping
[03:09] <Yagisan> pitti: If I understand correctly, you will discuss setting up a personal firewall, rather then say ubuntuising ipcop ?
[03:09] <slomo> pitti: pong
[03:13] <pitti> slomo: mplayer warty+hoary FTBFS on powerpc
[03:14] <pitti> Yagisan: s_personal_Ubuntu/Debian specific_
[03:14] <zyga> pitti: hello :)
[03:14] <slomo> pitti: uh? hmm, can you give me the buildlog? it's not here: http://people.ubuntu.com/~lamont/buildLogs/m/mplayer/
[03:15] <pitti> slomo: your email?
[03:15] <slomo> pitti<EMAIL_ADDRESS>[03:15] <Yagisan> pitti: thanks.
[03:15] <slomo> pitti: and both worked fine here on x86... :/
[03:16] <pitti> slomo: I sent you all three logs (but don't worry about ia64)
[03:20] <slomo> pitti: uh... that's nothing caused by the patch... it was broken before it seems :(
[03:21] <pitti> slomo: but we have a deb in hoary (however, not in warty)
[03:21] <pitti> mplayer-powerpc | 1:1.0-pre6-0.3ubuntu5 | hoary/multiverse | powerpc
[03:22] <ivoks> hi guys
[03:22] <slomo> pitti: ubuntu5, yes... but the newest was ubuntu6 :/
[03:22] <pitti> ah, too bad
[03:22] <pitti> ok, let's forget about that then
[03:23] <pitti> slomo: I release the i386/amd64 packages now
[03:23] <slomo> ok, thanks :)
[03:23] <slomo> at least in breezy mplayer was buildable on all 3 arches at release time ;)
[03:23] <pitti> slomo: breezy was not vulnerable to that issue?
[03:24] <slomo> pitti: no... i fixed it weeks before release while i was doing other stuff with mplayer
[03:24] <pitti> nice
[03:25] <carstenh> pitti: ok, thanks.
[03:25] <pitti> carstenh: is it possible for you to be online at that time, in case questions arise?
[03:26] <carstenh> sure, 14:30 in which timezoe?
[03:26] <pitti> carstenh: we are -5 here
[03:26] <pitti> carstenh: e. g. 20:30 CET
[03:26] <carstenh> ok, i'll be there :)
[03:26] <pitti> carstenh: thanks
[03:46] <zyga> issue to think about
[03:46] <zyga> if we use utf8 by default we could gain significant memory savings by converting all .mo files to use utf8
[03:47] <zyga> that saves iconv runs and memory duplication
[03:47] <zyga> pitti: ^^^
[03:47] <pitti> zyga: this shuold be handled by the Rosetta output
[03:47] <zyga> pitti: rosetta always keeps existing encoding
[03:47] <zyga> (on export)
[03:47] <zyga> and carlos said that's the preferred way
[03:47] <pitti> zyga: by default yes, but we might tell it to convert it to UTF-8 on langpack export
[03:47] <pitti> carlos: ^
[03:47] <carlos> zyga, I think that it would cause problems with some applications that are not UTF-8 friendly if the user has an UTF-8 locale (as ubuntu does by default)
[03:48] <zyga> carlos: such apps could be crashed in dapper devel run
[03:48] <zyga> carlos: and the majority of apps gains 1/2 memory less used
[03:48] <carlos> zyga, I can do that special export easily, but I'm a bit concerned about it....
[03:49] <pitti> carlos: but gettext does automatic conversion anyway, doesn't it?
[03:49] <zyga> carlos: we could build a blacklist
[03:49] <zyga> pitti: yes but it pulls memory
[03:49] <zyga> pitti: if the .mo file is utf8 and the output is utf8 then you only get one mmap
[03:49] <pitti> zyga: I mean, if apps run in latin1, they can still use utf8 mo files
[03:49] <carlos> pitti, you can disable that
[03:50] <zyga> pitti: yes
[03:50] <carlos> pitti, in fact, GNOME applications 'disable' it and force UTF-8
[03:50] <zyga> carlos: exactly
[03:50] <zyga> the more utf8 we have the better
[03:50] <zyga> legacy encodings only cause problems in the long run
[03:50] <carlos> zyga, you don't need to convince me, it's just something that we should handle with upstream, that's all
[03:51] <carlos> at least that's my opinion
[03:51] <pitti> sounds sane
[03:51] <pitti> in the long run upstreams will convert anyway (most of them)
[03:51] <zyga> carlos: upstream can keep using their version, usually legacy encodings come from legacy systems and legacy translators, not for some real need
[03:51] <zyga> pitti: did you hear about .desktop gettext support? :)
[03:51] <carstenh> pitti: do you care about ipv6 for dapper?
[03:52] <carlos> pitti, if you want to play with all .po files as UTF-8 is your choice, file a bug and I will change the code to produce the language packs as UTF-8 exports
[03:52] <pitti> carstenh: doesn't breezy support ipv6?
[03:52] <carlos> pitti, I will not have time to test dapper for errors, that's why I'm not too excited about it, that's all
[03:52] <pitti> carlos: we could build the first dapper langpack with it, just to try it out
[03:52] <carstenh> pitti: breezies kernel does not support stateful package filtering for ipv6
[03:52] <zyga> pitti: I second that idea
[03:52] <carlos> pitti, sure
[03:52] <pitti> carlos: ok
[03:53] <carlos> pitti, zyga file a bug about it with High priority so as soon as dapper opens at launchpad so we have something to export
[03:53] <zyga> pitti: I've patched some libs and gnome can use gettext for .desktop files ATM
[03:53] <carlos> I will change it
[03:53] <zyga> carlos: sure
[03:53] <Yagisan> carstenh: IIRC no kernels do stateful filtering on ipv6 yet
[03:53] <carlos> zyga, really?, please, mail us the patch so we can take a look
[03:53] <carstenh> pitti: when the firewall should support ipv6 the kernel needs a patch
[03:54] <zyga> carlos: they are online already
[03:54] <carlos> zyga, thank you for working on it
[03:54] <carstenh> Yagisan: yes, that is the problem
[03:54] <carlos> zyga, URL?
[03:54] <zyga> carlos: added that to the specs, one sec
[03:54] <carlos> ok
[03:54] <zyga> https://launchpad.net/distros/ubuntu/+spec/langpacks-desktopfiles
[03:54] <zyga> carlos: both patches are attached to the bugs
[03:54] <carlos> ok
[03:54] <zyga> carlos: it works but I didn't test performance yet
[03:55] <carlos> zyga, if you would do some performance tests with and without your changes that would be really cool
[03:55] <carlos> so we can ask upstream again to include it (if the performance is good enough)
[03:55] <zyga> carlos: I plan to really, if performance sucks I'll write a gettext proxy and see how that helps
[03:55] <carlos> zyga, we should use some kind of cache
[03:55] <zyga> carlos: there are some serious issues that need to be addressed
[03:56] <carlos> zyga, so we only read the .mo once per session
[03:56] <zyga> carlos: I was thinking about a gettextd that builds /var/cache/gettext but IPC could harm the performance
[03:56] <zyga> carlos: or simply build one .mo file for all .desktop files
[03:56] <zyga> carlos: but that's an issue with another lengthy rebuild every upgrade
[03:57] <zyga> mvo: ping, around? :)
[03:58] <carlos> zyga, dude, a daemon for this is completely a waste of resources...
[03:58] <zyga> carlos: I was worried about it too ;-)
[03:59] <zyga> carlos: but when you need to open a 100 of .mo files and a 100 of .desktop files it will kill startup easily
[03:59] <zyga> carlos: such daemon (or cache in other way) could reduce that to 2 files
[03:59] <zyga> and that would really help
[04:00] <Lathiat> we simply need a single file cache of /usr/share/applications
[04:00] <zyga> Lathiat: yes, but after decoupling the translations we need a second cache for all the .mo files
[04:00] <Lathiat> why decouple the translations?
[04:00] <Lathiat> they can be stuck in the cache
[04:00] <Lathiat> a single slightly big file isnt a proabbly
[04:00] <Lathiat> 350 tiny files is
[04:00] <zyga> Lathiat: hmm
[04:00] <zyga> Lathiat: true
[04:01] <zyga> Lathiat: but what could rebuild/invalidate that cache?
[04:01] <Lathiat> like you could read in a 10M file happily
[04:01] <Lathiat> reading in 350 200K files sucks
[04:01] <zyga> Lathiat: I agree but I'd say using two caches is easier
[04:01] <Lathiat> zyga: well, 350 50K
[04:01] <Lathiat> zyga: so realistically you want the packages to ask for updates
[04:01] <zyga> Lathiat: one for gettext is easy (easy to build, easy to patch)
[04:01] <Lathiat> but youd probably want some kind of inotify daemon
[04:01] <Lathiat> i guess
[04:01] <zyga> Lathiat: I don't know how to get .desktop cache as I don't know the source that good
[04:02] <zyga> carlos, pitti: I'd love to hear your comments on those patches
[04:02] <Lathiat> zyga: really need to talk to someone a little smarter than i
[04:02] <Lathiat> for the specifics
[04:16] <carlos> zyga, does gnome-panel read all .desktop files every time you open the menu?
[04:17] <zyga> carlos: I'm not sure but it does listen to changes in /usr/share/applications
[04:17] <carlos> zyga, we are a bit busy atm as soon as we get some spare time will look into the patches, UBZ you know...
[04:17] <zyga> carlos: more than fine :-)
[04:17] <carlos> zyga, that means that it only reads the .desktop files again if they change
[04:17] <zyga> carlos: it probably reads them every time something changes
[04:17] <zyga> carlos: yes, and it leaks alot of memory at that time
[04:17] <zyga> (really really bad feature)
[04:18] <carlos> zyga, so you can just store that translation into memory instead of the english string
[04:18] <zyga> carlos: hmm?
[04:18] <carlos> zyga, it stores the menu into memory
[04:18] <zyga> carlos: right
[04:18] <zyga> carlos: and?
[04:18] <carlos> zyga, if you store the translation at that time, you have there the cache feature too
[04:19] <zyga> carlos: that's not the same
[04:19] <zyga> carlos: I want to cache .mo files, not .desktop files yet
[04:19] <zyga> carlos: for every .desktop file it needs to open corresponding .mo file and that kills performance
[04:19] <carlos> zyga, it makes no sense to cache .mo files when you only want two strings from every .mo file...
[04:19] <zyga> carlos: right
[04:19] <zyga> carlos: so we need to cache the looked up strings somewhere :)
[04:19] <carlos> zyga, that happens only the first time you read all menu entries
[04:20] <carlos> zyga, the gnome-panel does it already for us!
[04:20] <zyga> carlos: no, the issues is that in the ideal world we'd have a .desktop = .mo relationship
[04:21] <zyga> carlos: but that means, that on startup for every .desktop file we also need to open a corresponding .mo file (gettext does that for us using lots of stats into various locations)
[04:21] <zyga> carlos: we can cache both things, multiple .desktop files and .multiple .mo files
[04:21] <zyga> carlos: the latter are easier because we could build a .mo file that contains only .desktop-relevant stuff
[04:23] <Mez> where cna i fie bugs against katie?
[04:23] <zyga> carlos: that's why I wanted a gettext daemon that can build a persistent cache, this would (after one run) reduce the number of open calls to 1
[04:23] <zyga> carlos: I'd love to discuss this in #u-desktop when you've got the time
[04:27] <carlos> zyga, you cannot implement this feature doing the implementation 100% depending on the .mo file
[04:27] <carlos> we want to share that with upstream and we can do it easily without depending on .mo files
[04:27] <carlos> so the distros that want (Ubuntu and Sun Solaris) can use .mo files
[04:28] <carlos> and the others will stay with current implementation
[04:28] <carlos> that means that we should be compatible with old .desktop files we are adding an optional improvement
[04:28] <carlos> zyga, I'm sure that a full new way to handle translations would be faster or better, but we should try to share as much code as possible with upstream and upstream already said that they don't want a solution that depends on gettext
[04:28] <zyga> carlos: this is 100% optional
[04:28] <zyga> carlos: the domain lookup takes preference, if possible
[04:28] <zyga> carlos: all existing functionality is preserved
[04:29] <zyga> carlos: eh, gettext is really good, I don't understand that argument
[04:29] <zyga> carlos: as you have argued on the xdg mailing list
[04:30] <zyga> carlos: this is an optional argument
[04:30] <carlos> zyga, but it's done only once and on startup time and we can preload the .mo files into memory like we do (or I think we did)  with hoary
[04:30] <zyga> carlos: yes we can
[04:30] <carlos> zyga, the problem with a single .mo po file is that the strings come from different packages
[04:30] <zyga> carlos: but it's still a significant number of files
[04:30] <zyga> carlos: yes and it needs to be rebuilt on every update somehow, that's bad
[04:30] <carlos> zyga, I think we should do it step by step
[04:31] <zyga> carlos: anyway I think we should check if that works fine now
[04:31] <carlos> first using what we have atm
[04:31] <zyga> carlos: if the performance is really bad we can work that out later or revert the changes anyway
[04:31] <carlos> and then, after some performance checks, start to optimize it
[04:31] <carlos> right
[04:31] <zyga> carlos: the one thing difficult to do with preloading is that it's locale dependent
[04:31] <zyga> you need to check  /usr/share/locale/$FOO/LC_MESSAGES/*.mo
[04:32] <carlos> zyga, you can preload the default locale
[04:32] <carlos> zyga, the amount of computers that use multiple locales is low compared to the ones that use a single one
[04:32] <zyga> carlos: agreed!
[04:32] <carlos> anyway, that's already an optimization, so...
[04:33] <carlos> koke, they removed the ban?
[04:33] <zyga> ca,
[04:33] <koke> carlos: it seems so
[04:33] <zyga> carlos: my plans are 1) make sure it's not buggy 2) make sure it has good performance 3) promote upstream
[04:34] <Mez> koke: for how long
[04:34] <carlos> zyga, 2b) land it into Dapper
[04:35] <zyga> carlos: :-)
[04:35] <zyga> carlos: right :-)
[04:35] <zyga> carlos: 2c) support me at the CC ;-P
[04:35] <carlos> you need it first inside dapper so upstream can see it working
[04:35] <zyga> true
[04:35] <carlos> zyga, I'm not an Ubuntu developer, not sure if I would help there ;-)
[04:36] <zyga> carlos: are you a member?
[04:38] <carlos> zyga, no, at least I'm not aware of it
[04:40] <zyga> carlos: strange I thought you were employed by cannonical
[04:40] <daniels> zyga: not all canonical employees are ubuntu members or developers
[04:40] <zyga> ah, I see
[04:41] <daniels> Mez: it's not coming back
[04:41] <carlos> zyga, I am, but working on Rosetta
[04:41] <Mez> daniels ???
[04:41] <daniels> Mez: the k-line
[04:41] <Mez> oh, good :D
[04:55] <Kamion> carlos: dapper == enterprise release, not great for new/experimental code
[04:55] <Kamion> dapper+1, sure
[04:55] <Mithrandir> Kamion: what, no shiny bling?
[04:56] <Kamion> "rigid and boring"
[04:56] <Mithrandir> but, but, I want xglx and luminocity on my server!
[04:56] <zyga> Kamion: but dapper is technically breezy+1 and breezy is out for a few weeks
[04:56] <carlos> Kamion, does it mean that we are not going to add new features?
[04:56] <Mez> Kamion: any idea why I'm not recieving any mail from katie?
[04:56] <Mithrandir> I want to throw my Xen instances around
[04:57] <Kamion> zyga: dapper will be an enterprise release, supported for five years; we are being very conservative about what we add to it
[04:57] <Kamion> I've mentioned this to you before
[04:57] <Kamion> carlos: cautiously
[04:57] <\sh> Mithrandir: wait for redhat :) they want to integrate Xen into RHEL 5 ,-)
[04:57] <\sh> Mithrandir: in a 2 months timeframe
[04:57] <Mithrandir> \sh: with xglx and luminocity?
[04:57] <Kamion> dude, we have xglx in dapper ;)
[04:57] <Mithrandir> shiny
[04:58] <carlos> Kamion, ok
[04:58] <Kamion> (but it doesn't affect anything else unless you choose to install it ...)
[04:58] <tseng> Mithrandir: WOBBLE
[04:58] <\sh> Mithrandir: well...i didn't read the specs...but there was the announcement today from redhat (or yesterday on eweek)
[04:58] <Mithrandir> Couldn't find any package whose name or description matched "luminocity"
[04:58] <Mithrandir> tseng: yeah, wobble.
[04:58] <jdub> Kamion: s/enterprise/long-term supported/ :-)
[04:58] <Kamion> jdub: whatEVAH
[04:58] <Mithrandir> jdub: semantics :-P
[04:58] <jdub> good sematics though :)
[04:58] <daniels> Mithrandir: not yet
[04:59] <daniels> Mithrandir: probably today or tomorrow, depends on how bored I get
[05:00] <Kamion> We received a request from the user named 'Jeff Waugh (jdub)' trying to join the team 'Ubuntu Members', but
[05:00] <Kamion> [...]
[05:00] <Kamion> I'm so declining this
[05:00] <Mithrandir> who's this Jeff Waugh ANYWAY?
[05:00] <tseng> and what is he good for?
[05:00] <tseng> if not wobbly windows
[05:01] <Mithrandir> he doesn't wobble.  much.
[05:24] <spayne> afternoon all
[05:28] <zyga> can anyone test nautilus crash for me?
[05:28] <spayne> zyga: is this Dapper?
[05:29] <zyga> spayne: yes
[05:29] <spayne> zyga: ach! sorry i only have it running under pbuilder :(
[05:29] <spayne> and my other laptop is busy atm
[05:29] <zyga> open a folder with nfs mountable folder inside, mount the folder outside of nautilus, open the folder in nautilus
[05:29] <zyga> the folder was not user-mountable
[05:30] <zyga> WaterSevenUb: hello! :)
[05:31] <WaterSevenUb> zyga, hey!:) Holiday in here :-p
[05:31] <zyga> WaterSevenUb: same here, the day of the dead
[05:31] <WaterSevenUb> zyga, yeah:)
[05:40] <spayne|laptop> looks like *ubuntu.com is down
[05:41] <Mez> www.ubuntu.com is
[05:41] <spayne|laptop> Mez: what's p?
[05:41] <Mez> dunno
[05:41] <Mez> I'm just saying - it's down here too
[05:43] <spayne|laptop> Mez: p.u.c is down
[05:43] <spayne|laptop> jdub: can i run something by you for the fridge?
[05:44] <tseng> spayne|laptop: are you still expecting the tech board to do something about ifolder today?
[05:44] <spayne|laptop> tseng: possibly, yes
[05:44] <spayne|laptop> tseng: the iFolder guys seem to have some positive stuff
[05:45] <tseng> why did they not reply the to mailing list thread
[05:45] <spayne|laptop> tseng: looks like Flaim may be Open Sourced soon
[05:45] <spayne|laptop> tseng: good question...let me find out
[05:45] <tseng> again
[05:45] <tseng> what does this have to do with the Tech Board
[05:45] <tseng> (no one answered this either)
[05:46] <tseng> its their software to license as theyd like
[05:46] <spayne|laptop> tseng: i answered but it is stuck in my SMTP queue
[05:48] <mjg59> If it can be legally redistributed, it can go in Multiverse and iFolder (if it depends on it) can go in there as well. If you think it could be put in Debian main, it can go in Universe and so can iFolder.
[05:48] <mjg59> So. Uhm.
[05:49] <spayne|laptop> mjg59: it is complicated as a lot of the licnesing isnt documented well
[05:49] <tseng> mjg59: its completely non-distributable as it stands
[05:49] <spayne|laptop> mjg59: which is hopefully what we are going to discuss
[05:49] <tseng> mjg59: but that discussion has nothing at all to do with the tech board
[05:49] <mjg59> spayne|laptop: Why not document the licensing rather than talk about doing so?
[05:49] <spayne|laptop> tseng: boyd said that he has seen it and thought what was going to be discussed later
[05:49] <tseng> sigh
[05:50] <spayne|laptop> mjg59: as i understand, Flaim DB is used by Groupwise and many other Novel products and is non-redistriutable with anyone apart from Novell
[05:50] <the--dud> canonical.com is down as well :o
[05:50] <tseng> all the relevant parties understand the problem
[05:50] <spayne|laptop> tseng: don't blame me :-)
[05:50] <tseng> please do not waste peoples time trying to get patted on the back or something
[05:50] <mjg59> spayne|laptop: So we know it's undistributable. They know it's undistributable. *What is going to be discussed*?
[05:50] <spayne|laptop> tseng: he has idea idea why the others didn't respond
[05:50] <mjg59> We can't do anything about it until the situation is rectified
[05:50] <tseng> mjg59++
[05:50] <tseng> NOTOURBUG
[05:50] <spayne|laptop> mjg59: the manager has been to the legal/flaim department about getting Flaim open sourced for Ubuntu use
[05:51] <mjg59> spayne|laptop: I hope you mean "open sourced for anyone's use"
[05:51] <spayne|laptop> mjg59: i don't know - hopefully yes
[05:51] <mjg59> ?
[05:51] <spayne|laptop> mjg59: i'm in the inbetween guy remember
[05:51] <mjg59> Wow.
[05:51] <spayne|laptop> mjg59: what?
[05:51] <tseng> you are the guy that took over for the inbetween guy
[05:51] <mjg59> spayne|laptop: This still doesn't tell me what's actually going to be discussed.
[05:51] <Robot101> open source for ubuntu's use is meaningless
[05:51] <daniels> so what do you intend to talk to the TB about?
[05:51] <tseng> which is extremely frustrating
[05:52] <tseng> spayne|laptop: please take it off the agenda
[05:52] <daniels> you're going to discuss with the TB how someone else is doing something non-specific which no-one knows about?
[05:52] <spayne|laptop> tseng: why? dholbach suggested it
[05:52] <tseng> spayne|laptop: youve proved the point i think
[05:52] <spayne|laptop> tseng: proved what point? why has this been left till today
[05:52] <mjg59> tseng: If Novell people are expecting to turn up, it should probably be left there. It looks bad otherwise.
[05:52] <mjg59> spayne|laptop: It would be helpful if you could flesh out the agenda item.
[05:53] <spayne|laptop> mjg59: what do you mean?
[05:53] <mjg59> At the moment I have no idea what's supposed to be discussed or what sort of decisions are supposed to be made.
[05:53] <mjg59> The tech board isn't there to be told things. It's there to make decisions.
[05:53] <daniels> what can it decide?
[05:53] <mjg59> So frame the discussion in such a way that there's a decision to be made.
[05:53] <mjg59> If there's no decision to be made, then it shouldn't have been brought up. That's unfortunate, but we'll have to live with it.
[05:54] <spayne|laptop> daniels: listening to what Novell have to say and decide if it is satisfactory for ubuntu inclusion
[05:54] <mjg59> spayne|laptop: That will depend entirely on what the LICENSE file in the tarball says.
[05:54] <daniels> spayne|laptop: so is a novell representative coming?
[05:54] <daniels> spayne|laptop: if so, then yes, I can see how that would be useful
[05:54] <spayne|laptop> daniels: most of the iFolder team yes
[05:54] <daniels> i see
[05:55] <tseng> i will not be a fan of any agreements that dont satisfy DFSG
[05:55] <mjg59> And the conclusion there is obvious - if it's distributable, it can be accepted. If it's Free, then it can go in Universe.
[05:55] <spayne|laptop> daniels: the manager for the whole iFolder project is coming
[05:56] <spayne|laptop> tseng: i'd love a situation that complies with the DFSG but i think getting packages into Ubuntu is the most important issue atm
[05:56] <spayne|laptop> tseng: as it is limiting the appeal of iFolder
[05:56] <spayne|laptop> tseng: but i'd love something that is DFSG as well
[05:57] <mjg59> spayne|laptop: You realise that putting iFolder in multiverse is limiting its appeal anyway
[05:57] <mjg59> As long as it's out there, it can never be on the CDs
[05:57] <spayne|laptop> mjg59: not as much as the moment - there are NO packages
[05:57] <Xof> daniels: regarding Ubuntu bugzilla #17002, can I ask whether you need any more information?  (It's still tagged as NEEDINFO)
[05:57] <spayne|laptop> mjg59: but any packages are better than no packages 'at the moment'
[05:57] <mjg59> spayne|laptop: Don't lose track of the big issue here. We're a Free software distribution.
[05:57] <spayne|laptop> mjg59: i am aware of that
[05:57] <mjg59> Putting stuff in multiverse should only happen if it's software that people really can't do without
[05:57] <tseng> lunch
[05:57] <tseng> sorry.
[05:58] <spayne|laptop> tseng: have fu
[05:58] <spayne|laptop> hey ogra
[05:58] <mjg59> We shouldn't be advertising multiverse. It's "Oh, yeah, we include some non-free shit if you really need it", not "And in multiverse we have this REALLY COOL STUFF"
[05:59] <mjg59> If you're happy with this stuff in Multiverse, then cool. But that means iFolder gets relegated, and we're not going to talk about how cool it is.
[05:59] <\sh> ifolder is not cool when it's not free...
[06:00] <daniels> Xof: finding out if it works with -driver-ati 6.8.2-75 would be interesting
[06:00] <mjg59> I'd love to have iFolder goodness, but if it's in multiverse then I really don't care
[06:00] <elarson> \sh, remember just flaim is not cool b/c _it_ is not free :)
[06:00] <spayne|laptop> Flaim is bad, i agree
[06:00] <spayne|laptop> but if it can be Open Sourced in a reasonable timeframe....
[06:01] <Mez> spayne|laptop, as I said in #ifolder
[06:01] <Robot101> ... then it's something Novell just has to do, nothing to do with us :)
[06:01] <Mez> until ifolder is under a licence that is compatible with ubuntu/DFSG then there is nothing to be discussed
[06:01] <mjg59> spayne|laptop: If it can be, then excellent. We can't do that for them.
[06:01] <Mez> (within ubuntu)
[06:01] <spayne|laptop> Mez: but we don't know what might be happening
[06:01] <mjg59> Nnngh.
[06:01] <Mez> which is why people like you an i keep on top of it
[06:01] <Mez> the tech board DONT need to know
[06:02] <mjg59> spayne|laptop: I /will/ point out now that the tech board meeting is going to be keeping me away from the pub, so if it turns into a huge discussion that's not actually relevent to the tech board I won't be very pleased
[06:02] <Mez> spayne|laptop, I seriously suggest you take it off the agenda
[06:02] <Mez> it is NOT relevant at the moment
[06:02] <Robot101> they could send an e-mail for example :P
[06:03] <Mez> and Calvin and I are talking via email about making changes to it to make it compatible with ubuntu/DFSG
[06:03] <spayne|laptop> why is everyone get at me at the moment? i added it several days ago as well as a mailing list post
[06:03] <spayne|laptop> why is this coming up now?
[06:03] <mjg59> Because the discussion started now
[06:03] <mjg59> That's the way things tend to happen in the real world
[06:04] <Mez> spayne|laptop, because we're just reviewing the list of agenda items now, before we go to the meeting
[06:04] <spayne|laptop> Mez: i will remove it and ask the guys not to come
[06:04] <mjg59> But, as I said, if the Novell guys are expecting to turn up, then we might as well go ahead with it
[06:04] <mjg59> We can quickly make the situation clear so there's no potential for misunderstanding
[06:05] <mjg59> (Speaking with my tech board hat on)
[06:05] <spayne|laptop> mjg59: fair enough
[06:14] <spayne|laptop> FYI: The TB iFolder thing is cancelled
[06:14] <spayne|laptop> the iFolder guys aren't coming
[06:15] <spayne|laptop> and nothing is happening
[06:15] <spayne|laptop> tseng, mjg59: there you do
[06:15] <spayne|laptop> *go
[06:22] <spayne|laptop> well, there you go then
[06:22] <spayne|laptop> tseng: you'll be happy
[06:22] <spayne|laptop> as will mjg59
[06:22] <spayne|laptop> THEY ARE GOING TO OPEN SOURCE Flaim!
[06:23] <Robot101> that's good. ifolder can go into ubuntu then. :)
[06:23] <spayne|laptop> just because i tried to push and push ;-)
[06:30] <slomo> spayne|laptop: good news :)
[06:30] <spayne|laptop> slomo: i'm glad you agree so that those who were eager to critise before aren't interested now :-(
[06:30] <daniels> spayne|laptop: please stop being a cock
[06:31] <daniels> spayne|laptop: regardless of whether or not it was a worthwhile idea (fwiw, I think it was if the iFolder guys were actually coming, as mjg59 said), you're just being disruptive and derailing the channel
[06:32] <spayne|laptop> daniels: i apologise - i didn't want to cause any harm
[06:34] <slomo> daniels: will the dbus package get a monodoc package with the libdbus-1-cil docs? or will you accept a debdiff which does this?
[06:35] <daniels> slomo: debdiff cheerfully accepted
[06:36] <slomo> daniels: ok, i'll send you a mail with it later... against the 0.50 package in debian/experimental or ours?
[06:36] <daniels> slomo: against 0.50 would be nice, since I'm going to rebase our packages against that
[06:36] <slomo> daniels: ok, fine :)
[06:43] <zyga> did anyone actually test server install on a small HDD?
[06:44] <zyga> I just checked that on 0.5GB partition it cannot be installed at all
[06:44] <zyga> I'll reinstall on 1,6GB to check if that works
[06:44] <zyga> I guess it needs 400 after the install but it needs way more during
[06:49] <snikker> hi, how can i replace a .deb package with the old version without remove the dependencies?
[06:50] <spayne> use force in synaptic?
[06:50] <spayne> or --force
[06:50] <carstenh> snikker: apt-get install package=version and next time use #ubuntu please, thanks
[06:51] <snikker> carstenth: ok i try... sorry, if i've posted here but no ones can help me in #ubuntu :-(
[06:52] <Kamion> I'm sorry but #ubuntu-devel isn't an escalated support channel, even if nobody can help in #ubuntu
[06:55] <carstenh> snikker: hint: you do not need to remove the old package before you install a new one. dpkg (the package-manager backend) does this automatically for you
[06:55] <Kamion> please take the help back to #ubuntu - thanks :)
[06:59] <slomo> daniels: ok, nm... the package in debian/experimental already has this ;) only ours doesn't...
[06:59] <daniels> slomo: okay, so we'll get it for free
[07:00] <snikker> carstenth: yes, but i must do a downgrade, not an update...
[07:00] <slomo> daniels: but when you base our packages on this you probably have to wait for monodoc 1.1.9... which waits for xsp to get into main
[07:02] <daniels> slomo: *grunt*
[07:04] <slomo> daniels: i planned to talk to mdz after UBZ about moving xsp into main... shouldn't be a problem as we only need the base package with some scripts in main for monodoc
[07:04] <the--dud> whats xsp?
[07:05] <slomo> the--dud: asp.net stuff
[07:05] <the--dud> ah, ok... know little about that
[07:50] <tseng> spayne: great, thanks alot
[07:57] <shaya> anyone seen mdz?
[07:58] <spayne> tseng: so, all my wailing and complaining got us somewhere afterall ;-)
[08:23] <pitti> carstenh: here?
[08:23] <carstenh> pitti: yes
[08:24] <pitti> carstenh: nice. Bof starts in about 5 minutes
[08:24] <carstenh> ok
[08:24] <pitti> carstenh: is there anything in particular you would like us to talk about?
[08:25] <carstenh> pitti: maybe if ipv6 should be supported
[08:25] <carstenh> pitti: and if yes how a) stateless b) hope that someone writes a proper patch that is usable
[08:26] <carstenh> (the one that exists are old and not that good, because they just copy and paste a lot of code)
[08:31] <pitti> carstenh: but that does not have anything to do with your scripts, right?
[08:31] <carstenh> pitti: i use some kind of generic language and that is translated in iptables commands
[08:32] <carstenh> pitti: so the only thing that need to be changed are some additional functions that enable stateful packet filtering
[08:32] <carstenh> ... for ipv6
[08:33] <carstenh> but that is only a small part of the whole tool
[08:50] <Keybuk> REMINDER: Ubuntu Technical Board meeting in 10 minutes on #ubuntu-meeting
[08:52] <ivoks> 10?
[08:52] <spayne> it starts in 8 minuts now
[08:52] <ivoks> ah, -1 hour happend :)
[08:53] <Keybuk> we think our math is right :p
[08:54] <mdz> mjg59: ping
[09:05] <pitti> carstenh: sorry, if you said something, please say it again
[09:07] <pitti> carstenh: what do you mean by "special P2P rule"?
[09:08] <carstenh> pitti: i don't use p2p, so i dont know which one are packaged for ubuntu and which not
[09:08] <pitti> carstenh: that's mentioned in the fw spc
[09:08] <pitti> spec, even
[09:08] <carstenh> pitti: we should provide a rule for the p2p tools that are not part of ubuntu but often used
[09:08] <pitti> carstenh: you mean allow all processes to connect to ports >= 1024?
[09:09] <carstenh> pitti: but not open every port >1023
[09:09] <pitti> carstenh: so what then?
[09:09] <carstenh> pitti: no, i.e. users commonly install kazza from 3rd party and some other tools to
[09:10] <pitti> carstenh: I'm not so familiar with P2P protocols, do they have a restricted set of ports?
[09:10] <carstenh> pitti: we provide a rule listen: 1234-1267, 1299
[09:10] <Amaranth> ha
[09:10] <Amaranth> they run all over the place
[09:10] <carstenh> pitti: yes, they have
[09:10] <Amaranth> and the day a new one comes out with a new port people start bitching about how ubuntu is broken
[09:10] <pitti> carstenh: ok, fine
[09:10] <carstenh> pitti: 1234-1267 is for p2p tool #1 and 1299 for p2p tool #2
[09:10] <pitti> well, let's put that into "future improvements"
[09:10] <carstenh> but only nessasary for 3rd party tools of course
[09:10] <pitti> since intially we want to have all ports open by default anyway
[09:10] <carstenh> ok, thats fine for me
[09:10] <pitti> ta
[09:11] <carstenh> do we want that really?
[09:11] <zyga> guys what about integrated firewall with rules for every p2p app that ships with ubuntu?
[09:11] <Amaranth> it doesn't hurt if nothing is listening on those ports by default
[09:11] <carstenh> jeffs idea was to open only required ports to prevent trojan horses etc. to listen to incoming connections
[09:12] <pitti> carstenh: initially, until all packages ship a policy
[09:12] <carstenh> sure
[09:14] <carstenh> zyga: every app should provide their own rules
[09:15] <carstenh> zyga: we just talked about additional rules for p2p tools commonly installed fron non-ubuntu sources
[09:15] <zyga> carstenh: is there no way to package those tools?
[09:15] <N6REJ> I need some help please.  Apprently I have "threaded perl" installed currently and need to change that for interchange to operate well.  Can you please advise me as to what to do?
[09:15] <zyga> are they non-free?
[09:16] <daniels> N6REJ: that's probably better suited for #ubuntu
[09:17] <N6REJ> oh, i'm sorry, I asked paul and belutz, as I normally am in offtopic and they didn't know... thought maybe as developers y'all would know better what part did the threading.
[09:18] <carstenh> zyga: i even don't know if they exist ;) of course would packaging them be the better way. i think i should ask on #ubuntu how people install their skype, kazzaa...
[09:20] <zyga> carstenh: well to 'support unofficiall p2p apps' we need to know them first
[09:20] <carstenh> zyga: sure, i guess other people know if they exist :)
[09:20] <zyga> carstenh: right
[09:23] <pitti> carstenh: would you be fine with splitting the spec into kraal and kraal-gtk?
[09:23] <carstenh> yes, sure
[09:23] <pitti> carstenh: there are currently no spec details about the gtk gui (ui mockups, and so on)
[09:23] <pitti> so this should be detailed
[09:26] <carstenh> pitti: so i should add some details (i.e. screenshots) to the gui-part after split
[09:30] <pitti> carstenh: would be nice; just some ui mockup, so that the ui usability can be discussed before actually implementing it
[09:30] <carstenh> pitti: ok, i'll do that. but after your meeting ;)
[09:31] <carstenh> do you plan to discuss that part this week on ubz?
[09:39] <N6REJ> I need to change perl to "non-threaded perl" and nobody seems to know how, can someone help me please?
[09:40] <carstenh> N6REJ: did you already ask on i.e. #ubuntu and #linux?
[09:41] <Amaranth> N6REJ: You were already told this isn't the right channel for that. Anyway I think you need to compile from source to get it.
[09:41] <N6REJ> not in #linux but yes in #ubuntu  I wouldn't think #linux would be the place cause they don't know ubuntu packages
[09:41] <N6REJ> Amaranth: please don't get that tone with me... I give as much as I can back to the group.... I'm asking here for a reason!
[09:42] <carstenh> N6REJ: some know debian and ubuntu packages, not everybody outside this channel uses gentoo or slackware
[09:42] <N6REJ> carstenh: I agree.   Now I think I'm about to have a "tone", though.
[09:43] <N6REJ> Amaranth: I can go there!
[09:44] <N6REJ> after all I would think the purpose of this channel aside from developers of ubuntu talking to each other would be for questions regarding HOW ubuntu is packaged.
[09:44] <N6REJ> and/or how those packages interact.
[09:45] <daniels> N6REJ: amaranth is right -- it's really the sort of support question for #ubuntu, and inappropriate for development.
[09:45] <N6REJ> daniels: ok, I'll accept that prima facie (sp?) but then please tell me this, what IS the purpose of the dev channel if you can't find out what packages do what?
[09:46] <N6REJ> daniels: escpecially when ubuntu doesn't know.
[09:47] <N6REJ> I'm asking honestly, not to be snotty.
[09:48] <tseng> it is assumed when you get here you can make a best effort at fixing a bug or creating new packages or something like that.. the focus is on the discussion of these activities
[09:48] <Kamion> N6REJ: honestly, when you said "the purpose of this channel aside from developers of ubuntu talking to each other", there isn't an aside - we can't have this channel be an escalated support channel or we won't get anything done
[09:48] <daniels> N6REJ: it's for discussing changes, mainly
[09:49] <Kamion> I'm sorry if that's inconvenient, but we have time constraints
[09:49] <N6REJ> nope, not inconvient... I understand.
[09:49] <Kamion> and when developers have time to work on answering questions, they'll be in #ubuntu :)
[09:50] <Kamion> if #ubuntu doesn't know, I suggest you try e-mail instead (ubuntu-users@lists.ubuntu.com), since most people aren't on IRC 24/7; failing that, if you absolutely have to have an answer and can't figure it out, there's always the support request mechanism
[09:51] <N6REJ> Please take note of this though....... as ubuntu CURRENTLY stands, documentation/support for "SERVER" is not very good.  I'm not very good at documentation or I would attempt to fix it.  I have fixed what I knew to be wrong in the wiki's.  I have submitted the bug-reports that I can validate.  I have an OLDER machine that after I get some "cool down time" and can dedicate time to y'all I'll...
[09:51] <N6REJ> ...work with
[09:51] <N6REJ> brb 911 here
[09:52] <magnon> N6REJ: work is going on this week to ensure dapper's awesomeness on the server. It'll be better. :-)
[09:53] <N6REJ> crud!!! some jerk just shattered the window on my bus!
[09:53] <carstenh> N6REJ: you propably already got the correct answer, rebuilt perl. so there is no need for further discussion and thanks for bugreports, fixes etc :)
[09:55] <N6REJ> ok, last comment and then I'm gone... as it currently stands, using the server distro, there is no "server" install option.  [F3]  says there is but it doesn't function... gl with dapper.
[10:11] <Mithrandir> ogra_: would it be possible for xscreensaver to not lock the screen for the first five seconds or so?  I just want to be able to hit a key and make it unblank when I see it blank
[10:12] <ogra_> Mithrandir, i'll have to examine the gnome-screensaver code more for that ...
[10:12] <ogra_> but probably yes ...
[10:12] <N6REJ> I don't know if this is the place or not to say this, but you guys MIGHT want to know that the interchange packages that are part of ubuntu, require "Non-threaded perl" instead of the perl that comes with ubuntu
[10:13] <tseng> its not
[10:13] <Mithrandir> N6REJ: please file a bug in bugzilla or malone.
[10:13] <tseng> http://launchpad.net/malone
[10:13] <tseng> (Thanks)
[10:13] <N6REJ> ok, ty... will do.
[10:13] <ogra_> Mithrandir, i think it could introduce something in the fade code
[10:13] <Mithrandir> ogra_: I can hack it in xscreensaver as a temporary solution, if that'd be ok?
[10:14] <zyga> hey guys
[10:14] <zyga> I've noticed something strange in dapper
[10:15] <zyga> I've got lots of gnome-pty-helper processes aroud
[10:15] <zyga> even though I've got no gnome-terminals at all
[10:15] <zyga> they just hang there indefinitly
[10:15] <ogra_> Mithrandir, i'm not sure if the fade code is just taken plain from xscreensaver ... but i guess its very similar in gnome-screensaver....
[10:16] <ogra_> Mithrandir, so hacking it in gnome-screensaver for dapper would rather be the way to go
[10:17] <Mithrandir> ogra_: so you don't care about xscreensaver any more?
[10:18] <ogra_> Mithrandir, not really ... its breezy, its done :) ... only for very weird bugs ...
[10:19] <Mithrandir> ogra_: 'k
[10:32] <pef> dholbach: can you have a look on #ubuntu-meeting ?
[10:35] <Riddell> lamont: hmm?
[10:36] <lamont> I'm gonna fix the build-deps on kdeutils, kdepim, kdemultimedia
[10:38] <Riddell> lamont: go ahead, or I'll be spending some time uploading stuff this evening
[10:38] <Riddell> I'm sure I heard lamont saying "Riddell rocks" earlier today
[10:38] <lamont> hehe
[10:38] <lamont> yeah, I did say that
[10:38] <lamont> because i thought you'd fixed kde for me. :-)
[10:38] <Mez> I dont think KDE can ever be fixed
[10:38] <Mez> :-"
[10:39] <carstenh> pitti: i guess your talk about firewall is over.  can you give me a short summary when you have some time?
[10:40] <pitti> carstenh: we basically just went through the spec and corrected a few little things
[10:40] <pitti> carstenh: but essentially the spec is fine as it is, it just lacks a complete implementation :-)
[10:40] <carstenh> pitti: will they be documented somewhere?
[10:40] <pitti> carstenh: yes, ajmitch will update the wiki (or already has)
[10:40] <carstenh> pitti: did you also talked about not using python?
[10:41] <carstenh> fine :)
[10:41] <pitti> carstenh: no, sorry, I completely forgot about that
[10:41] <carstenh> pitti: we can talk about it later and ask $whoever_is_responsible_for_such_things
[10:43] <pitti> carstenh: it doesn't actually belong into the spec
[10:43] <Akatemik> Kamion: In case you're interested, both archs are now booting to shell. Still working on why it doesn't like xdm.
[10:43] <pitti> carstenh: but I'd recommend Python or Perl for it
[10:44] <carstenh> pitti: i know :) let's decide it later
[10:51] <seb128> pitti, stop recommending perl you big freak
[10:52] <dholbach> seb128: ah ah
[10:53] <pitti> seb128: it's the only other language that I'd really accept for the project
[11:12] <corey_> mdz, ping
[11:13] <mdz> corey_: pong, but in a BOF
[11:14] <corey_> mdz, when you have time, need to raise the priority of a bof --> https://launchpad.net/distros/ubuntu/+spec/better-wiki-docs
[11:15] <corey_> mdz, needs to be high (approved by jdub)
[11:23] <jdub> ah, not that i've looked at it yet
[11:30] <ogra> fabbione, ??
[11:48] <schweeb> has there been any more work into Xen packages for ubuntu yet?  I know it was a kind of unlikely effort for breezy due to some kernel difficulties
[11:48] <schweeb> I'm within a couple weeks of buying myself a server for hosting, and want to revisit the possible packaging of Xen
[11:49] <Mithrandir> we would want it for dapper, but I'm not sure if it's actually on the list of stuff to discuss here at UBZ.
[11:51] <smurf> it isn't
[11:54] <Mithrandir> fabbione: ^^ ? Any ideas what's up there?
[11:58] <fabbione> schweeb: there are no specs planned and unlikely to happen
[12:01] <bob2> elmo: Znarl www.ubuntulinux.org is very very slow, fwiw
[12:02] <Mithrandir> bob2: it's probably trying to give you the authentic Canonical Conference Feeling.


[00:58] <lotuspsychje> good (early) morning to all
[07:07] <lordievader> Good morning
[07:09] <Bashing-om> lordievader: It is, it is // A bit slow .. but next second, who knows ?
[07:11] <lordievader> Is it?
[07:15] <Bashing-om> lordievader: Well, you will have to tell me later if it is, as I am close to closing out for this session .
[07:16] <lordievader> ;)
[07:50] <Bashing-om> I be down for the count.
[17:27] <lotuspsychje> good evening guys
[17:34] <lotuspsychje> someone on 15.04 or 15.10 can confirm if startup items list is fully showing on systemd?
[17:35] <lotuspsychje> or does it hide items to enable/disable like in trusty?
[17:35] <lotuspsychje> TJ-: good evening
[21:57] <Astronautr> Hey