Re: Remove
Ken Bloom wrote: Henning Makholm wrote: Scripsit Chris Boyle <[EMAIL PROTECTED]> On Thu, Nov 24, 2005 at 06:54:12PM +, paddy wrote: I though a robots.txt thingy on the list web archive is coming to the rescue ? Huh? Isn't having the lists searchable generally a good thing? Yes, a very good thing in general. But excluding specifically the posts about c*llw*ve and d**l*ng b*nj*s might be worth a try. Of course, that is if somebody can be bothered to keep such exclusion lists up-to-date. On the other hand, l.d.o. is not the only place debian-devel is publicly archived, so it might not be worth the trouble to try to fix things locally. It's not. When querying for "Call Wave remove", the top hits are on a message from opensubscriber.com. When googling for "callwave remove" we get a page on lists.debian.org: --Ken Bloom And now you're perpetuating the trend, since you have that link next to the keyword. Suggestion: Why don't all the readers of debian-devel put something like this on their blogs: Google has a tendency for improperly indexed items to stay that way. In order to fix this, it is neccessary to create a "google bomb" by having several sites all create a link to the correct page with the keyword. In order to fix an incorrect entry that causes spam to the debian-devel mailinglist, I want everyone to know that you should go here to _remove callwave_ [0]. Cheers, Benjamin [0] http://www.callwave.com/members/help/help.asp?item=SEARCH_cancel signature.asc Description: OpenPGP digital signature
Re: Intel notebooks for needy developers in developing countries
Daniel Baumann wrote: Lars Wirzenius wrote: I don't like those laws, but publically urging people to violate them isn't going to do anyone any good. Hu? Why should it be illegal to re-sell or outreach a piece of US hardware, which is already imported into a free country, into another free country? However, it's not imported yet for breaking onces head about it anyway. Regards, Daniel I would assume that it'd be illegal for the US company to export it to someone with the knowledge that that person/group/company intends to re-export it to an embargoed nation. signature.asc Description: OpenPGP digital signature
Re: Thoughts on Debian quality, including automated testing
Andrew Suffield wrote: On the other hand, I think there might be some benefit to requiring that the Maintainer field must always denote one single Debian developer, who would be the "buck stops here" guy for that package. Not an applicant, not a mailing list, and not a group of people. I believe the tools have now advanced to the point where this is a practical option. In general you're always far better off forcing every *change* to a given component to go through a single individual. Large projects need a pumpking, because dogpiling creates lousy software. For Debian this would be cumbersome and unwieldy as a rule, but some high-importance tasks could benefit from it. I think you have something here, but I think allowing an applicant/mailing list in maintainer should be ok. In the case of an applicant, if they're doine the work, they both deserve the credit and should be the one to get all the messages that the various debian infrastructures sends out (Archive scripts, BTS, point of contact for security, etc). The latter also holds for mailing lists. Instead, why not propose a Responsible-For: header for control that lists a person inside the project who the buck stops with in the case of an applicant or team maintained package? Benjamin signature.asc Description: OpenPGP digital signature
Re: switching to vim-tiny for standard vi?
Eric Dorland wrote: but this change is the sort of thing that will help the change perception of Debian for people who think we're a bunch of crazies. Wait...is that an arguement for or against? ;-) Benjamin signature.asc Description: OpenPGP digital signature
Re: Thoughts on Debian quality, including automated testing
Andrew Suffield wrote: On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote: Andrew Suffield wrote: On the other hand, I think there might be some benefit to requiring that the Maintainer field must always denote one single Debian developer, who would be the "buck stops here" guy for that package. Not an applicant, not a mailing list, and not a group of people. I believe the tools have now advanced to the point where this is a practical option. In general you're always far better off forcing every *change* to a given component to go through a single individual. Large projects need a pumpking, because dogpiling creates lousy software. For Debian this would be cumbersome and unwieldy as a rule, but some high-importance tasks could benefit from it. I think you have something here, but I think allowing an applicant/mailing list in maintainer should be ok. In the case of an applicant, if they're doine the work, they both deserve the credit I don't think we should be using the control file for this purpose. Particularly since it does not and never has included a list of the people who do most of the work on a given package. Consider samba - the 'maintainer' hasn't been heard from in ages, and nowhere in the control file are all the relevant people listed. The obvious place for this information would be the changelog - this is the current convention (again, see samba). Fair enough. The reason I think of maintainer as this is that it's the most often seen item associating the package with a person. Example being apt-cache show, the front-ends, the bts, etc. and should be the one to get all the messages that the various debian infrastructures sends out (Archive scripts, BTS, point of contact for security, etc). I *think* that the relevant infrastructure tools have now all been fixed so that you don't have to use the Maintainer field to accomplish this. Instead, why not propose a Responsible-For: header for control that lists a person inside the project who the buck stops with in the case of an applicant or team maintained package? Because I don't see how it would be semantically different to the Maintainer field. The distinction between them is not apparent (what is Maintainer supposed to mean under this scheme?). And adding new fields is more work, so you don't do it without a good reason. The difference is who does the work. The Responsible field would be the one to talk to if the package does something bad from the project's perspective such as a deliberate security issue or it not being up to snuff. They would also be the one to talk to if the maintainer or team doesn't respond to other complaints. The maintainer would be the one that users look to on a daily basis - manages bugs, does most of the work, etc. Basically, the Responsible field would be what you suggested - a Debian Developer in good standing who offers accountability for the project. The Maintainer would be the person or team doing the work, possibly a mailing list or someone who is not a DD. The key is that the Responsible-Person field would add accountability. Benjamin signature.asc Description: OpenPGP digital signature
Re: Thoughts on Debian quality, including automated testing
Frank Küster wrote: Benjamin Seidenberg <[EMAIL PROTECTED]> wrote: Andrew Suffield wrote: On Fri, Dec 23, 2005 at 02:31:19PM -0500, Benjamin Seidenberg wrote: Instead, why not propose a Responsible-For: header for control that lists a person inside the project who the buck stops with in the case of an applicant or team maintained package? Because I don't see how it would be semantically different to the Maintainer field. The distinction between them is not apparent (what is Maintainer supposed to mean under this scheme?). And adding new fields is more work, so you don't do it without a good reason. The difference is who does the work. I a well-team-maintained package, the work is actually done by "the team", and decisions are made after finding a consensus solution in the team. Right. That was the biggest problem I had with Andrew's idea, he wanted to use the maintainer field for one person and only one person, who was a DD. As an applicant, I didn't particularly care for this, and suggested a "lesser-of-two-evils" approach. The Responsible field would be the one to talk to if the package does something bad from the project's perspective such as a deliberate security issue or it not being up to snuff. I don't see why you wouldn't want to talk to the list in this case. We don't need someone to put the blame on (we don't have and don't want any "punishment"), rather we need someone to make the necessary changes, be it in the package or in the minds of the people who maintain the package. *shrug* I agree. At least in my suggestion, you still have the maintainer field, as opposed to it being a single DD in Andrew's proposal. They would also be the one to talk to if the maintainer or team doesn't respond to other complaints. The maintainer would be the one that users look to on a daily basis - manages bugs, does most of the work, etc. I really can't see the difference, neither in a team-maintained package nor with an applicant. In the latter case, of course the sponsor is responsible; but even then there's not much point in talking to the sponsor if the applicant can just search a new one. If a package is badly maintained and you get no response, the usual procedure is to start with NMUs and proceed with orphaning the package (or taking over); where's the difference here between a non-responsive single maintainer and a non-responsive team? Again, it was my way of tempering Andrew's proposal. And in case of complaints about a package, how should someone be able to make good decisions if he does *not* receive the messages about it on a daily basis, but instead has to dig through them afterwards? Well, there might be rare cases where this is the only way to get an outside view of some quarrel, but we already have the TC for this. That was one of my points, under Andrew's proposal, the maintainer would become a DD and the team/applicant wouldn't recieve these emails. Basically, the Responsible field would be what you suggested - a Debian Developer in good standing who offers accountability for the project. Ah, so we're going to have two classes of DDs: The ones with "good standing", and the others who are not allowed to be in the Responsible field? I would assume all DD's are members in good standing of the project, if not, shouldn't they be kicked out? The Maintainer would be the person or team doing the work, possibly a mailing list or someone who is not a DD. The key is that the Responsible-Person field would add accountability. Accountability? That only makes sense if there are consequences in case that person does bad work. Either a "criminal action", or some sort of private punishment like having to pay money. All this does not exist in Debian, and IMO it doesn't make sense to introduce them. Regards, Frank Again, this is partly a response to Andrew's proposal of only allowing a DD as a maintainer and having them as the person where "the buck stops here". The accountability he wants is the one refered to here. Cheers, Benjamin signature.asc Description: OpenPGP digital signature
Re: Size matters. Debian binary package stats
Michelle Konzack wrote: Please not, that I had berween 12/1999 and 12/2004 a contract with a Parisian ISP for a OC-3 and Hosting of one 19" Rack (210cm, 600kg). I have payed including unlimited traffic 499.998 French Francs (76.000 Euro) per month and my own Class-C Block registered at RIPE. I heared (on debian-isp) that in the USA you can get a BGP4 routed STM4 (622MBit) Fiber Optic for only 120.000 US$ PER YEAR !!! Argh... Do I live in the false country? Greetings Michelle Seriously? Where? I live in the states, and we pay approx. $50/month (600 USD/year) for residential DSL (I think, parents pay the bill). That's a 1.5m down/512k up pipe, with horrible reliability (alltel sucks). Where can I get the fiber optic for $10/year? Benjamin signature.asc Description: OpenPGP digital signature
Re: Size matters. Debian binary package stats
Benjamin Seidenberg wrote: Michelle Konzack wrote: Please not, that I had berween 12/1999 and 12/2004 a contract with a Parisian ISP for a OC-3 and Hosting of one 19" Rack (210cm, 600kg). I have payed including unlimited traffic 499.998 French Francs (76.000 Euro) per month and my own Class-C Block registered at RIPE. I heared (on debian-isp) that in the USA you can get a BGP4 routed STM4 (622MBit) Fiber Optic for only 120.000 US$ PER YEAR !!! Argh... Do I live in the false country? Greetings Michelle Seriously? Where? I live in the states, and we pay approx. $50/month (600 USD/year) for residential DSL (I think, parents pay the bill). That's a 1.5m down/512k up pipe, with horrible reliability (alltel sucks). Where can I get the fiber optic for $10/year? Benjamin Oopps. Strike that. I read 120.000 as 120 dollars, I'm not used to the European '.' as the seperator, but the US ','. I also meant $10/month above, but that's obviously not relevant anymore. signature.asc Description: OpenPGP digital signature
Re: Packet radio and foul language
Thijs Kinkhorst wrote: On Sun, 2006-01-08 at 09:02 +0100, Stephan Hermann wrote: - Do not use foul language; besides, some people receive the lists via packet radio, where swearing is illegal. This sentence surprised me in quite some ways: - "besides": besides what? Do not swear, and apart from that, some people receive it over radio. There seems to be something missing. - Are there really people known to receive these lists over packet radio?? - Is swearing actually illegal on packet radio? What authority issues and enforces those rules? Yes, the FCC. See part 97 of the FCC rules (US CFR Title 47), specifically § 97.113(1) [0] - Is it actually true that when sending encoded data over this medium, it's illegal when it can be decoded in some way into a foul word? Yes. And actually, it wouldn't be sent encoded that much (unless it's base64 encoded server to server or something), it'd be an ASCII transmission. Since I know virtually nothing about packet radio, I'd really appreciate some light shed on these things :) Glad to help. 73, Benjamin, KI4CXN Thijs [0] http://ecfr.gpoaccess.gov/cgi/t/text/text-idx?c=ecfr&view=text&node=47:5.0.1.1.6&idno=47#47:5.0.1.1.6.2.155.7 signature.asc Description: OpenPGP digital signature
Re: Packet radio and foul language
Benjamin Seidenberg wrote: Yes, the FCC. See part 97 of the FCC rules (US CFR Title 47), specifically § 97.113(1) [0] Err, sorry, I meant § 97.113(a)(4). Also, my previous message applies to amateur operators in the US. Amateurs in other nations are similiary regulated by their equivelent to the FCC, with similar rules which are all based on ITU regulations. signature.asc Description: OpenPGP digital signature
Re: Packet radio and foul language
Miles Bader wrote: Benjamin Seidenberg <[EMAIL PROTECTED]> writes: Err, sorry, I meant § 97.113(a)(4). Also, my previous message applies to amateur operators in the US. Amateurs in other nations are similiary regulated by their equivelent to the FCC, with similar rules which are all based on ITU regulations. So what's the likelihood that this is actually a problem? 0.1%? 0.001%? Probably a bit higher (not too much), given that radio waves propagate, and anyone in a large area could see them, but you're right it's very low. However it's also a fact of professionalism. Do you tolerate bugs in your software? What about policy violations in your packages? Even if no one sees them, you still avoid them, because you agreed to the rules, and consider yourself bound to them as a matter of course. And by what bizarre standard is saying "foo sucks" really profane??? Ok, by the "wackos like ed meese" standard maybe -- but nobody cares about that. FCC has specific rules about what's obscene, although they're not in part 97. Think George Carlin's "Words you can't say on the radio". In the extremely unlikely event that it is a problem, why should it be up to list posters to deal with it? If some readers use a service governed by authorities that are prudish to an absurd degree, it seems like the onus is on them to try and deal with the probably technically; at the least it's up to them to demonstrate that it is a _real_ issue before asking people to modify their behavior based on this. That's a matter for the list managers to decide, and I won't speak on this issue, as I have no opinion. The debian-ham mailing list (of which I am not a part) might however, you could try asking them. Regardless, I think the rules are based on common courtesy; in that one should curb their language on any publicly distributed medium such as this. Think of the "80 year old grandmother rule" (Would someone's 80 year old grandmother be offended by what you say?) It's just being polite and courteous to others. This is my interpretation of the listmaster's rules, I'm not taking a position on them, although I will say that I think that people sound more reasoned when they make an arguement with ideas rather than profanity or namecalling. I assume that in truth, you're not really worried about the FCC breaking down your door, but rather don't like the language you see, and are trying to come up with a less subjective reason to object to it. The FCC would actually send a letter of notice, and possibly a fine (which can get quite high, especially if actions are repeated). Anyway, I'm not arguing for or against the rules, just giving some references and explanations to someone who asked them. Probably most posters would agree that extreme torrents of abuse are annoying and (usually) out of place, but for many speakers mild "profanity" is a normal part of informal language; most people understand that (even if they don't like it), and deal with it. I think this is a reasonable arguement, but I think there are reasonable arguements on both sides. -Miles I just want to add something. I don't know why, but at my high school, which has fairly restrictive internet filters, lists.debian.org is blocked. The strage part is that it's under the catagory "Abortion/Abortion Advocacy Groups". This is done by SonicWall, which is a very large provider of filter technologies. Even if it's miscatagorized, one wonders if foul language could cause other filtering groups to block it as obscene. Just food for thought. 73, Benjamin, KI4CXN signature.asc Description: OpenPGP digital signature
Re: Need for launchpad
Thomas Bushnell BSG wrote: Stephan Hermann <[EMAIL PROTECTED]> writes: - Do not use foul language; besides, some people receive the lists via packet radio, where swearing is illegal. Are you saying some people are transmitting the lists via radio without taking personal responsiblity for their transmissions? Shame on them. Oh, it gets even better. The fun part is that the one who wants to receive the list may not be the one who actually transmits the signal (and hence would be at fault). That'd be the transmitting station. for those who are having trouble following, think of this analogy. I (client send a request to another station (server) asking for the list. It (server) sends back the message, with the bad language. Thus, the transmitting station (server) is at fault, even though it's most likely automated. Isn't it all so fun? Benjamin, KI4CXN signature.asc Description: OpenPGP digital signature
Re: Getting rid of circular dependencies, stage 3
Joey Hess wrote: Bill Allombert wrote: Although sarge's aptitude did.. I don't know, there were no ways to upgrade to sarge's aptitude. The bug log contains a log of astronut doing the upgrade with sarge's aptitude.. I think the bigger problem is not whether it's possible to do this (which it somewhat was) but that it's not intuitive and that it would require research for someone to figure out how to do. Perhaps there should be some kind of upgrade pseudo-package created to ease the transition, that depends on the tools needed? Ie, aptitude install etch-upgrade would install the later version of aptitude, etc. needed for the upgrade. Benjamin (astronut) signature.asc Description: OpenPGP digital signature
Re: For those who care about the GR
Martijn van Oosterhout wrote: 2006/1/22, Thijs Kinkhorst <[EMAIL PROTECTED]>: This goes even further here, because the DFSG is not even a strict set of rules but are guidelines. As we all know, guidelines are subject to interpretation on a case-by-case basis, that's what distinguishes them from rules. Therefore, I think a specific application of guidelines can not be seen as a fact. As someone who can't vote and thus whose opinion doesn't matter, it seems to me that the issue is that people may actually want to vote multiple ways: 1. debian-legal is wrong, the GFDL is compatable with the DFSG and thus should be included in main. 2. I know the GFDL isn't compatable with the DFSG but I think it should be allowed in main anyway. 3. I know the GFDL isn't compatable with the DFSG but the DFSG is only for software not documentation, so it's allowed in main for documentation only. :) It seems that some people see the vote as meaning 1 and others want meaning 2. The latter would seems to require changing the SC, the former wouldn't. -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ You forgot 1b) I think that the GFDL-without-invariant-sections is compatible with the DFSG. That's an interpretation, and should only need a majority. Other than that, you're right (IMHO) Benjamin signature.asc Description: OpenPGP digital signature
Re: Bug#349693: ITP: gst-fluendo-mp3 -- MP3 decoder plugin for GStreamer
Joe Wreschnig wrote: It's clear to me you've never had to use an iRiver's Ogg support. It fails outside a limited bitrate range, drains battery faster, does not read metadata, and is not available on all devices. Newer iRivers also use a proprietary communications protocol that is not yet supported in Debian. Finally, the recording is MP3 only. While this is true wrt the flash based iRivers currently sold, the hard drive based ones found in stores (The h10 line) can use standard UMS as an alternative mode (hold down the select button during boot), and the databases can be generated by easyh10 (which I package for Debian). You're still correct that they don't suppot ogg. HTH Benjamin signature.asc Description: OpenPGP digital signature
Re: Amendment to GR on GFDL, and the changes to the Social Contract
Nathanael Nerode wrote: Incidentally, if I ever become a DD, I *will* immediately propose a GR to amend the Social Contract to explicitly allow unmodifiable license texts in Debian, since it technically doesn't, but everyone agrees that it should. I'd welcome someone else beating me to it. Well... as far as I understand it, you can always modify legal text since it's not copyrighted. You obviously would have to change the name, and it wouldn't apply to the program, but you could create the "Foo License" that's based on the GPL and distribute your own software for you. I could be wrong of course. Benjamin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
Henning Makholm wrote: Scripsit Gunnar Wolf <[EMAIL PROTECTED]> Xavier Roche dijo [Mon, Feb 13, 2006 at 10:55:57AM +0100]: So a cat is a software, or a hardware ? Do I have to provide the sources (the DNA full sequence) if I want to give a kitten to someone, following the "free" spirit ? :p A cat is not licensed under a viral license ;-) And, more important, is not covered by copyright law Even more important: Debian does not distribute kittens at all. Hmmm... [EMAIL PROTECTED]:~$ ls -l /bin/cat -rwxr-xr-x 1 root root 16744 2005-11-16 08:17 /bin/cat [EMAIL PROTECTED]:~$ I guess we just don't deal in juveniles? Benjamin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Michelle Konzack wrote: > Since I have no valid ID-Card (problens with France, since I am origin > iranish/turkish witeh illegal german adoptivp arents) I can not enter > the NM... nobody can sign legaly my GPG key and more bs. > > Maybe if I go back to Iran or Turkey it would be possible for me. > > > You can always use a Transnational Republic ID card. *ducks* Benjamin [ For those who don't understand, read http://blog.madduck.net/geek/2006.05.24-tr-id-at-keysigning ] signature.asc Description: OpenPGP digital signature
Re: Why does Ubuntu have all the ideas?
Adam Borowski wrote: > On Sat, Aug 26, 2006 at 02:01:21AM -0400, Benjamin Seidenberg wrote: > >> Michelle Konzack wrote: >> >>> Since I have no valid ID-Card (problens with France, since I am origin >>> iranish/turkish witeh illegal german adoptivp arents) I can not enter >>> the NM... nobody can sign legaly my GPG key and more bs. >>> >>> Maybe if I go back to Iran or Turkey it would be possible for me. >>> >> You can always use a Transnational Republic ID card. >> > > I am pretty sure Michelle has at least _some_ sort of ID, even as an > illegal alien. And with the current anti-Arab scare she would be > already deported were she lacking complete valid papers -- you can > sit in peace if you don't travel anywhere, but by browsing > debian-devel I get the impression Michelle travels around a lot. > > > And, there is a number of ways to reasonably prove your identity > better than an ID. And ID can be gotten by talking to an > absent-minded clerk, bribing the said underpaid clerk or even get a > nice blank one from Ivan -- so an ID cannot be deemed a solid proof. > > Michelle, you're not a nobody. Many people know you. If I walked > with you to a known figure who knew you for a number of years and he > vouched for you, I would be a lot more certain than if I had seen > nothing but a smudged photo on an ID. You can bribe or sweet-talk the > guy to fool me, but I still would call an university professor or the > like someone more trustworthy than a nameless clerk. And I'm sure > there's a number of similar people who know you. What would you say > about the chief of Polish chapter of FFII? He's a long-time buddy of > mine, even though I haven't seen him for a number of years. While > not a DD, I don't think his word would have less weight than an ID > you can get for $25. > > > Also, the name means little. I don't really care if an upload was > done by a person who claims to be named "Benjamin Seidenberg", I care > that it was done by a person with a history of valid good > contributions whose prior work was checked by many people. Whether > it was signed by "Benjamin Seidenberg" doesn't matter until I want to > pursue legal action. I don't need your real name to appreciate your > deeds -- feeling thankful to "astronut" works as well. > > > It's the ownership of the key what matters, not the name attached to > it. It's important to know that the key is yours, not that it > belongs to a "Benjamin Seidenberg". > > > This issue was heavily discussed in a previous project thread after the blog post I linked to was published. It incited a huge flame war, which I was referring to in humor. signature.asc Description: OpenPGP digital signature
Re: Conditionally applying an architecture-dependent patch
Shaun Jackman wrote: > When using CDBS, what is the best way to conditionally apply an > architecture-dependent patch. I'm using CDBS, but not yet using a > patch system such as simple-patchsys, dpatch, or quilt, so > recommendations of a patch system are welcome. Currently I have... > > ARCH64 := alpha amd64 ia64 > > ifneq (,$(filter $(DEB_HOST_ARCH),$(ARCH64))) > configure/foo:: > patch -p1 endif > > Cheers, > Shaun > > Heh. This is swt-gtk? I (with help from Sven Müller) worked on getting a conditional patch for it a while back using dpatch, but then I wanted to try to do some sed magic instead based on upstream's missing build system and never got around to sending it to you. I'm putting what I have online at dlgeek.net/swt-gtk/. Sorry about starting this and not giving back. Benjamin signature.asc Description: OpenPGP digital signature
Re: Naming a 32-bit/64-bit specific Java package
Shaun Jackman wrote: > On 11/28/06, Shaun Jackman <[EMAIL PROTECTED]> wrote: >> I'm personally leaning towards to two arch: all packages (one 32-bit, >> one 64-bit) and a meta-package which depends on the right one. I am >> considering and open to the one arch: any package though. If it >> affects the decision, the binary package is roughly 1.2 MB. > > I take it back. I implemented the arch: all method, and it wasn't that > tricky, but the arch: any method is definitely technically simpler. > Without a good reason, I can't see why I shouldn't use the simpler > method. The argument for the arch: any case is obvious -- it's simpler > -- what's the best argument for the arch: all case? > > Cheers, > Shaun > > Less archive/mirror bloat. signature.asc Description: OpenPGP digital signature
Re: Naming a 32-bit/64-bit specific Java package
Florian Weimer wrote: > * Benjamin Seidenberg: > > >> Less archive/mirror bloat. >> > > Which is easily nullified if the more complex Architecture: all > approach needs more bug fixes. > > > Except old versions are dropped from mirrors. So after a time, the old packages will disappear and only two copies (as opposed to 12 or what not) will be on the mirrors. signature.asc Description: OpenPGP digital signature
Re: Bug#401227: ITP: metacafe-dl -- download videos from metacafe.com
Nacho Barrientos Arias wrote: > Package: wnpp > Severity: wishlist > Owner: Nacho Barrientos Arias <[EMAIL PROTECTED]> > > * Package name: metacafe-dl > Version : 2006.11.25 > Upstream Author : Ricardo García González > * URL : http://www.arrakis.es/~rggi3/metacafe-dl/ > * License : MIT > Programming Lang: Python > Description : download videos from metacafe.com > > Metacafe-dl is a small command-line program to download videos > from metacafe.com featuring a simulation mode to get the video's > URL and download it with another download manager. > . > Command-line syntax is similar to youtube-dl. > . > Homepage: http://www.arrakis.es/~rggi3/metacafe-dl/ > > Why not just have metacafe added to youtube-dl and possibly ship a symlink named metacafe-dl? (Hmm, as youtube-dl also does google video, maybe we should rename it to something like flash-dl.) Benjamin signature.asc Description: OpenPGP digital signature
Re: shared libraries dependecy problem.
Grzegorz Bizon wrote: > Hi. > > I have problem with dependecies on shared libraries in my package > (tleenx2). > Linda complains that: > W: tleenx2; A binary links against a library that is not depended on. > (By the way - shoudn't it be error rather than warning ?) > Linda seems to be doing this with all packages with ELF binaries for me. Random sample from /var/cache/apt/archives: W: bash; A binary links against a library that is not depended on. W: bsdutils; A binary links against a library that is not depended on. W: cdparanoia; A binary links against a library that is not depended on. W: coreutils; A binary links against a library that is not depended on. W: cron; A binary links against a library that is not depended on. W: curl; A binary links against a library that is not depended on. signature.asc Description: OpenPGP digital signature
Re: etch before vista
Kevin Mark wrote: > Hi *, > I noticed on occassion on -devel and planet that folks mention in passing > that "I'll be in MN in US from MAR 01 thru 05" and I'd like to have a > beer and do keysigning. Would it be worthwhile to create a list like > 'debian-meetup' (or debian-beer-meetup x-))that would allow folks to > give this info on what would be a low-volume list. I love to meetup with > floss folks who have a flight stop-over or will be in town for a day or > so. I guess some issue maybe the idea of personal security and > privacy--- people knowing where you will be and providing contact > info--but the messages as specific as people want and the basic info > could be state and email contact address with a month/week given. > Cheers, > Kev > ps. I recall folks saying that debian-private has 'holiday info' or > people whereabouts. This would be voluntary and would not include that > info. > I think a wiki would be more effective. That way you could have people in those areas say "I'd love to meet any DD passing through" and actually be noticed. It could be organized with separate pages for various regions, etc. Just my $0.02 Benjamin signature.asc Description: OpenPGP digital signature
Re: etch before vista
Kevin Mark wrote: > On Fri, Mar 24, 2006 at 09:28:47PM -0500, Benjamin Seidenberg wrote: > >> Kevin Mark wrote: >> >>> Hi *, >>> I noticed on occassion on -devel and planet that folks mention in passing >>> that "I'll be in MN in US from MAR 01 thru 05" and I'd like to have a >>> beer and do keysigning. Would it be worthwhile to create a list like >>> 'debian-meetup' (or debian-beer-meetup x-))that would allow folks to >>> give this info on what would be a low-volume list. I love to meetup with >>> floss folks who have a flight stop-over or will be in town for a day or >>> so. I guess some issue maybe the idea of personal security and >>> privacy--- people knowing where you will be and providing contact >>> info--but the messages as specific as people want and the basic info >>> could be state and email contact address with a month/week given. >>> Cheers, >>> Kev >>> ps. I recall folks saying that debian-private has 'holiday info' or >>> people whereabouts. This would be voluntary and would not include that >>> info. >>> >>> >> I think a wiki would be more effective. That way you could have people >> in those areas say "I'd love to meet any DD passing through" and >> actually be noticed. It could be organized with separate pages for >> various regions, etc. >> > Hi Ben, > so instead of DD-post->ML-sent->readers, you'd say > readers-post->wiki-read->DD-sent->readers? > > so if r(0)+r(1)+...r(n)=R all people in regions > then the mailing list would be sent to R people while with your approach > the DD(x) would send mail to r(x) people where DD(x) would be the DD > going to region(x) and r(x) would be the people in that region? So that > would mean that less people would be emailed and be 'more efficient'? > > I think that approach requires more 'effort' because the people have to > find the right page on the wiki, figure out how to add their name and > then the DD has to find the right page on the wiki also and then extract > the list and then mail them. Whereas, my idea for the readers to just > subscribe to the list and the DD's to post to the list. > > Cheers, > Kev > I was thinking more about how easy it is to access old data. Lets say I'm going to Boston, and also want to see who's in town. I would have to go searching through the past month or so on the mailing list archives to find who else is going. I also wouldn't be able to see people who live there. While I could email the list, that requires every person who is going to Boston or lives there to email me back. They'd also have to email every other person. Compare this to the wiki, where they simply go to the Boston page, update it with their details once, and it's set. HTH, Benjamin signature.asc Description: OpenPGP digital signature
Re: Keysignings and other "meetups" (Was: etch before vista)
Luk Claes wrote: > Jeroen Massar wrote: > >> On Sat, 2006-03-25 at 11:53 -0500, Benjamin Seidenberg wrote: >> >> >>> Kevin Mark wrote: >>> >>> >>>> On Fri, Mar 24, 2006 at 09:28:47PM -0500, Benjamin Seidenberg wrote: >>>> >>>> >>>> >>>>> Kevin Mark wrote: >>>>> >>>>> >>>>> >>>>>> Hi *, >>>>>> I noticed on occassion on -devel and planet that folks mention in passing >>>>>> that "I'll be in MN in US from MAR 01 thru 05" and I'd like to have a >>>>>> beer and do keysigning. Would it be worthwhile to create a list like >>>>>> 'debian-meetup' (or debian-beer-meetup x-))that would allow folks to >>>>>> give this info on what would be a low-volume list. >>>>>> >> [..] >> >> >> >>> I was thinking more about how easy it is to access old data. >>> >> You might want to check https://www.biglumber.com/ which contains >> already a very nice interface for all of this. >> > > Or you might want to use https://nm.debian.org/gpg_offer.php. Have a > look at https://nm.debian.org/gpg.php if you want to be listed... > > Cheers > > Luk > > (For those who tried to access it, that service is currently down due to a planned outage at HP). That's what I was thinking of when I suggested a wiki. The problem with the NM one is it is hard to change, and often out of date. A wiki would allow anyone to change it, without the bottleneck of going through whoever is in charge of it (Front Desk I assume). Benjamin signature.asc Description: OpenPGP digital signature
Re: Bug#360224: ITP: dglog -- CGI log analyzer for DansGuardian
Elizabeth Krumbach wrote: > Package: wnpp > Severity: wishlist > Owner: Elizabeth Krumbach <[EMAIL PROTECTED]> > > > * Package name: dglog > Version : 1.0 > Upstream Author : Jimmy Myrick <[EMAIL PROTECTED]> > * URL : http://www.tiger.org/technology/dg/ > * License : GPL > Description : CGI log analyzer for DansGuardian > > A CGI log analyzer for the web content filter DansGuardian. > . > Homepage: http://www.tiger.org/technology/dg/ > > -- System Information: > Debian Release: testing/unstable > APT prefers testing > > APT policy: (500, 'testing') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.8-2-686 > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) > > > > I use this script myself, but it's only one file. An entire package for it seems like overkill. Would it not be better to try to have it shipped as part of dansguardian? signature.asc Description: OpenPGP digital signature
Re: Bug#361418: [Proposal] new Debian menu structure
Andrew M.A. Cater wrote: > On Sun, Apr 09, 2006 at 09:48:48AM +1000, Hamish Moffatt wrote: > >> On Sat, Apr 08, 2006 at 04:46:10PM +0200, Bill Allombert wrote: >> >>> Package: debian-policy >>> Version: 3.6.2.2 >>> Severity: wishlist >>> >>> Background: >>> -- >>> The menu structure define the list of sections and subsections of >>> the Debian menu system (which are displayed in window-managers menus). >>> The official list is part of the Debian menu subpolicy. This list is a >>> bit outdated, so we are proposing an update. >>> >>> >> [...] >> >>> 2) Renamed sections: >>> Applications [was:Apps] >>> Educational [was:Education] >>> HAM Radio [was:Hamradio] >>> >> [...] >> >> Hi Bill, >> >> "HAM" is not an acronym, so "Ham Radio" would be more appropriate. >> >> Even better (IMHO) is the full term "Amateur Radio", but some may >> disagree. I've CC'd debian-hams for their input also. >> >> > Radio amateur / amateur radio : either would be fine IMHO. > > Andy [Amateur radio callsign G0EVX] > > > Radio amateur doesn't sound right from my en_US perspective. I would go with "Amateur Radio" Benjamin (KI4CXN) signature.asc Description: OpenPGP digital signature
Re: Reforming the NM process
Steve Langasek wrote: > On Tue, Apr 11, 2006 at 06:40:34PM +0200, Marc 'HE' Brockschmidt wrote: > >> 2.1 Multiple advocates >> -- >> > > >> Ask for more than one advocate (at the moment, I'm thinking about >> two). This should get the number of people advocated with a "Errr, >> I met him, he seemed nice" down. At the same time, encourage prospective >> advocates no to advocate too fast. >> Also, two advocates are not a problem for someone who should apply in >> the NM queue - if there is only one project member who's willing to >> advocate you, something is foul anyway. >> > > We discussed this a bit on IRC, and feedback seemed positive, so I'll > comment here as well. I don't think having multiple advocates solves > anything; if the problem is that you have a large pool of people acting as > poor advocates, then requiring them to get *two* bad advocates is only > slightly more challenging than getting one. > > It would be better if we could have clear guidelines for advocates, to cover > the gap between what AMs are expecting of incoming NMs and who advocates are > actually advocating; and if necessary, to disqualify certain DDs from > advocating if they consistently abuse the system by ignoring these > guidelines. > You mean like http://www.debian.org/devel/join/nm-advocate ? It's sparse, but after you give your name to be an advocate, there's an email questionnaire that asks about the applicants and should let an advocate know if the candidate is qualified or not. Cheers, Benjamin signature.asc Description: OpenPGP digital signature
Re: Bug#361418: [Proposal] new Debian menu structure
Manoj Srivastava wrote: > To the practitioners, it is HAM radio. Not Amatuer radio -- > and the only reason we are considering not calling it ham since > ignorant users should not be confused. Sounds like dumbing down to > me. > > manoj > > Eh? I use amateur radio all the time, any time I speak of it formally, in essays, etc. My license also says "AMATEUR RADIO LICENSE" on it, not ham. I use amateur for formal situations or people who aren't aware of the hobby, ham for informal use. Just my $0.02 Benjamin, KI4CXN signature.asc Description: OpenPGP digital signature
Re: Please remove rules.old
Dirk Eddelbuettel wrote: > On 17 April 2006 at 22:42, Peter Eisentraut wrote: > | There are a few dozen source packages in the archive that contain a file > | called debian/rules.old. In many cases, this was apparently the backup > | copy during a cdbs conversion or something similar that should have > | been removed. If you appear below, please consider fixing this. > > Sure, but why? Doesn't exactly do harm, does it? > > Dirk (not sub'ed on d-devel so please CC me) > > Any unnecessary cruft is a waste of both mirror space and bandwidth. I know the college I'm going to next year has a 2 gb/month cap on the net. Anything over that, and you pay. (And I currently transfer 30+gb over lan+net...ouch). HTH, Benjamin signature.asc Description: OpenPGP digital signature
Re: irc.debian.org
Petter Reinholdtsen wrote: > [Steve McIntyre] > >> I can see that more and more of my own Debian IRC discussions are on >> oftc, to the extent that I'm (currently) not on any freenode >> channels at all. >> > > For me it is the other way around. I am currently on one channel on > OFTC, while I am on 7 channels on Freenode, 4 of them related to > Debian. > > > I agree with Steve. While I agree that freenode has many flaws (the biggest being NOIDPRIVMSG), I find that while I am in Debian channels on both networks, many more open source projects are on freenode, and that makes things much more convenient. Even if all Debian development moved to OFTC, I'd still stay on freenode for fluxbox, all of the various kde components I use, postfix, etc, etc etc. I think it might be better for us to try to use our influence as a huge source of users to try to better freenode than to just move. signature.asc Description: OpenPGP digital signature
Re: irc.debian.org
Benjamin Seidenberg wrote: > Petter Reinholdtsen wrote: > >> [Steve McIntyre] >> >> >>> I can see that more and more of my own Debian IRC discussions are on >>> oftc, to the extent that I'm (currently) not on any freenode >>> channels at all. >>> >>> >> For me it is the other way around. I am currently on one channel on >> OFTC, while I am on 7 channels on Freenode, 4 of them related to >> Debian. >> >> >> >> > I agree with Steve. While I agree that freenode has many flaws (the > biggest being NOIDPRIVMSG), I find that while I am in Debian channels on > both networks, many more open source projects are on freenode, and that > makes things much more convenient. Even if all Debian development moved > to OFTC, I'd still stay on freenode for fluxbox, all of the various kde > components I use, postfix, etc, etc etc. I think it might be better for > us to try to use our influence as a huge source of users to try to > better freenode than to just move. > > Sorry, accidentally sent this to wrong list, should be on -project. signature.asc Description: OpenPGP digital signature
Re: Shouldn't we have more ftp masters ?
Stefano Zacchiroli wrote: > On Sun, May 28, 2006 at 11:42:16PM +0200, Bartosz Fenski aka fEnIo wrote: > >> I think it's debconf time and everything is slower, but will be as >> usual when it's end and everyone came back to his/her normal work. >> > > The point of the first mail was exactly about that. NEW queue can't stay > unprocessed just because 1 or 2 ftp masters/assistants are attending > debconf or on vacation. They have all rights of doing so, of course! But > we need someone else able to take over their duties in this respect. > > I do think that NEW processing is rather important for package > maintenance and that it can hinder development. > > Cheers. > > FYI: 12:33 < Ganneff> and for all those impatient waiting for NEW: i will clear that in my jetlag time, in those nights i cant sleep (ie 1st -> 2nd june, 2-> 3) :) 12:37 < Ganneff> maybe i can do a bit of NEW later today, but im going to look around in mx city in a few minutes, only doing urgent stuff online atm) signature.asc Description: OpenPGP digital signature
Re: mystery of dh_installdirs
Atsuhito Kohda wrote: > Hi all, I got an FTBFS bug yesterday; > > On Thu, 8 Jun 2006 08:13:53 +0200, Bastian Blank wrote: > > >> Package: lynx-cur >> Version: 2.8.6dev18-1 >> Severity: serious >> >> There was an error while trying to autobuild your package: >> > ... > >>> install -m 755 debian/lynx >>> /build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur-wrapper/usr/bin/lynx-cur >>> install: cannot create regular file >>> `/build/buildd/lynx-cur-2.8.6dev18/debian/lynx-cur-wrapper/usr/bin/lynx-cur': >>> No such file or directory >>> > > My guess is, it would be necessary to add "-A" like > dh_installdirs -A in rules' install target. > (there are two packages, lynx-cur which is architecture dependent > and lynx-cur-wrapper which is independent) > > Yes. Or -plynx-cur-wrapper > But I couldn't understand why there was no problem on my machine > but there was on buildd. > > Your machine built both the arch-independent and arch-dependent targets, the buildd only builds arch-dependent. (For your source, pbuilder build lynx-cur_2.8.6dev18-1.dsc succeeds, but pbuilder build --binary-arch lynx-cur_2.8.6dev18-1.dsc fails.) Since debhelper acts on the first package by default, it doesn't happen for lynx-cur-wrapper, and you include parts of the building of lynx-cur-wrapper in your rules. You may want to consider splitting build and install into build/install-indep/dep to minimize the work of the systems building only the arch-dependent package. > Please enlighten me. > > Thanks in advance,2006-6-9(Fri) > > Happy to help, Benjamin signature.asc Description: OpenPGP digital signature
Re: SUMMARY -- Generic handling of WORD, EXCEL, FILE MANGER ...
Jari Aalto+usenet wrote: [] > Where items proposed for graphical programs could include: > x-word-processor > x-spreadsheet > x-file-manager > x-archiver > x-media-player or "x-video-player" > x-media-editor or "x-media-mastering" > x-music-player > x-music-editor think "audacity" etc. > > x-audio-editor, it's not just for music. I think of music editor as moving notes around on a score. signature.asc Description: OpenPGP digital signature
Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package
Joe Smith wrote: > > "Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >> Package: wnpp >> Severity: wishlist >> Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]> >> >> * Package name: googleearth-package >> Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]> >> * URL : (native package) >> * License : GPL >> Description : utility for automatically building a Google Earth >> Debian package >> >> Google Earth is a great program now available for GNU/Linux, but sadly >> is both non-free and non-distributable. For those who wish to run it on >> their Debian system, but wish it to be managed by the normal Debian >> packaging system, this program will assist in building a local Debian >> package in a similar fashion to java-package. This package *itself* >> contains absolutely no code from Google and is 100% free. (For the >> curious, this is appropriately destined for contrib.) >> >> > > Is this really needed? Google was very careful in making sure that the > package installs in /usr/local, and does not interfere with the > system. Normally the main reason why a debian package is better than > what upsteam distributed is because using upstreams packages will mess > with stuff it should not touch. > > The reason java-package is needed is that upstream's packages are not > well behaved, and install into /usr, potentially causeing problems if > it decides to edit the files of other packages. > > > Google Earth takes care of its own updates by prompting the user, and > allowing them to download and run the new installer (or at least it > does on windows, and I can't imagine why the linux version would not). > Needing to use a *-package utility prevents automatic updates anyway, > and does not simplify installation much if any. So the only real > advantage would seem to be that it would make Google Earth easier to > uninstall. Well I guess it simplifies pushing updates out to a bunch > of workstations, but in most cases users should just download the the > .bin and run it. > > What's more, google earth can be installed without root privileges and installs into a users home directory, thus the systems administrator doesn't even need to install it, the user can signature.asc Description: OpenPGP digital signature
Re: Bug#374373: ITP: googleearth-package -- utility for automatically building a Google Earth Debian package
Ron Johnson wrote: > Benjamin Seidenberg wrote: > >> Joe Smith wrote: > >>> "Wesley J. Landaker" <[EMAIL PROTECTED]> wrote in message > > >>>> Package: wnpp > >>>> Severity: wishlist > >>>> Owner: "Wesley J. Landaker" <[EMAIL PROTECTED]> > >>>> > >>>> * Package name: googleearth-package > >>>> Upstream Author : Wesley J. Landaker <[EMAIL PROTECTED]> > >>>> * URL : (native package) > >>>> * License : GPL > >>>> Description : utility for automatically building a Google Earth > >>>> Debian package > >>>> > >>>> Google Earth is a great program now available for GNU/Linux, > >>>> but sadly is both non-free and non-distributable. For those > >>>> who wish to run it on > >>>> their Debian system, but wish it to be managed by the normal > >>>> Debian packaging system, this program will assist in > >>>> building a local Debian package in a similar fashion to > >>>> java-package. This package *itself* contains absolutely no > >>>> code from Google and is 100% free. (For the curious, this is > >>>> appropriately destined for contrib.) > [snip] > >> What's more, google earth can be installed without root > >> privileges and installs into a users home directory, thus the > >> systems administrator doesn't even need to install it, the user > >> can > > When I tried to install it as root (using "su -" from an xterm > window), it complained about not being able to find DISPLAY. Unlike > Sun Java & Macromedia Flash, it uses a GUI installer. > > Since many (most?) desktop users install apps from within su or > sudo'ed xterm windows, how will you work around that? > If you don't use -, DISPLAY should be preserved. Ditto for sudo. Benjamin (Postscript: I almost replied to your sig, but decided i wasn't going to go there.) signature.asc Description: OpenPGP digital signature
Re: README - confusing, irrelevant, redundant, useless
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
W. Borgert wrote:
> Hi,
>
> I have to start yet another discussion about our packaging
> practise. Did anyone ever take a look at our
> /usr/share/doc//README{,.gz} files? If the users have
> difficulties with a package, we often reply "Why didn't you read
> the README? It's called README for a reason!" However, the README
> files are cluttered with confusing, irrelevant, redundant, and
> useless stuff. That way, we educate our users not to
> ReadTheFineReadme.
>
> Do you think, that this does any favour to our users? E.g.
>
> - "Debian packages of this software are currently available. It
> should be possible to run "apt-get install " and have a
> recent version installed."
>
> This is a Debian package, so what?
>
> - "Please send bug reports, requests for features, etc. to
> ."
>
> Don't we ask our users to use our BTS primarily?
>
> - "To build , please run: ./configure; make; make
> install."
>
> This is OK to have in the source, but not in the .deb. Same goes
> for information about possible configuration options. OTOH, the
> configuration options actually used in the Debian package are
> seldomly documented :-(
>
> - ...long history of who maintained the package when...
>
> This information - not really relevant to the user - is, of course,
> in the changelog as well.
>
> - ...stuff about API usage in a library package...
>
> That does belong to the -dev package only, right?
>
> - "Common options: --foo --bar --baz"
>
> According to our policy, the program has a manual page. While it's
> not bad, to repeat the information in other formats, it does -
> IMHO - not make sense in a README.
>
> - "Readme file for ."
>
> Really?
>
> - "This program is..." - exact copy of the package description.
>
> This README is redundant.
>
> - "$Id: ... $" (one line Id plus four lines of text)
>
> Maybe I become picky, but CVS/RCS ids are not relevant to the user,
> esp. if the remainder of the README is irrelevant, too.
>
> - "The latest version of can be obtained at website>."
>
> As a Debian user, I expect to get packages the Debian way. It's
> nice to have the upstream website address, but according to our
> policy I can find it in the copyright file.
>
> Package maintainers, please:
>
> 1. Do not include the upstream README in the binary package, if
> it's not really important to the user.
>
> 2. Just copy the 5..10% of relevant information into the
> README.Debian, if appropriate.
>
> 3. Don't invent a README file artificially, if you don't have to
> say anything.
>
> 4. File minor bugs about such README files.
>
> Cheers,
While I agree the README can be confusing, I think we do a disservice
to our upstream by not including it. Some readers may be interested in
the people who brought them the software, or knowing upstream's email
or any of these items you mention. As for readme versus man page, I
find manpages are usually more of a reference about syntax while
readme's are closer to a tutorial on usage.
I think a better solution would be to duplicate all the important
information about the software into the README.Debian and train users
to read that soley. The original readme is still intact for those
users who care. In addition, I would like to see a standardazation on
whether to compress the README and similar files, I always end up
typing less /usr/share/doc/blah/README.Debian[.gz] using tab
completion and have to go back and correcting my command to use zless
because half are compressed and half aren't. I also agree with what
Branden said in his WTFM presentation at debconf.. a readme command to
display the readme's to the user would be a very nice tool.
Benjamin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC/3dtev9LOsNKpIQRAkmyAJ9EQMuQCpPOW5P6XtPdGps2sms1mgCgsgEz
eUaQF/vXKll2trd+dU0GXEA=
=/crF
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mindterm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Javier Fernández-Sanguino Peña wrote: > On Sat, Aug 20, 2005 at 06:15:45PM +0200, Henning Makholm wrote: > >> Proxies and firewalling is not in my experience a huge trouble in >> these environments; the general non-availablity of any other >> software than IE (with JVM and various scripting languages) on >> netcafe/library computers is. >> >> Is putty available as a Java applet, plugin or the like? That >> would solve the problem that mindterm addresses, but I doubt it. > > > No it isn't, but you can always download it from the putty project > page [1] and just run it from the Internet. Unless there are > paranoid settings you can't change in IE you can just download the > exe file and run it in the system you are using. Why do you need a > Java applet when Windows will happily run any non-signed exe file? > > > Many internet cafe's or kiosk computers (or school computers, *sigh* though they're a lot better than they used to be) prevent running executables from outside specific paths, and limit write access to those paths. Also, I've seen lots of kiosks that keep a browser in full screen mode, preventing access to anything other than the web. A java applet is the only viable solution in cases like these. Benjamin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDCACUev9LOsNKpIQRAjraAKDDmMPdQAQDUyZVZmzJoqBRBaJ1pwCfcvKE uBLBJ3kypnlMYtT3hAP1kls= =2qts -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mindterm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Suffield wrote: > On Sun, Aug 21, 2005 at 12:18:29AM -0400, Benjamin Seidenberg > wrote: > >> Many internet cafe's or kiosk computers (or school computers, >> *sigh* though they're a lot better than they used to be) prevent >> running executables from outside specific paths, and limit write >> access to those paths. Also, I've seen lots of kiosks that keep a >> browser in full screen mode, preventing access to anything other >> than the web. A java applet is the only viable solution in cases >> like these. > > > I've hacked a lot of those kiosks to run putty on them. It's > really, really hard to stop people from running arbitrary code on > windows. Most people can't even do it to people who *don't* have > terminal access. > > Not that mindterm isn't still useful. > That's only good until the librarian/teacher/kiosk owner/etc walks past, notices something else running and kicks you out. In the case of school, well, lets not underestimate the idoicy of most school systems, some kid could be expelled for hacking. (I've been accused of hacking before by the school, go figure). Cheers! Benjamin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDCWVXev9LOsNKpIQRAmNOAJ4t9xOzkPoFW19KP1145cjNrR15bgCgoZUU Icou/HWRdr+hLfpooAz7YNg= =k7bg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: REMOVE ME FROM C4LL W4VE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bob Proulx wrote: > David Pashley wrote: > >>> Don't follow up. Reply to them privately. >> >> No, because that doesn't help the next person that searches on >> Google. > > > That is exactly the point. We DO NOT WANT people to find the > Debian mailing lists in any relation to that search. Every time > someone references it in a Debian mailing list it increases the > page range on Google. That is the problem. > > By referencing it here and keeping the Google page rank pointing > here you are actually hurting the users searching Google in the > future. > > What would help the user would be to increase the page range of > (avoding the name here) in Google so that when they search for it > that Google actually points them to the right place. > > Bob I wonder if it would be possible to appeal to google to have them manually edit that search so that l.d.o doesn't appear. (Same for dueling banjo's) Benjamin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDHH7Nev9LOsNKpIQRApVFAKCHxXBpqxcZY1yPRu+s5ZzJTy7w7ACeLuSx MVJeDyiGlNohqvqLfYk8+4g= =egpV -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#327425: ITP: gaim-slashexec -- adds functionality to execute commands from within a Gaim conversation
Package: wnpp Severity: wishlist Owner: Benjamin Seidenberg <[EMAIL PROTECTED]> Package name: gaim-slashexec Version : x.y.z Upstream Author : Gary Kramlich <[EMAIL PROTECTED]> Peter Lawler Daniel 'datallah' Atallah URL : http://guifications.sourceforge.net/SlashExec/ License : GPL Description : adds functionality to execute commands from within a Gaim conversation SlashExec is a Gaim Plugin that lets you execute commands from within a Gaim conversation. SlashExec provides a limited command-line interpreter for this purpose. SlashExec can also either display the command's output locally or send the output as a message in the current conversation. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#327425: ITP: gaim-slashexec -- adds functionality to execute commands from within a Gaim conversation
owner 327425 ! thanks Benjamin Seidenberg wrote: Package: wnpp Severity: wishlist Owner: Benjamin Seidenberg <[EMAIL PROTECTED]> Package name: gaim-slashexec Version : x.y.z Upstream Author : Gary Kramlich <[EMAIL PROTECTED]> Peter Lawler Daniel 'datallah' Atallah URL : http://guifications.sourceforge.net/SlashExec/ License : GPL Description : adds functionality to execute commands from within a Gaim conversation SlashExec is a Gaim Plugin that lets you execute commands from within a Gaim conversation. SlashExec provides a limited command-line interpreter for this purpose. SlashExec can also either display the command's output locally or send the output as a message in the current conversation. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12.2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Version: 1.0 Sorry, missed a field. Also used wrong email (annoyed at reportbug for not honoring $DEBEMAIL) Cheers, Benjamin signature.asc Description: OpenPGP digital signature
Re: Bug#327425: ITP: gaim-slashexec -- adds functionality to execute commands from within a Gaim conversation
Hamish Moffatt wrote: On Fri, Sep 09, 2005 at 09:24:20PM -0400, Benjamin Seidenberg wrote: Sorry, missed a field. Also used wrong email (annoyed at reportbug for not honoring $DEBEMAIL) Err, it does? Hamish See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324341 . It now won't unless the config file is set, which mine was because I came from a version before the fix. Benjamin signature.asc Description: OpenPGP digital signature
Re: Easy third-party package installer for debian-based distributions
Sami Dalouche <[EMAIL PROTECTED]> writes: OK, may be an overkill. But what happens with your solution if skype depends on libskype, which is not available from debian's repository ?The user has to download several .debs in order to install a single software ? Skype should set up their own Debian repository and tell people to add it to /etc/apt/sources.list. It's not exactly hard. Agreed. And if they HAVE to have some kind of one click installer, make a small script. #!/bin/sh echo "http://whatever/path/to/repository"; >> /etc/apt/sources.list apt-get install skype signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: Bug#331528: ITP: debinstaller -- a graphical frontend for installing local .deb packages
Joe Smith wrote: I wonder why nobody did implement that feature before. I imagine (without knowing much about APT's internals), the pseudocode would look like that: - install command gets the list - if the package does not exist in the cache and the given string is a file, then: - read the metadata of this package - creating a virtual sources set containing that package and inject it somewhere in APTs graph representation. The access method would be "file:", and it should get the highest possible priority (at least higher than any seen priority) - install the prerequisites and then the package with the usual methods fi would it not be simpler to have have apt just ask dpkg what the dependencies of the passed .deb are and then install the dependencies (and their dependecies) and then just pass the deb directly to dpkg? I see no need to create a virtual sources set or worry about priorities as the next time the apt is run the package will be seen as 'obsolete or locally created' (unless it exists in the repository), and therefore would use whatever priority apt gives such packages. But then again this might be too mutch of a kluge. I agree. I think that there should be a way to use apt to install a .deb with automatic dependency handling (in fact when I first began using debian I tried several times to install a .deb using apt). I don't know why this functionality was never written. It seems to be fairly trivial. Perhaps there were some reasons that precluded this feature? Benjamin signature.asc Description: PGP signature signature.asc Description: OpenPGP digital signature
Re: Bug#333844: override changes are not announced to the package maintainers
Matthias Klose wrote: Package: general override change are not announced to the package maintainers, _after_ a package is uploaded. I don't beleive this is true. I just got the following email from the archive: --- Subject: easyh10 override disparity There are disparities between your recently accepted upload and the override file for the following file(s): easyh10_1.0.0-1_alpha.deb: package says priority is optional, override says extra. easyh10_1.0.0-1_i386.deb: package says priority is optional, override says extra. easyh10_1.0.0-1_sparc.deb: package says priority is optional, override says extra. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. [NB: this is an automatically generated mail; if you replied to one like it before and have not received a response yet, please ignore this mail. Your reply needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) signature.asc Description: OpenPGP digital signature
Re: eidviewer menu entry
Wouter Verhelst wrote: On Sat, Nov 12, 2005 at 06:33:07AM -0500, Kevin Mark wrote: On Sat, Nov 12, 2005 at 11:44:50AM +0100, Wouter Verhelst wrote: [eidviewer menu category] These things are about user identity and authentication for possibly bank transactions or login like cryptographics tokes, no? Well, yes and no. It's supposedly possible to turn the X.509 key on the eID card into something that can be used as an SSH key (though I wouldn't know exactly how); also, with the (provided) mozilla plugins you can use it to sign emails, etc. However, the eidviewer (what this query is about) has nothing to do with all that. A typical use case for the eidviewer is a hotel reception where identity information needs to be stored and/or printed out. That's something entirely different... So, wouldn't they be in the same catagory as pgp or openct thingy? I could do that, except that none of the binaries in opensc, openct, or gnupg have a menu entry. What about th eGUI frontends? For me, GnomePGP is in Apps -> Tools. signature.asc Description: OpenPGP digital signature
Re: New README.source documentation for Debian packages
martin f krafft wrote: > also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.04.29.0113 +0200]: >> Here is a sample of the sort of documentation that would satisfy this >> recommendation, written for a package that's using quilt: > > Might I suggest that for such cases, a common file explaining how to > use quilt can be used or better yet: referred to? > Full ACK. I'd also like to see one for dpatch. Possibly something that can just be symlinked too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: update on binary upload restrictions
Tollef Fog Heen wrote: > * Joey Hess > > | > (b) source only uploads are in my experience very often badly tested > | > if they're even tested at all. For a long time after Ubuntu > | > switched to source only uploads, it was really obvious that a > | > large number of them hadn't even been test built, never mind > | > installed or used.[3][4] > | > | Hmm, are you implying that it eventually got better? > > It seems to have gotten better now, yes. However, people are often > quite happy to just throw source at the buildds until it builds, at > least unless they're told not to. This is less of a problem for > Ubuntu than Debian because Ubuntu's slowest arch is quite fast, while > doing the same to the Debian ARM port would make the buildd (and the > buildd operator) very unhappy. If we do go to source-only uploads, could this problem be avoided by having arm and other slow arches wait until at least one other arch successfully builds the package? signature.asc Description: OpenPGP digital signature
Re: Handling of (inactive) Debian Accounts
Mike Hommey wrote: > On Mon, Feb 12, 2007 at 07:47:48AM +0100, Yves-Alexis Perez <[EMAIL > PROTECTED]> wrote: > >> Yeah, you're perfectly right. That's the best advice one could give to >> not so active DD who doesn't want to lose much time («"lose" the time to >> vote so you don't "lose" the time in NM»). But as someone said, some DD >> may not be interested in Debian politics (and especially since >> recently), and Debian is first about about tech, so they may have lost >> all interest in politics (to the point of forgetting that "Voting" is >> present in the DD Duties, in dev-ref). >> > > The difference between a DD and a non-DD is mainly about voting, so if a > DD doesn't have interest in politics, he could just do like a lot of > non-DD people: have a sponsor. > > Mike > > > Someone could be interested in voting on things like the GFDL, technical questions, etc, but not care about the DPL election. Benjamin signature.asc Description: OpenPGP digital signature
Re: /foo has been mounted xx times... check forced
Theodore Tso wrote: > > At the moment, if you want ^C to interrupt the e2fsck and you want the > boot to continue, you actually have to set the following in > /etc/e2fsck.conf: > > [options] > allow_cancellation = 1 > > See the e2fsck.conf(8) man page for more details. > > Regards, > > - Ted Is there a way to set hard and soft limit? IE, after 30 mounts, checking is strongly suggested and automatically run, but able to be canceled but after 35 it is mandatory? Benjamin signature.asc Description: OpenPGP digital signature
Re: Bug#412570: ITP: fldigi -- digital modem program for hamradio operators
Joop Stakenborg wrote: > Package: wnpp > Severity: wishlist > Owner: Joop Stakenborg <[EMAIL PROTECTED]> > > > * Package name: fldigi > Version : 1.30 > Upstream Author : David H. Freese <[EMAIL PROTECTED]> > * URL : http://www.w1hkj.com/Fldigi.html > * License : GPL > Programming Lang: C++ > Description : digital modem program for hamradio operators > > fldigi is a Digital modem program for Linux written with the Fast Light > Toolkit. It supports most of the modern digital modes used by hamradio > operators. It can also be used for soundcard calibration and frequency > measurement. A CW decoder is included. > I would suggest adding a word about the interface - is it a GUI or console program? > -- System Information: > Debian Release: 4.0 > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.18-4-k7 > Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) > > > signature.asc Description: OpenPGP digital signature
Re: Bug#412570: ITP: fldigi -- digital modem program for hamradio operators
Aaron M. Ucko wrote: > Benjamin Seidenberg <[EMAIL PROTECTED]> writes: > > >> I would suggest adding a word about the interface - is it a GUI or >> console program? >> > > FLTK is a GUI toolkit. > > Ah, I didn't know that. Thanks. signature.asc Description: OpenPGP digital signature
