[00:01] <porthose> nhandler: Thank you for your mentoring efforts. ;-)
[00:09] <crist1> aloha
[00:10] <crist1> if a package is named 1:0.3.0-14, i should rename after altering 1:0.3.0-15ubuntu1?
[00:10] <crist1> or <IP_ADDRESS>-14ubuntu1?
[00:12] <goshawk> crist1: second form
[00:12] <goshawk> but wait me have a look
[00:13] <crist1> goshawk: thank you
[00:15] <goshawk> yep crist1 second form
[00:57] <nazgand> What are the requirements to become a MOTU member, and how long does it usually take after applying to become a member?
[00:58] <evilv> nazgand: https://wiki.ubuntu.com/MOTU will have the info you are looking for
[00:59] <nazgand> I've already been there, but I applied and I haven't been accepted yet, so I was wondering if I didn't fill a requirement that I didn't read about or if I was just too impatient.
[01:00] <evilv> nazgand: it takes time to go through the process
[01:00] <nazgand> Ok, thank you.
[01:00] <evilv> after having several packages sponsored, your sponsors will tell you when you are ready
[01:01] <nazgand> Ok.
[01:14] <__iron> hi
[01:14] <nhandler> Hey __iron
[01:15] <__iron> i'm just writing a java ftp-client framework
[01:17] <__iron> and i would release it for ubuntu is anybody interessed ?
[01:18] <__iron> hi nhandler
[01:20] <nhandler> __iron: I'm sure some people would be interested in an application like that
[01:20] <__iron> k fine
[01:22] <__iron> thx nhandler
[01:23] <nhandler> You're welcome __iron. If you need any help packaging it, feel free to ask.
[01:24] <__iron> k thx+
[02:46] <ripps> Hey, I'm back and I'm still needing help getting my source package to install correctly.
[02:55] <nhandler> ripps: What is the issue?
[02:57] <ripps> nhanler: I have a source package that runs a script that clones 20 plugins from git, runs autogen.sh in each, and then installs them. The probelm is at the final stage of dh_install, it can't find the files so I seperate them according their debian/package_name.install.
[02:57] <ripps> Hold on, I'm doing a fresh pbuilder build with a logfile.
[03:02] <ripps> Man, it segfaulted again. This is getting pretty annoying
[03:07] <nhandler> ripps: I'm going to head off to bed. I'm sure someone else will be able to help you.
[03:08] <ripps> nhandler: okay, thanks anyway
[04:08] <adelie421> anyone else having connectivity issues with launchpad?
[04:16] <JanC> adelie421: seems t owork for me?
[04:16] <JanC> it's sometimes slow though
[04:18] <wgrant> Production doesn't work, but edge does sometimes.
[04:19] <wgrant> Hmm, prod does too, but very, very slowly.
[05:04] <adelie421> is motu only about packaging, or does it include all direct contributions to ubuntu. Reading the packaging guide right now and trying to get a feel for the scope of motu
[05:12] <ripps> Can someone help me figure out what's wrong with my source package build? I'm using a scritpt that pulls plugins from git, runs autogen.sh in each one, and then builds and installs them. I have it setup for split packages using debian/package_name.install, but something goes wrong at dh_install. Here's the pbuilder logfile: http://paste.ubuntu.com/130899/
[05:46] <adelie421> Anyone free to help a noob? Do I need to register a branch before I use bzr send -o foo.patch?
[05:47] <adelie421> I am feeling a bit overwhelmed here trying to properly submit a patch. I have been following http://doc.bazaar-vcs.org/latest/en/mini-tutorial/index.html
[05:49] <ripps> adelie421: Try asking for help in #bzr as well.
[05:49] <adelie421> k
[06:25] <Ryan52> ripps: did you get it figured out?
[06:25] <Ryan52> (whatever it might be..)
[06:25] <ripps> Ryan52: no
[06:26] <Ryan52> I might be able to help...
[06:29] <Ryan52> ripps: so what was your question?
[06:30] <ripps> Ryan52: Oh, you just logged on, so you haven't seen my post, hold on.
[06:30] <ripps> I'm using a scritpt that pulls plugins from git, runs autogen.sh in each one, and then builds and installs them. I have it setup for split packages using debian/package_name.install, but something goes wrong at dh_install. Here's the pbuilder logfile: http://paste.ubuntu.com/130899/
[06:32] <Ryan52> okay, what do your debian/package_name.install files look like?
[06:32] <ripps> I have 20 of them, but I'll post one of them to give you an idea.
[06:34] <ripps> Ryan52: Here's debian/gmpc-alarm.install: http://paste.ubuntu.com/130916/
[06:35] <ripps> It's based on what dpkg -L says about it as a standalone package.
[06:38] <Ryan52> hmm.
[06:38] <Ryan52> debian/tmp/usr/lib/gmpc/plugins/alarmplugin.la exists?
[06:39] <ripps> Well, according to libtool, it installed the file there. I can't check because this was built in a pbuilder environment
[06:40] <Ryan52> why are you building in pbuilder?
[06:40] <ripps> Ryan52: to keep the build environment clean, and so that I know that it will work when I upload to the ppa
[06:43] <Ryan52> what's debian/compat?
[06:44] <ripps> Ryan52: 5
[06:44] <Ryan52> change it to 7
[06:44] <Ryan52> and see if it works.
[06:45] <ripps> Okay, let me warn you I tend to get segfaults often while building, so it might take awhile
[06:46] <Ryan52> ripps: http://pastie.org/415971
[06:46] <Ryan52> it lookes like that syntax only works with debhelper 7 and up.
[06:47] <ripps> Ryan52: Oh, I wish someone had told me about that sooner
[06:47] <ripps> Every package guide I read said to leave it at 5
[06:48]  * ripps crosses his fingers
[06:48] <Ryan52> :)
[06:49] <Ryan52> usr/share/doc/gmpc-alarm/TODO
[06:49] <Ryan52> usr/share/doc/gmpc-alarm/AUTHORS
[06:49] <Ryan52> usr/share/doc/gmpc-alarm/README
[06:49] <Ryan52> hmm.
[06:49] <Ryan52> is the upstream Makefile actually installing those there?
[06:49] <Ryan52> I doubt it.
[06:49] <fabrice_sp> ripps, when you have problems building a package, you can login to the chroot hidden behind pbuilder and make a manual build
[06:50] <fabrice_sp> this way, you can check where the files are installed
[06:50] <Ryan52> you probably should put the path (in the source, not from debian/tmp/) of those in debian/gmpc-alarm.docs instead.
[06:51] <ripps> Ryan52: I'll do that, if it gets past the point it always fails.
[06:51] <ripps> fabrice_sp: I know I can use pbuilder --login, but how do I move my package source into there?
[06:51] <Ryan52> well, it'll still fail at the same point if those aren't being installed by the upstream makefile.
[06:51] <Ryan52> ripps: cp? wget?
[06:52] <ripps> ... how about a bindmount?
[06:52] <Ryan52> man pbuilder
[06:52] <Ryan52> /--bindmounts
[06:52] <fabrice_sp> --bindmounts option
[06:52] <fabrice_sp> too late :-)
[06:52] <Ryan52> hehe
[06:53] <ripps> I use bindmounts with a hook script to have pbuilder scan it's result directory and import the completed packages into it's database.
[06:54] <Ryan52> pbuilder has a database?
[06:54] <ripps> it's apt database, just like ubuntu has.
[06:55] <ripps> So it'll install packages I built there that aren't included in any repositories (sometimes necesary when I'm testing new packages that have upstream dependencies)
[06:55] <Ryan52> nice.
[06:55] <Ryan52> ripps: could you please share those scripts? :)
[06:58] <ripps> Ryan52: http://paste.ubuntu.com/130928/
[06:59] <ripps> I'll rename it to .D70results when I'm not needing upstream dependencies, because it slows down the package fetching time with apt-get update.
[07:00] <ripps> I commented out lines from an old version of the script that didn't work.
[07:00] <Ryan52> oh, so you're just building an apt repository in your result dir. that seems useful.
[07:00] <ripps> Basically
[07:00] <ripps> very useful
[07:01] <ripps> make sure to have you result directory in you bindmounts, otherwise it's useless
[07:01] <Ryan52> right.
[07:02]  * Ryan52 usually goes through the trouble to build the package, use my custom repository building scripts to build an apt repo, sign it, rsync it to my vps, and manually edit the chroot's sources.list :P
[07:04] <ripps> I tried doing that before I read this: http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#usingspecialaptsources
[07:09] <ripps> If you guys are wondering what this is for, it's because I maintain the gmpc-trunk team ppa, and try to keep it updated somewhat close to git upstream. The problem is that it has over 20 plugins that I've had to package and upload individually, and they need to be reuploaded everytime there's been a change to the core program. Not to mention that I backport it to intrepid and hardy.
[07:11] <ripps> Please don't segfault... please don't segfault...
[07:13] <ripps> dammit, signal 11 segfault
[07:13] <ripps> trying again...
[07:26] <fabrice_sp> ripps, what is your memory size? I had this problem when I was compiling huge C++ programs and only 1Gb.
[07:26] <ripps> fabrice_sp: only 512mb.
[07:26] <ripps> But I think it's past the point I usually fail at, the gcc compiling.
[07:26] <fabrice_sp> ripps, that could explain the segfaults...
[07:27] <fabrice_sp> oh
[07:27] <ripps> I closed a bunch of stuff I had open. Probably freed up a little memory
[07:28] <Ryan52> lack of memory causing a seg fault? that's a bug in something. :P
[07:28]  * Ryan52 thinks somebody forgot to check some return codes :)
[07:31] <ripps> fabrice_sp, Ryan52: It went further than it did before, but I still got an error
[07:31] <ripps> cp: cannot stat `debian/tmp/usr/share/doc/gmpc-alarm/TODO': No such file or director
[07:31] <Ryan52> yep, I knew that would happen.
[07:31] <ripps> But I think that's fixable, it's my *.install file's fault.
[07:32] <Ryan52> like I said, do the docs thing.
[07:32] <ripps> Getting on it now.
[07:32] <fabrice_sp> that's why building inside a chroot allows you to check that, and only repeat the install part :-)
[07:33] <Ryan52> that's why ripps shoulda just made the change when I first brought it up :D
[07:33] <ripps> I was impatient, it's gonna take me awhile to change 20+ files
[07:33] <Ryan52> oh, fun.
[07:33] <ripps> (although I could have been doing it while it was compiling)
[07:36] <ripps> Ryan52: what about *.png files?
[07:39] <Ryan52> what do you mean what about them?
[07:39] <ripps> Do they go in *.doc or *.install?
[07:39] <Ryan52> depends.
[07:39] <Ryan52> if upstream Makefile installs them debian/tmp
[07:39] <Ryan52> then specify the path from as if you are in debian/tmp and put it in package.install
[07:40] <Ryan52> if you want them in /usr/share/doc/package/ put them in package.docs
[07:40] <ripps>  /usr/bin/install -c -m 644 'magnatune.png' '/tmp/buildd/gmpc-plugins-0.18.0/debian/tmp//usr/share/gmpc/plugins/magnatune//magnatune.png'
[07:40] <ripps> so *.install
[07:40] <Ryan52> yep.
[07:41] <ripps> Well, let's try this one more time (hopefully.
[07:43] <ripps> I usually do my builds using cowbuilder, but I think the original pbuilder works well with this build, probably because pbuilder doesn't operate within the userspace.
[08:12] <eMerzh> if a motu want to review my package, it's waiting at http://revu.ubuntuwire.com/details.py?package=sqliteman :)
[12:03] <DktrKranz> RainCT, heh :)
[12:03] <DktrKranz> feel free to reupload with suggestion I just mailed ;)
[12:06] <RainCT> lol
[12:07] <directhex> mornin'
[12:10] <DktrKranz> hi directhex
[12:12]  * directhex finds himself unable to test-build things, as his mirror's Packages.gz for universe is busted
[12:14] <directhex> DktrKranz, feel like the adventure of a lifetime? try building http://ftp.de.debian.org/debian/pool/main/b/boo/boo_<IP_ADDRESS>65-3.dsc in an up-to-date jaunty pbuilder!
[12:15] <directhex> DktrKranz, oh, and you know the monodevelop FFe was a good idea when you receive lengthy thank you messages from projects, cc'd to miguel de icaza
[12:17]  * wgrant is very concerned about the >100 FTBFSes like http://builder.ubuntuwire.com:9998/job/43267 we are looking at.
[12:17] <wgrant> I have 56 at the moment, with only half of universe built.
[12:33] <c_korn> can a MOTU have a look at sivp and upload it to the jaunty queue if everyting is correct? bug 334362
[13:25] <lfaraone> Is there any utility in attaching a debdiff to a sync request?
[13:26] <RainCT> uhm.. can I install a i386 package on amd64?
[13:27] <lfaraone> RainCT: It'll *run*, if it has all of the compat libs installed.
[13:27] <lfaraone> RainCT: why?
[13:27] <lfaraone> RainCT: as a rule it's a bad idea :)
[13:27] <RainCT> but dpkg won't let me install it :)
[13:28] <RainCT> *cough* because I want to try an applications for which there's only a .deb for i386 and I'm too lazy to compile it myself *cough*
[13:28] <geser> RainCT: use more force (--force-architecture)
[13:29] <geser> and it's not statically build you need all the needed libs as i386 too
[13:30] <directhex> usually by dumping them in /usr/lib32
[13:31] <RainCT> Ah right, thanks. But it conflicts with another package, so I guess I'll wait until someone packages it :P
[13:50] <DktrKranz> directhex, :)
[13:50] <DktrKranz> directhex, still need a testbuild?
[13:51] <directhex> DktrKranz, please. and if it works, you could ack https://edge.launchpad.net/bugs/339808 !
[13:52] <DktrKranz> directhex, I'll fire up my company's server, just some minutes :)
[13:52] <DktrKranz> directhex, it's i386
[13:52] <c_korn> what does this line mean in a diff?
[13:52] <c_korn> ! import_all(tesseract)
[13:53] <directhex> i386? yay, retro!
[13:53] <DktrKranz> intel xeon dual core
[13:53] <DktrKranz> but still i386
[13:53] <pmjdebruijn> hmmm is it already possible to use PPA for Jaunty?
[13:53] <directhex> pmjdebruijn, of course!
[13:54] <pmjdebruijn> do I need to do anything for that? or will it recognize it in the changelog?
[13:54]  * iulian is free to testbuild things.
[13:54] <slytherin> pmjdebruijn: changelog
[13:54] <pmjdebruijn> sweet
[13:56] <pmjdebruijn> I recently got a mail telling my that I was reaching my PPA's 1GB limit
[13:56] <pmjdebruijn> but, I can see why... archived packages?
[13:57] <directhex> iulian, if you have an absolutely up-to-date jaunty environment to hand, can you pastebin the output of apt-cache rdepends libmono-corlib1.0-cil for me?
[13:59] <iulian> directhex: http://paste.ubuntu.com/131065/plain/
[14:02] <ryanakca> Ok, I got a pile of packaging bugs for slingshot fixed in Debian. Is it too late to sync? No changes on the Ubuntu side.
[14:04] <directhex> iulian, neato - log4net is definitely not on that list anymore (1.2.10+dfsg-3 Published in jaunty-release 16 hours ago), so boo is the single remaining 1.0-using source package in the archive (other than mono itself)
[14:05] <DktrKranz> directhex, I haven't it in my list
[14:05] <DktrKranz> apt-get update just two hours ago
[14:06] <iulian> directhex: Ouh, lemme run an upgrade again.
[14:06] <directhex> so if boo gets synced, then the mono transition is over. fini. kaput.
[14:07] <DktrKranz> c_korn, I'll probably have a look at sivp later, unless mok0 is already on it
[14:07] <iulian> It takes much more time to unpack and replace than download packages.
[14:07] <DktrKranz> directhex, what about the remaining packages? Are they going to disappear?
[14:08] <directhex> DktrKranz, the remaining packages are all produced by the mono source package. they're occasionally used for building, and may be of use for compatibility for people running arbitrary .net apps, but no app/lib dep will pull them in
[14:09] <DktrKranz> directhex, so they can be moved to universe?
[14:09] <DktrKranz> (if not already)
[14:09] <directhex> DktrKranz, some, not all, can be (check reverse-build-depends)
[14:10] <directhex> corlib, cairo, and system will resist
[14:10] <DktrKranz> well, if we can move some out of seeds and save some disk space, I think some people could be happy :)
[14:15] <directhex> you'll need to manually check reverse-build-depends on all of them. but a cursory examination suggests that most can be moved to universe
[14:15] <directhex> also check rdepends
[14:16] <directhex> in theory only the ones depended on by mono-devel are needed anymore, i think
[14:16] <directhex> but double-check to be sure
[14:16] <DktrKranz> are the all belonging to mono source package?
[14:17] <directhex> yes
[14:17]  * DktrKranz looks
[14:18] <DktrKranz> directhex, some of them belong to xsp
[14:19] <DktrKranz> apt-cache rdepends libmono-corlib1.0-cil | xargs apt-cache showsrc | grep Package | sort -du
[14:24] <pmjdebruijn> "Rejected: Could not find person ''"
[14:24] <pmjdebruijn> I got that in an email from PPA
[14:24] <DktrKranz> directhex, btw build successful, I'm going to ACK that bug
[14:24] <pmjdebruijn> what could be wrong...
[14:25] <pmjdebruijn> these are packages for Jaunty... not Intrepid
[14:25] <DktrKranz> pmjdebruijn, is Maintainer field correctly formatted?
[14:26] <pmjdebruijn> I think so?
[14:26] <pmjdebruijn> It's not different from when I built  for Intrepid?
[14:26] <pmjdebruijn> have new check/policies been introduced?
[14:26] <DktrKranz> I don't think so
[14:27] <DktrKranz> also check if changelog timestamp entry is ok
[14:27] <pmjdebruijn> it's `date -R`
[14:29] <c_korn> DktrKranz: ok. I did not see mok0 online here for some time. don't know if he is on it
[14:30] <DktrKranz> pmjdebruijn, check the name and email after --
[14:30] <DktrKranz> c_korn, I'll have a look then
[14:30] <c_korn> ok
[14:30] <DktrKranz> btw, it's not necessary using REVU for merges or package updates
[14:31] <c_korn> so the debdiff would have been enough?
[14:33] <DktrKranz> c_korn, yes, it's more evident to see changes introduced, REVU is mainly for new packages, where every bit must be looked
[14:33] <pmjdebruijn> DktrKranz: yep, that's okay
[14:33] <DktrKranz> c_korn, I'm looking at your debdiff in the bug report, you removed .svn directory, isn't it?
[14:33] <c_korn> yes
[14:34] <DktrKranz> pmjdebruijn, did you adjusted your dput.cf file?
[14:34] <DktrKranz> *adjust
[14:34] <pmjdebruijn> the login?
[14:35] <DktrKranz> yes
[14:35] <DktrKranz> errr...
[14:35]  * pmjdebruijn doesn't remember changed that last time... but I'm semi-senile... so that doesn't mean anything
[14:35] <DktrKranz> incoming
[14:35] <DktrKranz> incoming                = ~%(ppa)s/ppa/ubuntu
[14:35] <DktrKranz> that's the default
[14:35] <pmjdebruijn> DktrKranz: yep, that's okayincoming                = ~%(ppa)s/ubuntu
[14:36] <pmjdebruijn> sorry
[14:36] <DktrKranz> you should replace %(ppa)s with your LP id
[14:36] <pmjdebruijn> 'incoming = ~pmjdebruijn/ubuntu' should be okay then?
[14:37] <DktrKranz> c_korn, it's legal to remove it, I'd be more inclined report Sylvestre just to be sure it will removed Debian side too
[14:37] <DktrKranz> pmjdebruijn, incoming = ~pmjdebruijn/ppa/ubuntu
[14:38] <pmjdebruijn> DktrKranz: my stock dput.cf doesn't include /ppa/
[14:39] <DktrKranz> pmjdebruijn, there have been changes in PPA incoming directory, now /ppa/ is part of the path. Not sure if they removed compatibility with old ~LP_id/ubuntu, though, but using new format is safe.
[14:39] <pmjdebruijn> ok
[14:41] <pmjdebruijn> now I have a file conflict
[14:41] <pmjdebruijn> a downstream tarball has changed
[14:41] <pmjdebruijn> aren't packages for intrepid and jaunty seperated?
[14:42] <pmjdebruijn> I need the new tarball, but I don't want to break my Intrepid package
[14:43] <cjwatson> I understand that you can do 'dput ppa:pmjdebruijn' rather than having to edit the default file
[14:43] <DktrKranz> if you have the same .orig.tar.gz name but with different md5 sums, it will get rejected
[14:43] <cjwatson> or 'dput ppa:pmjdebruijn/ppa' if you have it in the form pmjdebruijn quoted
[14:43] <pmjdebruijn> cjwatson: right
[14:43] <cjwatson> http://blog.launchpad.net/ppa/http://blog.launchpad.net/ppa/
[14:43] <cjwatson> oops
[14:43] <cjwatson> http://blog.launchpad.net/ppa/simplifying-dputcf-for-multiple-ppas
[14:43] <pmjdebruijn> I already edited the file, and it's fine now
[14:44] <pmjdebruijn> my problem now is a tarball conflict with an older package
[14:44] <pmjdebruijn> which I do _not_ want to break
[14:44] <directhex> DktrKranz, xsp is in univsre, and it's okay for xsp to have 1.0 deps (xsp2 from the same course package is the 2.0 version)
[14:44] <cjwatson> if the tarball has changed but has the same version number, then you must artificially rename it
[14:44] <c_korn> DktrKranz: I am in contact with Sylvestre. will notify him.
[14:44] <DktrKranz> directhex, cool then
[14:44] <pmjdebruijn> cjwatson: like?
[14:44] <cjwatson> you cannot have two objects with the same file name but different contents in the same archive
[14:44] <cjwatson> pmjdebruijn: up to you
[14:45] <pmjdebruijn> cjwatson: "the same archive" is intrepid and jaunty stuff mixed then?
[14:45] <cjwatson> yes.
[14:45] <pmjdebruijn> ugh
[14:45] <DktrKranz> pmjdebruijn, foo_0.1+repack.orig.tar.gz could go
[14:45] <cjwatson> there's a single pool
[14:45] <pmjdebruijn> hmmm
[14:45] <cjwatson> which will then mean that your package is versioned 0.1+repack-0ubuntu1 or whatever
[14:45] <pmjdebruijn> oh well, too bad for folks still on Intrepid then
[14:45] <cjwatson> why *not* rename it?
[14:45] <cjwatson> it's the right thing to do
[14:46] <pmjdebruijn> is it?
[14:46] <directhex> the root question here is, why do you WANT different orig with the same version?
[14:47]  * cjwatson -> out
[14:48] <DktrKranz> nhandler, bug 266919, is it managed using Rosetta? I can't find it in package list.
[14:49] <slytherin> when specifying CFLAGS, is order of the flags important?
[14:50] <pmjdebruijn> directhex: I'm going to check the differences
[14:52] <pmjdebruijn> directhex: the base directory seems to be the only difference, then I'll stick with the old tarball
[14:53] <pmjdebruijn> won't the common pool mean I can't have identical debian versions in different dists as well?
[14:54] <pmjdebruijn> cd ..
[14:55] <DktrKranz> pmjdebruijn, you can have identical upstream versions, but you have to use a different version for each release
[14:56] <pmjdebruijn> seems rather nasty
[14:56] <DktrKranz> e.g. if you have foo 0.1-1ubuntu1 in jaunty, you can upload foo 0.1-1ubuntu1~intrepid for intrepid, foo 0.1-1ubuntu1~hardy for hardy and so on
[14:57] <DktrKranz> package contents do not change, only version is mangled
[15:03] <directhex> siretart, ping
[15:07] <DktrKranz> c_korn, are bug 340520 and bug 329399 addressed with your upload?
[15:09] <c_korn> DktrKranz: should be fixed in the package. it was because the package did not check if the symlink was there and tried to remove it. (it is not fixed in the debian version yet)
[15:09] <c_korn> I tried updating sivp-4.x to sivp-5.x and removing
[15:09] <c_korn> everything works
[15:09] <DktrKranz> so, it's fixed by new upstream?
[15:12] <DktrKranz> c_korn, --^
[15:13] <c_korn> DktrKranz: yes, I would say so. it is because the install directory detection changed from scilab-4 to scilab-5 so sivp-4.x cannot find scilab.
[15:13] <DktrKranz> ok, I'll mangle your changelog entry to reflect it
[15:33] <slytherin> what is the way to figure out differences between two versions of same library?
[15:37] <eMerzh> if a motu want to review my package, it's waiting at http://revu.ubuntuwire.com/details.py?package=sqliteman
[15:37] <lidaobing> sladen, dpkg-gensymbols works for you?
[15:38] <lidaobing> slytherin,  dpkg-gensymbols works for you?
[15:39] <slytherin> lidaobing: does it work as standalone tool?
[15:39] <lidaobing> slytherin, no, but you can use objdump
[15:45] <siretart> directhex: pong
[15:45] <DktrKranz> c_korn, done
[15:47] <c_korn> DktrKranz: thanks, I currently see it building. looks fine
[15:52] <directhex> siretart, any guesses why i'd see cd /tm
[15:52] <directhex> gah
[15:53] <slytherin> lidaobing: I am using that but not able to figure out the differences.
[15:54] <directhex> siretart, any guesses why i'd see "/tmp/buildd/ffmpeg-0.svn20090303/libavcodec/dsputil.c:2846: error: 'CONFIG_H263_ENCODER' undeclared (first use in this function)" when trying to build unstripped ffmpeg locally?
[15:59] <siretart> directhex: well, see http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/strip.sh;hb=HEAD
[15:59] <c_korn> DktrKranz: because scilab is now free the sivp package can go into universe I think. should I wait until released in multiverse and request a move or can it be released into universe directly?
[15:59] <siretart> directhex: that sed command is removing the h263 encoder, which is required for ffmpeg-debian in main
[16:00] <ScottK> c_korn: Is sivp in New or waiting to be uploaded?
[16:01] <c_korn> ehm, it is currently building: https://launchpad.net/ubuntu/jaunty/+source/sivp/0.5.0-1ubuntu1
[16:01] <directhex> siretart, damn, that's it, i was switching debian/control to build unstripped but hadn't realised orig differed
[16:05] <pmjdebruijn> eh... now I have a bigger issue
[16:05] <pmjdebruijn> I have lensfun_0.2.3.orig.tar.gz in my intrepid ppa, which differs from Ubuntu's master archive lensfun_0.2.3.orig.tar.gz
[16:05] <pmjdebruijn> I can't use either
[16:06] <pmjdebruijn> without renaming
[16:06] <pmjdebruijn> so I can't use the proper tarball, because I used a bad one in the past
[16:07] <siretart> directhex: get the branch from git.debian.org and 'git checkout ubuntu.jaunty.unstripped'
[16:10]  * pmjdebruijn is getting punished for being sloppy in the past :(
[16:21] <maxb> pmjdebruijn: I *think* if you delete things from your PPA and wait long enough for them to be purged completely you can replace the tarball.
[16:21] <directhex> siretart, there aren't any conflicts that would prevent me from installing it alongside lavc51 in intrepid are there?
[16:22] <siretart> directhex: there are. the new libavutil has a Breaks: libavcodec51. On purpose :(
[16:23] <siretart> directhex: see also my PPA. I have backported most packages in intrepid for the new ffmpeg
[16:24] <pmjdebruijn> maxb: yes, but this library is a dependancy for most of my PPA packages for Intrepid, so if I delete the packages, I can basically empty out my entire PPA
[16:28] <directhex> siretart, probably best to wait until jaunty, i fear. i can make do for now
[16:29] <siretart> directhex: or you could help me backporting the rest of the packages, and have then in the motumedia ppa
[16:29] <siretart> s/have/maintain/
[16:30] <directhex> siretart, sorry, i don't have enough free cycles to take that on
[16:31]  * pmjdebruijn is going to purge his entire PPA...
[16:41] <c_korn> hm, does this build hang? https://launchpad.net/+builds/crested/+index
[16:41] <c_korn> others only needed 10minutes
[16:44] <slytherin> any autotools experts here?
[16:48] <slytherin> siretart: remember the discussion about libxine having it's own copy of libdvdread/libdvdnav? What kind of analysis should I do before proposing that we use the external libdvdread/libdvdnav?
[17:24]  * hyperair wonders if anyone can review gtk2-engines-aurora
[19:34] <ryanakca> When trying to make a building chroot, I get W: BAD signature from "Debian Archive Automatic Signing Key (4.0/etch<EMAIL_ADDRESS> ... any iedas?
[19:44] <sistpoty> hi fols
[19:44] <sistpoty> +k
[19:47] <iulian> Hey sistpoty.
[19:47] <sistpoty> hi iulian:
[19:48] <sistpoty> iulian, DktrKranz, ScottK, DktrKranz, nhandler: proposal for mail to ubuntu-devel-announce... problem is that I'm not too sure about rebuild statistics yet (which is [4]): http://paste.ubuntu.com/131242/
[19:49] <pochu> DktrKranz: you gotta read it twice :)
[19:49] <sistpoty> damn
[19:51] <sistpoty> slangasek: oh, if the mail proposal finds approval, anything you'd like to add for ubuntu-relelase? (http://paste.ubuntu.com/131242/)
[19:51] <sistpoty> s/relelase/release/
[19:52] <DktrKranz> pochu, I'm like Dr. Jekill and Mr. Hyde, you have to ping me twice in a statement to have my full attention, or you receive just a half
[19:52] <sistpoty> haha
[19:52] <RainCT> lol
[19:52]  * RainCT is happy because he got his boot time from 80 to 50 seconds :)
[19:53] <pochu> huh, 80
[19:53] <pochu> RainCT: is that your Acer eMachines? ;-)
[19:53] <RainCT> yeah.. 20 of those are the X trying to start several times..
[19:53] <DktrKranz> RainCT, have you hamsters instead of CPUs?
[19:53] <RainCT> pochu: No. The eMachines one is really fast :)
[19:54] <iulian> Hamsters... yikes!
[19:54] <RainCT> hah
[19:54] <DktrKranz> sistpoty, what about qa.ubuntuwire.com/ftbs or http://builder.ubuntuwire.com:9998/dist/jaunty/arch/i386/failed ?
[19:54] <iulian> I'd go with the former.
[19:54] <DktrKranz> *ftbfs
[19:55] <RainCT> btw, does concurrency=shell work now? last time I tried the boot would get slighly slower because the laptop did everything twice (once at every CPU) XD
[19:55] <sistpoty> DktrKranz: cool, didn't know about that link... even seems up to date
[19:55] <sistpoty> DktrKranz: thanks
[19:55] <RainCT> (s/CPU/core, of course)
[19:56] <DktrKranz> sistpoty, np, thanks for preparing it :)
[19:56] <RainCT> jdong_: thanks for the readahead tutorial, btw :)  that gave me, together with switching to ext4, 25 seconds
[19:57] <DktrKranz> RainCT, I'll be satisfied when my system will boot in -3 seconds
[19:57] <RainCT> DktrKranz: Heh. How long does it take now?
[19:57] <DktrKranz> about 70 seconds
[19:57] <dtchen> DktrKranz: that's easy - just remove all the hw.
[19:57] <RainCT> DktrKranz: err.. and you complain about my CPU? :P
[19:58] <DktrKranz> dtchen, I was thinking about a system plugged with my brain which interpretes my wish to turn on PC and he starts system in advance
[19:58] <iulian> Hmm, I believe my crappy lappy boots in less than 50 seconds.
[19:58]  * iulian should test it some day.
[19:58] <DktrKranz> RainCT, in two years my PC won't be underage anymore :)
[19:58] <jdong> RainCT: neat :)
[19:59] <jdong> RainCT: another bootup hack to try is to "delay" noncritical bootup services until way after GDM
[19:59] <RainCT> jdong: how is that done?
[19:59] <dtchen> or just drop your rotary disks for SSD
[19:59] <jdong> RainCT: in my system GDM is S13, everything that GDM doesn't depend on is moved to S50 and beyond, and S45 is basically "sleep 120s"
[19:59] <sistpoty> slangasek: around? I'd like to send a mail to u-d-a regarding a new ubuntu-release delegate, which however also mentions common tasks at this point, want to add s.th. for ubuntu in general? (proposal: http://paste.ubuntu.com/131252/)
[19:59] <jdong> (it's a hack but gets me to the login screen ~5s faster)
[20:00] <DktrKranz> lol, my package FTBFS and I wasn't aware of that!
[20:00] <DktrKranz> http://builder.ubuntuwire.com:9998/job/43632
[20:00] <iulian> Heh
[20:00] <RainCT> although I guess I'd already be happy if I got ride of the damn 20 seconds worth in tries to start X.. XD
[20:00] <RoAkSoAx> bug 277648
[20:00] <sistpoty> DktrKranz: that happens... fauhdlc FTBFS'd on anything but i386 and amd64 even though I wrote almost every single line for it
[20:01] <RainCT> jdong: uhm.. wheren't they discussing doing something like that in #ubuntu-devel a few days ago
[20:01] <DktrKranz> sistpoty, I wasn't aware of that because I haven't rebuilt my python packages against 2.6
[20:01]  * DktrKranz should have a run at them tomorrow
[20:02] <sistpoty> DktrKranz: heh... I'm still curious what edos is about :P
[20:02] <DktrKranz> I love edos-debcheck
[20:02] <DktrKranz> it's simply extraordinary :)
[20:03] <sistpoty> (the pasted commands won't work for me... I'm on unstable right now, and don't intent to reboot to jaunty as of speeking)
[20:04] <sistpoty> DktrKranz: what exactly does edos provide?
[20:04] <sistpoty> (or edos-debcheck?)
[20:05] <DktrKranz> sistpoty, it checks for package installability comparing package versions, conflicts or blocks fields
[20:06] <sistpoty> DktrKranz: then it'd be similar as in "apt-cache -i unmet" for a given arch?
[20:06] <DktrKranz> mostly, but it tells you why:
[20:06] <DktrKranz> envyng-qt (= 2.0.1): FAILED
[20:06] <DktrKranz> The following constraints cannot be satisfied:
[20:06] <DktrKranz>   envyng-qt (= 2.0.1) depends on python (<< 2.6) {NOT AVAILABLE}
[20:07] <DktrKranz> e.g.   this one states envyng-qt requires to be rebuilt against 2.5, apt-cache -i unmet tells you it's just uninstallable
[20:07] <sistpoty> DktrKranz: well, apt-cache -i unmet also tells you why... but only for the arch *you are running apt-get on*
[20:08] <DktrKranz> ah, long time I don't use it
[20:08] <sistpoty> DktrKranz: so, it seems like a arch-independent apt-get -i unmet is a *huge* win ;)
[20:08] <DktrKranz> well, edos-debcheck needs Package from mirrors, so you can run it for sparc, ppc or armel
[20:08] <jdong> RainCT: the Dell Mini 9 Ubuntu spin does something similar too
[20:09] <DktrKranz> just fetch Packages.gz files and give it them to eat
[20:09] <sistpoty> sure, the info should be there
[20:09] <sistpoty> still it's a leap jump from checking unstallable package for
[20:10] <sistpoty> + *one* arch, instead of any arch
[20:10] <sistpoty> I guess only britney could do this back then... (or whatever is the name now that debian-release use for their testing-migration script)
[20:11] <DktrKranz> I guess it's britney
[20:11] <sistpoty> heh
[20:11] <DktrKranz> oh, holger is doing amazing job on piuparts these days!
[20:11] <DktrKranz> I'd like to use it more in Ubuntu
[20:12] <ryanakca> I got a pile of packaging bugs for slingshot fixed in Debian (bugs were filed in both Ubuntu and Debian). Is it too late to sync?
[20:12] <dtchen> no
[20:12] <sistpoty> DktrKranz: oh? cool... from my personal setup, it usually bailed out (since I guess I must have been doing s.th. wrong... either wrong .tar.gz or s.th. else)
[20:13] <DktrKranz> sistpoty, I plan to have it working out-of-the-box, it needs some love :)
[20:13] <sistpoty> ryanakca: new upstream release in unstable?
[20:13] <sistpoty> ryanakca: that brings in new features apart from only bug fixes?
[20:13]  * DktrKranz runs now, c u tomorrow
[20:14] <sistpoty> cya DktrKranz:
[20:15] <sistpoty> ryanakca: if it's only bug fixes, there's no problem... otherwise we'd need a feature freeze exception request
[20:21] <ryanakca> sistpoty: No, same old version, upstream is MIA. Just packaging bug fixes (aka, inserted an xpm icon, updated path to GPL, depend on ttf-freefont instead of installing a duplicate, etc)
[20:22] <sistpoty> ryanakca: then that's fine... can you file a sync request?
[20:22] <ryanakca> sistpoty: Sure.
[20:22] <sistpoty> ryanakca: thanks!
[20:23] <c_korn> I don't understand why the build of sivp for amd64 fails: https://launchpad.net/ubuntu/+source/sivp/0.5.0-1ubuntu1/+build/904358/+files/buildlog_ubuntu-jaunty-amd64.sivp_0.5.0-1ubuntu1_FAILEDTOBUILD.txt.gz
[20:23] <c_korn> it succeeds in a PPA
[20:24] <c_korn> (the PPA is here https://launchpad.net/~getdeb.packages/+archive/ppa)
[20:26] <ScottK> c_korn: Put it in a PPA that doesn't have a lot of non-Ubuntu stuff in it and see if it builds.
[20:26] <ScottK> There may be something it builds against in the PPA that isn't in Ubuntu.
[20:26] <c_korn> ScottK: lots of non-ubuntu stuff?
[20:27] <c_korn> there is only vlc in it
[20:27] <ScottK> Oh.  OK.
[20:27]  * ScottK made an assumption that the getdeb PPA would have lots of stuff in it.
[20:27] <ScottK> Nevermind then.
[20:27] <ScottK> Let's give it a retry.
[20:29] <c_korn> ScottK: hrhr. reuploading
[20:29] <ScottK> c_korn: No need to reupload.  I can trigger a retry
[20:29] <ryanakca> sistpoty: Hmmm... ``The versions in Debian and Ubuntu are the same already (0.8.1p-1). Aborting.'' ... however, http://packages.debian.org/sid/slingshot shows 0.8.1p-2 ... give it a few hours?
[20:29] <c_korn> ScottK: I mean I reupload it to the PPA. just for testing
[20:30] <ScottK> c_korn: Ah.  OK.  Makes sense.  I just retried it too, so we'll see.
[20:31] <c_korn> ScottK: actually there was scilab before in the PPA (when scilab was not yet in ubuntu). but the same version has been published in jaunty
[20:31] <ScottK> OK.
[20:32] <sistpoty> ryanakca: ubuntu doesn't have -2, so at this point of time, you'd need to file a sync request for -2
[20:32] <sistpoty> ryanakca: only before debian import freeze, packages are synced automatically (if these don't have ubuntu changes)
[20:33] <ryanakca> sistpoty: *nod*, ... so, shouldn't ``requestsync -k E95EDDC9 slingshot jaunty'' do it?
[20:33] <sistpoty> ryanakca: no idea, haven't use requestsync myself yet (I'm always filing these by hand *g*(
[20:34] <ryanakca> *nod*, thanks :)
[20:37] <jacob> would patching mail-notification to work well with notify-osd be something that would require a FFe? I ask because the proposal on https://wiki.ubuntu.com/NotifyOSD suggests UI changes if notify-osd is in use
[20:57] <c_korn> ScottK: it still builds fine in the PPA https://launchpad.net/~getdeb.packages/+archive/ppa/+build/904630
[21:09] <wgrant> apachelogger: kde-i18n-* all seem to FTBFS like http://builder.ubuntuwire.com:9998/job/43356.
[21:11] <apachelogger> wgrant: --without-arts needs to be added to the configure arguments
[21:12] <wgrant> apachelogger: I presume there's some way to do it to all of them?
[21:12] <apachelogger> not really
[21:12] <apachelogger> I'd recommend to write a simple script apt-get source'ing through apt-cache search kde-i18n- and then edit all of them
[21:13] <wgrant> I don't really care about them - I'm just triaging all of the rebuild failures - but I'll do them if nobody else wants to.
[21:13] <apachelogger> JontheEchidna: pling
[21:16] <apachelogger> wgrant: I'll mail kubuntu-devel
[21:16] <wgrant> apachelogger: Thanks.
[21:17] <wgrant> Similar failures make up about 10% of the failures so far.
[21:17] <wgrant> Most of those being langpacks.
[21:18] <adelie421> ok, finally figured out how to do a simple patch, but when I run 'debuild -S' I get " clearsign failed: secret key not available". I have a registered key. Any help? I am new
[21:19] <adelie421> I am following this guide given to me by the maintainer: https://wiki.ubuntu.com/Bugs/HowToFix
[21:19] <JontheEchidna> apachelogger: plong
[21:19] <maxb> adelie421: Are you actually trying to prepare an upload, or just test the build?
[21:20] <apachelogger> JontheEchidna: do we have a minion to address the kde-i18n ftbfs?
[21:20] <JontheEchidna> hrm...
[21:20] <adelie421> I am trying to prepare an upload
[21:20] <JontheEchidna> apachelogger: not that I know of
[21:21] <adelie421> It was mostly spelling errers / typos in documentation
[21:21] <JontheEchidna> but I would rather not fancy getting 13K emails by doing it myself
[21:21] <apachelogger> JontheEchidna: lol
[21:21] <apachelogger> JontheEchidna: you must triage your mails I say
[21:21] <wgrant> Why 13K?
[21:21] <maxb> adelie421: Run 'gpg --list-secret-keys' and check whether any of the printed user IDs corresponds to the user ID of the top entry in the debian/changelog
[21:21] <wgrant> Since they're not in main...
[21:22] <JontheEchidna> oh, I was confusing them with kde-l10n
[21:22] <adelie421> gpg --list-secret-keys
[21:22] <adelie421> ha ha, doh
[21:22] <JontheEchidna> which are in main
[21:23] <JontheEchidna> That being said kde-l10n needs an upload too, bug 330069.
[21:24] <apachelogger> JontheEchidna: maybe batl10n-edit is of need
[21:24] <JontheEchidna> apachelogger: I already blackhole everything from<EMAIL_ADDRESS>:P
[21:24] <adelie421> is the name supposed to be under the date?
[21:25] <adelie421> err... email does not match. must be it
[21:25] <apachelogger> JontheEchidna: actually it could share most stuff with batl10n anyway ... so batl10n just needs to be copied and modified and the appropriate stuff moved to bat.rb
[21:25] <apachelogger> JontheEchidna: then it would also be mostly useable for kde-i18n
[21:25]  * JontheEchidna nods
[21:27] <adelie421> that was the problem. Thanks! btw, how do I change it so 'dch -i' uses the right email address?
[21:27] <maxb> export DEBEMAIL=....
[21:27] <c_korn> ScottK: I don't know why it hangs again https://launchpad.net/+builds/yellow
[21:28] <adelie421> maxb: will that fix it permanently?
[21:28] <apachelogger> anyway
[21:28] <apachelogger> wgrant, JontheEchidna: mail sent
[21:28] <c_korn> ScottK: exactly the same package has been built successfully here: https://launchpad.net/~getdeb.packages/+archive/ppa/+build/904630
[21:29] <apachelogger> JontheEchidna: also, I am not sure kde-l10n should be changed to resolve that bug ... rather kde 3 should be using a different path for it's localized content, one really might want kde-l10n-de and kde-i18n-de for example
[21:30] <JontheEchidna> true
[21:30] <apachelogger> JontheEchidna: also-ng, you should blackhole everything from<EMAIL_ADDRESS>that contains "successfully imported" or something ;-)
[21:31] <JontheEchidna> what do I with failure though? lol
[21:31] <JontheEchidna> bring a sacrificial goat next time?
[21:31] <apachelogger> JontheEchidna: poke launchpad guys and tell them their product is broken ;-)
[21:32] <wgrant> apachelogger: The success notifications are disabled.
[21:33] <wgrant> But they probably won't actually go away until the next release, unless somebody can convince them a cherrypick is justified.
[21:34]  * apachelogger thinks that new contributors might get easily annoyed
[21:35] <adelie421> ok, after running debdiff, at the top it says "gpg: Can't check signature: public key not found". Is that ok, or did I miss something?
[21:41] <ScottK> wgrant: That's an odd definition of disabled then.
[21:41] <ScottK> c_korn: No idea then.
[21:41] <wgrant> ScottK: Disabled in trunk.
[21:41] <ScottK> is/will be then.
[21:41] <wgrant> Much that we mark as fixed many bugs that won't be fixed in a release for several months.
[21:41] <wgrant> s/that/like/
[21:42] <ScottK> Trunk is a VCS, not a developemental release.
[21:42]  * ScottK thinks it's rather different.
[21:42] <wgrant> A development release here will be a VCS within a few releases, I suspect.
[21:43] <ScottK> Also with Ubuntu one could choose to run the developmental release.  With a service like LP, no such choice exists.
[21:43] <wgrant> Mm, edge, but that doesn't help for this particular change.
[21:43] <ScottK> Right.
[21:48] <jmarsden> I've made a versioning mistake in my PPA.  It thinks 1.7rc1 is newer than the final 1.7 release, and so won't accept the upload of the "final" version... is there a way to fix this?  I'm seeing: Rejected:
[21:48] <jmarsden> bibletime_1.7-1ubuntu1~jmarsden1.dsc: Version older than that in the archive. 1.7-1ubuntu1~jmarsden1 <= 1.7rc1-1ubuntu1~jmarsden1
[21:49] <wgrant> jmarsden: You wanted ~rc1. There's no clean way to fix this, but using 1.7.0 instead will work.
[21:50] <jmarsden> Thanks, yes, I realise (now) the value of the ~ :)   I'll go with 1.7.0.
[22:04] <c_korn> ScottK: who should I ask about then?
[22:04] <c_korn> it is very odd
[22:13] <c_korn> is this move request allright? bug 342954
[22:15] <c_korn> I have an odd situation: sivp compiles fine in a PPA for amd64. but the build on the official build machines just freezes for amd64. who should I contact about that?
[23:25] <ScottK> c_korn: Someone who has amd64 (not me) and someone who understands java stuff (not me).
[23:31] <c_korn> ScottK: I contacted someone from #launchpad . he wants to investigate. thanks
[23:31] <c_korn> need to sleep. bye
[23:34] <meoblast001> hi
[23:34] <meoblast001> you guys here make debs regularly correct?
[23:37] <joaopinto> meoblast001, yes
[23:37] <meoblast001> ok
[23:38] <meoblast001> i'm trying to become fluent at deb building and i've ran into a wall
[23:38] <meoblast001> http://rafb.net/p/vB4wRZ75.html
[23:38] <meoblast001> dpkg-source is failing
[23:39] <joaopinto> meanburrito920_, the error message tells it all :)
[23:39] <meoblast001> you mean meoblast001?
[23:39] <joaopinto> ops :P
[23:39] <joaopinto> I do
[23:39] <joaopinto> your clean rules is not cleaning what it should
[23:39] <meoblast001> joaopinto: i'm sort of new at deb building (only built 2 packages before) so that error message isn't registering with my brain
[23:39] <meoblast001> sounds to me like something exists now that didn't exist before?
[23:40] <joaopinto> meoblast001, yes, something that resulted from building, which means, it should be removed, at your clean rule
[23:40] <joaopinto> usually with a -make distclean
[23:40] <meoblast001> joaopinto: would that delete the entire compile?
[23:40] <meoblast001> it took some time to compile audacity on this pentium m
[23:40] <meoblast001> i don't want to recompile it all
[23:41] <meoblast001> should i just remove the files it's speaking of in the error? that sounds like it would break audacity
[23:42] <joaopinto> it would not break, they will be rebuilt
[23:42] <joaopinto> you just want to build a .deb for your own use ?
[23:43] <meoblast001> joaopinto: well... basically... for learning purposes
[23:43] <meoblast001> ugh.... the Do Not Eat on the package that came with this beef jerky is tempting
[23:43] <meoblast001> oh wait.... ontopic
[23:43] <meoblast001> debs
[23:44] <meoblast001> joaopinto: ok thanks... let me try that real quick
[23:49] <meoblast001> joaopinto: something makes me want to think it's remaking everything
[23:49] <meoblast001> joaopinto: well... looks like i'll be waiting a while
[23:49] <joaopinto> meoblast001, if you didn't use -nc, it did
[23:49] <meoblast001> joaopinto: thanks for the heads up :P
[23:50] <meoblast001> joaopinto: so i have to use -nc for it to not rebuild everything?
[23:50] <meoblast001> or -nc makes it rebuild everything
[23:54] <meoblast001> joaopinto: ?
[23:55] <_Groo_> meanburrito920_: me? nope, but i know him :)
[23:56] <_Groo_> meoblast001: sorry i sent to meanburrito920_
[23:56] <meoblast001> _Groo_: ?
[23:57] <_Groo_> meoblast001: never mind :D
[23:57] <meoblast001> am i supposed to -nc my dpkg-buildpackage for it not to rebuild everything?


[00:04] <m4v> rww: zibor wasn't looking for support, just spamming that link btw
[00:05] <m4v> s/btw/fyi/
[00:13] <rww> ah :(


[00:13] <lug|32668> how do i request the color scheme for the website  ~~  dvlug.org ~~  be made more readable???  Its horribly hard to read with a dark purple background and black text and blue hyperlinks...


[11:14] <beerpages> Erstelle dir deine eigene Umfrage - Beispiel: http://www.beerpages.de/view/2H/Anti-%22Die%20%C3%84rzte%22%20Kampagne
[15:57] <skaet_> hi pitti, ara
[15:57]  * marjo waves
[15:58] <skaet_> hi marjo
[15:58] <pitti> o/
[15:59] <jdstrand> o/
[15:59] <Riddell> hi
[15:59]  * charlie-tca waves
[16:00]  * skaet_ waves to charlie-tca, Riddell, jdstrand  :)
[16:00] <skaet_> ... ok lets get this started
[16:00] <skaet_> #startmeeting
[16:00] <MootBot> Meeting started at 10:00. The chair is skaet_.
[16:00] <skaet_> To make the meetings be a bit more efficient, :) , would like us to follow the convention like some other teams are using ".." on separate line when you've finished typing.    If someone wants to comment on the last point, please "o/", so we know to wait.  Anyone object to trying this?
[16:01] <pitti> sounds fine
[16:01] <skaet_> :)
[16:01] <jdstrand> sure
[16:01]  * pitti suppresses the question whether left-handed smileys will work as well
[16:01] <skaet_> cool,  then moving along...
[16:01] <jdstrand> (as in, sure, sounds good)
[16:02] <skaet_> There's an agenda in the usual place.   Will post the link later.
[16:02] <skaet_> Would like to quickly go through some new business, then go into the round table.
[16:03] <skaet_> We're looking at changing date for release candidate to be on Tuesday 19th April (instead of April 21st).  Reason for this is that Good Friday is April 22, and Easter Monday is April 24th.   By shifting 2 days earlier, it will give us the week to test out the candidate properly.  Any objections/concerns?
[16:03] <skaet_> ..
[16:03] <pitti> +1
[16:03] <charlie-tca> +1
[16:03] <ScottK> \o
[16:03] <marjo> +1
[16:04] <skaet_> ScottK?
[16:04] <ScottK> I'm here now
[16:04]  * ogra_ac too
[16:04] <skaet_> ok, thought that meant you had a comment ;)
[16:04] <skaet_> [ACTION] skaet to update schedule for Release Candiate
[16:04] <MootBot> ACTION received:  skaet to update schedule for Release Candiate
[16:04] <ScottK> I do think it'd be useful to resolve the question of if our Release Candidate is really a Release Candidate or not.
[16:05] <ScottK> Clearly the last several cycles it has not been treated as such.
[16:05] <skaet_> ScottK,  agreed.   Will kick that discussion off last week (its in the agenda as a pending action item for me )
[16:06] <skaet_> just wanted people to know that the date will be shifting if we keep to the traditional approach.
[16:06] <pitti> for 10.10 it was really more like a beta2
[16:06] <pitti> since we had 4 days more than usual
[16:06] <cjwatson> it's always been more like a final beta, and perhaps we should name it as such
[16:06] <cjwatson> there has not been a single cycle in my memory when it's been a true candidate
[16:07] <marjo> cjwatson: +1
[16:07] <marjo> cjwatson: to reflect reality
[16:07]  * skaet_ observes that discussion is happening now, so will see if she can avoid a long email thread ;)...
[16:08] <ScottK> cjwatson: I agree with renaming.
[16:08] <skaet_> cjwatson, pitti, ScottK - if you're feeling like that,  I'm cool with renaming, and moving it up.
[16:08] <cjwatson> I think those two actions are independent, FWIW
[16:08] <apw> will that mean it needs a new milestone ?
[16:08] <apw> as right now we only have a beta milestone
[16:08] <ogra_ac> for LP and workitems
[16:09] <ogra_ac> it likely does
[16:09] <cjwatson> historically the feeling was that if you were targeting release rather than release candidate you were Doing It Wrong
[16:09] <cjwatson> I think that still holds even for beta-2 or whatever, TBH
[16:09] <skaet_> apw, yeah, I'm thinking we might.   Ok,  will look at a beta 2 earlier, and then moving rc candidate to just before.
[16:09] <cjwatson> but I don't really mind adding a new milestone ...
[16:10] <skaet_> ok, will put a proposal out to email in this direction, and then we can revisit at next meeting.
[16:10] <skaet_> ..
[16:10] <skaet_> Other topic that's come up this week is Python 2.7 - what will be the transition plan?
[16:11] <pitti> I guess there are some remaining rebuilds to do before we can switch over for it to be the default version?
[16:11] <ScottK> AIUI the plan has been to get the rebuilds we can do before switching the default and then see where we are in the schedule and switch if it's not too late.
[16:12] <doko> I was waiting for the archive being unfrozen
[16:12] <skaet_> doko, thanks.   it was only soft frozen.
[16:12] <ScottK> For rebuilds or switching the default?
[16:12] <doko> no, the plan is to do the rebuilds, then to switch the default, and then fix the outstanding breakage
[16:13] <ScottK> I'd prefer an "assess the breakage" step between doing the rebuilds and switch the default.
[16:13] <ScottK> Based on lucas' rebuild test, I suspect it won't be too bad though.
[16:14] <pitti> do you have some tricky grepping of Contents.gz to see which packages ship stuff for 2.6, but not 2.7?
[16:14] <ScottK> I don't.  I've just been uploading rebuilds as I hit problems that needed it.
[16:15] <doko> if you can do that with reasonable effort, please do. I do not want to spend too much time with this. and we will have 2.7 as the default in natty, so we have to do the fixes anyway
[16:15] <skaet_> we've put out the armel port, so I'm not aware of anything else stopping going forward as doko and ScottK outline at this point.  anyone else have concerns?
[16:15] <cjwatson> none from me; can I restart autosyncs?
[16:15] <ScottK> I have the concern that we aren't proposing the same thing.
[16:16] <cjwatson> oh, sorry, "none from me" meant "regarding going forward on <stuff in general> rather than continuing to freeze" ...
[16:16] <doko> but you'r not proposing anything which leads us forward, and you don't say how *you* want to achieve the 2.7 goal
[16:17] <skaet_> Scott,  I took the "plan" to be a merge of your ideas - as doko outlined, with an assess the breakage step inserted.
[16:17] <ScottK> skaet_: doko doesn't agree to that.  He wants to just switch regardless of how prepared the archive is.
[16:17] <ScottK> He can do that and he's welcome to fix it then.
[16:19] <doko> barry did the rebuild tests, so we know that we can expect few failures. and yes, I'd rather spend time fixing remaining issues, than spending time on over-pedantic qa during alpha time
[16:20] <skaet_> how about we do all the rebuilds this week, and see where we are next week at this meeting?
[16:20] <pitti> FWIW, since we already had a test PPA, I agree with doko; the longer we have 2.7 the default, the better we can test it
[16:20] <pitti> and we could always switch back to 2.6 as the last resort
[16:20] <pitti> (this is just where /usr/bin/python symlinks to, right?)
[16:20] <marjo> pitti: +1 for backup plan
[16:21] <doko> skaet_: I'd like to have most of 2.7 fixed before the holidays. just waiting one more week gives us just two weeks to address these issues
[16:21] <doko> pitti: yes
[16:21] <jdstrand> for the little it is worth, I would tend to agree with pitti and doko
[16:22]  * skaet_ is seeing concensus building...
[16:22] <doko> and I'll write up an announcement before doing the default change
[16:22] <ScottK> pitti: If we'd switched when doko wanted it would have broken obscure things like debconf.
[16:22] <cjwatson> FWIW, hardly anything uses debconf.py
[16:22] <ScottK> I think it would be nice to actually minimize the breakage and not just jump off a cliff.
[16:22] <ScottK> OK
[16:22] <cjwatson> that actually *is* fairly obscure (with the exception of the installer but it could have been worked around if need be)
[16:22] <skaet_> doko,  ok, if you send out the announce that would be good.
[16:22] <doko> and no, debconf wouldn't even be built because of component-mismatches ...
[16:23] <cjwatson> skaet_: unfortunately, I think this is majority rather than consensus
[16:23] <skaet_> cjwatson,  you're right
[16:23] <skaet_> :)
[16:23] <skaet_> ok, we need to move forward.
[16:24] <skaet_> lets go with the rebuilds, if nothing catastrophic, doko sends out anounce, then we make it the default... and start fixing.
[16:24] <skaet_> ..
[16:24] <doko> thanks
[16:25] <skaet_> New Topic: QA team update - marjo
[16:25] <marjo> = Natty Alpha1 Test Report - December 3rd, 2010 =
[16:25] <marjo> https://wiki.ubuntu.com/QATeam/ReleaseReports/NattyAlpha1TestReport
[16:25] <marjo> [16:25] <marjo>  * Image Coverage: 43/47 = 91.49 %
[16:25] <marjo>  * Mandatory Testcase Coverage: 133/163 = 81.60 %
[16:25] <marjo>  * Optional Testcase Coverage: 12/40 = 30.00 %
[16:25] <marjo> [16:25] <marjo>  * 36 Test Failures
[16:25] <marjo>  * Failure Rate 36/145 = 24.83 %
[16:25] <marjo> == Bugs summary ==
[16:25] <marjo> [16:25] <marjo> 30 bugs unfixed
[16:25] <marjo>  * Critical - 1
[16:25] <marjo>  * High - 7
[16:25] <marjo>  * Medium - 4
[16:25] <marjo>  * Low - 3
[16:25] <marjo>  * Undecided - 15
[16:26] <marjo> [16:26] <marjo>  * LP: #669496 - natty fails ec2 boot on i386 or t1.micro - Confirmed - Critical
[16:26] <marjo> [16:26] <marjo>  * LP: #684036 - Installation stalls after keyboard selection - New - High
[16:26] <marjo>  * LP: #684304 - cciss module does not identify resources - New - High
[16:26] <marjo>  * LP: #683367 - apport fails to create crash file during upgrade to 11.04 - New - High
[16:26] <marjo>  * LP: #650703 - oem-config-prepare works, but oem-config fails to start after reboot - Confirmed - High
[16:26] <marjo>  * LP: #684060 - separated menus: no keyboard shortcuts for menus - Triaged - High
[16:26] <marjo>  * LP: #683700 - tasksel 'Virtualisation Host' fails to install - Triaged - High
[16:26] <marjo>  * LP: #683775 - Natty Alpha 1, i915 has blank screen after boot - In Progress - High
[16:26] <marjo> thx to jibel for the report
[16:26] <marjo> QA Dashboard
[16:26] <marjo> http://reports.qa.ubuntu.com/reports/qadashboard/qadashboard.html
[16:26] <MootBot> LINK received:  http://reports.qa.ubuntu.com/reports/qadashboard/qadashboard.html
[16:26] <marjo> QA Dashboard now includes automated server test results
[16:27] <marjo> thx to hggdh & bdmurray for that
[16:27] <marjo> any questions?
[16:27] <marjo> otherwise
[16:27] <marjo> ..
[16:27] <skaet_> :)
[16:27] <skaet_> thanks marjo - looking forward to going through then new dashboard.
[16:28] <marjo> skaet: as usual, please provide feedback on format & usefulness
[16:28] <victorp> the dashboard seems to point to old hw cert results
[16:28] <cjwatson> I'm confused by http://people.canonical.com/~mvo/automatic-upgrade-testing/current/
[16:28] <cjwatson> it has date finished yesterday
[16:28] <cjwatson> if you follow the links, the logs are dated September
[16:28] <marjo> victorp: is this no longer correct? http://people.canonical.com/~fader/hw-testing/current.html
[16:29] <cjwatson> mvo: ^-
[16:29] <fader_> marjo: I am no longer updating that as I have changed teams... I believe ara is creating these reports now, but I don't know where they are located
[16:30] <victorp> marjo - sorry fader is no longer in hw cert
[16:30] <marjo> fader_ ok, will follow up w/ ara; thx
[16:30] <victorp> at the moment we are using http://people.canonical.com/~ara/hw-testing/current
[16:30] <fader_> I will update my "current" page to reflect this and provide a link to ara's page
[16:30] <marjo> victorp: ack; will change accordingly
[16:30] <victorp> but trying to get a generic account so it doesnt matter who does the test :)
[16:30] <skaet_> also,  before we move on just wanted to say thank you to everyone who pitched in and helped with testing the alpha1.  excellent job!
[16:30] <marjo> victorp: great idea; thx
[16:30] <victorp> marjo - I will ping you once that is done
[16:31] <skaet_> ... and on that note, let's move on to victorp
[16:31] <victorp> yes? :)
[16:31] <skaet_> New Topic: Hardware Certification team update -victorp
[16:31] <victorp> [LINK] http://people.canonical.com/~ara/hw-testing/current
[16:31] <MootBot> LINK received:  http://people.canonical.com/~ara/hw-testing/current
[16:32] <victorp> we finally got testing going for clients
[16:32]  * skaet_ \o/
[16:32] <victorp> the test failures in the link are due to script problems
[16:32] <victorp> not due to image issues
[16:32] <victorp> unfortunately we did not get any results from servers
[16:32] <victorp> lab issues, we are working to resolve this asap
[16:33] <victorp> we will now start running this test weekly
[16:33] <victorp> skaet - that is about it
[16:33] <skaet_> thanks victorp
[16:33] <skaet_> ..
[16:33] <victorp> once we have the test running we will look into adding unity testing and boot metrics
[16:33]  * skaet_ looks around for questions?
[16:34] <skaet_> cool - looking forward to seeing them.
[16:34] <skaet_> New Topic: Security team update - jdstrand
[16:34] <jdstrand> hi
[16:34] <skaet_> :)
[16:34] <jdstrand> [LINK] https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Natty
[16:34] <MootBot> LINK received:  https://wiki.ubuntu.com/SecurityTeam/ReleaseStatus/Natty
[16:34] <jdstrand> [LINK] http://people.canonical.com/~platform/workitems/natty/canonical-security.html
[16:34] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/canonical-security.html
[16:35] <jdstrand> We have one milestoned bug: LP: #667815. Kees filed it and is working on it.
[16:35] <jdstrand> Not a lot to report due to the Thanksgiving vacations most of our team had. Beyond that, we've been focusing primarily on USNs.
[16:35] <jdstrand> ..
[16:35] <skaet_> thanks!  questions?
[16:35] <jdstrand> I actually have one :)
[16:35] <jdstrand> oh
[16:35] <jdstrand> o/
[16:35] <skaet_> :)
[16:35] <jdstrand> sorry if I missed it, but did cjwaton get an answer for turning on autosync?
[16:36] <cjwatson> I interpreted the answer as yes
[16:36] <skaet_> I was assuming we'd be turning it on now.
[16:36] <cjwatson> it's running noww
[16:36] <skaet_> :)
[16:36] <jdstrand> ok
[16:37] <skaet_> New Topic: Kernel team update - apw
[16:37] <apw> o/
[16:37] <apw> Overall status is reported at the first link below.  Burn down for the release milestone is at the second link below.  Burndown for the cycle is at the third link:
[16:37] <apw> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
[16:37] <apw> [LINK] http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team-natty-alpha-1.html
[16:37] <apw> [LINK] http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.svg
[16:37] <MootBot> LINK received:  https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Natty
[16:37] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team-natty-alpha-1.html
[16:37] <MootBot> LINK received:  http://people.canonical.com/~platform/workitems/natty/canonical-kernel-team.svg
[16:37] <apw> natty-alpha-1 is now officially over, we achieved most of the coding items for the kernel but a number of ancillary and documentation tasks have been pushed out to natty-alpha-2.  Those pushed out are listed with background on the overall status above (first link).
[16:37] <apw> Of the bugs called out on the agenda: little progress has been made on the first; the second is possibly related to the grub2 changes and testing is required there; the third it seem the i386 issues are likely a corrupt image with the t1.micro issues being real on both amd64 and i386; little progress has occured on the remainder; the last bug is really not a kernel issue either.
[16:37] <apw> The main distro kernel is now rebased forward to mainline v2.6.37-rc3 and uploaded.  A bnx2 firmware issue affecting a number of Dell servers triggered a kernel respin just after the natty-alpha-1 freeze.  A further upload rebasing to v2.6.37-rc4 is pending the release of the milestone freeze.  Some testing of Linaro ARM kernels has been ongoing and the current feeling is that the kernels do have most of what is needed, some gap analysis is still need
[16:37] <apw> ed for the configuration.
[16:37] <apw> ..
[16:38] <skaet_> thanks apw!
[16:38] <skaet_> questions?
[16:38] <skaet_> New Topic: Foundations team update - cjwatson
[16:38] <cjwatson> just to be clear: the grub2 change you mention was the one we agreed to do at UDS in the awareness that that would expose kernel problems
[16:38] <cjwatson> (for people unfamiliar with that project)
[16:38] <cjwatson> This week was quite quiet with the exception of alpha-1.  Interesting bits and pieces:
[16:39] <cjwatson>  - installer autotest framework no longer blocked on IS, should be ready for action soon
[16:39] <apw> cjwatson, yes, that is correct, fallout from a pre-approved change
[16:39] <cjwatson>  - working through various python2.7 build failures
[16:39] <cjwatson>  - interesting news from grub upstream: experimental reverse-engineered btrfs support.  this is unfortunately not based on our work which had been stalled on licensing issues, which is a shame, but it's good to see something that seems like a resolution anyway
[16:39] <cjwatson>  - some progress on software-center startup performance (now with data, http://people.canonical.com/~mvo/software-center/mini10-startup/startup-times.png)
[16:39] <cjwatson> The work items graph (http://people.canonical.com/~platform/workitems/natty/canonical-foundations.html) is trending downwards at an acceptable rate, though it remains to be seen how much the holidays get in the way.
[16:39] <cjwatson> I don't have much else to report right now.
[16:39] <cjwatson> Questions?
[16:39] <cjwatson> ..
[16:39] <skaet_> o/
[16:39] <cjwatson> aye
[16:39] <mvo> cjwatson: auto-upgrade-tester> hrm, hrm, the current symlink is broken , i fix that
[16:39] <skaet_> any help needed on the licensing issue?
[16:41] <cjwatson> skaet_: we tried to move it forward several times (it relied on approval from two other big companies) and got nods and smiles but little actual paperwork.  at this point I suspect that letting upstream go ahead with their reverse-engineered version (not that we could stop them!) is the best answer.  there's still things we can help with
[16:41] <skaet_> cjwatson,  ok,  thanks.
[16:42]  * skaet_ looks around?
[16:42] <skaet_> ..moving on
[16:42] <doko> one thing about component-mismatches
[16:42] <skaet_> ?
[16:43] <doko> would it be possible if every team looks at these and cares about resolving them for alphas and betas?
[16:43] <doko> they usually tend to accumulate
[16:43] <cjwatson> it would definitely help if it wasn't just us.  are people confused about what's needed?
[16:44]  * ogra_ac thinks right before milestones the teams are busy getting milestones ready
[16:44] <doko> not confused, just not looking
[16:44] <ogra_ac> i would rather propose to do it after a milestone
[16:44]  * skaet_ nods
[16:44] <doko> people tend to forget after a milestone
[16:44] <ogra_ac> make it a fixed task
[16:44] <cjwatson> ogra_ac: even that would be better than the current situation
[16:45] <cjwatson> I don't actually care much when people decide to do it
[16:45] <skaet_> I can add it to the list and remind in these meetings?
[16:45] <ogra_ac> ++
[16:45] <cjwatson> doko: not looking> it's difficult to tell because we have no throughput log, only a snapshot of current state
[16:45] <doko> sounds good
[16:45] <skaet_> okie  moving on...
[16:45] <cjwatson> I know that a lot of stuff stays on the list but I don't really get to see what moves off it
[16:46]  * skaet_ seems like this should be another sort of report, will add to ponder list...
[16:46] <skaet_> New Topic: Server team update - robbiew
[16:47]  * skaet_ looks around for robbiew or someone from server, since robbiew's traveling..
[16:47] <skaet_> Daviey?
[16:48] <skaet_> .. hmm,  ok, will move on and see if someone shows up later.
[16:48] <skaet_> New Topic: Desktop team update - pitti
[16:48] <pitti> As usual, detailled report including RC bug status is at
[16:48] <pitti> [LINK] https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[16:48] <MootBot> LINK received:  https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
[16:48] <pitti> Blueprint drafting: All done, except for two stragglers which our team doesn't work on (see wiki)
[16:48] <pitti> Development status:
[16:48] <pitti> - Alpha-1 work items were almost all done; 4 stragglers, moved to alpha-2.
[16:48] <pitti> - Netbook CD now merged into Desktop (except on ARM), unity vs. classic detection is in place.
[16:48] <pitti> - There are currently a lot of compiz crashes, these are being worked on.
[16:48] <pitti> CD space savings:
[16:49] <pitti> - Need more package rebuilds to reduce changelogs and PNG files
[16:49] <pitti> - There has not been much movement on the perl-base-only discussion; if it doesn't make further progress by the end of the year, we will drop this goal and instead just try to get rid of some separately packaged Perl modules.
[16:49] <pitti> - Once we rebuild OO.o, we'll drop another ~ 9 MB due to dropping the NBS libicu42 and changelogs.
[16:49] <pitti> - We need to get rid of Python 2.6 on the CDs.
[16:49] <pitti> ..
[16:49] <pitti> (sorry, the python one has already been discussed)
[16:50] <skaet_> thanks pitti!  questions?
[16:50] <skaet_> .. ok, onward down the agenda.
[16:50] <skaet_> New Topic: Ubuntu One Team
[16:50] <robbiew> o/
[16:51] <skaet_> hi robbiew :)
[16:51] <robbiew> sorry...am in a meeting but I can give a quick Server Team update
[16:51] <skaet_> yes please
[16:52] <robbiew> http://wiki.ubuntu.com/ServerTeam/NattyBlueprints
[16:52] <MootBot> LINK received:  http://wiki.ubuntu.com/ServerTeam/NattyBlueprints
[16:52] <robbiew> so this is a "final" list of 11.04 committments
[16:53] <robbiew> there are a few undetermined blueprints
[16:53] <robbiew> where we are waiting on some input
[16:53] <robbiew> if anyone has comments/questions...send me email ;)
[16:54] <robbiew><EMAIL_ADDRESS>[16:54] <skaet_> ..
[16:54] <robbiew> ..
[16:54] <skaet_> thanks robbiew :)
[16:54]  * skaet_ looks around for anyone from Ubuntu One team?
[16:54] <joshuahoover> skaet_: me (sorry)
[16:55] <joshuahoover> [LINK] https://wiki.ubuntu.com/UbuntuOne/NattyReleaseStatus
[16:55] <MootBot> LINK received:  https://wiki.ubuntu.com/UbuntuOne/NattyReleaseStatus
[16:55] <joshuahoover> details on where we're at with blueprints and releases is in the link above
[16:55] <joshuahoover> we have a rather important bug to fix with couchdb not working in natty right now, bug #682866
[16:55] <joshuahoover> that bug, in addition to couchdb not working, is preventing us from getting our new packages for desktopcouch in...thisfred is working (with a number of people) on getting the bug fixed asap
[16:55] <joshuahoover> the other thing to note is we're behind in our work to get u1 events in zeitgeist...we thought we'd have this done this week for alpha1 but it's been a bit more work than we originally estimated...we think we'll have it done the end of next week
[16:55] <joshuahoover> ..
[16:55] <skaet_> thanks joshuahoover.  :)  questions?
[16:56] <skaet_> New Topic: Kubuntu Team update - Riddell
[16:56] <Riddell> hi
[16:56] <Riddell>  * Alpha 1 out, no major problems
[16:56] <Riddell>  * GCC should be fixed for ARM, Qt build now ongoing
[16:56] <Riddell>  * KDE Platform 4.6 beta 1 is in (minus KDE PIM which we are being more cautious about)
[16:56] <Riddell>  * KDE Platform beta 2 due to packagers yesterday, due for release next week
[16:56] <Riddell>  * hal removed from kubuntu seeds and CDs.  Testing ongoing.
[16:56] <Riddell>  * Bug #684703 "Generated symbols different on different archs with gcc-4.5" causing annoyance
[16:57]  * pitti yays about Khalsectomy
[16:57] <ogra_ac> heh
[16:57] <Riddell> upstream have been moaning lots about the lack of any docs for the replacements
[16:58] <Riddell> but then it's not like hal had any documetation
[16:58] <pitti> what specifically? udisks, upower, and udev have quite decent docs, I think
[16:58] <Riddell> yes those
[16:59] <doko> Riddell: a reduced testcase would be much appreciated
[17:00] <skaet_> ?
[17:00] <skaet_> ..?
[17:01] <Riddell> I can play around with libraries, but I don't have any methodical way of making one
[17:01] <Riddell> skaet_: doko is talking about the symbols bug
[17:01] <skaet_> Riddell, thanks.
[17:02] <skaet_> was wondering if you had any other updates, or we should move on?
[17:02] <Riddell> I'm done
[17:02] <skaet_> ..
[17:02] <skaet_> thanks Riddell :)
[17:02] <skaet_> New Topic: Desktop Experience Team Update
[17:02]  * skaet_ looks around?
[17:03] <ogra_ac> no experience today :)
[17:03] <skaet_> New Topic: ARM team update - ogra
[17:03] <ogra_ac> thats me !!!
[17:03] <ogra_ac> ;)
[17:03] <ogra_ac> Full Status at https://wiki.ubuntu.com/ARMTeam/ReleaseStatus/Natty
[17:03] <ogra_ac> ..
[17:03] <ogra_ac> - Team worked towards alpha 1 release, one massive blocker bug was holding us up here
[17:03] <ogra_ac> - OMAP4 daily images build again, we had to drop some apps that build dep on QT for making the meta installable
[17:03] <ogra_ac> - OMAP3 kernel from linaro was tested with our image and looks good, we now wait for security and support commitment from kernel team for 18 months (a spec of the kernel team exists for this)
[17:03] <skaet_> :)
[17:03] <ogra_ac> - There are still some open SRU bugs left
[17:03] <ogra_ac> - The gcc fix for the QT FTBFS apparently went in unnoticed before alpha 1, QT should build now which should soon start to clean out the KDE FTBFS
[17:03] <ogra_ac> - Bug 683683 is the above mentioned bug that blocked A1, it turned out to be an issue with building busybox with the -marm flag, worries are big that -marm with new gcc might be busted, we need to research other -marm using packages here
[17:03] <ogra_ac> ..
[17:03] <ogra_ac> Image Status
[17:03] <ogra_ac> ..
[17:03] <ogra_ac> - Alpha 1 went out belated today
[17:03] <ogra_ac> ..
[17:03] <ogra_ac> Work Items
[17:03] <ogra_ac> ..
[17:03] <ogra_ac> - Entire http://people.canonical.com/~platform/workitems/natty/canonical-arm.html
[17:03] <ogra_ac> - Next Milestone http://people.canonical.com/~platform/workitems/natty/canonical-arm-natty-alpha-2.html
[17:03] <ogra_ac> ..
[17:03] <ogra_ac> Bugs
[17:04] <ogra_ac> ..
[17:04] <ogra_ac> Serious: bug 683683
[17:04] <ogra_ac> on a sidenote i'm on vacation til end of the year, rsalveti will take my part in this meeting until i return
[17:04] <skaet_> ack.
[17:05] <ogra_ac> thats it from me
[17:05]  * skaet_ wishes ogra_ac a good vacation.  :)
[17:05] <ogra_ac> :)
[17:05] <skaet_> thanks ogra_ac!  questions?
[17:05] <skaet_> New Topic: MOTU team update - ScottK
[17:06] <ScottK> On the phone.  Please come back to me
[17:06] <skaet_> ok ScottK
[17:07] <skaet_> New Topic: Linaro update - JamieBennett
[17:07] <skaet_> .. hmm no JamieBennett either...
[17:07] <skaet_> ok then open floor time
[17:08] <skaet_> New Topic:  Other questions, comments, etc?
[17:09] <skaet_> hmm,
[17:10] <skaet_> looks like we're pretty much at the end of the meeting, except for ScottK's input then.
[17:10] <pitti> nothing pressing right after an alpha
[17:10] <skaet_> heh, indeed.
[17:10] <skaet_> except the python 2.7 transition ;)
[17:11] <pitti> skaet_: buildds will be busy with that over the weekend :)
[17:11] <skaet_> ok,  so not to waste folk's time,  I'll add into the minutes any updates from ScottK after the meeting
[17:11] <cjwatson> I'm hunting around for people who object to decommissioning the ps3 port
[17:11] <skaet_> cjwatson - I don't!
[17:11] <cjwatson> does anyone have comments to make on that?
[17:12] <pitti> we could send an announcement similar to the ia64/sparc one?
[17:12] <doko> heh, I just updated to maverick last month
[17:12] <pitti> (not that I'd particularly care about the ps3 port)
[17:12] <cjwatson> doko: your ps3?
[17:12] <doko> yes
[17:12] <ogra_ac> play games on it !
[17:13] <cjwatson> ok ... do you have comments on decommissioning the port?  I assume that upgrades would still work, I'm just talking about continuing to build installer images
[17:13] <ogra_ac> stop using it for work
[17:13] <cjwatson> which is a fairly significant drain on resources for hardware with a vendor actively hostile to running Linux on it
[17:13] <charlie-tca> cjohnston, no objection from here
[17:13] <skaet_> decomission away, from my perspective... after a nice announcement.  ;)
[17:13] <cjwatson> (upgrades> since it's the same architecture after all)
[17:13] <doko> can we move this offline/to next week?
[17:13] <cjwatson> sure
[17:14] <skaet_> yup.
[17:14] <charlie-tca> cjwatson, no objection (sorry, cjohnston )
[17:14] <cjwatson> I've put it off long enough anyway
[17:14] <skaet_> Thanks marjo, victorp,jdstrand, apw, cjwatson, pitti, doko, robbiew, joshuahoover,  ogra_ac,  ScottK, charlie-tca
[17:14] <didrocks> david has a dropping freenode connection
[17:14] <skaet_> #endmeeting
[17:14] <MootBot> Meeting finished at 11:14.
[17:14] <pitti> thanks everyone
[17:14] <pitti> have a good weekend
[17:14] <didrocks> so, just giving that: DX status update at: https://wiki.ubuntu.com/DesktopExperienceTeam/NattyReleaseStatus as usual
[17:14] <joshuahoover> thanks everyone
[17:14] <marjo> skaet_ thx for an efficient meeting
[17:14] <ogra_ac> thx skaet_
[17:14] <didrocks> skaet_: if you need to have a look ^^
[17:15] <skaet_> didrocks, thanks for letting us know.
[17:15] <didrocks> yw :)
[17:15] <skaet_> will follow up with davidm, and ScottK offline for the minutes.
[17:15] <davidbarth> skaet_: and my connection is back
[17:15] <jdstrand> thanks everyone
[17:16] <davidbarth> sorry for not being there when it was my turn; the online world had suddenly frozen
[17:16] <skaet_>  davidbarth,  no worries - it happens.
[17:16]  * skaet_ keeping fingers crossed it doesn't happen to me during one of these ;)
[17:16] <skaet_> davidbarth, can you send me update by email and I'll just paste into the minutes?
[17:16] <davidbarth> sure
[17:17] <skaet_> awesome.  thanks!
[17:17] <skaet_> have a good weekend all.
[17:18] <charlie-tca> Thank you
[17:18]  * skaet_ heads over to #ubuntu-release channel again...
[17:18] <davidm> skaet_, you need me for something or did you mean davidbarth ?
[17:19] <skaet_> davidm, sorry meant davidbarth
[17:19] <skaet_> :(
[17:19] <davidm> NP just making sure ;-P
[17:22] <ScottK> skaet_: I'm off the phone now.
[17:22] <ScottK> skaet_: the rebuild results that lucas published today are pretty scary.  Plenty of MOTU work to do just to get stuff to build.
[17:23] <ScottK> Not that many python2.7 related build failures, so that looks ~OK for Universe, but that's just building.  Working is a different question.
[17:23] <skaet_> ScottK, anything I can do to help?
[17:23] <ScottK> So we'll have to see.
[17:24] <ScottK> A couple of meetings ago we had an action to document how to deal with the linker order problems.
[17:24] <ScottK> Did that ever get done?
[17:24] <ScottK> If not, we need it done.
[17:24] <skaet_> yeah, its in the action items.
[17:24] <ScottK>  If so, it needs to get publicized.
[17:25] <skaet_> doko was supposed to update an existing description.
[17:25] <ScottK> Once that's done, we need to make sure people are aware of it.
[17:25]  * skaet_ nods
[17:25] <doko> ahh, about the ordering being relevant on the command line?
[17:25] <skaet_> doko,  yup.  :)
[17:26] <ScottK> and how to identify such a problem and determine the solution.
[17:28] <skaet_> doko, can you get an email out about it early next week?   (update the online description, and then follow up with an email version)
[17:28]  * skaet_ likes to overcommunicate on these sorts of things...
[17:28] <doko> skaet_: update about what?
[17:29] <skaet_> order of command line args is important, how to identify when it might be happening and work around it.
[17:30] <skaet_> there's a link in the agenda to the site with the description it was suggested to be updated.
[17:30]  * skaet_ goes gets it...
[17:32] <skaet_> doko, ScottK - this is the link I had,  http://wiki.debian.org/ToolChain/DSOLinking
[17:33] <ScottK> skaet_: That describes the indirect linking changes, but not the ordering changes.
[17:33] <skaet_> ScottK, ack, which is why it was suggested it be updated.  ;)
[17:35] <skaet_> if that's not appropriate place in yours and doko's mind, I'm fine with it being documented on one of the ubuntu wiki's and a pointer made to it.
[17:35] <ScottK> I don't care where.
[17:36] <ScottK> I just want there to be enough of a tutorial that people can figure out how to fix it.
[17:36] <skaet_> doko?
[17:39] <skaet_> hmm, we seem to have lost him....
[17:39] <skaet_> ScottK,  any other updates you want me to put in the minutes for this week?
[17:40] <ScottK> Nope.
[17:40] <skaet_> ok,  thanks.
[17:40] <ScottK> Thanks for checking.
[17:40] <skaet_> np
[17:40] <skaet_> I'll head back to ubuntu-release then, and we can leave this clear for others.
[17:44] <doko> skaet_: done


[09:44] <AlanBell> !oggcamp-#ubuntu-uk is Oggcamp is a two day unconference on August 13th/14th 2011
[09:45] <AlanBell> oggcamp-#ubuntu-uk is Oggcamp is a two day unconference on August 13th/14th 2011
[09:45] <AlanBell> it doesn't listen to me
[09:51] <tsimpson> !oggcamp-#ubuntu-uk is a two day unconference on August 13th/14th 2011
[09:51] <tsimpson> !oggcamp-#ubuntu-uk
[09:51] <tsimpson> AlanBell: ^
[09:51] <elky> AlanBell, you might want linkyness in there?
[09:53] <AlanBell> ooh, good idea elky, tsimpson can you add http://oggcamp.org/
[09:54] <tsimpson> !no oggcamp-#ubuntu-uk is a two day unconference on August 13th/14th 2011 - See http://oggcamp.org/
[09:54] <AlanBell> thanks \o/
[09:54] <tsimpson> :)
[20:56] <ubot4> In #ubuntu-women-project, maco said: !uw is the group tag
[20:57] <ubot4> In #ubuntu-women-project, maco said: !uw is an alias for !ubuntuwomen
[20:57] <maco> ignore those. its in reference to identi.ca group tags


[07:35] <Myrtti> oh btw - just a reminder - dapper is closing in on EOL
[07:35] <Myrtti> now that I remember it again
[07:37] <Madpilot> June 2009
[07:37] <Myrtti> yep
[07:38] <Myrtti> so now would be the time to prod people mentioning dapper to upgrade
[07:51] <Flannel> only desktop
[07:51] <Myrtti> and I know there's people that still use it
[07:52] <Flannel> I did until January!
[09:38] <gnomefreak> how do i find the full output of !find bleh
[09:38] <Madpilot> 'more' or !more? not actually sure.
[09:39] <gnomefreak> !find infinity more
[09:39] <gnomefreak> !find more infinity
[09:39] <Myrtti> !find infinity
[09:39] <Myrtti> !more
[09:39] <Myrtti> ok
[09:46] <Mamarok> morning
[10:17] <Mamarok> what's that package again that enables ctrl+alt+backspace again in Jaunty
[10:17] <Mamarok> ?
[10:17] <Mamarok> !find xserver
[10:18] <Mamarok> hm...
[10:18] <Mamarok> !find xkill
[10:20] <topyli> Mamarok: dontzap
[10:20] <Mamarok> topyli: thx :)
[10:20] <topyli> or you could just use altgr-sysrq-k like you're supposed to :)
[10:21] <Mamarok> topyli: well, yes, that too :)
[10:22] <Madpilot> whattheheck is altgr?
[10:29] <jussi01> Madpilot: its the right alt key...
[10:30] <Mamarok> AltGr
[10:30] <Madpilot> cool, wasn't aware some functions distinguished btwn alt keys.
[10:31] <Mamarok> Madpilot: ? it always did, it replaces the 'compose' key on old unix keyboards
[10:32] <Madpilot> my background as a Windows refugee instead of a *nix beard betrays me :)
[10:33] <Mamarok> ah, so I guess you use the windows key ...
[10:33]  * Mamarok doesn't need that one at all
[10:33] <Mamarok> althoug, I should put a penguin on it, then I might use it :)
[10:34] <Madpilot> someone sells Tux decals for keyboards - I think there's Tux keyboards as well, for that matter
[10:37] <Mamarok> yeah, I think I even must have some sticker lying around here small enough for my key
[11:17]  * topyli uses the super key all the time
[13:18] <Jack_Sparrow> @login
[13:18] <Jack_Sparrow> @btlogin
[13:39]  * elky waits.
[13:42]  * Pici sighs
[16:32]  * jussi01 is tired
[16:32] <Pici> me too
[16:34]  * Myrtti drinks a pot of coffee
[16:34] <Pici> FYI, I will probably be stressed out next week, so if I seem a bit on edge, just let me know.
[16:35] <Myrtti> Pici: cuddles coming your way then
[16:36] <Pici> We're going live with a new financial/registration system.  I'll be working a 16 hour shift the first night and then 4am to 4pm thereafter until wednesday.
[16:47] <LjL> there are a few bots connected from <IP_ADDRESS>, and two of them are in #edubuntu. i'm not sure whether they're allowed there - one of them was in another channel where it was definitely not allowed by the ops
[16:48] <Myrtti> oh boy
[16:48]  * Myrtti sees what channel one of them is
[16:48] <Pici> LjL: Are the bots doing anything?
[16:48] <LjL> Pici: they gave an announcement in the another channel.
[16:48] <LjL> in #edubuntu they might have given the same announcement, but i don't know as i wasn't there
[16:49] <Myrtti> oh - it's not even a bot
[16:49] <Pici> LjL: Announcing what?
[16:49] <LjL> [17:36:18] <BenBot> Announcement from my owner (bencrisford): Hey! This is BenBot, he does all sorts of tricks. He can play russian roulette, log channels, read RSS feeds, shrinkURLs, do maths and much much more! If you want to use him on your IRC channel, join #spux and speak to bencrisford. :)
[16:49] <Pici> ...
[16:50] <Pici> LjL: thanks.
[16:50] <LjL> welcome
[16:51] <Pici> Myrtti: Did you message any of them, if not I think we need to invite their owner in here.
[16:51] <Myrtti> no, didn't
[16:51] <Myrtti> bencrisford2 seems to be online and coming from that IP
[16:52] <Pici> bencrisford is also on
[16:53] <Myrtti> hmmm
[16:53] <Myrtti> bencrisford2: hi
[16:53] <bencrisford2> Hi
[16:53] <Myrtti> could you explain what are your bots doing in #edubuntu?
[16:54] <bencrisford2> Well, they aren't there officially, but LaserJock is cool with it.  We were gonna log meeting with them, but LaserJock said we'll probably use #ubuntu-meeting if we can from now on, but they might be useful
[16:55] <bencrisford2> If they're not allowed to be there ill remove them immediately, but I thought it would be ok..?
[16:56] <bencrisford2> Myrtti: ?
[16:56] <Myrtti> Pici: thoughts?
[16:57] <ikonia> I'm curious to why it takes 2 bots to log something ?
[16:57] <bencrisford2> it doesnt
[16:57] <bencrisford2> they arent there to log anymore
[16:57] <ikonia> so what's the pupose now ?
[16:57] <bencrisford2> we were just exploring how we could use bots, we havent got a clear purpose at the present tim
[16:57] <bencrisford2> time*
[16:58] <bencrisford2> but we think they could be useful
[16:58] <Pici> bencrisford2: Could you remove the bots for now until we talk to LaserJock?
[16:58] <bencrisford2> of course
[16:58] <bencrisford2> all done
[16:58] <Pici> Is it just you and LaserJock who were discussing using them? Or does 'we' refer to someone else too?
[16:59] <bencrisford2> when i say 'we' i just mean the edubuntu folks
[16:59] <Pici> Okay ;
[16:59] <Pici> er, ;)
[16:59] <bencrisford2> LaserJock hasnt officially said "sure lets have bots"
[16:59] <bencrisford2> but i was interested in using some
[16:59] <bencrisford2> and he said a channelogeer wouldnt be useful
[16:59] <bencrisford2> but we might find a use for some bots
[17:00] <bencrisford2> for example, I have already found the "seen" tool particurlaly useful
[17:00] <Myrtti> that's what nickserv info is good for
[17:00] <Pici> /msg nickserv info <nick>  can also tell you the last time a person was on, if they have a registered name.
[17:01] <jussi01> We have offcial logbots and info bots already
[17:01] <bencrisford2> I know, I just thought maybe some other bots can help
[17:01] <bencrisford2> as far as I know, I havent broken any rules..  have I?
[17:02] <Pici> Actually bots are addressed in our guidelines.
[17:02] <Pici> !guidelines
[17:03] <bencrisford2> :S Im really, really sorry
[17:03] <bencrisford2> like I say I didn't think I had done anything wrong, I was just trying to help out :/
[17:04] <Myrtti> no harm done :-)
[17:04] <Myrtti> atleast now that they're not there anymore
[17:04] <bencrisford2> ok
[17:04] <bencrisford2> sorry
[17:04] <jussi01> bencrisford2: keep working with tsimpson ;)
[17:08] <jussi01> !releasenotes | Mamarok, intel fixes are in here:
[17:08] <Pici> !intel | too
[17:08] <Mamarok> Pici: thx :) but I guess that users needs more than that...
[17:09] <Mamarok> seems even that it is Kwin related, according to the bug report it works in Gnome...
[17:27] <Pici> I sent a memoserv message to laserjock asking him to join here and discuss having extra bots in #edubuntu
[17:35] <Mamarok> I guess me and support have a love-hate relationship :)
[18:06] <jussi01> Pici: lasejock is around, you may just want to pm him, he may have missed the memoserv message...
[18:08] <jussi01> heh... actually I take that back...
[19:17] <Myrtti> tis not
[19:29] <Pici> argh
[19:29] <Pici> Why are people telling others the bot trigger instead of triggering it themselves?
[19:38] <Flannel> because they're silly.
[19:40] <vorian> it's less calories, ubottu lite
[20:46] <Pici> !-iso
[20:46] <Pici> !-isomount
[20:46] <Pici> !-mountiso
[20:46] <Pici> hmm
[22:34]  * jussi01 prods ikonia
[22:51] <Myrtti> @bansearch madbuntu
[22:52] <Myrtti> oh well, wrong hunch
[23:32] <mneptok> vorian: actually, it's "fewer calories"


[16:10] <omega_doom> pkgconfig for libprotoc-dev seems to be missing https://packages.ubuntu.com/focal/i386/libprotoc-dev/filelist