=== Starting logfile irclogs/ubuntu-motu.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #ubuntu-motu === Topic for #ubuntu-motu: Ubuntu Masters of the Universe: https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | http://ubuntu.joejaxx.org/ - TOP 10 Uploaders/Packages | New Packages Freeze / Upstream Version Freeze in effect - The rest of universe is NOT frozen === Topic (#ubuntu-motu): set by Hobbsee at Sat Oct 6 08:27:58 2007 [05:10] (slangasek/#ubuntu-motu) hmm, scratch that, it is installed [05:12] Do the language catalogs translate "Password:" as "Password:" for PAM, perhaps? [05:12] no [05:13] $ su [05:13] Contrasea: [05:13] gksudo still works, so maybe it's setting the locale somewhere first, dunno [05:16] hrm you would think there would be an api or message passing specificly for something like this, scrapping dosent seem "proper" [05:16] there is an API. [05:16] psh [05:16] its called pam === Konam [n=Konam@61stb68.codetel.net.do] has joined #ubuntu-motu [05:16] hi [05:16] but nobody wanted to work with that when just frontending sudo might work [05:17] the deluge gutsy package is bad, it works but not properly, take a look at it [05:17] seems like a expect script hehe === Knightlust [n=dax@ubuntu/member/knightlust] has joined #ubuntu-motu [05:17] Konam: Anything specific? [05:17] Konam: If you want someone to actually care, you are going to have to provide specifics. [05:17] Konam: Bonus marks for LP bugs. [05:18] mega-bonus-points for actually doing the work. [05:18] +1 [05:19] - === RAOF should move the enter key somewhere less accidentally hittable. [05:20] RAOF: Like off the keyboard entirely? :-P [05:20] StevenK: can't do that, that's where capslock is slatd to go! === RAOF finds the "enter is an additional control key" option === persia points at gizmod as an amusing way to swap capslock & enter with the mouse scroll wheel, saving heaps of accidental clicks. [05:23] Konam: Of course, the very best way to ensure that no-one does anything about a problem is to pop up, make vague statements about brokenness, then disappear. === avoine [n=avoine@modemcable003.251-59-74.mc.videotron.ca] has left #ubuntu-motu [] [05:26] RAOF i'm in the deluge channel to see if it is bug or something [05:26] but thanks for your interest [05:27] Am I correct in thinking my pbuild env. needs all dependencies satisfied prior to building, or will pbuild try and satisfy those from repos? === greeneggsnospam [n=JSG@ubuntu/member/jsgotangco] has joined #ubuntu-motu [05:30] it will try to satisfy those [05:30] as it bulds === nuu [n=neuro@2001:5c0:8fff:fffe:0:0:0:1893] has joined #ubuntu-motu [05:30] more spam! === Hobbsee pokes greeneggsnospam [05:30] spam? [05:30] if it cant, to clarify, do I just install them to my system, or is there some way I need to isntall them into the pbuild chroot env? [05:31] no [05:31] the whole point is to make sure it builds anywhere [05:32] so if you've gone and created the base, with universe enabled [05:32] you'll need to figure out where the bug is =/ [05:32] Konam: That's OK, thanks. [05:33] macd: You'll want to remove the depens on libmocha before you try to build it. It's not in Ubuntu and not really needed. === ScottK was paying attention earlier in the day. [05:33] ScottK, yeah the 1.2.4 orig.dsc doesnt have libmocha as a dep [05:33] soren, Im a bit confused as to why the debian package has it [05:33] eww so* [05:34] heh === tonyyarusso [n=anthony@ubuntu/member/tonyyarusso] has joined #ubuntu-motu [05:35] macd: It's needed for some test stuff, but doesn't actually hurt anything if not present. [05:36] macd: it does have it, in debian/control [05:36] as ScottK says, testing only === ScottK knows nothing about it however. My sole contributions were to work on a project with a guy who uses rails and to sucker him in here to help figure it out. [05:39] heh === ScottK is not kidding. [05:40] then you've had more experience with it than I have [05:41] It wasn't actually hard as he's using Feisty for development and will upgrade to Gutsy shortly, so it was in his self interest for us not to mess it up. [05:41] if a package is in universe and meets the version requirements and pbuilder cant find it, uhh what then? [05:42] macd: Can it find any Universe packages? [05:44] I'm not exactly sure how to check that, It found debhelper and dpatch but those are in main [05:44] macd: What instructions did you use to set up your pbuilder? [05:44] https://wiki.ubuntu.com/PbuilderHowto and Im on feisty. [05:45] IIRC that doesn't include enabling Universe. [05:46] that explains alot then ;) === No1Viking [n=No1Vikin@83.140.104.41.dyn.rp80.se] has joined #ubuntu-motu [05:46] imbrandon or ajmitch: I really need to concentrate on not messing up the code I'm writing as I'm about to do a release. Would one of you please help macd enable universe on his pbuilder... [05:46] Anyone else for that matter... [05:46] Could someone with experience understanding crash reports take a look at https://bugs.edge.launchpad.net/ubuntu/+source/kompozer/+bug/148576 please? [05:46] Launchpad bug 148576 in kompozer "kompozer-bin crashed with SIGSEGV" [Medium,New] [05:46] ty [05:47] macd: the part about enabling universe is actually on that wiki page [05:47] the .pbuildrc I just saw that [05:47] sure one sec lemme grab a drink, the short of it , do `sudo pbuilder login --save-after-login` [05:47] err yea what ajmitch said === ajmitch never has a normal pbuilder setup [05:48] tonyyarusso: I'd add to that request and knows something about why stuff dies on 64bit archs. [05:48] ScottK: good point === Jaearess [n=Jaearess@208-78-99-101.slicehost.net] has joined #ubuntu-motu [05:52] RAOF: If you're around, would you be willing to try reproducing that bug? [05:53] tonyyarusso: Ok, but it'd need to wait for the evening. [05:53] RAOF: That's still infinitly sooner than I'll have a clue what to do about it. [05:53] bbiab [05:53] I'm looking at the backtrace, and it's... urgh. [05:59] Hello all. I'd like to get involved in packaging for Hardy, but I'm not sure when people can start working on packaging for a new release. Is it when the tool chain is released (Oct. 25 according to the Hardy schedule) or is it some time later? [05:59] tonyyarusso: Do you have the hardware & can you reproduce? [06:00] Jaearess: as soon as you feel like it, especially for new packages === buzztracker [n=buzztrac@pelikan.garga.net] has joined #ubuntu-motu [06:00] nothing can be uploaded to the archive until the toolchain is inplace & settled [06:01] persia: I only have 32-bit running feisty, so probably not the best environment to test. [06:01] but that doesn't stop people from preparing things to be uploaded [06:01] ajmitch: Ah, I see. Thank you :) [06:01] Jaearess: what did you have in mind that you would be doing? === Hobbsee tickes ajmitch [06:01] tonyyarusso: Ah. OK. Briefly it looks like there's an issue discovering the current context for the spellchecker, but without a test environment it's hard to be sure. [06:03] persia: as in figuring out whether aspell is present and if so where? [06:03] Jaearess: if you haven't any experience with packaging, there's an intro to packaging that walks you through a hello world. that's probably the best place to start. you can probably have that down by the time hardy's open [06:03] pwnguin: I'm not really sure at the moment. I was thinking of packaging somethings that people had reported on Launchpad as needing packaging and just whatever else I could do to help. I just know I want to give something back to Ubuntu :) [06:03] tonyyarusso: Take a look at the StatketraceSource.txt. I think the problem is either related to the call in #3 or the call in #7. === anon [n=anon@61-230-83-227.dynamic.hinet.net] has joined #ubuntu-motu [06:04] tonyyarusso: Specifically, I think that mozRealTimeSpell, when enabled, is unable to do it's thing because it's not been told where to paint. [06:04] s/it's/its/ [06:04] tonyyarusso: Just based on the topic, I wonder if Kompozer is doing something like Gramps was: https://bugs.edge.launchpad.net/ubuntu/+source/gramps/+bug/120569 [06:04] Launchpad bug 120569 in gramps "[gutsy] gtkspell segfaults when trying to set the language on gtk.TextView" [Medium,Fix released] [06:04] pwnguin: Yeah, I've been looking through some of the stuff on the wiki; I just need to actually go through and work on getting packaging figured out. [06:04] Jaearess: in that case, how about taking notes while you walk through packaging-guide? [06:05] Or reading what persia just said, nevermind I think. [06:05] !info packaging-guide [06:05] packaging-guide: The Ubuntu Packaging Guide. In component main, is optional. Version 7.04.4 (feisty), package size 100 kB, installed size 612 kB [06:05] ScottK: No, that's the annoying API change in GTK memory management :) [06:05] I know it's out of date, and it would greatly help if someone pointed out the changed needed [06:05] persia: OK. [06:05] pwnguin: Okay, I think I'll give that a try. [06:05] pwnguin: what's out of date? [06:06] persia: Anything that starts with G, I hardly know about. [06:06] last i looked, i think hello world isn't up to date [06:06] and i know upstream has a new version [06:06] of hello-world [06:06] ScottK: heh. Most of them are similar to thinks beginning with K or Q, except targeting a different API. [06:06] pwnguin: it shouldn't be that bad [06:06] LaserJock: well, the less barriers the better :) [06:07] Right. I like server stuff. Little/no annoying user interface stuff to deal with. [06:07] ScottK: amen to that [06:07] pwnguin: so you're volunteering to fix it then? :-) [06:07] 'sides, if we get new people to file bugs against the packaging documentation and submit diffs, the better! [06:08] Personally, I like GUI and Audio bugs: they tend to be easier to fix, as the code hasn't been reviewed by as many people. Mind you, deep GTK or QT bugs are frustrating. [06:09] LaserJock: hey, no fair defending your work and then asking someone else to fix it :P === persia thought that was one of the benefits of open source [06:10] pwnguin: that's how free software works :) [06:10] pwnguin: it's not my work, it's the communities work ;-) [06:10] is anybody here in the Desktop Team? [06:11] I need to find a project to work on that actual has bugs [06:12] kde exists. [06:12] the one I'm working on now doesn't have much for bugs so it's not as interesting from a "let's learn how to use the tools" perspective === pwnguin nominates gksudo [06:12] yay, it built, installed and my rails app didnt break with it. [06:12] fixing bugs isnt exactly "learning to use the tools" [06:12] LaserJock: "project" meaning what? [06:12] at some point it becomes "applying judgement and wisdom" [06:12] Hobbsee: does Kubuntu have a "Desktop Team"? [06:13] LaserJock: Aren't there still a fair number of outstanding MOTU Science bugs? [06:13] LaserJock: "Riddell" [06:13] LaserJock: kubuntu-members [06:13] so, somewhat [06:13] LaserJock: kubuntu-members [06:13] does kubuntu need a NOT desktop team? [06:14] kubuntu-kernel ;) [06:14] heh [06:14] pwnguin: Kubuntu differs from Ubuntu primarily due to the desktop, so in a sense, the Kubuntu team is a desktop team. [06:14] persia: that is the essence of my point, i think [06:14] pwnguin: Right. Sorry. My slow typing combined with your separated statement. Apologies. [06:15] hmm, it's just always bugged me that the Ubuntu Desktop Team is really the Ubuntu Gnome Desktop Team [06:16] persia: I'm looking for upstream projects [06:16] LaserJock: the names get more screwy, and now that actually refers to a subset of canonical developers [06:16] or something. [06:16] i have a list of all the teams now, somewhere [06:16] LaserJock: get me phred and phrap from upstream into ubuntu :P === jsgotangco [n=JSG@ubuntu/member/jsgotangco] has joined #ubuntu-motu [06:18] Hmm, we don't have autopackage stuff ? [06:18] huh? [06:18] autopackage? [06:18] why would ubuntu have it? [06:19] Sorry, trying to build a new game and he is using it :-( [06:19] apg++ [06:20] we have 0install, why not autopackage? :-) [06:20] LaserJock: limiting crack. [06:20] too late ;-) [06:20] That reminds me. I need to make checkinstall SEGV [06:20] autopackage appears to automatically download random libraries from the internet. That can't be ideal. [06:21] Aye though apparently this apg++ think somehow makes linking easier [06:22] Easier than what? [06:22] Dunno I didn't even know WTF it was until I just googled it :-) [06:22] bddebian: It does make it easier, for a developer, or someone with a dedicated need. It reminds me of why I prefer to avoid python packages (EZinstall) [06:23] StevenK: Easier than having the user hunt down the right libraries and install them, or waiting for the distro maintainers to package the software in the first place. [06:23] persia: Just patch the ezinstall stuff out. [06:23] persia: Ah yes, along with the fun "autopackage appears to automatically download random libraries from the internet." [06:24] ScottK: Right. For C, I don't have to worry about that: if upstream is whiny about package dependencies, they provide the source of the libraries, so I can check if there are useful patches to extract. [06:24] StevenK: Indeed. Context is suprisingly useful :) [06:24] Right. Well right thinking Python developers don't use ez_install. === radamantis [n=radamant@201.137.25.241] has joined #ubuntu-motu === persia thinks right-thinking developers also shouldn't use autopackage [06:25] Sounds reasonable to me. [06:25] autopackage kinda sounds like a distro without a home === ScottK is off to bed. Good night all. [06:26] Or one that just piggybacks [06:26] Gnight ScottK [06:26] pwnguin: Sortof. It's based on the concept of there being one true linux, with various distributions just means to get a base install, on top of which one uses autopackage. [06:27] the whole thing reeks of "i hate finding rpms for fedora when I use mandrake!" [06:27] pwnguin: Exactly, except replace with linspire & MEPIS [06:27] well, I'm seeing some interest in autopackage for science apps on the forums [06:27] from who? [06:27] users [06:27] users or developers? [06:28] for stuff that's not in Ubuntu [06:28] 0install seems safer than autopackage: it doesn't install as root. [06:28] I'm not sure what a good response is [06:28] my favorite line from the FAQ [06:28] # What about security? [06:28] What about it? [06:28] at some point it's unrealistic to assume we can provide *all* software [06:28] well, i'd say debian's pretty good at it === zakame [i=zakame@ubuntu/member/zakame] has joined #ubuntu-motu [06:29] pwnguin: We've more than Debian (at least at the beginning of dev cycles), but that's still not everything. === coolbhavi [n=bhavi@59.92.206.119] has joined #ubuntu-motu [06:31] Perhaps we should determine a "Ubuntu best practice" method for 3rd party preparations, and recommend it? Checkinstall is out, but having something that lets upstreams make instant (if bad) .debs for distribution might help, and may even be better for users, as the software could then be uninstalled cleanly (unlike building from source). [06:31] isn't it called dpkg? [06:31] persia: I think I agree [06:32] pwnguin: That takes a fair bit or work to learn, and is a high bar for people who primarily develop for Mac & Fedora (for example) [06:32] perhaps a dh_make2 [06:32] One more thing... doko: Please consider adding libsigc++-2.0 to your ia32-libs upload so Skype will work on AMD64. [06:32] well basicly that means make pbuilder ( and debootstrap ) distro independant, easy to install and give it a front end [06:32] persia: easy and "best practices" might not go together [06:33] hello...... Can you please resync my keyrings to the revu uploader keyring so that I can upload packages..Please.. Everything is done according to revu wiki page [06:33] well, if we had something that was at least PPA-ready [06:33] when I use dget to grab source, where does pbuilder store that? [06:33] imbrandon: That does the backend, but there's still the preparation of debian/rules, debian/copyright, and debian/control. copyright is easy to do sufficiently (if poorly) from a form. control is similar, although perhaps it needs something to check dependencies somehow. rules is not always obvious. [06:33] I poked around in /var/cache/pbuilder but didnt see it [06:34] macd: dget doesn't build the source package automatically [06:34] macd: pbuilder doesn't store it anywhere. dget puts it in . [06:34] coolbhavi: it'll take around an hour [06:34] persia: true the gui could mix dh_make and pbuilder, kinda like installshield builder does [06:35] checkinstall makes you specify your own vesrion # though, so may actually be safer [06:35] as in, easier ot reject teh bugs. [06:35] imbrandon: That sounds reasonable. I'm still not sure about rules: there are so many exception cases. [06:35] persia, so If I need to make a change to debian/control I'll need to untar it, change it and retar it up? Im just a bit confused on a few things [06:36] persia: yea nothing is gonna subsitute good old packing , but to make a "something for upstream to get by with" thing [06:36] macd: just grab the source, unpack it, and debuild it back up [06:36] My launchpad id is https://launchpad.net/~bhavi.. please....... [06:36] Hobbsee: Yes, although checkinstall has other failings. Perhaps just fixing checkinstall to be acceptable is a solution. === Hobbsee liked it when it segfaulting. [06:36] macd: Use `dpkg-source -x fo.dsc` to unpack, and `debuild -S` to pack. [06:37] if checkinstall has some dependancy checking would be nice [06:37] imbrandon: Exactly. Even better, something that was pluggable, so that with sufficient chroots it could produce .deb, .rpm, .tgz, etc. [06:38] definately [06:38] sonds like a good project [06:38] (for extra points, produce .dsc/diff.gz, .srpm, etc.) [06:38] this would of course require defining equivilent packages across dkg and rp [06:38] m [06:39] pwnguin: No: it just means having a pluggable dependency analysis checker: check what gets dlopen'd, check the parent package, and assign a dependency. [06:39] hrm lots of reflection [06:39] yup [06:39] all done in the chroot [06:39] The problem I see is getting the initial set of build-deps to contruct. Iterative, or source-inspection? [06:40] thats what i meant [06:40] well if it builds and runs on the host ...... hrm [06:40] how do you define build-deps across debian / redhat? [06:41] imbrandon: That does it: build it locally, determine deps from the local build, and then pass to chroots. Clean, and only requires +1 builds. [06:41] pwnguin: Watch the local build, and determine which files are used. In the chroots, determine which package provides that file. Add those packages as build-dependecies. [06:42] yea, would require lots of work but i think its a great idea === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-motu [06:43] and would be WELL worth the effort, even if a package needed some manual tweaking to go into a repo its still does the major stuff in a point-n-clicky way accross distros, hell gentoo has debootstrap and iirc so does suse 10.x [06:44] i'm sure there are ways to get base suse / fedora / mandrake chroots [06:44] well, just getting a .deb solution would be great, IMO [06:44] what exactly does this solve? [06:44] That would go a great way towards reducing checkinstall / 0install / autopackage / ezinstall / etc., as developers could easily produce distro-tailored binary packages, and source packages in all desired formats to ease distro adoption. [06:44] i dont think it would apply to meta distros like freebsd ports or gentoo though [06:45] LaserJock: The problem with a .deb only solution is that it's not much better than checkinstall, but building the .deb / .dsc target seems a good first goal: with other distros perhaps adding their components if desired. [06:45] if i'm a developer for say suse, and i want an easy way to deb [06:45] no, I didn't mean .deb only [06:46] how does the chroot work? [06:46] I meant not worrying about .rpms, etc. [06:46] pwnguin: you know how bsd jails work ? [06:46] pwnguin: Unpack the tarball, chroot into the minimal ubuntu, pbuild. [06:46] ah. [06:46] LaserJock: I think it's worth worrying about sufficient abstraction to easily allow RPMs later, but I'd agree for a first pass. [06:47] so we're talking everyone carries an debian / ubuntu minimal build env [06:47] pwnguin: The tool would presumably have minimal tarballs for all desired target environments. [06:47] no only upstream packagers that wish to use this tool [06:47] I thought everything was going to be in some VCS so we are all saved anyway? :-) [06:47] bddebian: How does that help for things we haven't packaged? [06:47] but how does the unpacker know which extra packages i need to install? [06:48] Dunno but it's some kind of cure-all I hear ;-P [06:48] pwnguin: from the local build that the upstream developer surely already has going [06:48] pwnguin: It doesn't. The sbuild or pbuilder process downloads the build-deps as required for the minimal chroot build. [06:49] so step one build locally and watch to see which files / headers are accessed [06:49] pwnguin: think of this as more of a MOTU-in-a-box for upstreams to use *instead* of them only providing a tar.gz for users to resort to checkinstall [06:49] step two build a .dsc etc and pbuild a deb [06:49] pwnguin: I'd say 1) local build, 2) analysis of local build, 3) build .dsc, 4) build n .debs, but otherwise yes. [06:50] i guess the other problem is [06:50] build deps missing / version problems? [06:51] pwnguin: You mean "missing in $DISTRO", yes? [06:51] somethings will always have to be checked and most auto* stuff will check the versioning when building [06:51] if $dist is missing it [06:51] pwnguin: For missing build-deps (the dependency also isn't packaged), the build would fail (with a log). For version conflicts, the build fails, and upstream version X isn't supported for distro Y. [06:52] If upstream wants to be fancy with super-portability (e.g. parallel code paths for QT3 vs. QT4), then there is wider support. [06:53] rember too this doesnt have to be a 100000% end all, we're looking for something inbetween checkingstall and MOTUship [06:53] ( with a GUI ) [06:53] heh [06:53] why the gui? [06:53] imbrandon: Even between checkinstall and MOTU Contribution [06:54] people love point-and-clicky [06:54] they still need to grab the build deps locally anyways [06:54] pwnguin: Easier to present multi-entry dialogs (e.g. template for debian/copyright). [06:54] pwnguin: If they are a developer, they probably already have the build-deps locally installed, no? [06:55] there's also the question of automatic builds and GUIs [06:55] persia: if they're the developer, then they outta be comfortable with the command line, i'd say. but if you think it'll be easier, hats off [06:56] it would only need to be done for the initial packageing pwnguin , subsuquint builds could be done the "normal" automated way [06:56] pwnguin: Not easier. Flashier. More candy. Easier to blog with screenshots. These build mindshare, which is useful. No reason it can't have a CLI backend. [06:56] you just said it'd be easier to present multi-entry dialog [06:56] automatix for MOTU's /me ducks [06:57] well, I think helping upstreams get to us is a good thing [06:57] and helping users help upstream get to us is a good thing [06:58] imbrandon: I'd disagree. It's doesn't try to do all the stuff you'd do if you had the secret info, but rather it provides a scripted bridge for the uninterested. Wait, nevermind. You're right. === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-motu [06:58] persia: hehehe [06:59] persia: you down for making any of this happen, i'm totaly psyced about it and actualy thinking about getting some design goals etc going [06:59] LaserJock: Do you think it would be easier to market a new tool, or overhaul/replace checkinstall? Also, should we point at getdeb as a central location to advertise new unofficial packages? [07:00] persia: +1 on the getdeb === Hobbsee would be reasonably happy to say "let getdeb deal with all of that" [07:00] but then, who knows of the quality of the getdeb stuff [07:00] im' assuming we're still rejecting all their bugs [07:00] Hobbsee: getdeb still (softly) recommends checkinstall. It'd be nice to have something a little cleaner. === buzztracker [n=buzztrac@pelikan.garga.net] has joined #ubuntu-motu [07:00] persia: problem with checkinstall would be that we don't have any control over it [07:00] Hobbsee: Ubuntu rejects the bugs, but LP upstreams may accept them, depending... === pwnguin quietly adds google toolbar installers to his ppa and submits to getdeb [07:01] persia: yeah, well. but we dont care about them either :) [07:01] lol [07:01] Hobbsee: As long as you have narrow enough vision when rejecting, I shan't complain :) [07:01] heh Hobbsee you are so pesimistic sometimes , i care about ( some ) upstreams , watch the word "we" :) [07:01] hehe [07:02] imbrandon: i was thinking in terms of bugs, and stuff that we personally would be fixing. [07:02] tru tru , just spoutin [07:02] but i agree - as a wider issue, it's worth thinking about :) [07:03] ok anyhow anything s better than checkinstall as is [07:03] LaserJock: Makes sense. I'm not so concerned about control, as long as the results are useful. Checkinstall already seems to generate .deb, .rpm, and .tgz. Perhaps we can send patches to make the .debs better. [07:03] persia: well, I'm just saying, can we just go "heh, we're gonna take over checkinstall, do you mind?" [07:04] persia: yea i was thinking the same thing, or a fork just adding a step inbetween building and packing [07:04] in checkinstall [07:04] that does the dep resolution [07:04] I'd like to avoid a fork, but I think we'd get on better with checkinstall upstream if we prepared some patches for them, rather than just repeating "checkinstall makes crack". [07:05] we would still need to make use of "clean rooms" though ( chroots ) [07:05] imbrandon: Something simple like adding something for dependency generation would be awfully nice. === persia prefers incremental adjustment to replace everything rather than rewrites === macd pulls hair out [07:06] heh depends on the job but yea i agree [07:06] heh === imbrandon prods google for checkinstall's homepage [07:06] I think I'm missing something seriously fundamental, Ive got the dsc, the source, the diff.gz which mentions changes to debian/* but nothing has a debian/* dir in it? [07:06] perhaps something that runs ldd on the binaries, and then uses apt-file to find where they are coming from [07:07] macd: `dpkg-source -x *.dsc` [07:07] imbrandon: no wonder i cant access it; we cant both browse mexico's only http server :P [07:07] it would grab a majority of the dependencies at least then [07:07] LOL [07:07] superm1: i was thinking exactly that [07:07] superm1: We can't guarantee the presence of apt-file: a network solution might be cleaner, but that sort of thing. [07:07] persia, well make checkinstall depend on apt-file then [07:07] heh [07:08] macd: That's normal. The .diff.gz gets applied to the .tar.gz, and generates the debian/ directory. [07:08] there can't be that many header files [07:08] or at least recommend it [07:08] just build a DB [07:08] a light upstairs just went off, thanks [07:08] and then if it doesn't detect its presence, then a network solution to query packages.ubuntu.com could go too [07:08] superm1: Think cross-distro. It'd be nice to get something better for checkinstall in Ubuntu, but if we can patch it so upstream can send it to everyone, we get better random crack out there. [07:09] indeed. your right it is always better to think on a more distro global scale with things like this [07:09] pwnguin: There's a potentially infinite number of header files: consider all the libraries that could ever be written, in all the programming languages that have been invented. [07:09] good news [07:09] nobody uses random infinite libraries [07:10] the one thing this is gonna be tricky with is pythn packages [07:10] Should I leave the maintainer name alone? or change it to mine so I can sign it when done? [07:10] you sign it based on the changelog [07:10] macd: theres a script out there to fix it up motu style [07:10] imbrandon: Why python? Can't we extract a fair amount of info from either setup.py or the ezinstall wrapper? [07:10] imbrandon, well you can always parse all python source files for import lines too [07:10] and do test imports if it came down to it [07:10] hr, [07:10] imbrandon: perl'd likely also be a pita [07:10] hrm === persia likes superm1's solution [07:11] Any scripting language is annoying : import, use, source, etc. It just needs parsers. === imbrandon hugs LaserJock for getting this convo going === asantoni [n=alb@CPE00095be80fce-CM001868e2c60e.cpe.net.cable.rogers.com] has joined #ubuntu-motu [07:12] someone should get this down into a spec to work on for hardy [07:12] Gnight folks [07:12] or at least discuss at uds [07:13] superm1: yea i'm doing just that right now === pgquiles [n=pgquiles@81.202.65.108.dyn.user.ono.com] has joined #ubuntu-motu [07:13] imbrandon: Thanks. Please subscribe me to the spec when you get it up. [07:13] k [07:13] me too, i'll join in on this if its put up for a sprint at uds [07:13] kk === pwnguin files an ohloh request to survey checkinstall [07:14] we should discuss something on ubuntu-motu/ubuntu-devel [07:14] wow checkinstall is just a big bash script [07:15] heh [07:15] i'm just putting some things in a text file for now, i'll write a coherant spec after soem sleep tonight [07:16] imbrandon: Yep. It's not very robust either: it assumes a fair amount about the running system, which is not always true. [07:17] but just from an initial inspection i'm thinking after mabe some "basic" dep checking in checkinstall we might be better making our own tool based in part on checkinstall code/ideas and distro indep [07:17] with an optional gui [07:18] imbrandon: That sounds good. I'm in favor of a parallel path: basic fixes to checkinstall (with efforts to get upstream), and a better local tool to assist Ubuntu users who are upstream developers in producing preview debs. === ajmitch hears madness [07:19] persia: exactly [07:19] ajmitch: cover your ears. === ajmitch rocks back & forth [07:19] ajmitch: It's silent. Otherwise, adjust your bell :) [07:19] uhm [07:19] checkinstall as a way to produce 'you should do X' - maybe [07:19] hi lifeless :) [07:19] as a way to make packages.... where do you live prey tell ? [07:19] heya lifeless [07:20] hi guys, and gal [07:20] Hey lifeless [07:20] hiya lifeless! [07:20] lifeless: For context: we're thinking that patching checkinstall will result in something more useful than enabling autopackage. [07:20] lifeless: hehe we're trygin to make a MOTU-in-a-box , lots of backlog to read, its not what you think :) [07:21] Further, replacing checkinstall with some guided .dsc/.deb builder that is relatively sane will further improve the random crack found on the internet. [07:21] by dependancy checking, gracefully pulling off dh_make type things etc [07:21] and clean room building with chroots/pbuilders [07:22] to put it in 2 sentances [07:23] seriously, we cant all visit the checkinstall website at once =/ [07:24] LOL [07:24] no browser == no random distraction [07:24] you should try it sometime [07:24] All the docs, etc. are available in the package. `apt-get source checkinstall` (and don't `aptitude install checkinstall`: that's not the right command yet :)) [07:25] telnet www.asic-linux.com.mx 80 === thekorn [n=markus@a89-182-10-242.net-htp.de] has joined #ubuntu-motu === imbrandon never uses aptitude [07:25] well, im trying to find a cvs for ohloh [07:26] imbrandon: If for nothing else, you might like `aptitude download hello` and similar. [07:26] it appears there's none [07:28] unrelated: "Back around 1999, I was really interested in getting all of Debian imported into CVS (ugh!) so we could have all the benefits of pervasive version control. I've always been sad it didn't happen, especially since ubuntu did it. Although they seem to get less benefits from it than I would have thought at the time, go figure." (from joey hess's blog) [07:28] all of ubuntu is in cvs/bzr? [07:29] i read that a few days ago [07:29] and no not afaik [07:29] Perhaps every Soyuz upload actually triggers a checkin somewhere :) [07:30] well, the are planning on it [07:30] *they [07:30] no-source-packages spec from way back in dapper [07:30] LaserJock: Is it not implemented at all? I thought there was at least some stubbing done. [07:30] or something liek that [07:30] well, they've got some code for it [07:30] but it's gonna take awhile [07:31] last I heard they were gonna just do it over some time [07:31] LaserJock: Do you know if there were plans to integrate with dget / dput, or will it all be bzr co, bzr ci? [07:31] no, they are gonna to vcs imports of the packages [07:32] the first thing is to just get everything into bzr [07:33] Too bad. It'd be nice to have it automatically scrape the last changelog entry for a commit comment when using dput, but I guess that's harder to implement cleanly. I do hope there will be something for dget. [07:34] well, I did get them to make dget'able URLs for source packages [07:34] anyway, I don't know much [07:34] just I heard they're gonna try to import Debian into LP [07:35] I thought that was discussed at last UDS. It'll be interesting, although I'm really not sure how useful it will be, nor how one might manage the synchronisation. === jussi01 [n=jussi@dyn3-82-128-184-36.psoas.suomi.net] has joined #ubuntu-motu [07:36] brb [07:37] can someone have a look @ http://pastie.caboo.se/105611 Im getting a cant find sec key error (but its there) [07:38]