[00:01] nhandler: Thank you for your mentoring efforts. ;-) === vorian is now known as MadMule [00:09] aloha [00:10] if a package is named 1:0.3.0-14, i should rename after altering 1:0.3.0-15ubuntu1? [00:10] or 1.0.3.0-14ubuntu1? [00:12] crist1: second form [00:12] but wait me have a look [00:13] goshawk: thank you === MadMule is now known as vorian [00:15] yep crist1 second form === vorian is now known as evil[v] === evil[v] is now known as evilv === EvilChild is now known as pricey === pricey is now known as Pricey [00:57] What are the requirements to become a MOTU member, and how long does it usually take after applying to become a member? [00:58] nazgand: https://wiki.ubuntu.com/MOTU will have the info you are looking for [00:59] 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] nazgand: it takes time to go through the process [01:00] Ok, thank you. [01:00] after having several packages sponsored, your sponsors will tell you when you are ready [01:01] Ok. [01:14] <__iron> hi [01:14] 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] __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] You're welcome __iron. If you need any help packaging it, feel free to ask. [01:24] <__iron> k thx+ === evilv is now known as vorian [02:46] Hey, I'm back and I'm still needing help getting my source package to install correctly. [02:55] ripps: What is the issue? [02:57] 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] Hold on, I'm doing a fresh pbuilder build with a logfile. [03:02] Man, it segfaulted again. This is getting pretty annoying [03:07] ripps: I'm going to head off to bed. I'm sure someone else will be able to help you. [03:08] nhandler: okay, thanks anyway [04:08] anyone else having connectivity issues with launchpad? [04:16] adelie421: seems t owork for me? [04:16] it's sometimes slow though [04:18] Production doesn't work, but edge does sometimes. [04:19] Hmm, prod does too, but very, very slowly. [05:04] 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] 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] Anyone free to help a noob? Do I need to register a branch before I use bzr send -o foo.patch? [05:47] 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] adelie421: Try asking for help in #bzr as well. [05:49] k [06:25] ripps: did you get it figured out? [06:25] (whatever it might be..) [06:25] Ryan52: no [06:26] I might be able to help... [06:29] ripps: so what was your question? [06:30] Ryan52: Oh, you just logged on, so you haven't seen my post, hold on. [06:30] 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] okay, what do your debian/package_name.install files look like? [06:32] I have 20 of them, but I'll post one of them to give you an idea. [06:34] Ryan52: Here's debian/gmpc-alarm.install: http://paste.ubuntu.com/130916/ [06:35] It's based on what dpkg -L says about it as a standalone package. === fabrice_sp is now known as fabrice_sp_ === fabrice_sp_ is now known as fabrice_sp__ [06:38] hmm. === fabrice_sp__ is now known as fabrice_sp [06:38] debian/tmp/usr/lib/gmpc/plugins/alarmplugin.la exists? [06:39] Well, according to libtool, it installed the file there. I can't check because this was built in a pbuilder environment [06:40] why are you building in pbuilder? [06:40] Ryan52: to keep the build environment clean, and so that I know that it will work when I upload to the ppa [06:43] what's debian/compat? [06:44] Ryan52: 5 [06:44] change it to 7 [06:44] and see if it works. [06:45] Okay, let me warn you I tend to get segfaults often while building, so it might take awhile [06:46] ripps: http://pastie.org/415971 [06:46] it lookes like that syntax only works with debhelper 7 and up. [06:47] Ryan52: Oh, I wish someone had told me about that sooner [06:47] Every package guide I read said to leave it at 5 [06:48] * ripps crosses his fingers [06:48] :) [06:49] usr/share/doc/gmpc-alarm/TODO [06:49] usr/share/doc/gmpc-alarm/AUTHORS [06:49] usr/share/doc/gmpc-alarm/README [06:49] hmm. [06:49] is the upstream Makefile actually installing those there? [06:49] I doubt it. [06:49] ripps, when you have problems building a package, you can login to the chroot hidden behind pbuilder and make a manual build [06:50] this way, you can check where the files are installed [06:50] you probably should put the path (in the source, not from debian/tmp/) of those in debian/gmpc-alarm.docs instead. [06:51] Ryan52: I'll do that, if it gets past the point it always fails. [06:51] fabrice_sp: I know I can use pbuilder --login, but how do I move my package source into there? [06:51] well, it'll still fail at the same point if those aren't being installed by the upstream makefile. [06:51] ripps: cp? wget? [06:52] ... how about a bindmount? [06:52] man pbuilder [06:52] /--bindmounts [06:52] --bindmounts option [06:52] too late :-) [06:52] hehe [06:53] 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] pbuilder has a database? [06:54] it's apt database, just like ubuntu has. [06:55] 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] nice. [06:55] ripps: could you please share those scripts? :) [06:58] Ryan52: http://paste.ubuntu.com/130928/ [06:59] 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] I commented out lines from an old version of the script that didn't work. [07:00] oh, so you're just building an apt repository in your result dir. that seems useful. [07:00] Basically [07:00] very useful [07:01] make sure to have you result directory in you bindmounts, otherwise it's useless [07:01] 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] I tried doing that before I read this: http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#usingspecialaptsources [07:09] 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] Please don't segfault... please don't segfault... [07:13] dammit, signal 11 segfault [07:13] trying again... [07:26] ripps, what is your memory size? I had this problem when I was compiling huge C++ programs and only 1Gb. [07:26] fabrice_sp: only 512mb. [07:26] But I think it's past the point I usually fail at, the gcc compiling. [07:26] ripps, that could explain the segfaults... [07:27] oh [07:27] I closed a bunch of stuff I had open. Probably freed up a little memory [07:28] 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] fabrice_sp, Ryan52: It went further than it did before, but I still got an error [07:31] cp: cannot stat `debian/tmp/usr/share/doc/gmpc-alarm/TODO': No such file or director [07:31] yep, I knew that would happen. [07:31] But I think that's fixable, it's my *.install file's fault. [07:32] like I said, do the docs thing. [07:32] Getting on it now. [07:32] that's why building inside a chroot allows you to check that, and only repeat the install part :-) [07:33] that's why ripps shoulda just made the change when I first brought it up :D [07:33] I was impatient, it's gonna take me awhile to change 20+ files [07:33] oh, fun. [07:33] (although I could have been doing it while it was compiling) [07:36] Ryan52: what about *.png files? [07:39] what do you mean what about them? [07:39] Do they go in *.doc or *.install? [07:39] depends. [07:39] if upstream Makefile installs them debian/tmp [07:39] then specify the path from as if you are in debian/tmp and put it in package.install [07:40] if you want them in /usr/share/doc/package/ put them in package.docs [07:40] /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] so *.install [07:40] yep. [07:41] Well, let's try this one more time (hopefully. [07:43] 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] if a motu want to review my package, it's waiting at http://revu.ubuntuwire.com/details.py?package=sqliteman :) === IVBela1 is now known as IVBela === DrKranz is now known as DktrKranzz === DktrKranzz is now known as DktrKranz [12:03] RainCT, heh :) [12:03] feel free to reupload with suggestion I just mailed ;) [12:06] lol [12:07] mornin' === asac_ is now known as asac [12:10] hi directhex [12:12] * directhex finds himself unable to test-build things, as his mirror's Packages.gz for universe is busted [12:14] DktrKranz, feel like the adventure of a lifetime? try building http://ftp.de.debian.org/debian/pool/main/b/boo/boo_0.8.1.2865-3.dsc in an up-to-date jaunty pbuilder! [12:15] 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] I have 56 at the moment, with only half of universe built. [12:33] can a MOTU have a look at sivp and upload it to the jaunty queue if everyting is correct? bug 334362 [12:33] Launchpad bug 334362 in sivp "FeatureFreezeException: Please update sivp 0.5.0 from REVU" [Wishlist,Confirmed] https://launchpad.net/bugs/334362 === Igorots is now known as Igorot [13:25] Is there any utility in attaching a debdiff to a sync request? [13:26] uhm.. can I install a i386 package on amd64? [13:27] RainCT: It'll *run*, if it has all of the compat libs installed. [13:27] RainCT: why? [13:27] RainCT: as a rule it's a bad idea :) [13:27] but dpkg won't let me install it :) [13:28] *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] RainCT: use more force (--force-architecture) [13:29] and it's not statically build you need all the needed libs as i386 too [13:30] usually by dumping them in /usr/lib32 [13:31] Ah right, thanks. But it conflicts with another package, so I guess I'll wait until someone packages it :P [13:50] directhex, :) [13:50] directhex, still need a testbuild? [13:51] DktrKranz, please. and if it works, you could ack https://edge.launchpad.net/bugs/339808 ! [13:51] Ubuntu bug 339808 in boo "Please sync boo 0.8.1.2865-3 (universe) from Debian unstable (main)." [Undecided,New] [13:52] directhex, I'll fire up my company's server, just some minutes :) [13:52] directhex, it's i386 [13:52] what does this line mean in a diff? [13:52] ! import_all(tesseract) [13:52] Error: I am only a bot, please don't think I'm intelligent :) [13:53] i386? yay, retro! [13:53] intel xeon dual core [13:53] but still i386 [13:53] hmmm is it already possible to use PPA for Jaunty? [13:53] pmjdebruijn, of course! [13:54] 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] pmjdebruijn: changelog [13:54] sweet [13:56] I recently got a mail telling my that I was reaching my PPA's 1GB limit [13:56] but, I can see why... archived packages? [13:57] 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] directhex: http://paste.ubuntu.com/131065/plain/ [14:02] 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] 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] directhex, I haven't it in my list [14:05] apt-get update just two hours ago [14:06] directhex: Ouh, lemme run an upgrade again. [14:06] so if boo gets synced, then the mono transition is over. fini. kaput. [14:07] c_korn, I'll probably have a look at sivp later, unless mok0 is already on it [14:07] It takes much more time to unpack and replace than download packages. [14:07] directhex, what about the remaining packages? Are they going to disappear? [14:08] 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] directhex, so they can be moved to universe? [14:09] (if not already) [14:09] DktrKranz, some, not all, can be (check reverse-build-depends) [14:10] corlib, cairo, and system will resist [14:10] well, if we can move some out of seeds and save some disk space, I think some people could be happy :) [14:15] 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] also check rdepends [14:16] in theory only the ones depended on by mono-devel are needed anymore, i think [14:16] but double-check to be sure [14:16] are the all belonging to mono source package? [14:17] yes [14:17] * DktrKranz looks [14:18] directhex, some of them belong to xsp [14:19] apt-cache rdepends libmono-corlib1.0-cil | xargs apt-cache showsrc | grep Package | sort -du [14:24] "Rejected: Could not find person ''" [14:24] I got that in an email from PPA [14:24] directhex, btw build successful, I'm going to ACK that bug [14:24] what could be wrong... [14:25] these are packages for Jaunty... not Intrepid [14:25] pmjdebruijn, is Maintainer field correctly formatted? [14:26] I think so? [14:26] It's not different from when I built for Intrepid? [14:26] have new check/policies been introduced? [14:26] I don't think so [14:27] also check if changelog timestamp entry is ok [14:27] it's `date -R` [14:29] DktrKranz: ok. I did not see mok0 online here for some time. don't know if he is on it [14:30] pmjdebruijn, check the name and email after -- [14:30] c_korn, I'll have a look then [14:30] ok [14:30] btw, it's not necessary using REVU for merges or package updates [14:31] so the debdiff would have been enough? [14:33] 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] DktrKranz: yep, that's okay [14:33] c_korn, I'm looking at your debdiff in the bug report, you removed .svn directory, isn't it? [14:33] yes [14:34] pmjdebruijn, did you adjusted your dput.cf file? [14:34] *adjust [14:34] the login? [14:35] yes [14:35] errr... [14:35] * pmjdebruijn doesn't remember changed that last time... but I'm semi-senile... so that doesn't mean anything [14:35] incoming [14:35] incoming = ~%(ppa)s/ppa/ubuntu [14:35] that's the default [14:35] DktrKranz: yep, that's okayincoming = ~%(ppa)s/ubuntu [14:36] sorry [14:36] you should replace %(ppa)s with your LP id [14:36] 'incoming = ~pmjdebruijn/ubuntu' should be okay then? [14:37] 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] pmjdebruijn, incoming = ~pmjdebruijn/ppa/ubuntu [14:38] DktrKranz: my stock dput.cf doesn't include /ppa/ [14:39] 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] ok [14:41] now I have a file conflict [14:41] a downstream tarball has changed [14:41] aren't packages for intrepid and jaunty seperated? [14:42] I need the new tarball, but I don't want to break my Intrepid package [14:43] I understand that you can do 'dput ppa:pmjdebruijn' rather than having to edit the default file [14:43] if you have the same .orig.tar.gz name but with different md5 sums, it will get rejected [14:43] or 'dput ppa:pmjdebruijn/ppa' if you have it in the form pmjdebruijn quoted [14:43] cjwatson: right [14:43] http://blog.launchpad.net/ppa/http://blog.launchpad.net/ppa/ [14:43] oops [14:43] http://blog.launchpad.net/ppa/simplifying-dputcf-for-multiple-ppas [14:43] I already edited the file, and it's fine now [14:44] my problem now is a tarball conflict with an older package [14:44] which I do _not_ want to break [14:44] 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] if the tarball has changed but has the same version number, then you must artificially rename it [14:44] DktrKranz: I am in contact with Sylvestre. will notify him. [14:44] directhex, cool then [14:44] cjwatson: like? [14:44] you cannot have two objects with the same file name but different contents in the same archive [14:44] pmjdebruijn: up to you [14:45] cjwatson: "the same archive" is intrepid and jaunty stuff mixed then? [14:45] yes. [14:45] ugh [14:45] pmjdebruijn, foo_0.1+repack.orig.tar.gz could go [14:45] there's a single pool [14:45] hmmm [14:45] which will then mean that your package is versioned 0.1+repack-0ubuntu1 or whatever [14:45] oh well, too bad for folks still on Intrepid then [14:45] why *not* rename it? [14:45] it's the right thing to do [14:46] is it? [14:46] the root question here is, why do you WANT different orig with the same version? [14:47] * cjwatson -> out [14:48] nhandler, bug 266919, is it managed using Rosetta? I can't find it in package list. [14:48] Launchpad bug 266919 in knoda "knoda italian translation" [Undecided,Invalid] https://launchpad.net/bugs/266919 [14:49] when specifying CFLAGS, is order of the flags important? [14:50] directhex: I'm going to check the differences [14:52] directhex: the base directory seems to be the only difference, then I'll stick with the old tarball [14:53] won't the common pool mean I can't have identical debian versions in different dists as well? [14:54] cd .. [14:55] pmjdebruijn, you can have identical upstream versions, but you have to use a different version for each release [14:56] seems rather nasty [14:56] 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] package contents do not change, only version is mangled [15:03] siretart, ping [15:07] c_korn, are bug 340520 and bug 329399 addressed with your upload? [15:07] Launchpad bug 340520 in sivp "package sivp 0.4.3-4 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [Medium,Confirmed] https://launchpad.net/bugs/340520 [15:07] Launchpad bug 329399 in sivp "Problem uninstalling sivp" [Undecided,New] https://launchpad.net/bugs/329399 [15:09] 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] I tried updating sivp-4.x to sivp-5.x and removing [15:09] everything works [15:09] so, it's fixed by new upstream? [15:12] c_korn, --^ [15:13] 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] ok, I'll mangle your changelog entry to reflect it [15:33] what is the way to figure out differences between two versions of same library? [15:37] if a motu want to review my package, it's waiting at http://revu.ubuntuwire.com/details.py?package=sqliteman [15:37] sladen, dpkg-gensymbols works for you? [15:38] slytherin, dpkg-gensymbols works for you? [15:39] lidaobing: does it work as standalone tool? [15:39] slytherin, no, but you can use objdump [15:45] directhex: pong [15:45] c_korn, done [15:47] DktrKranz: thanks, I currently see it building. looks fine [15:52] siretart, any guesses why i'd see cd /tm [15:52] gah [15:53] lidaobing: I am using that but not able to figure out the differences. [15:54] 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] directhex: well, see http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/strip.sh;hb=HEAD [15:59] 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] directhex: that sed command is removing the h263 encoder, which is required for ffmpeg-debian in main [16:00] c_korn: Is sivp in New or waiting to be uploaded? [16:01] ehm, it is currently building: https://launchpad.net/ubuntu/jaunty/+source/sivp/0.5.0-1ubuntu1 [16:01] siretart, damn, that's it, i was switching debian/control to build unstripped but hadn't realised orig differed [16:05] eh... now I have a bigger issue [16:05] 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] I can't use either [16:06] without renaming [16:06] so I can't use the proper tarball, because I used a bad one in the past [16:07] 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] 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] siretart, there aren't any conflicts that would prevent me from installing it alongside lavc51 in intrepid are there? [16:22] directhex: there are. the new libavutil has a Breaks: libavcodec51. On purpose :( [16:23] directhex: see also my PPA. I have backported most packages in intrepid for the new ffmpeg [16:24] 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] siretart, probably best to wait until jaunty, i fear. i can make do for now [16:29] directhex: or you could help me backporting the rest of the packages, and have then in the motumedia ppa [16:29] s/have/maintain/ [16:30] 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] hm, does this build hang? https://launchpad.net/+builds/crested/+index [16:41] others only needed 10minutes [16:44] any autotools experts here? [16:48] 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] When trying to make a building chroot, I get W: BAD signature from "Debian Archive Automatic Signing Key (4.0/etch) " ... any iedas? [19:44] hi fols [19:44] +k [19:47] Hey sistpoty. [19:47] hi iulian: [19:48] 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] DktrKranz: you gotta read it twice :) [19:49] damn [19:51] slangasek: oh, if the mail proposal finds approval, anything you'd like to add for ubuntu-relelase? (http://paste.ubuntu.com/131242/) [19:51] s/relelase/release/ [19:52] 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] haha [19:52] lol [19:52] * RainCT is happy because he got his boot time from 80 to 50 seconds :) [19:53] huh, 80 [19:53] RainCT: is that your Acer eMachines? ;-) [19:53] yeah.. 20 of those are the X trying to start several times.. [19:53] RainCT, have you hamsters instead of CPUs? [19:53] pochu: No. The eMachines one is really fast :) [19:54] Hamsters... yikes! [19:54] hah [19:54] sistpoty, what about qa.ubuntuwire.com/ftbs or http://builder.ubuntuwire.com:9998/dist/jaunty/arch/i386/failed ? [19:54] I'd go with the former. [19:54] *ftbfs [19:55] 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] DktrKranz: cool, didn't know about that link... even seems up to date [19:55] DktrKranz: thanks [19:55] (s/CPU/core, of course) [19:56] sistpoty, np, thanks for preparing it :) [19:56] jdong_: thanks for the readahead tutorial, btw :) that gave me, together with switching to ext4, 25 seconds [19:57] RainCT, I'll be satisfied when my system will boot in -3 seconds [19:57] DktrKranz: Heh. How long does it take now? [19:57] about 70 seconds [19:57] DktrKranz: that's easy - just remove all the hw. [19:57] DktrKranz: err.. and you complain about my CPU? :P [19:58] 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] Hmm, I believe my crappy lappy boots in less than 50 seconds. [19:58] * iulian should test it some day. [19:58] RainCT, in two years my PC won't be underage anymore :) [19:58] RainCT: neat :) [19:59] RainCT: another bootup hack to try is to "delay" noncritical bootup services until way after GDM [19:59] jdong: how is that done? [19:59] or just drop your rotary disks for SSD [19:59] 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] 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] (it's a hack but gets me to the login screen ~5s faster) [20:00] lol, my package FTBFS and I wasn't aware of that! [20:00] http://builder.ubuntuwire.com:9998/job/43632 [20:00] Heh [20:00] 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] bug 277648 [20:00] Launchpad bug 277648 in vm-builder "libdevmapper does not load its kernel modules upon install" [Medium,Confirmed] https://launchpad.net/bugs/277648 [20:00] DktrKranz: that happens... fauhdlc FTBFS'd on anything but i386 and amd64 even though I wrote almost every single line for it [20:01] jdong: uhm.. wheren't they discussing doing something like that in #ubuntu-devel a few days ago [20:01] 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] DktrKranz: heh... I'm still curious what edos is about :P [20:02] I love edos-debcheck [20:02] it's simply extraordinary :) [20:03] (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] DktrKranz: what exactly does edos provide? [20:04] (or edos-debcheck?) [20:05] sistpoty, it checks for package installability comparing package versions, conflicts or blocks fields [20:06] DktrKranz: then it'd be similar as in "apt-cache -i unmet" for a given arch? [20:06] mostly, but it tells you why: [20:06] envyng-qt (= 2.0.1): FAILED [20:06] The following constraints cannot be satisfied: [20:06] envyng-qt (= 2.0.1) depends on python (<< 2.6) {NOT AVAILABLE} [20:07] 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] DktrKranz: well, apt-cache -i unmet also tells you why... but only for the arch *you are running apt-get on* [20:08] ah, long time I don't use it [20:08] DktrKranz: so, it seems like a arch-independent apt-get -i unmet is a *huge* win ;) [20:08] well, edos-debcheck needs Package from mirrors, so you can run it for sparc, ppc or armel [20:08] RainCT: the Dell Mini 9 Ubuntu spin does something similar too [20:09]