[00:01] Ok. That should be easy, then; just a $PACKAGENAME.install file containing "foobar.script usr/share/mythtv/mythstream/parsers" [00:01] great, got that [00:01] the file installs just fine, it's just getting it packaged and past revu thats a pain ;) [00:01] Yes. [00:02] but so far, i've complied with everything, it's just this diff problem [00:21] tgm4883_laptop: Sorry, gnome-terminal crashed. [00:22] tgm4883_laptop: What is the usr directory there for? [00:22] tgm4883_laptop: Oh, that's the problem. You've added a usr directory to the source; that's not necessary. [00:26] RAOF, I need to pull that and fix the install file don't I? [00:26] Right. [00:26] ok [00:26] I'm not sure that the diversions are a great idea, though. [00:27] and move the youtube dir back to the root dir? [00:27] why not? [00:27] I think I have to do them [00:28] You could modify the mythstream package to not install the youtube parser, but to depend/recommend it. [00:29] heh, yea, working on that too [00:29] but that i'm less familiar with, as the actual mythstream package installs that rather than something like the install file [00:30] That can be corrected in the mythstream packaging. [00:30] how so? I've been looking at it (admittedly I am not the best guy to look at that) [00:30] By deleting the youtube filter stuff after it gets installed :) [00:38] heh, well at least i'm getting different results now when trying to build the package [00:39] RAOF, now i'm getting this tar: youtube/search.pl: Cannot open: File exists when trying to build the package [00:39] and it doesn't build at atll [00:40] This are the last two lines before it crashes dpkg-source: failure: tar -xkf - gave error exit status 2 [00:40] dpkg-buildpackage: failure: dpkg-source -i.bzr -b mythstream-parser-youtube gave error exit status 29 [00:40] I really appreciate you help btw [00:47] bah, that was a typo, nm [01:41] * emgent need DD. === vorian is now known as vorian_ [02:03] Thanks again for the help RAOF, everything seems to be working now [02:04] If any MOTU has some spare time, I'd appreciate another REVU of this package http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube I've made the requested changes. === macd_ is now known as macd [02:10] Hm. It seems the recent REVU work has broken some of the database. In particular... http://revu.ubuntuwire.com/details.py?package=gtk2-engines-aurora [02:18] I'm sorry, when making the requested changes I introduced a bug. Please disregard my request for a REVU on http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube My apologies === wolfger_ is now known as wolfger [02:39] ok [02:39] http://paste.ubuntu.com/35777/ [02:39] this is the error i'm getting [02:40] the odd thing [02:40] is that using a debian chroot env to build it works fine [02:40] it should be an issue with ubuntu specific autotools/libtool [02:47] nxvl: I've not seen that error before. Which version of libtool is specified in ltmain.sh? [02:49] 1.5.24 [02:50] libtool | 2.2.4-0ubuntu3 | intrepid | source, amd64, i386 [02:50] StevenK: yep [02:50] the most odd thing [02:50] is that on debian works fine [02:50] libtool | 1.5.26-4 | unstable | source, alpha, amd64, arm, armel, hppa, hurd-i386, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc [02:51] nxvl: Enable experimental in your debian chroot. [02:51] oh [02:51] nxvl: I bet it then blows up [02:51] * nxvl creates experimental chroot [02:51] nxvl: Well, I'd recommend starting from http://people.debian.org/~keybuk/libtool-updating.html or http://people.dooz.org/~lool/debian/relibtoolize if you want to update it. Both of those are a little out of date, but likely helpfull. [02:52] i've been following http://wiki.debian.org/LibtoolUpdate [02:53] nxvl: Updating my documentation redirects, but that doesn't look much fresher. [02:53] Ok, i've fixed that bug I introduced, so if any MOTU has some spare time, I'd appreciate another REVU of this package http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube I've made the requested changes. [02:54] mm [02:55] i will check and write some documentation on the issue [02:55] there should be more packages that will have the same issue soon [02:55] nxvl: Thank you. === emma_ is now known as emma [03:58] What directories are considered "standard", and don't need to be included in .dirs files when packaging an application? [04:01] nhandler: Everything. [04:02] What do you mean RAOF ? [04:02] nhandler: In most cases you don't need a *dirs at all. It's only if you need some directories to exist that the build process doesn't create. [04:03] RAOF: So if you have a .install file that is moving some files into a directory, you don't need to include those directories in a .dirs file? [04:03] nhandler: If the build process creates those directories, no. If it doesn't, yes. [04:03] I think you will, unless your build system already creates those directories. [04:04] python, sure. If you like we are in #rapache-devel [04:04] wrong window -.-' [04:06] According to https://wiki.ubuntu.com/PackagingGuide/Basic, it says "dh_install and .install files will automatically take care of creating directories. You only need to use dh_installdirs if your package needs to ship empty nonstandard directories". That is why I was asking. [04:10] nhandler: Why not try? If the package builds and contains the files you expect, then it works :) [04:11] I suspect that it might, because I don't think that any of the packages I've touched has needed a .dirs file. [04:12] Ok, I guess I can do that. Thanks for your help RAOF [06:30] moin people [06:31] :D === superm1 is now known as superm1|away [07:00] Ok, i've fixed that bug I introduced, so if any MOTU has some spare time, I'd appreciate another REVU of this package http://revu.ubuntuwire.com/details.py?package=mythstream-parser-youtube I've made the requested changes. [07:18] good morning [07:32] morgen dholbach [07:32] hi jpds [07:33] dholbach: I did some changes to hugdaylist and get-branches and uploaded to intrepid yesterday. [07:34] jpds: nice! :) [07:34] :) [08:17] sistpoty: I never mind a query, but can't promise being around :) === POX__ is now known as POX_ [09:22] morning everyone [09:23] could some motu-sru member have a look at https://bugs.edge.launchpad.net/ubuntu/hardy/+source/pymsn/+bug/255307 ? [09:23] Launchpad bug 255307 in pymsn "Can't connect to msn accounts" [Medium,Confirmed] [09:23] hi [09:28] hm. how can i see the build log for a debian package? [09:29] directhex: packages.qa.debian.org has lots of useful links [09:39] what kind of half-baked autoconf files use "no" as your compiler if the following happens: "checking for ./../mcs... no" [09:39] directhex: The very special ones :) [09:40] bleh [09:40] okay, let's see it build now === dholbach_ is now known as dholbach [09:47] directhex: That's _awesome_. Who's autoconf is that? [09:48] RAOF, monodoc :) [09:48] !!! [09:48] righty. i post the debdiff from the latest debian package to the new ubuntu package for a merge, yes? [09:48] Ya. [09:49] directhex: As long as the Debian orig.tar.gz represents either a new version or is bit-identical to the Ubuntu orig.tar.gz [09:49] * RAOF watches #nouveau work out how to resume an nv3x card in a macbook [09:49] RAOF: That reminds me: how are the libdrm debates coming along? [09:50] persia: Dunno, really. It seems that GEM is going to to go upstream sometime soon (2.6.28 is a number that springs to mind), but I don't think that TTM has died, either. [09:51] RAOF: So the prospect of nouveau in intrepid+1 still looks dim? [09:51] Intrepid+1? I'd hope that'd fly. [09:52] Unless we lose step, 2.6.28 seems the right target. If that's GEM, and there is an expectation that all the drivers will migrate, I'm hoping nouveau will be amoung the "all". [09:52] On the other hand, until TTM either wins or dies, I'm less sure. [09:53] I think that maybe we'll end up with two managers. [09:53] I thought the kernel folk felt that was a fundamentally stupid way to do it. [09:53] TTM doesn't seem like dying; people working on slightly more sophisticaed hardware than Intel cards seem skeptical that GEM can do everything they need. [09:54] On the other hand, nouveau doesn't actually have to care; it's not blocking on a GPU memory manager. Just a libdrm release new enough. [09:54] IE: 2.4.x [09:54] Oh. I thought it was blocking on both. [09:55] No. [09:55] Cool then! I suppose the interim release (2.3.1?) wasn't sufficient? [09:55] I don't believe so. [09:56] libdrm was blocking on GEM/TTM; even if they do a GEM-only 2.4 release nouveau gains a new-enough drm to build. [09:56] Ah, I understand now. Thanks. [09:57] At least for now; it's a bit of a maintenence problem, since they don't give any API guarantees. That said, their drm API has changed only twice in the last 6 months or so from memory. Possibly only once, actually. === Czessi__ is now known as Czessi [10:45] ScottK: ping, do you have a moment to speak about julius? === RainCT is now known as RainCT_ [11:29] bobbo: you commented 'waiting for -4 so we can sync' for the prayer merge, but I don't see any bug related to this on the BTS. private email ? [11:52] ScottK: I've answered to your comment on REVU. [11:52] can i pray for syncs too? [11:53] * RainCT looks at directhex with a ???? face :P [11:54] LP:256641 [11:54] syntax failure bug #256641 [11:54] Launchpad bug 256641 in ubuntu "[sync request] webkit-sharp from Debian Unstable, version 0.2-1" [Wishlist,Confirmed] https://launchpad.net/bugs/256641 [11:56] directhex: that's already ack'd [11:56] directhex: Even with the bug reference, it doesn't make any sense. At first, I was ignoring what I thought was a reference to the merge of prayer, but now I'm also confused. What do you mean? [11:56] i mean i'm waiting on a sync. nothing more than that. [11:57] directhex: Ah, you just have to wait for an archive admin to look at it; that shouldn't take much. [12:07] hm, maybe it's a good thing i forgot to add u-u-s to a merge bug. sounds like there'll be a new version in debian later today [12:12] moin [12:39] moinmoin [13:00] can anyone please ack bug 254919? [13:00] Launchpad bug 254919 in libdvdnav "Please update to 4.1.2-3" [Undecided,New] https://launchpad.net/bugs/254919 [13:00] * RainCT looks [13:01] RainCT: are you a MOTU? [13:01] slytherin: yep [13:01] oh, I didn't know that. :-) [13:08] slytherin: You might want to look at the requestsync output for the common format for sync bugs. [13:09] ooh, i didn't know about requestsync [13:09] persia: I didn't log that but, I was going to log one when I saw an existing bug. I just subscribed u-u-s and gave reason for sync. [13:10] any motu-sru around? [13:11] slytherin: please correct the bug title & summary before subscribing u-u-s in the future [13:11] slytherin: Ah. I usually edit the description when I do that, as many people who aren't regularly in this channel aren't familiar with the specific format that reduces work for the archive admins (so we can get more syncs). [13:12] RainCT: persia: Ok. Will keep in mind. [13:16] slytherin: Ack'd. I can give-back gst-plugins-bad0.1 if you ping me once the new version has been build [13:16] RainCT:. Ok. Will keep watch. [13:20] RainCT: I'm not so great on library stuff either. I'd suggest ask sistpoty when he's around. [13:22] ScottK: Okay, thanks. [13:25] RainCT: which package? [13:26] persia: http://revu.ubuntuwire.com/details.py?package=julius [13:30] does anyone if it it possible to provide more than one package names in apt:// style link? [13:31] slytherin: yep. iirc just do apt:package1,package2 [13:31] or with ; perhaps, I'm not sure [13:32] slytherin: yes, apt:pidgin,pidgin-plugin-pack [13:32] it'd be nice to specify repos with apturl [13:32] directhex: +1 [13:32] especially useful for PPAs [13:33] apturl supports adding repositories, or at least it was on the specification [13:33] that's one thing suse has right now - "1-click" lin ks which can define a repo as well as a package [13:34] joaopinto, where's it documented? [13:34] I believe that was left unimplemented due to the stupidity of the idea. [13:34] directhex: I think the reason why this isn't enabled (the code is already there, or at least some of it) is that some people feared that it would be too easy to use evil repositories then. That doesn't make sense, IMHO, as if they want to break their system they will do anyway, and if they do it with apturl we have the chances to show a nice, big, warning [13:35] RainCT: it works with ',' but it shows one confirmation dialog per package. === nhandler_ is now known as nhandler [13:35] RainCT, have you heard sorry tales of malicious suse 1-click repos? [13:36] nope, but neither have I heard about SuSe having 1-click repos :P [13:36] And neither have I heard about anybody using SuSE. [13:36] how would it differ from the current gdebi implementation ? [13:36] directhex: and you don't need to convince me (I like the idea), convince wgrant :P [13:36] joaopinto: that you don't have to download the files yourself [13:37] Particularly given that PPAs are unsigned, it is very bad to encourage their use. [13:37] wgrant, so do it on a temporary basis. allow an apturl link to specify a repo which is only used for resolving the requested package list - but is not added permanently [13:37] RainCT, uh ? I mean from a security perspective, you always have to request for the action, regardless if you are installing from APT or from a .deb [13:38] so you get to show all the usual gpg moaning all you want. it just makes adding split packages from outside the main repo much easier [13:38] wgrant: Having apturl support them doesn't mean encourage their use. The point is that if they add them through apturl we have the chance to say "Hey, that's bad. Don't do it."; else they will just see "add ... to your sources.list" [13:38] joaopinto: in my view, it's the same [13:39] directhex: Why would you wish to do that? [13:40] directhex: How does that make it any better? [13:40] So now I both have a chance of getting a bogus repo, and not getting security updates. [13:40] wgrant, it's still better than the current approach spread far & wide over the internet involving "sudo wget" [13:41] Perhaps not. [13:41] copypaste this lengthy string to set up your system. don't worry abuot confirmation screens, our nice clever config lines take care of them for you [13:42] wgrant, such risk exists if you add the repository manually, your concerns is not on how to setup the repositories, but on the repository contents itself [13:43] We don't want a facility for websites to be able to present links like that with the only confirmation being dialogs that users will just click throough. [13:43] if someone clueless wants to add a potentially bad repository to their system, i really fail to see why a popup warning "this repo is unofficial and might screw you up" is worse than people just pasting things like "sudo wget http://somebadsite.com/sources.list.d/hardy.list -O /etc/apt/sources.list.d/badsite.list" into a terminal [13:44] On the other hand, it is nice to present links that let people install packages from the already configured repositories, for documentation, etc. [13:44] directhex: Users dislike click-through dialogs. [13:44] directhex: Users just click through them. [13:44] and <3 terminals! [13:44] Terminals seem to generally do a good job of scaring new users off. [13:45] wgrant, users dislike security concerns in general, so what's the point ? [13:45] wgrant: yes, but put a shiny warning icon there and if they don't see it it's their problem. with the current approach they will just copy-paste stuff without even knowing what it does [13:45] I don't see why we should make it easier for users to click-through potentially fatal warnings. [13:46] wgrant, actually it usualy breaks their system frequently, because users without a security conscience are those which try anything on the terminal [13:46] wgrant, eep, who's suggesting that? [13:49] * slytherin feels responsible for starting flame war on the channel. :-( [13:50] slytherin, not at all, you reminded me of a pet peeve [13:53] wgrant: surely you'd have to type your password though? That's harder to sleepwalk through than clicking on stuff. [13:53] andrew_sayers: You'd be surprised what users will do. [13:53] like run random things as root in terminals? [13:54] Lots of people complain about terminals. [13:54] So people obviously vastly prefer GUIs. [13:54] directhex: i see people run rm -rf /, when suggested. [13:55] why would they not click through warnings? [13:55] which are less scary than opening a terminal? [13:55] Hobbsee, some warning or no warning. pick one. [13:56] Terminals are scary enough to send people back to Windows. [13:56] this is a new security technique, security through scariness [13:56] why doesn't ubuntu alias rm to "rm -i" like on redhat? people can't be trusted, evidently [13:56] If you really wanted to be malicious, wouldn't you just create a shell script that called gksudo? [13:56] joaopinto: There is no other solution to stupid users. [13:57] Then tell people to double-click on the script and click/type through. [13:57] A dialog that forces you to type “I am possibly letting happen” to continue? :-) [13:57] ion_, remember glxgears -iacknowledgethstthistoolisnotabenchmark ? [13:57] wgrant, that is why stupid users have problems into getting into Linux, some people instead of educating prefers to keep stupids away [13:57] "Yes, do as I say!" [13:57] Like what apt does when you’re removing something essential [13:58] 'tis what I was quoting from. [13:58] I hope. [13:58] joaopinto: based on their frustration level at attempting to get anything done, si that such a bad thing? [13:59] clearly, you have to have some form of clue, and actually read things, to succeed. [13:59] the same thing happens in windows, or in anything else complex, that you haven't seen before. [14:00] Hobbsee, no, but I believe that stupidity is not a non treatable disease, is something that your turn into knowledge, it is not not something that you just care about keeping away [14:00] case study: bubblewrap. [14:00] Hobbsee: Indeed. [14:00] yeah....right.... [14:01] wgrant: i take it you've seen enough of the saga to be well aware... [14:01] Hobbsee: I have. [14:01] joaopinto: One can't educate clueless users immediately. You have to scare them from some things first. [14:01] joaopinto, ignorance is curable. stupidity isn't [14:01] Hobbsee, why not adding a warning on the installer "Are you stupid Y/N?" ? [14:01] joaopinto: because i don't write the installer? [14:02] directhex, users are ignorant, not stupid [14:02] It seems like the argument against modifying apturl is that we're protecting the set of users that would click through absolutely anything in a window, but would never touch a console... [14:02] joaopinto, you'd be surprised. there's a definite mix [14:02] joaopinto: i'd prefer to do it as "here's a block of text. here's a multiple choice quiz, to check that you actually can read" [14:02] or something. but that's idealism. [14:02] ... from the set of bad guys that can do anything with a shell script, but can't call a GUI from it. [14:03] how big is that demographic? [14:03] Surely the intersection of those two sets is pretty small? [14:04] Hobbsee, no, because your personal believe does get proper recognition, otherwise the installer developer would implement it, but I am sure it would not be on Ubuntu :) [14:04] * wgrant -> bed [14:04] joaopinto: or because i'm not silly enough to ask for it. [14:05] while it would be nice, it's not feasible. [14:05] Adri2000 or Lutin: The main.php page on DaD is serving up the Universe list ... [14:06] well, you could provide a terminal to them with "Please type at least 3 unix commands", that would scare them during the install phase [14:06] yes, but that would nto be my aim. [14:06] Umm. Lots of discussion on this, which is good. Tone is less ideal. [14:06] * white waves [14:06] here's the thing. [14:06] my aim would be to check fi they're actually capable of taking in information. [14:07] gdebi makes it easy to download and run a .deb [14:07] of unknown safety and origin [14:07] Given the number of bug reports we had from easyubuntu, automatix, etc., I think it's better to say that the desire it to make it difficult to install software not currently in the repositories. [14:07] Hobbsee: so when are you in melb? no more excuses ;) [14:07] How about taking such users out of sudoers and forcing them to do a root log-in to a session that can only do a limited set of jobs? [14:07] however, we're saying a procedure to make installing two debs is ZOMGBADNOOOOOOOOOOOOOOOOO! [14:07] because if they're not, then really, they should go back to windows, where they might have somehow understood it. [14:07] (Install packages, edit a few things) [14:07] white: no idea........ [14:07] ;? [14:07] ;/ [14:07] persia, so why is gdebi there? [14:08] persia, if the policy is terminal-or-repo-only, gdebi violates that [14:08] andrew_sayers: Once you are root, then there is no such thing as a limited set of jobs. [14:08] directhex: I'd prefer it weren't. [14:08] persia, add ultabreaksit to that list [14:08] ScottK: If you're smart, yes. But we're talking here about people that will run "sudo rm -rf /" if a stranger tells them to. [14:08] directhex: It's not policy, it's guidelines to reduce invalid bug reports, and yes, gdebi does violate the guideline. [14:09] andrew_sayers: ultimately, they will still find ways around, to screw stuff up. [14:09] I'm fairly well convinced that being both easy and secure is a system administration design problem that is not yet solved. [14:09] I thought the goal was to make the users aware of the risks of installing software from untrusted sources, not to block them [14:10] andrew_sayers: OTOH, they might learn, after the first time. [14:10] I'm not convinced it's solvable. [14:10] Hobbsee: what about mid-semester break or so? [14:10] white: perhaps. i'll think on it :) [14:10] :) [14:10] ScottK: still having the main/universe issue with DaD ? works just fine here [14:10] * ScottK tries again. [14:10] Hobbsee: then why bother putting such a small roadbump to stupidity as apturl when there are legitimate uses where it's quite handy? [14:11] ScottK: anyways given the number of broken merges for main, you might not want to use it [14:11] Lutin: Fine now. [14:11] Lutin: It's useful for knowing IF there's one I should look into. [14:12] andrew_sayers: because for the people who are ignorant, it's a good wake up call. those are unlikely to screw up their system. [14:12] ScottK: true :) [14:12] Thanks for the warning though. [14:13] andrew_sayers: those that do not take in any information are doomed to fail, whatever is done. [14:13] Ignorant users don't need applications features to turn their system insecure, they are insecure by nature [14:13] (which is a different category) [14:13] Hobbsee: but forcing them to log in to an alien environment that they haven't seen for X months isn't a wake-up call? [14:14] andrew_sayers: What is the use case which this solves? [14:14] Hobbsee, what is your definition for "taking any information?", how does an sources.list setup instructions improve the information quality to a dialog presenting the repository url and a warning about the risks of using it ? [14:15] persia: The use case for apturl: I'm writing an application that I plan to put into a PPA some time soonish. After that, I'd like to go to ubuntuforums.org and tell people "click here to try the app out, then tell me if it's any good". [14:16] andrew_sayers: Of course given the current DNS cache poisoning problems that's a fundamentally insecure approach since PPAs aren't even signed. [14:16] andrew_sayers you're dangerous then! [14:16] What would be a more secure approach? [14:16] the mythbuntu team will be handing out free mirror-and-sign scripts in the foyer during the interval [14:16] It doesn't matter how you install it or get it, there's no guarantee the user is getting the package you served. [14:17] andrew_sayers, you can just ask "please ALT-F2: "wget && sudo " I am sure that will be clear for them :P [14:17] ScottK: nor that the package that was uploaded to the main archive is any good, or was for anything but testing purposes. [14:17] andrew_sayers: Build your own binaries, sign them and serve them. [14:17] ain't security great? [14:17] Hobbsee: [14:17] Hobbsee: Yes. [14:17] and write a six step guide on accessing them [14:17] bonus points for subtle differences from the last 3rd party repo instructions you read [14:18] Hobbsee: I think maybe we need a script like the contentless ping script that drops a warning about unsigned repositories into the channel every time someone says PPA. [14:18] andrew_sayers: I guess. I'm not very comfortable with that being a means to get users, but that may be me. [14:18] medibuntu earns double bonus points for use of "sudo sed" [14:18] Heya gang [14:18] If im looking at a merge and looking at a debdiff and i see +- printf(buf); (new line) ++ printf("%s", buf); (what is the +- and ++ showing as opposed to just + or -)... [14:19] joaopinto: i wasn't making a point about that at all. My point was that we have users who are determined to do silly things, and that click through warnings probably aren't effective. But then, consoles don't appera to scare them either. [14:19] stefanlsd: that there's a diff in the debdiff [14:19] stefanlsd, it usually means changes are being made to a patch in debian/patches/ [14:19] ScottK: well, they do plan to sign them eventually. I personally think that's more dangerous. [14:19] directhex: thanks for the bonus points [14:20] Hobbsee: In a different way. [14:20] ScottK: well, people don't even think about it - all it says is "this comes from launchpad" [14:20] but i don't currently see a way around that. [14:20] Lutin, and you increase the score further by having over 1000 words in the repo howto [14:21] directhex: woot [14:21] i wonder if the solution is to implement complete rollbacks. [14:21] Hobbsee: Yes. I agree that's a problem. Personally I think that PPA and such mark the eventual doom of the official repository. [14:21] ScottK: that, adn other reasons. [14:21] Lutin, disappointing use of a keyring package instead of wget and apt-key though :( [14:21] but i think other reasons will be the predominant factors. [14:23] Random idea - how about wrapping apturl in a questionnaire when it tries to install from random sources? [14:23] "Why did you install this [for fun, to solve a problem, other]? How much do you expect it to crash [1..5]?" [14:24] Then a similar questionnaire on exit. [14:24] lol [14:24] That would give great feedback for the legitimate use case of developing packages, would scare users and be non-ignorable, and would make life harder for bad guys. [14:25] directhex, ScottK - thanks. I see that there is a patch in the debian/patches directory which i guess explains the ++ and +-. Am I right in saying that debuild doesnt apply the patches... [14:25] andrew_sayers, you could implement it by allowing your repo to define a script to run as root when the repo is added! [14:25] andrew_sayers, your script could call a gui-drawing script tool, like lots i forgot the names of! [14:25] directhex: why disappointing ? [14:25] "pop all this bubblewrap, and think about what you're about to do. it could break your system" [14:26] "you can't install this until you finish" [14:26] Lutin, too user friendly [14:26] directhex: ahah. good one [14:26] directhex: I know you're being silly, but you'd have a set of standard scary questions, and a text file defining optional extra useful questions. [14:26] Lutin, ooh, how about making people do apt-key -add standard == for all packages, hardcoded in apturl. [14:26] directhex: and btw, we (as in, the medibuntu team) didn't write that documentation. we're merely updating the URLs [14:27] Lutin, i'm not trying to mock you guys, i'm just using it as an example. it's probabnly one of the most popular third party repos on the interwebs [14:27] Lutin, how many hits do you get on packages.gz a month? [14:28] directhex: I don't even know. lots [14:28] Laney: I've made some changes to pull-lp-source in ubuntu-dev-tools trunk. [14:31] i wonder what discussions the suse people had over ymp. === zookoaway is now known as zooko [14:34] anyone having powerpc machine access right now? I need confirmation on some observation related to java on intrepid. [14:35] hi folks [14:35] hey sistpoty|work [14:35] hi Hobbsee [14:36] slytherin: I'd suggest asking TheMuso. [14:37] <\sh> directhex: they can use "signed rpm packages" so when I trust one dev who signed his/her packages, I can be sure that this package is no malware.... [14:37] ScottK: I dropped a message on #ubuntu-powerpc but no one responded. [14:37] <\sh> directhex: but regarding the repos , they are lost, too [14:38] <\sh> directhex: hint on binary packages [14:40] \sh, i just find it dumb that you can pick four popular third party repos, and find four different instructions for enablement [14:40] Does anybody know if there are any plans make deb package for dbus-c++? [14:40] Could someone from the mentoring team please respond to https://lists.ubuntu.com/archives/motu-council/2008-August/001369.html (in the appropriate forum) [14:41] the irony being that the most "user-friendly" method is opening a terminal & blindly copypasting things into it, entering a sudo password when prompted [14:41] slayton: Is there a needs-packaging bug? If not, you might search for a Debian ITP. If neither exists, the chances are very low that someone is working on it. [14:43] Is it worth sticking a few installation-related ideas up on brainstorm and seeing what the crowd makes of them? [14:43] * soren would also be hesitant to consider the existence of an ITP much of a suggestion that someone is working on said package [14:43] andrew_sayers: It's certainly more likely to generate a useful discussion than an IRC log. [14:44] soren: An ITP is explicitly a statement that someone *is* working on a package. This is how it differs from an RFP. [14:44] persia: I'd dispute "discussion", but "evidence", certainly :) [14:44] persia: I've lost count of the times I've wanted a package of some software, found that it wasn't in Debian, and then went on to find a several year old ITP about it. [14:44] persia: depends on how old the ITP is [14:45] soren: however, they are getting expired semi-automatically these days [14:45] persia: It doesn' imply that someons is working on it. It implies that at some point, someone *intended* to work on it. [14:45] but yeah, I'm sometimes annoyed by this [14:45] soren: The owner of the ITP should be pinged, and if not responsive, it ought be retitiled to an RFP. Anyway, for many of those I've found an ignored package on mentors.debian.net to go with the old ITP. [14:45] <\sh> directhex: well, how could someone solve those issues, without distributing everything....people without a clue should not deal with those things...but this is a dream [14:45] In fact, I'll bet that in more than a few cases, those stale ITP's have caused people to NOT package stuff, because apparantly someone else is working on it (only they're not). [14:46] persia: That's a reasonable point. [14:46] persia: I've, in fact, myself had a package in that state. [14:46] soren: Well, sure, but that's because not enough people triage wnpp, rather than being part of the definition of an ITP. [14:46] persia: this /is/ happening [14:46] azeem: Which is happening? [14:47] retitling to RFP or closing of ITP bugs after a timeout [14:47] soren: I'd hope by now you had the appropriate levers to get out of that state. [14:47] some people just reopen them, though [14:47] persia: If you look at it from the perspective of a new developer who comes along and thinks, "hmm, Debian doesn't have this package, apparantly. I'll be a good boy and package it.. ... Oh, someone is already working on it. I'll play some more WoW instead of working on Debian." [14:47] azeem: Yep. There are many people with persistent intentions. I will very likely someday be the maintainer of uqm. This may not happen until after lenny+1 ships. [14:47] soren, been there done that [14:48] persia: Exactly that happened to me. [14:48] persia: WEll, without the WoW stuff. [14:48] persia: I was more of a Tetris kind of kid. [14:48] soren: You didn't even bother to contact the person working on it? [14:48] persia: Nope. [14:48] persia: Who was I to question their work? [14:48] (or lack thereof) [14:49] soren: Hrm. You've improved with time, but still, communication is good. [14:49] persia: This was many, many moons ago. [14:49] \sh, as andrew_sayers pointed out, i think the number of people who will blindly click through things ignoring the consequences, but who won't open a terminal & paste things in ignoring the consequences, is small [14:49] * persia had issues with Debian back in woody/sarge days that cause Ubuntu to be the primary focus of development, but doesn't understand not communicating if you want something done. [14:49] persia: /me guesses ~10 years. [14:50] universal saying of the day: you just have to get the right blocks into the right slots :) === superm1|away is now known as superm1 [14:50] That's what she said. [14:50] sistpoty|work, not if you have a hammer [14:50] sistpoty|work: Indeed. [14:50] directhex: heh [14:50] soren: You were a Hamm user? [14:51] persia: Bo. [14:51] <\sh> directhex: well, people are more likely to click through a UI wizard, but regarding my experiences with "start term, copy&paste this" it works very well and easy even for non - knowledged people... [14:51] * persia is impressed [14:52] soren: I was just lucky that the only guy packaging stuff in my field (chemistry) soon left Debian after I got interested [14:52] persia: And unfortunately, I never made the step from user to developer and I largely blame stale ITP's. I think I must have gone through the "hmm.. I'll try packaging this.. Oh, someone's already doing it" cycle at least 10 times. [14:53] When i finally found something that noone had packaged, and I did it, I never was able to find a sponsor, but that's a different argument altogether. [14:53] \sh, as soon as you give instructions to people involving a terminal, you've lost the "linux isn't hard & nerdy" argument. the sad thing is, for most people, it's simply incomprehensible voodoo - and either you end up scaring them away from gettring things done, or teach them pasting random lines from the internet is safe [14:54] soren: Ah. I've never been a fan of new packaging. My largest contribution to Debian pre-Ubuntu was trying to get packages that hadn't updated in testing since potato pushed back to sid for sarge (which is now fairly standard practice) [14:54] Which gets back to my point that both secure and easy is a sysadmin problem that is not solved. [14:54] directhex: ^^ [14:55] <\sh> directhex: not if they have to just consume...really...people will eat, sorry to say, shit to get things done... [14:55] \sh, if they're going to fuck up anyway, why not make it easier for the rest of us, then? [14:55] persia: Well, that I didn't do either, because each package had a maintainer, so they were probably already working on it. [14:55]