Bug#578580: ITP: skipfish -- A fully automated, active web application security reconnaissance tool
Package: wnpp Severity: wishlist Owner: Martin Meredith * Package name: skipfish Version : 1.32b Upstream Author : Michal Zalewski * URL : http://code.google.com/p/skipfish * License : Apache Programming Lang: C Description : A fully automated, active web application security reconnaissance tool Key features: High speed: pure C code, highly optimized HTTP handling, minimal CPU footprint - easily achieving 2000 requests per second with responsive targets. Ease of use: heuristics to support a variety of quirky web frameworks and mixed-technology sites, with automatic learning capabilities, on-the-fly wordlist creation, and form autocompletion. Cutting-edge security logic: high quality, low false positive, differential security checks, capable of spotting a range of subtle flaws, including blind injection vectors. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100420232002.53d7d...@lazy.sourceguru.net
Intending to Hijack pound
Hi all, As it seems the maintainer for pound is MIA, I intend to hijack this package. This will be placed in a 3 day DELAYED queue later on today. If there are any objections, please give me a shout via email (Please CC me in the reply, as I only read the lists on occasions) -- Regards, Martin "Mez" Meredith signature.asc Description: Digital signature
Re: Environment variable for alioth login names.
On Fri, Dec 26, 2008 at 06:58:36PM +0100, Adeodato Simó wrote:
> * Charles Plessy [Sat, 27 Dec 2008 02:51:00 +0900]:
>
> > Dear all,
>
> Hola,
>
> > I am playing with Joey Hess's `mr' tool and try to prepare a configuration
> > file
> > shareable by people having the same interests. I have a lines like this:
>
> > [debian-med/insighttoolkit]
> > checkout = svn co
> > svn+ssh://${aliothlog...@svn.debian.org/svn/debian-med/trunk/packages/insighttoolkit/trunk/
>
> > I was just wondering if some scripts are already using an environment
> > variable
> > for storing the alioth login name (ALIOTHLOGIN above), so that I can use the
> > same and reduce environment chaos…
>
> In my opinion, the proper way to address this issue is to configure a
> username for svn.debian.org in ~/.ssh/config; that way
> svn+ssh://svn.debian.org/... works directly, without having to specify a
> username.
>
> Example (if you're a DD):
>
> Host *.debian.org
> User foo
Also, if you're a DD and your local username is the same as your DD Account
name, then there's no need to
even add that in!
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Package plugins packaging
On Sun, 2008-11-09 at 17:24 +0100, Vincent Fourmond wrote: > Hello, > > Всеволод Величко wrote: > > May be, you can help me with the following? > >> which CC licenses are treated as DFSG compatible now? Could someone read > >> this license: > >> http://pastebin.com/m4ba1c5ed and say, can I package smile pack, which > >> uses this license, > >> for the non-free section, or it'll be rejected? > > I see this: > > - You can distribute them for free use in forums, chats and other > applications, as long as the smiles are unmodified and this text file is > included within the RAR file. > - You may not repackage them and redistribute them with other smiles > without my permission. > > This makes it look like it is not possible to switch from the original > archive to any other kind of archive. So you cannot distribute it as a > Debian package. Drop it ;-)... Or, put the rar file in a tarball, and it qualifies for non-free if it's REALLY important to have it available. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG-violations and NEW and DFSG-violations and I would fix them, but...
On Fri, 2008-10-24 at 10:57 +0300, Kalle Kivimaa wrote: > Reinhard Tartler <[EMAIL PROTECTED]> writes: > > With "Like this" I mean packages that have been held back in NEW for a > > very long time without response or REJECTED with an reason not > > acceptable to the maintainer? Does mediating this kind of issues fall > > under the authority of the TC, or should they be escalated rather to the > > DPL? > > Well, if a package is in NEW for a long time, that's something that > really cannot be mediated, as it probably means that none of the > ftpmasters (or assistants) have had the time to look into it (meaning > it is very likely a very complex package with licensing issues), and > no authority in Debian can force any project member to do work the > member doesn't want to do. > > If a package is REJECTED with a reason the maintainer thinks is > invalid, I think the first step should be to tell the ftpmaster (as a > group) the reasons. It is always possible that a ftpmaster (as a > person) has made a mistake. Indeed, I recently actually had this happen to me. An upload that I made was rejected by an FTP Master (for convenience copies of code) - when I pointed out to the FTP master the reason(s) why this was there (was actually modified from upstream, debian didn't have the latest package, the latest packages had huge API changes, etc etc) - he was happy to let it through. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lenny frozen
On Mon, 2008-07-28 at 17:15 +0200, Olivier Berger wrote: > OK, thanks. > > I still am not completely sure about something : should only bugs of > severity >= "important" be fixed (and uploaded to unstable for the > "important" ones) in order for inclusion in lenny, or also lesser > severities too ? As far as I can tell, unstable continues as normal. However, nothing that is uploaded to unstable as of the start of the freeze will be automatically migrated into testing. severity >= "important" are a reason that you might ask for an exception to the freeze, which, if accepted, will allow that package to be migrated to testing as it would normally do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Pre-Depends addition for debconf on package rar
As mrvn pointed out to me earlier, rar's licence should be displayed to the user before the package is installed. To this end, I plan to add a preinst script which displays the licence to the user, and lets them agree or disagree to the licence. As policy frowns on Pre-Depends, I thought I'd check here first -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Pre-Depends addition for debconf on package rar
As mrvn pointed out to me earlier, rar's licence should be displayed to the user before the package is installed. To this end, I plan to add a preinst script which displays the licence to the user, and lets them agree or disagree to the licence. As policy frowns on Pre-Depends, I thought I'd check here first signature.asc Description: This is a digitally signed message part
Re: Non-free question regarding upstream releasing different binary-only tarballs for different architectures
On Tue, 2008-06-17 at 11:13 +0800, Paul Wise wrote: > On Tue, Jun 17, 2008 at 3:36 AM, Martin Meredith <[EMAIL PROTECTED]> wrote: > > > Any thoughts? > > Not sure if dak/buildds can handle this, but what about multiple > source packages? > > Something like unrar-nonfree-64 producing rar binary package for amd64 > and unrar-nonfree-32 producing rar binary package for i386. Buildd's wouldn't have anything to do with it anyway, as it's not auto-built. Would an ftp-master be able to answer whether thats possible? (having 2 different source packages provide debs for the same source package, but different architectures) signature.asc Description: This is a digitally signed message part
Non-free question regarding upstream releasing different binary-only tarballs for different architectures
Hi there. I currently maintain rar and unrar-nonfree in debian. When uscanning for the latest version of rar - it started to download the x64 version, which I haven't seen before. Anyway - It seems that upstream are now packaging a i386 binary, and an x64 binary. I'm not too sure how I should handle this, currently - I've been using ia32-libs for x64... but with the new tarball, I don't know if I can do this. I'm also pretty sure that the licence doesn't let me do a "tarball-in-tarball" thing (orig.tar.gz has to stay the same) Any thoughts? signature.asc Description: This is a digitally signed message part
Where to put in Menu?
Hi there, Looking over the lintian reports for katapult, I've noticed that the Apps/Tools section seems to be missing now from the menu system (yes, I know I'm a bit late - but better late than never!) Anyway, I can't see a suitable alternative for katapult, any ideas? (Please reply to list + myself incase I miss this in the flood of mailing list traffic) Regards, Mez signature.asc Description: This is a digitally signed message part
Re: Where to put in Menu?
On Tue, 2008-01-01 at 18:32 -0800, Russ Allbery wrote: > Martin Meredith <[EMAIL PROTECTED]> writes: > > > Looking over the lintian reports for katapult, I've noticed that the > > Apps/Tools section seems to be missing now from the menu system (yes, I > > know I'm a bit late - but better late than never!) > > > > Anyway, I can't see a suitable alternative for katapult, any ideas? > > > > (Please reply to list + myself incase I miss this in the flood of > > mailing list traffic) > > It looks like katapult is a launcher, which seems like a gap in the > current menu policy. I don't see a good category for applications that > launch other applications. > > I'd probably use Applications/File Management as the closest compromise, > but I'm cc'ing the menu maintainer in case he has another suggestion. I'm guessing that gnome-do, kommando, and some others would come under a similar place in the menu, could it possibly be worth adding a new subsection? signature.asc Description: This is a digitally signed message part
Re: Derived distributions and the Maintainer: field
However, if you were to request it - either through a member of core-dev - or through the person who last updated the package, then as long as yourdebian package worked exactly as it is intended to in ubuntu - I'm sure they'd not have a problem with syncing and using your package from debian. The only reason packages are changed in ubuntu is because they don't work as expected in ubuntu - whether this be a different "vision" for the package's use, or just a problem with it having gone through a different transition/having a different toolchain, is a different point. But even so - We DO try and use as many things as possible from debian unchanged ;) Thomas Bushnell BSG wrote: > Henning Makholm <[EMAIL PROTECTED]> writes: > >> Scripsit Nathanael Nerode <[EMAIL PROTECTED]> >> >>> If they are also compiled with a toolchain unchanged from Debian, >>> the binaries can legitimately have the same Maintainer: field as in >>> Debian, because they are essentially the same package. >>> If not, the binary packages should have different Maintainer: >>> fields, unless the maintainer agrees to have his name on it. >> You seem to require a standard of attribution in the Maintainer field >> that Debian does not itself follow in our default procedures. To wit: >> NMUs _within_ Debian keep the Maintainer field unchanged. > > The difference is that a Debian Maintainer can replace the NMU any > time he wants with his own package. > > I don't have the same ability to replace a non-Debian altered package. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Thomas Bushnell BSG wrote: > I have only said that I would like Ubuntu to clearly label > which is the Debian maintainer and which is the Ubuntu maintainer. Thing is, in ubuntu - we don't neccesarily have "maintainers" for packages. We use a collaborative process - anyone who had access can modify the package. Basically - many many people can change a package, which can be confusing for people. Usually, there is someone you can contact regarding a specific package, and it will either be dealt with by that person, or passed on to the relevant person. Personally, I used to use the ubuntu bugzilla to see who to contact regarding a specific package, whoever the bug was assigned to was the person to contact - but I'm not sure how to get that information now. It's basically a fact that most people outside of ubuntu don't know the structure within ubuntu of wo to contact about certain packages etc etc - I know I've had problems myself, but usually, you will have a specific person taking care of a package in main. I think that this is a big problem, and could easily be solved by having either proper QA contacts for packages, or at least having a list somewhere of who to contact for what package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Games Team
Ben Finney wrote: > On 13-Jan-2006, Miriam Ruiz wrote: > >> --- Eddy Petriºor <[EMAIL PROTECTED]> escribió: >> >>>Can ome packaging can be done for non-free games? >> >>To be honest, I'm not particulary interested in non-free software at >>all, including games, but I have nothing against it if we decide as >>a group to do so. In my oppinion there's so much work to do about >>free games that I don't think it's a good idea giving away our time >>to non-free projects. > > > Seconded. This Debian user would be much better pleased by Debian's > efforts going to improving the packaging and coordination of free > software games. > Thirded :D lol - I'd love to participate in this - but more on the side of "game utilities" like aabrowse :D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Please read my first couple of lines in the email - as quoted below >>Ok - I'm going to reply to the first post i found on this whole - >>thing, so apologies if it shows up in some weird place in threaded >>view. Manoj Srivastava wrote: > OK. Since you selected my post to reply to -- are you implying > that choosing not to use a propreitary, non-free, repository system > for primary debian development, and abandoning my decade old workflow > processes constitute non-cooperation? > > manoj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
It has come to my attention that this last email could have been construed as a personal attack against a certain ubuntu developer. It is not meant that way. What I don't seem to have put across properly are the following points. 1) the blog post mentioned that made me irate was because of the way It was worded andhow i read it at the time. I didnt read this properly the first time round - and the opinion is expressed about what I thought the person was trying to put across. After re-reading the article - I changed my mind (but would still have been irate if the post had been what I first thought it was) 2) I am not lumping all Ubuntu Devs into one boat - nor all Debian Devs - I'm jsut saying that I think it's the few people out of the large who arent willing to cooperate for whatever reason that are causing this tension. Martin Meredith wrote: > Ok - I'm going to reply to the first post i found on this whole - thing, so > apologies if it shows up > in some weird place in threaded view. > > Basically the way I see it isnt the fact that ubuntu isn't giving back to > debian - or debian isn't > willing to have the stuff from ubuntu. The way i see it is that there are a > few people - who - for > some reason or another - just don't do the right thing. > > I can definately understand some DD's views here - they seem to get nothing > from ubuntu - have to > wade through patches or whatever to try and find the useful stuff - have to > do all this work to get > all the stuff from ubuntu, because whatever ubuntu dev is doing things isn't > contributing back to > debian. This definately happens. There's no doubt about it. > > But, also - and I've had this experience myself - there are some DD's who > just plain and simple dont > want the stuff from ubuntu. I've had a couple of times where I've had an > issue with a package - and > realised it was a problem in debian and upstream too. Usually - I've > contacted both upstream and the > DD via Email about this - and have had various responses - for example, for > one package - I sent > about 7 emails over the space of a month, emailed upstream, tried to contact > the DD on IRC - many a > thing - but well - no response - and I've tried a couple of times with > different issues to contact > that developer regarding those issues - but have never had any > awknowledgement, reply etc etc. > > I eventually gave up trying contacting that maintainer - and just carried on > with the work in ubuntu > - and worked with upstream. It's people like that that are spoiling it, as > I've had experiences with > other DD's who've been very helpful indeed. > > Recently, a certain member of the MOTU team in ubuntu posted a blog post > basically saying (from the > way it came across to me) that contributing back up to debian was a waste of > our meagre resources. I > can't express how ... and this is a very mild way of me putting it (Code of > Conduct and all - darn > it!)... annoyed that made me - I was infuriated, espescially seeing as I'd > been one of those people > who'd raised the issue of contributing back to debian. > > I, personally - see contributing to debian as a vital part of the ubuntu > development process - after > all - debian is our upstream - and I'm sure none of the DD's would think that > contributing to > upstream for the packages they maintain is a waste of the time that they > could be putting back into > debian. > > To me though - and i will stress this highly - I don't think that it's a fact > that ubuntu isnt > contributing to debian - because it is. But I believe that some people (maybe > a lot of people) for > whatever issue aren't willing to work either way - as Ubuntu can't do all the > work - and nor can > debian - but - when one side isnt willing to work (I'm not on about projects > as a whole - I'm on > about individual people/maintainers) then it spoils the whole thing. > > Basically - I dont think the brand should be put on ubuntu as a whole - feel > free to target those > people specifically you see not contributing - but remember - it's a two way > thing - and there are > people not willing to cooperate on both sides. > > *dons asbestos underwear and waits for replies* > > > > > Manoj Srivastava wrote: > >>On Fri, 06 Jan 2006 15:19:42 -0500, Frans Jessop >><[EMAIL PROTECTED]> said: >> >> >> >>>Ubuntu's launchpad is amazing. Do you think it would be helpful if >>>all DD's worked through it on their projects? >> >> >>
Re: Need for launchpad
Ok - I'm going to reply to the first post i found on this whole - thing, so apologies if it shows up in some weird place in threaded view. Basically the way I see it isnt the fact that ubuntu isn't giving back to debian - or debian isn't willing to have the stuff from ubuntu. The way i see it is that there are a few people - who - for some reason or another - just don't do the right thing. I can definately understand some DD's views here - they seem to get nothing from ubuntu - have to wade through patches or whatever to try and find the useful stuff - have to do all this work to get all the stuff from ubuntu, because whatever ubuntu dev is doing things isn't contributing back to debian. This definately happens. There's no doubt about it. But, also - and I've had this experience myself - there are some DD's who just plain and simple dont want the stuff from ubuntu. I've had a couple of times where I've had an issue with a package - and realised it was a problem in debian and upstream too. Usually - I've contacted both upstream and the DD via Email about this - and have had various responses - for example, for one package - I sent about 7 emails over the space of a month, emailed upstream, tried to contact the DD on IRC - many a thing - but well - no response - and I've tried a couple of times with different issues to contact that developer regarding those issues - but have never had any awknowledgement, reply etc etc. I eventually gave up trying contacting that maintainer - and just carried on with the work in ubuntu - and worked with upstream. It's people like that that are spoiling it, as I've had experiences with other DD's who've been very helpful indeed. Recently, a certain member of the MOTU team in ubuntu posted a blog post basically saying (from the way it came across to me) that contributing back up to debian was a waste of our meagre resources. I can't express how ... and this is a very mild way of me putting it (Code of Conduct and all - darn it!)... annoyed that made me - I was infuriated, espescially seeing as I'd been one of those people who'd raised the issue of contributing back to debian. I, personally - see contributing to debian as a vital part of the ubuntu development process - after all - debian is our upstream - and I'm sure none of the DD's would think that contributing to upstream for the packages they maintain is a waste of the time that they could be putting back into debian. To me though - and i will stress this highly - I don't think that it's a fact that ubuntu isnt contributing to debian - because it is. But I believe that some people (maybe a lot of people) for whatever issue aren't willing to work either way - as Ubuntu can't do all the work - and nor can debian - but - when one side isnt willing to work (I'm not on about projects as a whole - I'm on about individual people/maintainers) then it spoils the whole thing. Basically - I dont think the brand should be put on ubuntu as a whole - feel free to target those people specifically you see not contributing - but remember - it's a two way thing - and there are people not willing to cooperate on both sides. *dons asbestos underwear and waits for replies* Manoj Srivastava wrote: > On Fri, 06 Jan 2006 15:19:42 -0500, Frans Jessop > <[EMAIL PROTECTED]> said: > > >>Ubuntu's launchpad is amazing. Do you think it would be helpful if >>all DD's worked through it on their projects? > > > Sure, as long as they change lauchpad to meet my workflow > requirements. This would mean letting me have a local repo, signed > remote repos, arch, email only interfaces, and not getting into my > way. If they make changes to meet these requirements, I'll have > absolutely no problem throwing away tools I have worked on honing for > a decade or so and switching to launchpad. Oh, and release launchpad > under a free license, of course, so I don't make Debian development > rely on a non-free toolset, of course. > > >>Wouldn't that keep things more organized and efficient? Or perhaps >>Debian could build its own version of launchpad which is better. >>Again, I think it would do a good job keeping everything organized >>an efficient. > > > Yup. Having all humans speak just a single language (and none > of these darned wide charset junk) would be way more efficient too. > And just have one model of a car -- I mean, who needs all these > different companies, so much inefficiency. > > BTW, thanks for the laugh. > > manoj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
immodule in Qt problems
Apparently - theres a major problem with immodule in Qt at the moment - which causes KeyReleasedEvent ro return a value of 0 for any QKeyEvent ... which is bad - and means that anything that relies on it will have problems processing the keypresses. I found this out after my app in ubuntu had problems - and traced it down to this Is it planned to include immodule in etch - ? because if so - I think this should be taken into consideration - as it could be an RC bug. No problems without immodule though -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#346569: ITP: idjc -- simple console for broadcasting/recording Internet Radio shows
Package: wnpp Severity: wishlist Owner: Martin Meredith <[EMAIL PROTECTED]> * Package name: idjc Version : 0.5.7 Upstream Author : Stephen Fairchild <[EMAIL PROTECTED]> * URL : http://www.onlymeok.nildram.co.uk * License : GPL Description : simple console for broadcasting/recording Internet Radio shows Internet DJ Console is an application allowing people to broadcast Internet Radio Streams Using the Jack Server - it allows all the conventional tools that a DJ needs, including Crossfader, "listen" features (allowing you to cue up one track while broadcasting another), Microphone input, and VOIP conferencing integration. It can broadcast both Shoutcast and ICECast (2&3) streams, and can also record the output locally -- 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.15-11-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
Manoj Srivastava wrote: > On Fri, 06 Jan 2006 15:19:42 -0500, Frans Jessop > <[EMAIL PROTECTED]> said: > > >>Ubuntu's launchpad is amazing. Do you think it would be helpful if >>all DD's worked through it on their projects? > > > Sure, as long as they change lauchpad to meet my workflow > requirements. This would mean letting me have a local repo, signed > remote repos, arch, email only interfaces, and not getting into my > way. If they make changes to meet these requirements, I'll have > absolutely no problem throwing away tools I have worked on honing for > a decade or so and switching to launchpad. Oh, and release launchpad > under a free license, of course, so I don't make Debian development > rely on a non-free toolset, of course. Other than the email interface - they have most of that planned in hct :D https://wiki.launchpad.canonical.com/HCT >>Wouldn't that keep things more organized and efficient? Or perhaps >>Debian could build its own version of launchpad which is better. >>Again, I think it would do a good job keeping everything organized >>an efficient. > > > Yup. Having all humans speak just a single language (and none > of these darned wide charset junk) would be way more efficient too. > And just have one model of a car -- I mean, who needs all these > different companies, so much inefficiency. > > BTW, thanks for the laugh. > > manoj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345909: ITP: qtodo -- Todo List Manager
Package: wnpp Severity: wishlist Owner: Martin Meredith <[EMAIL PROTECTED]> * Package name : qtodo Version : 0.1 Upstream Author : Tobias [EMAIL PROTECTED]> * URL : http://qtodo.berlios.de/ * License : GPL Description : Todo List Manager QTodo is a todo-list manager. It is designed to be simple but powerful and focused on helping the user to get things actually done. -- 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.15-9-386 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
