Bug#932103: RFP: fuidshift -- remap a filesystem tree to shift one set of UID/GID ranges to another
On 15/07/2019 06:16, Nicholas D Steeves wrote: > Package: wnpp > Severity: wishlist > > Package name: fuidshift > Version : 3.0 > Upstream Author : Name > URL : https://github.com/lxc/lxd/tree/master/fuidshift > License : Apache 2.0 > Programming Lang: Go > Description : remap a filesystem tree to shift one set of UID/GID ranges > to another > > Fuidshift is useful for converting privileged containers to > unprivileged ones, and also to adapt a container master to multiple > users' authorised subuid and subguid ranges. It also sounds like it > might be useful for fixing up cases where --numeric-owner should have > been used, but where it would be too labour-intensive to manually chown. > > I learned about this tool via the following document: > https://github.com/BenSartor/unprivileged-lxc-containers > > Here is the upstream description: > > This tool lets you remap a filesystem tree, switching it from one > set of UID/GID ranges to another. > This is mostly useful when retrieving a wrongly shifted filesystem tree > from a backup or broken system and having to remap everything either to > the host UID/GID range (uid/gid 0 is root) or to an existing container's > range. > A range is represented as > :::. > Where "u" means shift uid, "g" means shift gid and "b" means shift uid and > gid. > > https://github.com/lxc/lxd/blob/81b81b9ace3064c8065319f4e984378244587d80/fuidshift/main_shift.go#L26-L36 > > It's part of the LXD project, but I'm not sure if it's as difficult to > package as LXD itself, which is one reason why I've CCed the Go team. > I also wonder if the best way to get this into Debian would be a > src:lxd that produces bin:fuidshift. > > An alternative to this, written on C, is uidmapshift that can be found at https://code.launchpad.net/~serge-hallyn/+junk/nsexec Its packaged for Arch, see: https://wiki.archlinux.org/index.php/Linux_Containers#Converting_a_privileged_container_to_an_unprivileged_container signature.asc Description: OpenPGP digital signature
Bug#822221: ITP: flipcoin -- flip an adjustable coin for random exit status
On 22/04/16 14:48, Adam Borowski wrote:
> On Thu, Apr 21, 2016 at 11:11:39PM -0700, Rudi Cilibrasi wrote:
>> * Package name: flipcoin
>> * URL : https://github.com/rudi-cilibrasi/flipcoin
>> Description : flip an adjustable coin for random exit status
>>
>> This command-line utility can be used to simulate a coin flip to get
>> a random exit status. The probability of success is adjustable using
>> an optional command line parameter.
> [...]
>> This package is a useful core utility for shell scripts that need to
>> do things in a way that is decorrelated in time and infrequent. Usage is
>> simple at the shell prompt:
>>
>> if flipcoin ; then echo heads ; else echo tails ; fi
>
> Sorry, but I don't believe that someone writing shell scripts is likely to
> not know one of many ways to do this, be it $RANDOM, perl, awk, or, if you
> really want to require something non-essential, rolldice.
>
> Thus, please reconsider the point of packaging this.
>
>
> Meow!
>
Indeed. With bash:
flipcoin() { return $(($RANDOM % 2)); }
if flipcoin ; then echo heads ; else echo tails ; fi
:)
signature.asc
Description: OpenPGP digital signature
Bug#686447: [Pkg-zfsonlinux-devel] Summary of ZFS on Linux for Debian
Hi Lucas, It has been already 3 months since you requested ftp-masters to ACK the mail quoted below. I have already requested several times on the IRC (#debian-ftp) to the ftp-team to ACK your mail, and they ignored my requests. I think that 3 months of waiting for an ACK is more than enough. At this point, I kindly ask you to pass our mail regarding the license issues about ZoL to the SFLC lawyer in the next couple of days if you don't get an ACK or a reply from ftp-masters about this issue. Thanks. On 31/08/14 01:28, Lucas Nussbaum wrote: Hi, On 29/08/14 at 09:42 +0800, Aron Xu wrote: Dear DPL and FTP Masters, As agreed at DebConf 14, Debian ZFS on Linux Maintainers have concluded into the following summary for the situation, please see as follows. Thanks a lot for this work. I think that adding an actual question to our legal counsel would help focus their work. If I understand correctly, that question should be: Does this summary accurately represents your understanding of the question? Can Debian distribute a ZoL package using (1) Source code and (2) Binary Linux LKM? In any case, I'll wait for comments or ACK from ftpmasters before forwarding your mail to SFLC. Lucas ___ Pkg-zfsonlinux-devel mailing list pkg-zfsonlinux-de...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-zfsonlinux-devel signature.asc Description: OpenPGP digital signature
Bug#686447: [zfs-discuss] Re: Licence issues and non-issues with ZoL: CDDL and GPL
On 30/08/14 01:03, Andreas Dilger wrote: On Aug 29, 2014, at 4:48 PM, Prakash Surya m...@prakashsurya.com wrote: On Fri, Aug 29, 2014 at 03:33:15PM -0600, Andreas Dilger wrote: On Aug 29, 2014, at 4:49 AM, Carlos Alberto Lopez Perez clo...@igalia.com wrote: On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote: Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it. On 27/08/14 16:38, Andreas Dilger wrote: Hi Carlos, I've been dealing with ZoL and the GPL/CDDL issues for a number of years for the Lustre filesystem. IANAL, but know quite a bit about these issues so I'd be happy to help out if I can. Thanks for the offer to help. Aron has posted our summary about the situation [1]. If you want to comment on it that would be great. In general I think this is a very well written summary of the issues. I think it is a disservice to your argument that you equate CDDL with proprietary binary licenses such as those used for NVidia or Broadcom. I would definitely seek clarification of what part of the spirit of the GPL is being violated. I think the most important point is that CDDL is an OSI-approved _open_source_ license, which eliminates IMHO the biggest objection to proprietary binary modules, since the source for ZFS is available for debugging, modification, and redistribution. The CDDL is actually a permissive license and even grants patent indemnification for any patents embodied in the original ZFS code (similar to GPLv3). It is the GPL that restricts distributing with CDDL code and not the reverse (CDDL 3.6 explicitly allows this). I probably could read the GPL and figure this out, but, in what way does the GPL restrict distribution of GPL and CDDL code together? And maybe how it specifically relates to this instance, as the ZFS code is obviously not a derived work of any GPL project. You are right, and I forgot to make this important point as I was writing my first email. It is clear that ZFS is _not_ a derived work of Linux (originally written for Solaris), and Linus has himself said this in the past about AFS [1], and the GPL only covers code which is derived: If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. and just distributing them together does not change this: In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. so if the ZoL module is not distributed as part of the kernel (i.e. in a separate package) it is no more incompatible with the GPL than any other piece of software that is available via download or on the same DVD as others. [1] http://yarchive.net/comp/linux/gpl_modules.html My understanding is that the part of the GPL that causes concerns is the one related to derived works. By comparing the CDDL with the proprietary licenses of the NVIDIA or Broadcom drivers, I tried to stress the point that this same concern related to derived works, would apply to any of this proprietary drivers. And Debian is already distributing this proprietary drivers in their archives. So it would be a non-sense that ZoL was deemed unsuitable for distribution by Debian, while at the same time Debian continues to distribute this proprietary drivers. You are right that maybe that comparison was not very fortunate. However, it should be kept in mind that the concerns of FTP Masters are not related with the CDDL license itself, but with the combination of GPL and CDDL in the same work. We hold the view that ZFS is not a derived work of the Linux Kernel, so the requirements of the GPL License for derived works would not apply to it, therefore both licenses could be satisfied at the same time when Debian distributes both the Linux Kernel and the ZFS driver (either in source code form, or as a binary loadable kernel module). Regards signature.asc Description: OpenPGP digital signature
Bug#686447: Licence issues and non-issues with ZoL: CDDL and GPL
On 27/08/14 14:33, Carlos Alberto Lopez Perez wrote: Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it. [...] On 27/08/14 16:38, Andreas Dilger wrote: Hi Carlos, I've been dealing with ZoL and the GPL/CDDL issues for a number of years for the Lustre filesystem. IANAL, but know quite a bit about these issues so I'd be happy to help out if I can. Thanks for the offer to help. Aron has posted our summary about the situation [1]. If you want to comment on it that would be great. Regards. [1] http://mid.gmane.org/20140829014229.GA9572@aron-laptop signature.asc Description: OpenPGP digital signature
Bug#759545: Ceni - Curses user interface for configuring network interfaces with ifupdown
Package: wnpp Severity: wishlist X-Debbugs-CC: k...@otaku42.de, bernard.g...@gmail.com, x-u...@berlios.de, s@gmx.de, andre...@debian.org * Package name: ceni Version : 2.28 Upstream Author : Kel Modderman k...@otaku42.de * URL : https://github.com/fullstory/ceni * License : GPL-2+ Programming Lang: Perl Description : Ceni - Curses interface to /etc/network/interfaces A Curses user interface for configuring network interfaces with ifupdown. Ceni can manage basic network interface ifupdown configuration stanzas for ethernet and wireless devices. signature.asc Description: OpenPGP digital signature
Bug#722451: Adoption
On 27/08/14 06:31, Prof. Dipl.-Ing. Klaus Knopper wrote: Hello, On Tue, Aug 26, 2014 at 11:56:48PM +0200, Carlos Alberto Lopez Perez wrote: On 11/08/14 23:50, MENGUAL Jean-Philippe wrote: Hi, Do you plan still to package Compiz? Do you have a problem which prevents this? Do you need help? Otherwise, can I adopt it so that someone and I can package it before freeze? Our work to prepare has now good improvement. Thanks, Regards, Hi, This bug is marked as RFP = Request For Package. This means that the reporter is asking for someone to package this software, but no one has still offered to package and maintain it. If you want to package/maintain it yourself, please retitle the bug to ITP = Intend To Package, assign the bug to yourself, and start working on it. Find here help about packaging for Debian: https://wiki.debian.org/DebianMentorsFaq#Packaging And here help about using the BTS (Bug Tracking System): https://wiki.debian.org/HowtoUseBTS https://www.debian.org/Bugs/server-control Thanks! Actually, I do package the compiz git from launchpad regularly for using it in Debian/Knoppix as the main window manager. Please find the source binary packaging here: http://debian-knoppix.alioth.debian.org/packages/compiz/ However, I'm not am official Debian Package Maintainer and thus the packages won't show up anywhere else than in Knoppix currently. You don't need to be a Debian Maintainer (DM) to maintain packages in Debian. Anyone can maintain packages in Debian. The only difference is that DM are allowed to upload directly to the archive, while not-DM people need that some DD (Debian Developer) review and sponsor the package. Once you are maintaining one or more packages in Debian you can apply to become a DM if you want, so you can upload further updates of your packages directly to the archive. We have a clear process defined for this. Once you have your package ready, you can upload it to mentors.debian.net (or to other site if you prefer) and you ask on the mailing list debian-ment...@lists.debian.org (subscribe yourself to the list) for someone to review and upload your package. Probably you will have to trim the Changelog for the initial upload to Debian, and include a line on it closing this bug #722451. But first you should retitle this bug to ITP and assign it to yourself, to show your intention of packaging Compiz for Debian. So anyone else that could be interested in doing the work is aware that you are already working on this. So we avoid duplicating work. signature.asc Description: OpenPGP digital signature
Bug#686447: Licence issues and non-issues with ZoL: CDDL and GPL (was: Re: [zfs-discuss] [Pkg-zfsonlinux-devel] zfs-linux_0.6.2-1_amd64.changes REJECTED)
On 26/08/14 23:00, Paul Richards Tagliamonte wrote: Hello, ZFS on Linux maintainers, At a recent ftpteam meeting we discussed this package, and what to do about it. Our consensus was that this package appears to violate the spirit of the GPL at minimum, and may cause legal problems. Judges often interpret documents as they're intended to read, hacks to comply with the letter but not the intent are not looked upon fondly. This may be a hard thing for technical folks to accept, but in legal cases one usually isn't dealing with technical people. As such, this package has been rejected with the following notes: * Please take care to fix your naming issues. Please talk with the kFreeBSD folks on how to best handle the namespace. The kFreeBSD folks had these names first, it's up to them how they're used. * We recommend that the DPL put a question to our lawyers, providing a full and complete background on the situation. (We are happy to help reviewing it before it gets sent off). We will defer judgement on the legality of distributing ZoL in Debian to them. Thanks, Paul, on behalf of the ftpteam We (the Debian ZoL package maintainers) have been talking about this. The Debian FTP Team wants us to write a summary of the situation regarding the license stuff describing how ZoL avoided violating the combination of GPL and CDDL. Then they may forward that to DPL (Lucas) and then to SPI's lawyer. They would be OK to accept the package if the lawyer says yes. We are already writing this summary. If someone wants to help please send me or Aron an e-mail. Maybe we could share a RFC of the summary here when we think is ready, in order to double-check our understanding of the license stuff and get more feedback about it. signature.asc Description: OpenPGP digital signature
Bug#722451: Adoption
On 11/08/14 23:50, MENGUAL Jean-Philippe wrote: Hi, Do you plan still to package Compiz? Do you have a problem which prevents this? Do you need help? Otherwise, can I adopt it so that someone and I can package it before freeze? Our work to prepare has now good improvement. Thanks, Regards, Hi, This bug is marked as RFP = Request For Package. This means that the reporter is asking for someone to package this software, but no one has still offered to package and maintain it. If you want to package/maintain it yourself, please retitle the bug to ITP = Intend To Package, assign the bug to yourself, and start working on it. Find here help about packaging for Debian: https://wiki.debian.org/DebianMentorsFaq#Packaging And here help about using the BTS (Bug Tracking System): https://wiki.debian.org/HowtoUseBTS https://www.debian.org/Bugs/server-control Thanks! signature.asc Description: OpenPGP digital signature
Bug#636679: ITP apitrace any progress?
On 12/03/14 10:39, Christopher James Halse Rogers wrote: Hi! It's been in an uploadable condition a couple of times over the last couple of years, but the DDs on the Debian X team have always been too busy to sponsor at those times (and I've never quite got around to apply for DD). I'll give it another update in git; a couple of the other Debian X guys are close to DD status, so the bandwidth for uploading should be better soon :) Hi, I think is easier to find a sponsor for your packages if you follow the documented procedure for RFS http://mentors.debian.net/sponsor/rfs-howto or you ask for it directly on the debian-mentors mailing list. Is also a good idea to include this bug in the CC, so people looking at this ITP like me can know that you are already actively looking for an sponsor. Thanks for the update. signature.asc Description: OpenPGP digital signature
Bug#636679: ITP apitrace any progress?
Hi, I'd wish to see this utility on Debian. This ITP has been open for more than 2 years already and the last update from the bug owner was more than one year ago. Christopher, is there any progress on this? If you are not longer interested or you don't have time for packaging apitrace on Debian, please retitle this bug to RFP so this package work can be taken by anyone interested and/or with time available. Thanks! signature.asc Description: OpenPGP digital signature
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 02/03/14 06:56, Turbo Fredriksson wrote: On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote: Hostile binary takeover is not allowed - that is two separate source packages should not build the same binary package names, even if on different architectures. Ok, sounds reasonable when you say it like that. I'd still appreciate a link to the policy for that. One possible example of theoretical breakage is to run the command apt-get source libzfs1, right now it downloads the kfreebsd/zfsutils sources, but I don't know what will happen when zfs-linux is allowed into the archives. Is apt intelligent enough to pick the source corresponding to the binary package of the host arch? signature.asc Description: OpenPGP digital signature
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/14 10:30, Turbo Fredriksson wrote: I'm basically Ccing half the world in this (only half sorry about that :) and I don't know who half of you are :), but there have been very little information on what's happening with ZoL in Debian GNU/Linux. Aron (and in some part Carlos) seems to have gone a-wall and the list have been VERY quiet. It seems like it's only Aron and me that is actually Debian GNU/Linux Developers (unless other things have happened outside the list that I'm not aware of - Carlos was/is a maintainer if I don't misremembering and Darik is in the wait queue?). And no actually status information/reason from the FTP maintainers about why it have been stuck in incoming for so long (accepted into incoming Sun, 07 Jul 2013 16:00:06 - that's more than six months ago!). Have it been rejected? Is it held up for some reason? What can I/we do to help move it along? I'm now the current Debian GNU/Linux Wheezy package maintainer (and have been for quite some time) for/in ZoL (upstream from Debian GNU/Linux I suppose) and I have contributed to both the packaging (that is already in the Alioth repos) as well as bits and pieces to ZoL code (such as SMB and iSCSI support - which will be accepted into post-0.6.3 which is due out very soon now we hope) and also wrote support for ZoL to be used as installation target (debian installer, part-man) etc. With that - I have a large vested interest in maintaining this and I work on it almost daily, so if no one else have the time (Aron, Carlos) I know that Darik is also very busy working on this, and he already maintain (and have for a very long time) the Ubuntu packages in ZoL, and much (most, all?) of the current packaging is from his busy hands. So I'd prefer to work with him on this (if aron/carlos don't have the time/interest that is - I'm not proposing to steal the packaging!). Since there have been next to no progress in the Debian GNU/Linux ZoL projects, I have done all my packaging stuff in the ZoL repos, so if/when this project is revitalized, I'll push all my work to the Debian GNU/Linux repos as individual commits. Hi, We are still waiting for ftp-masters. I already poked them yesterday and this was their answer: Thu Feb 26 #debian-ftp on OFTC [13:20] clopez anyone from the ftp team can quickly and gently tell me about the status of the package zfs-linux on NEW? It has been sitting there for 6 months already [14:28] paultag clopez: no one has had time to properly ensure the CDDL / GPL linking mess is above the table [14:29] paultag k [14:29] paultag whoops [14:29] clopez paultag: there is no CCDL / GPL linking: the package only ships the kernel module in source format, the kernel module binaries are built at install time with dkms [14:29] paultag I understand that's the line [14:30] paultag but the fact is it's transitively linking is something we have to look at [14:30] paultag I know when the website copy says about it [14:30] clopez sorry, what means transitively linking? [14:31] paultag I need to leave for work, just because you link to a shim which links to something doesn't mean it's not all linked together. [14:32] clopez paultag: I understand, but the package don't ships kernel binaries, only source code. So as long as binaries are not distributed (and the package don't distributes them) I think there is no problem [14:32] paultag I understand what the website says [14:33] paultag but you'll not be suprised when we take our time figuring out what the hell is going on with this one. [14:34] clopez yes, I understand you need your time, only wanted to have an update regarding this because I felt it was somehow forgotten [14:34] clopez thanks for the update [14:34] paultag it's not forgotten, we just haven't had a slice of time to commune about it [14:34] paultag feel free to email ftpmaster@ and poke [14:37] clopez Liang Guo did that some weeks ago but he got not reply (AFAIK) So, I don't know how more we can do other than wait. Regards! signature.asc Description: OpenPGP digital signature
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/14 17:23, John Paul Adrian Glaubitz wrote: On 02/28/2014 04:13 PM, Turbo Fredriksson wrote: Is it ok/allowed to upload a new package, even though the initial one is still stuck in incoming? I suggest asking the FTP masters to mark the package as REJECT if you want to change something again. As long the package is still stuck in NEW (not incoming, this is where the package goes once it's been ACCEPTED), you can always have it rejected. It's the cleaner solution in my opinion instead of uselessly bumping the package revision to fix minor issues before the package isn't even ACCEPTED. Adrian I advise against this. The upload is to experimental, is OK if the package has RC bugs. Let the ftp-master team accept the package first, and once that is done we can upload a better version to unstable. In the meanwhile you can continue working on the package repository as usual. However, I will wait for a resolution from ftp-master before resuming my work on the package, because there is the possibility of ftp-master not allowing the upload and I don't like to waste my time. Regards! signature.asc Description: OpenPGP digital signature
Bug#686447: [Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?
On 28/02/14 17:58, John Paul Adrian Glaubitz wrote: However, I will wait for a resolution from ftp-master before resuming my work on the package, because there is the possibility of ftp-master not allowing the upload and I don't like to waste my time. Just because your package is rejected doesn't mean you can't get it into unstable at all. Packages are rejected all the time. It just means the package is not *yet* fit for ACCEPT. What I'm afraid of is ftp-masters rejecting the package for license issues (CDDL-GPL). If the ftp-masters reject the package on a license issue basis this would mean that zfs-linux won't get into Debian. So I rather will wait for this before resuming my work on the current package. I think the license isn't a problem at all because zfs-dkms only ships source code (no binary distributed). And the binary utilities distributed on zfsutils don't depend on any CDDL-incompatible library/package. signature.asc Description: OpenPGP digital signature
Bug#694257: fdk-aac: who knows more?
On 10/05/13 07:41, Arto Jantunen wrote: The difference between the GPL and the LGPL does solve the problem if the program you are developing wants to link to both LGPL licensed and GPL incompatible libraries, assuming that the license of the program itself is not either GPL or LGPL. Parts of libav are GPL and the rest is LGPL, thus the problem remains. So the problem all boils down that the fact that libav contains GPL code? I was supposing that libav was 100% LGPL (with no GPL code). If libav contains GPL code then the whole viral nature of the GPL license will entangle everything. AFAIK there is no practical difference between being libav 100% GPL or beeing libav 1% GPL. You have to obey the GPL in both cases, which means that you can't link libav with GPL-incompatible license software. Isn't it? signature.asc Description: OpenPGP digital signature
Bug#694257: fdk-aac: who knows more?
On 09/05/13 23:27, Adam M. Costello wrote: Fabian Greffrath fab...@greffrath.com: Is fdk-aac finally the first *free* high-quality AAC encoder or is it just the next *non-free* one after FAAC? From what I've read, FAAC is not a high-quality AAC encoder. As far as I know, fdk-aac is the only high-quality open-source AAC encoder. I don't know if fdk-aac is DFSG-free, or GPL-compatible, but even if it's neither, Debian could still package it, right? There's also a command-line tool, fdkaac, that uses it. Yes. If you are interested in packaging it, please go ahead. Of course, the library would be much more useful if avconv could use it. If libfdk-aac is GPL-incompatible, what does that imply? That avconv must not require libfdk-aac to be present at runtime? Could it check for the existence of libfdk-aac and dlopen() it if it's found? Would that make them independent enough that their licenses wouldn't need to be compatible? The thing is that libav (ffmpeg) is LGPL (not GPL). So, my understanding is that it shouldn't be a problem to use a third-party library (fdk-aac or whatever) even if this library is GPL-incompatible (or even proprietary). I tried to clarify this point with libav developers [1]. But the replies I got where not clear to me so I gave up. They seem to be more interested in improving the internal AAC encoder of libav. I still think that it shouldn't be any problem by linking libav with fdk-aac or any other library given the LGPL license of libav. But I am not a lawyer, maybe I'm wrong. It's a shame that various open-source licenses fight each other and thus impede rather than promote the development of free software. Yes. I agree. This whole incompatibility between open source licenses is a complete mess and a PITA for everybody. I was pushing to ensure that the copyleft-next license that Richard Fontana is creating address this specific point [2] Regards! [1] http://thread.gmane.org/gmane.comp.video.ffmpeg.libav.user/9395 [2] https://github.com/richardfontana/copyleft-next/issues/15 signature.asc Description: OpenPGP digital signature
Bug#706985: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon
On 06/05/13 18:42, Lars Wirzenius wrote: On Mon, May 06, 2013 at 05:10:17PM +0100, Daniel Walrond wrote: Package: wnpp Severity: wishlist Owner: Daniel Walrond deb...@djw.org.uk * Package name: opensmtpd Version : 5.3.1p1 Upstream Author : OpenBSD * URL : http://www.opensmtpd.org/ * License : ISC, BSD Programming Lang: C Description : Simple Mail Transfer Protocol daemon OpenSMTPD is a FREE implementation of the server-side SMTP protocol as defined by RFC 5321, with some additional standard extensions. It allows ordinary machines to exchange e-mails with other systems speaking the SMTP protocol. Is this better than exim4 or postfix, or one of the other SMTP servers we already have in Debian? It has a special focus on security: https://en.wikipedia.org/wiki/OpenSMTPD#Goals http://www.opensmtpd.org/goals.html I'm eager to try it. Thanks for packaging it! signature.asc Description: OpenPGP digital signature
Bug#705221: ITP: pcapfix -- repair broken pcap files
On 12/04/13 10:00, Ansgar Burchardt wrote: Could this be made part of pcaputils instead? From the package description it looks like it might fit in there. How such things could be done? It will require both upstreams to merge? Or do you can create a Debian package that merges two upstreams tarballs? How? I'm just curious. signature.asc Description: OpenPGP digital signature
Bug#448638: RFP: i2p -- I2P is an anonymizing network
retitle 448638 RFP: i2p -- I2P is an anonymizing network noowner 448638 thanks Hi Given the timeline, I think is pretty clear that nobody is working on this package. In the mean time another ITP was filled for this package #665450 (now merged on this one). So I'm retitling this bug to RFP to easily allow anyone that wants to take care of this to work on it. If anyone of you want to step in and take care of packaging I2P for Debian please re-title the bug back to ITP and assign it to you. If it happens that there is more than one person interested on packaging I2P, then the interested ones can talk between them to check the possibility of maintaining the package together. Thanks! signature.asc Description: OpenPGP digital signature
Bug#423458: Status of dnscap ITP?
On 26/10/12 00:19, Andrew Ruthven wrote: On Thu, 2012-10-25 at 15:00 +0200, Marc Haber wrote: On Tue, Feb 07, 2012 at 12:39:18AM +, Andrew Ruthven wrote: Our git repo for dnscap is here: http://git.catalyst.net.nz/dnscap.git I'm waiting for a minor update to a patch we're carrying, then we can upload it to unstable. What's the status for that? Is that minor update there now? Yes, and you're prodded made me go and check for a new release, so I've just updated the packaging to dnscap v141. I am a DD and can sponsor your upload to unstable. If you want me to help, please build a source package and make it available for me. Having it sponsored would be great. I'm a DM, so I'll be able to continue to maintain it once it is uploaded. I should really get around to becoming a DD. ;) The git repo is here: http://git.catalyst.net.nz/dnscap.git You can grab the source package and an amd64 binary from here: http://magnus.catalyst.net.nz/~puck/dnscap_debian.tar.gz Thank you! Hi, I will also like to see this package on Debian. I tested Andrew package and works like a charm. Could some DD sponsor it? Thanks! signature.asc Description: OpenPGP digital signature
Bug#686447: [RFC] First release of spl-dkms and zfs-linux packages for Debian
Hi! An update here. I was a bit busy later. Today I was talking with Aron on IRC and we agreed that we will push your repository on Alioth in order to keep the full history. In fact is already there: http://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/zfs.git http://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/spl.git And we will start from this codebase. I will be rebasing some of the changes I did on a separate branch (and splitting them in small commits) so we could discuss later each one of this changes. See below for the inline replies to your last mail: On 16/12/12 09:19, Darik Horn wrote: Strip from spl-dkms all files not related to kernel modules. Why are you removing copyright attributions like the AUTHORS file? This could upset ZoL contributors and cause legal exposure. I thought that debian/copyright file would be enough to give credit to the authors of the software. However you are right. A simple apt-file search AUTHORS give me more than enough reasons to keep this file. Rewrite postinst helper that ensures that /etc/hostid is valid and will remain constant across reboots. The __BYTE_ORDER__ test is interesting. I will likely add it to pkg-spl. However, randomizing the hostid violates the principle of least astonishment because it causes a zpool.cache mismatch that breaks subsequent imports, and it can break license management for non-Debian software. Stabilizing the hostid is safe, but changing the hostid is unsafe for the same reason that randomizing a missing hostname is wrong. I'm only randomizing it when the current host's hostid is 0x, which I understand is an invalid hostid for ZFS and would case it to stop working properly. Isn't this the case? The pristine-tar branch already exists in pkg-spl and pkg-zfs. Using the pristine-tar facility is certainly correct, but not currently practical for doing the frequent releases that ZoL users expect. We should agree on a common way of working. Either we use pristine-tar or not. I'm relative new to use git for Debian packages. So I'm open to follow yours and Aron advice. Fix clean target and use dh_autoreconf This breaks backports for Lucid (and its derivatives) because dh-autoreconf is a non-main package on those systems. Keeping compatibility with all officially supported Ubuntu variants is worthwhile and something that I want to do. Well. I love to have things as clean and small as possible. dh_autoreconf helps with that. But I understand your point. Not big deal. Update debian/watch to track upstream official release tarballs Is the Github redirector fully obsolete? (nb: http://wiki.debian.org/debian/watch/) The pkg-spl and pkg-zfs watch files were added after an earlier private ITP review. github redirector is not longer needed, so why use it? http://wiki.debian.org/debian/watch?action=diffrev2=10rev1=9 Also the url on the debian/watch on your packages is not working. This is what the current master on Alioth (your package) reports: $ uscan --report-status Processing watchfile line for package zfs-linux... Newest version on remote site is 0~master, local version is 0.6.0.97 zfs-linux: remote site does not even have current version This is what the package that I did previously reports: $ uscan --report-status Processing watchfile line for package zfs-linux... Newest version on remote site is 0.5.2, local version is 0.6.0~rc12 zfs-linux: remote site does not even have current version Strip from zfs-dkms all files not related to kernel modules. Clean debian directory for unneeded *.docs (copyright notices should be added to debian/copyright properly) The OPENSOLARIS.LICENSE file should be unmodified and bundled in every ZFS package, even if the CDDL is duplicated in the debian/copyright file. Modifying or omitting Oracle legal notices will attract Oracle lawyers. Saving less than 64 kilobytes of boilerplate per installation is just not worth the risk. Ok. Add zfs-linux metapackage for convenience to install all ZFS Consider naming this debian-zfs to fit the naming convention of other meta packages already in distribution, and to better accommodate the kFreeBSD platform in case the meta package can be shared. Big or important source packages do not typically provide their own meta. Doing this makes it more difficult for large sites to do local overrides and customization. (And it follows that I should rename the ubuntu-zfs source package to something like meta-ubuntu-zfs for better conformance.) I don't see the point of sharing such metapackage with kFreeBSD. The whole point of the metapackage is to pull the right versions of the spl and zfs dkms modules (which are linux specific) plus the right versions of the user space tools that are also linux specific. ensure dependencies are also always updated to the right version. This reintroduces a dkms ordering bug where the zfs build races the spl
Bug#647939: RFP: certwatch -- generate SSL certificate expiry warnings
On 05/02/13 10:23, Joachim Breitner wrote:
Hi,
today I was thinking about implementing a similar tool, and uploading it
to Debian. I’d done a few things differently:
* I’d simply process all certificates found in /etc, i.e. every file
called .pem or .crt that seems to be a SSL certificate. This way, certs
used by mail and jabber servers are also found.
* I’d send a report only if any cert is about to expire, but in that
case, send one mail containing every cert that is about to expire;
likely several certs expire together. And just for good measure, the
report would include the times to expiration for all found certs, to
give the admin a better overview of what certs are there (and what certs
are found).
* I’d include a nagios-check-compatible invocation as well.
* I’d not run a daily check for things that expire in a month; weekly
sounds more useful here.
If these would be added to certwatch I’d be interested in maintaining
them for Debian.
Greetings,
Joachim
I have a shell script that I have been using for a while on my servers
with success.
I drop it on /etc/cron.weekly and configure the directories to scan and
the mail address to send the notifications.
It just checks the certificates that are going to expire in the next 30
days (with openssl) and sends a warning.
I attach it here, just in case you or anybody else find it useful.
Regards!
#! /bin/bash
#
# Designed to be run weekly and send mail reports for certificates going
# to expire in the next 30 days.
#
# Configure the variables mailto, includedirs and excludedirs and drop
# it into /etc/cron.weekly
#
# -- Carlos Alberto Lopez Perez clo...@igalia.com
#
#
set -o noclobber
# Where to send warnings
mailto=root
# Directories to search for certificates
includedirs=(/etc/ssl/certs /etc/openvpn)
# Subdirectories to exclude
excludedirs=(/etc/openvpn/ssl/newcerts)
_mail () {
tag=${1}
shift 1
echo -e ${@} |\
mail -s [${tag}] Certification Expiration Notice on
$(hostname) \
${mailto}
if [[ $? -ne 0 ]]; then
# Print a warning for cron.
echo FATAL ERROR sending mail. Script ${0} on host $(hostname)
echo Message was ::
echo -e ${@}
exit 1
fi
}
_include () {
for idir in ${includedirs[@]}; do
[[ -d ${idir} ]] echo -n ${idir}
done
}
_exclude () {
for edir in ${excludedirs[@]}; do
[[ -d ${edir} ]] echo -n ! -path '${edir}*'
done
}
for file in $(eval find $(_include) $(_exclude) ! -type d); do
if [[ -L ${file} ]]; then
# If the file is a symbolic link to another file on the same
directory
# We skip it
readlink ${file} | grep -q '/' || continue
fi
# Check that is a valid certificate
if file -bL ${file} | grep -q PEM certificate || grep -q BEGIN
CERTIFICATE ${file}; then
expiredate=$(openssl x509 -text -noout ${file}|grep Not
After :| head -n1| cut -d: -f2-)
echo ${expiredate} | egrep -q '\w{3} [ :0-9]{11}
[._[:alnum:]-]+' || \
_mail ERROR Unable to parse date: \${expiredate}\
on file ${file}
warningepoch=$(date +%s -d ${expiredate} - 30 days)
expireepoch=$(date +%s -d ${expiredate})
todayepoch=$(date +%s)
if [[ ${todayepoch} -ge ${warningepoch} ]] [[ ${expireepoch}
-ge ${todayepoch} ]]; then
_mail WARNING \
The following certificate is going to expire:
\n\n \
Certificate: ${file}\n \
Expiration: ${expiredate}\n \
Left: $(( $(( ${expireepoch} -
${todayepoch} )) / 86400 )) days\n
fi
fi
done
signature.asc
Description: OpenPGP digital signature
Bug#698428: ITP: ansible -- Configuration management, deployment,
Great! I was looking forward to test ansible, and having it packaged within Debian would help. Thanks for the effort! signature.asc Description: OpenPGP digital signature
Bug#686447: [RFC] First release of spl-dkms and zfs-linux packages for Debian
Hi! Finally found some time to work on the spl-dkms and zfs-linux packages. I started with debian helpers from Darik Horn and I ended rewriting many things. Hope all looks ok O:-) You have a summary of the most relevant changes on the commit message [1] Keep in mind that the packages are still in beta status. There are things to fix like all the pending lintian warnings, perhaps rewriting debian/copyright (copyright notices can be added together when they share one or more authors, there is not need for an entry for each one) Also I will wait until upstream releases 0.6.0. I don't want to release a -rc version. Also 0.6.0 would be the version where the ZPL layer will be considered stabilized. I founded that there is not possible to add two people as maintainers. debuild will complain about malformed maintainer address. So I guess we need to set-up a project on Alioth to handle the team maintenance. I'm not a DD, so I would be very grateful if some of you that are DDs (Aron?) could set-up the Alioth project to collaborative maintain this package and add us to it (my login-name on Alioth is clopez-guest). I removed from the control files lot of replaces/conflicts that didn't make sense to me. Perhaps for Ubuntu make sense (don't know). I guess Darik can review it and fix when needed so Ubuntu users can have a painless upgrade from the Darik's PPA packages to this ones. As you probably know Ubuntu steals the packages from Debian/sid for normal versions and from Debian/testing for LTS versions. So I guess this packages would end on Ubuntu's official repositories in a year or so. One question that floats over my mind is related to the name of the packages libzfs-dev libzfs1 and zfsutils. On Debian/kFreeBSD there are packages with the same name. Is allowed to have different source packages building binary packages with the same name when they are different architectures? If is not allowed then I guess we will have to rename the packages. The repositories with the packages are here: https://github.com/clopez/zfs-linux https://github.com/clopez/spl-dkms Just in case someone want to test it, I have uploaded all packages built for AMD64 as also the source packages to here: http://ftp.neutrino.es/zfs-linux/ To test it, at least the packages zfs-dkms and zfsutils should be installed (with all the required dependencies). I will be on holidays next week. So looking forward to see your replies when I come back. Keep in mind that the packages are still a work-in-progress. Patches/pull-requests/suggestions are welcome :) Best regards! - [1] https://github.com/clopez/spl-dkms/commit/a88b5bf72fe8f11f7dbd0ebe17ba7b46e00a4e6f https://github.com/clopez/zfs-linux/commit/8f3e1ef9a2dfbff9594e5d823e0d18121efba688 signature.asc Description: OpenPGP digital signature
Bug#694257: RFP: libfdk-aac -- The Fraunhofer FDK AAC Codec Library
Package: wnpp Severity: wishlist X-Debbugs-CC: pkg-multimedia-maintain...@lists.alioth.debian.org, maril...@free.fr, mar...@martin.st * Package name: libfdk-aac Version : 0.1.1 Upstream Author : Martin Storsjo mar...@martin.st * URL : http://opencore-amr.git.sourceforge.net/git/gitweb.cgi?p=opencore-amr/fdk-aac git://opencore-amr.git.sourceforge.net/gitroot/opencore-amr/fdk-aac * License : custom copyleft [1] Programming Lang: C++ Description : The Fraunhofer FDK AAC Codec Library Fraunhofer FDK AAC library, is an encoding and decoding library for the AAC audio format. . Fraunhofer's FDK AAC code provides a complete, high-quality audio solution. Fraunhofer does not only contributed codec code, but also the audio systems knowledge and profound experience as the primary AAC and MP3 inventor. This library was released as part of the Android Jelly Bean source code, and was repackaged by the opencore-amr project. Check: http://sourceforge.net/mailarchive/message.php?msg_id=29526038 [1] http://opencore-amr.git.sourceforge.net/git/gitweb.cgi?p=opencore-amr/fdk-aac;a=blob;f=NOTICE signature.asc Description: OpenPGP digital signature
Bug#658783: Re: MATE Desktop Environment in Debian
On 21/10/12 01:15, Josselin Mouette wrote: Most issues people have with GNOME 3 “classic” usually boil down to “the panel is black instead of grey”. Anyway, you’re welcome to package MATE in Debian. Just fix all the code duplication stupidity before. So far no one has volunteered to do so. Probably you all know already, but GNOME classic (aka fallback) is going to be removed with GNOME 3.8 [1] So, for those who like GNOME but want a classic desktop metaphor the options are now reduced to cinnamon and mate. I didn't tried cinnamon yet, but I guess I will do soon because it is coming to Debian now [2] Anyway, I was very happy with GNOME2 and all its applets, so if Mate is packaged inside Debian it will be for sure my preferred option. Also, mate is now the only option for those who want a GNOME desktop but don't have 3D acceleration or don't have a fast enough CPU to run LLVMpipe On top of that, Mate is now packaged officially on Fedora [3]. So if they can support it and live together with the code duplication stupidity, then I don't see why Debian couldn't do it. Also, as others pointed before, it's not clear at all which means that affirmation that mate is duplicating code. Could you please elaborate this generic code duplication stupidity on specific issues? Which libraries/code is MATE duplicating? Regards! [1] https://lwn.net/Articles/523774/ [2] http://ftp-master.debian.org/new/cinnamon_1.6.2-1.html #657395 [3] https://fedoraproject.org/wiki/Features/MATE-Desktop signature.asc Description: OpenPGP digital signature
Bug#616126: ITP: authprogs -- A simple wrapper for SSH's resticted commands via pubkey auth
Hi Alex,
I was testing your initial package [1] and it looks good.
However I found two issues:
- perl-doc build-depend is missing
- you should use Architecture:all for packages that are
architecture-independent like interpreted languages
(perl/python/bash..)
I am attaching here the debdiff to fix this issues
I encourage you to retry submitting a new version of your
package to debian-mentors.
Regards!
[1] http://www.biotec.tu-dresden.de/~alex/authprogs/authprogs_0.1-1.dsc
diff -Nru authprogs-0.1/debian/control authprogs-0.1/debian/control
--- authprogs-0.1/debian/control 2011-03-02 20:24:19.0 +0100
+++ authprogs-0.1/debian/control 2012-09-18 12:55:57.0 +0200
@@ -2,7 +2,7 @@
Section: misc
Priority: optional
Maintainer: Alex Mestiashvili a...@biotec.tu-dresden.de
-Build-Depends: debhelper (= 7.0.50~)
+Build-Depends: debhelper (= 7.0.50~), perl-doc
Standards-Version: 3.9.1
Vcs-Svn: https://elite.bshellz.net/svn/rsvn/authprogs/trunk/
Vcs-Browser: https://elite.bshellz.net/svn/rsvn/authprogs/trunk/
@@ -10,7 +10,7 @@
Package: authprogs
-Architecture: any
+Architecture: all
Depends: ${misc:Depends} ,${perl:Depends}
Description:A simple wrapper for SSH's resticted commands via pubkey auth.
authprogs is a wrapper script for the ssh public key based authentication.
signature.asc
Description: OpenPGP digital signature
Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
On 04/09/12 00:37, Darik Horn wrote: Hello all, For more than two years, I've been maintaining the Ubuntu PPA for ZoL: https://launchpad.net/~zfs-native/+archive/stable https://github.com/dajhorn/pkg-spl https://github.com/dajhorn/pkg-zfs I put effort into keeping the packaging compatible with Debian Squeeze and Debian Wheezy, and I support a significant number of Debian users. If the Debian project is now willing to add the native ZFS implementation to regular distribution, then please consider me for the maintainer role. I've been looking for a mentor and sponsorship. Hello Darik, I'm aware of your great work on the Ubuntu PPA and I'm happy to see that you care also about Debian and not only Ubuntu. Fist of all let me clarify that there isn't such thing as The Debian project willing ... Debian hasn't any central authority deciding upon which software is packaged and which isn't. All the packages available on Debian are pushed either by individuals or teams. Meanwhile the package you intent to introduce inside Debian meets certain basic requirements you shouldn't have any problem at all to get it inside the distribution or to find a sponsor. The Debian project is always happy to accept new software that adds value to it. Among this requirements are: 1. The license of the software that you are packaging allows Debian to re-distribute it. 2. The software has certain quality (For ex: it don't introduce severe security issues or breaks unrelated packages) 3. The software is useful (Silly example: you shouldn't introduce a hello world! program) 4. The maintainer(s) behind the package are doing a good work packaging the software and maintaining it. And I'm sure that ZoL meets all this requirements without problems... that's why I filled this ITP Before filling this ITP I researched about previous tries of packaging ZoL on Debian and I wasn't able to find any previous ITP related to ZoL at all or even any discussion/thread on the Debian mailing lists about packaging ZoL Did you tried to package or introduce ZoL on Debian previously? If you want, I will be more than happy to co-maintain the package with you inside Debian. As Arno said, team maintenance is a great thing. Nowadays many of the Debian packages are maintained by teams rather than individuals. This helps to ensure a very high quality of the packages. So, let me know if you are willing to co-maintain ZoL inside Debian with me (and with anybody else who wants to help with the effort also) and we could start by setting up a repository for the team. Best regards! signature.asc Description: OpenPGP digital signature
Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
Package: wnpp Owner: Carlos Alberto Lopez Perez clo...@igalia.com Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org * Package name: zfs-linux Version : 0.6.0 Upstream Author : Brian Behlendorf behlendo...@llnl.gov * URL : http://zfsonlinux.org/ * License : CDDL Programming Lang: C Description : The native Linux kernel port of the ZFS filesystem. ZFS is an advanced file system and volume manager which was originally developed for Solaris. It provides a number of advanced features like snapshots, clones, live integrity checksums, deduplication, compression and much more. The port to the Linux kernel includes a functional and stable SPA, DMU, ZVOL and ZFS Posix Layer (ZPL). . This package contains the source code for the native implementation of ZFS for the Linux Kernel, which can be used with DKMS, so that local kernel modules are automatically built and installed every time the kernel packages are upgraded. . This package also contains the user space utilities needed to manage ZFS. signature.asc Description: OpenPGP digital signature
Bug#686453: ITP: spl-dkms -- The Solaris Porting Layer (SPL) for the Linux kernel
Package: wnpp Owner: Carlos Alberto Lopez Perez clo...@igalia.com Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org * Package name: spl-dkms Version : 0.6.0 Upstream Author : Brian Behlendorf behlendo...@llnl.gov * URL : http://zfsonlinux.org/ * License : GPL-2+ Programming Lang: C Description : The Solaris Porting Layer (SPL) for the Linux kernel. The Solaris Porting Layer (SPL) is a Linux kernel module which provides many of the Solaris kernel APIs. This shim layer makes it possible to run Solaris kernel code in the Linux kernel with relatively minimal modification. . This can be particularly useful when you want to track upstream Solaris development closely and don't want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives. . This package contains the source code for the SPL Linux kernel module, which can be used with DKMS, so that local kernel modules are automatically built and installed every time the kernel packages are upgraded. signature.asc Description: OpenPGP digital signature
Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
On 01/09/12 20:18, John Paul Adrian Glaubitz wrote: On Sat, Sep 01, 2012 at 08:02:21PM +0200, Carlos Alberto Lopez Perez wrote: This package contains the source code for the native implementation of ZFS for the Linux Kernel, which can be used with DKMS, so that local kernel modules are automatically built and installed every time the kernel packages are upgraded. . This package also contains the user space utilities needed to manage ZFS. Wow, this is actually very nice. I didn't know the implementation of ZFS has advanced that much. I would really love to see this in Debian anytime soon. Do you know how it compares to the version of zfs available for the FreeBSD kernels feature-wise? Cheers, Adrian Wikipedia has a nice table comparing the different ports of ZFS [1] According to it, both the FreeBSD port and this Native Linux port (LLNL) are based on zpool version 28, for which the relevant changelog is also detailed on Wikipedia [2]. For the Linux port, the ZFS Posix Layer (ZPL) is available from version 0.6.0-rc1 and is expected to be completely stabilized for version 0.6.0 [3] Regards! [1] https://en.wikipedia.org/wiki/ZFS#Comparisons [2] https://en.wikipedia.org/wiki/ZFS#Release_history [3] https://github.com/zfsonlinux/zfs/issues/7 signature.asc Description: OpenPGP digital signature
Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
On 01/09/12 20:36, Arno Töll wrote: Hi, On 01.09.2012 20:02, Carlos Alberto Lopez Perez wrote: This package contains the source code for the native implementation of ZFS for the Linux Kernel, which can be used with DKMS, so that local kernel modules are automatically built and installed every time the kernel packages are upgraded. Question remains whether the resulting binary packages are distributable by Debian. You'd basically need to ship source only binary packages which are built on the installing platform - including utilities, not only for the kernel driver. The user space utilities are not linked against any GPL library so there isn't any license problem distributing them in binary form. The only external dependencies for the user-space utilities are: libselinux1, zlib1g, and of course libc6. signature.asc Description: OpenPGP digital signature
Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
On 01/09/12 21:45, Dmitrijs Ledkovs wrote: On 1 September 2012 19:02, Carlos Alberto Lopez Perez clo...@igalia.com wrote: Package: wnpp Owner: Carlos Alberto Lopez Perez clo...@igalia.com Severity: wishlist X-Debbugs-CC: debian-de...@lists.debian.org * Package name: zfs-linux Version : 0.6.0 Upstream Author : Brian Behlendorf behlendo...@llnl.gov * URL : http://zfsonlinux.org/ * License : CDDL Programming Lang: C Description : The native Linux kernel port of the ZFS filesystem. ZFS is an advanced file system and volume manager which was originally developed for Solaris. It provides a number of advanced features like snapshots, clones, live integrity checksums, deduplication, compression and much more. The port to the Linux kernel includes a functional and stable SPA, DMU, ZVOL and ZFS Posix Layer (ZPL). . This package contains the source code for the native implementation of ZFS for the Linux Kernel, which can be used with DKMS, so that local kernel modules are automatically built and installed every time the kernel packages are upgraded. . This package also contains the user space utilities needed to manage ZFS. If packaged properly, I am sure many people will find this useful. The missing revisions / functionality are: 29 RAID-Z/mirror hybrid allocator. 30 ZFS encryption. 31 improved 'zfs list' performance. 32 One MB block support 33 Improved share support I do have (personal?!) concerns about the ZFS future. After the zpool version 28, no more source code was release by oracle (please correct me if I am wrong). Are the specs released for the later zpool versions? As it is now, all implementations are incomplete in comparison with Oracle's implementation. And if no specs are available, the open source / linux implementations are going to become more and more incomplete in the future. This is true, the latest release of the ZFS source code is the zpool version 28. After Oracle took over Sun, they turned Solaris into a closed-source operating system effectively killing OpenSolaris. However, several open source projects (OpenIndiana and Illumos) forked OpenSolaris and continued its development in parallel. Also FreeBSD added official support for ZFS on their Kernel. So, while is true that possibly we can't expect Oracle supporting further development for the open-source ZFS, we can (and should) expect that this development effort continues in the open backed by the several open source efforts behind this (zfsonlinux, freebsd, illumos, openindiana, smartos, nexenta ...). There is already a working group composed by some of the former communities working on further development of the open source version of ZFS [1] About the ZFS specifications for the Oracle's zpool greater than 28, I don't know if they made this documents public (probably they didn't) Anyway this ZFS working group is developing the open source ZFS version independently from Oracle, so I guess (not sure about this) that the last ZFS version compatible between all the ZFS ports and Oracle/Solaris ZFS will be zfs=5,zpool=28. The ZFS working group has already shared a proposal for allocating zfs/zpool version numbers that allows the different parties to add features to ZFS independently without conflicts between them [2] For example, Illumos released a few months ago a new version of ZFS (zpool=5000) which added support for asynchronous destruction of ZFS datasets and SPA versioning with zfs feature flags [3], and the FreeBSD folks are already merging this in their port [4]. Its expected that the zfsonlinux project would also merge this changes on their port [5]. Also, ZFS in its current state (zfs=5 / zpool=28) is very stable and more feature-wise than any of the other filesystems available for Linux. Furthermore none of the features added from [29-33] is a killer feature, for encryption we already have LUKS/dm-crypt on Linux (you can just build a zfs volume on top of a LUKS/dm-crypt volume). What is the status on trademarks? Can we use the name zfs? For example, drdb trademark is actively being enforced. We already have in the archives the following packages using the zfs name: http://packages.debian.org/search?keywords=zfssearchon=namessuite=allsection=all So I don't see any problem there. If Oracle decide to enforce the zfs trademark we simply can rename the package and problem solved. Also, as I can see, Oracle not longer holds the ZFS trademark since they abandoned the application for it [6] While the future of alternative zfs implementations does look gloom, I do think zfs (-like) implementations would be useful on linux and in debian. I also think that can be useful, ZFS has many nice features that would boost Linux and Debian possibilities. Regards! [1] https://lwn.net/Articles/444882/ http://lanyrd.com/2012/illumos-user-group-meetup-january/smxwd/ http://blog.delphix.com/csiden/files/2012/01
Bug#686453: ITP: spl-dkms -- The Solaris Porting Layer (SPL) for the Linux kernel
On 01/09/12 22:56, Dmitrijs Ledkovs wrote: replying in private On 1 September 2012 19:41, Carlos Alberto Lopez Perez clo...@igalia.com wrote: This can be particularly useful when you want to track upstream Solaris development closely and don't want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives. . How does one track upstream Solaris development? Is it not closed source since Solaris 11 release? Or is this in reference to other solaris kernels used by open source forks after the end of the OpenSolaris project? Regards, Dmitrijs. You are right. I CP the description from the source code [1]. I will rephrase the package description as: This can be particularly useful when you want to track upstream Illumos (or any other OpenSolaris fork) development closely and don't want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives. Regards! [1] https://github.com/zfsonlinux/spl signature.asc Description: OpenPGP digital signature
Bug#652745: RFP: razor-qt -- simple qt-based desktop window manager
Any progress here? If you are working on the package you should retitle this bug from RFP to ITP and assign it to you as owner to avoid duplicate work and send the typical mail to debian-devel telling about the ITP. signature.asc Description: OpenPGP digital signature
Bug#682706: ITP: crtools -- tools for freezing/checkpointing/restoring a running application
On 25/07/12 04:19, Yaroslav Halchenko wrote: On Tue, 24 Jul 2012, Artem Leshchev wrote: * Package name: crtools ... Checkpoint/Restore In Userspace, or CRIU, is a tool, that can freeze a running application (or part of it) and checkpoint it to a hard drive as a collection of files. You can then use the files to restore and run the application from the point it was frozen at. The distinctive feature of the CRIU project is that it is mainly implemented in user space. NB Kapil, would you be kind to clarify the relation/comparison? http://openvz.livejournal.com/42414.html signature.asc Description: OpenPGP digital signature
Bug#522935: ITP: emerald -- Window Decorator shipped with Compiz Fusion.
Hello, This ITP is one year and a half old. Any progress here? I am interesting in having this software on Debian... So if you are not longer interested on it I would appreciate if you can re-title this to an RFP so I can take over it. Thanks! signature.asc Description: OpenPGP digital signature
Bug#323420: Status update?
Hello, It seems that some parts of metasploit-framework (byakugan at least) are proprietary. What about doing a metasploit-framework package with the core and all the free parts and a metasploit-framework-nonfree with the non-free parts? signature.asc Description: OpenPGP digital signature
Bug#642934: Aircrack-ng
On 20/06/12 23:01, Erik Adler wrote: Hi Carlos, Really happy to see somebody picked the Aircrack-ng suit up. Letting it die would have been a shame. I installed 1:1.1-3 on Debian GNU/Linux http://mentors.debian.net/debian/pool/main/a/aircrack-ng/aircrack-ng_1.1-3.dsc and tried it out for a while testing and played with it for a while. The only problem I found was Airdriver-ng cannot compile/install drivers, when trying to install new ones. I get a depmod -ae WARNING: -e needs -E or -F. The instillation of divers then fails. This is only a harmless warning. You have to look at the file /var/log/airdriver for the log of what went wrong. Are you still looking for a sponsor? If so I know someone who _might_ be able to help. Paul has sponsored the package. It is on the NEW queue [1] waiting for the ftp-masters approval. Thanks again for picking project up. All the best Erik Adler gpg key ID 0x2B4B58FE About the airdriver-ng patches I think that the 90% of this patches are not necessary anymore if you are running a modern kernel (=3.2). This patches are dated from [2006-2010] [2] and I don't think they will apply on any kernel greater than 2.6.2X What kind of wireless card do you have? What kernel are you running? Have you tried to inject without patching your kernel? I suggest you to try to put your wireless card in monitor mode with airmon-ng without patching the driver. For me works out of the box. Once upstream fixes their problem with the tracker I should talk with them about this patches because I feel that the great majority of this patches either were merged upstream long ago or need to be refreshed to apply on a modern kernel. Regards! [1] http://ftp-master.debian.org/new.html [2] http://patches.aircrack-ng.org/ -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#642934: Sponsorship for aircrack-ng
On 18/06/12 07:26, Paul Wise wrote: On Sun, 2012-06-17 at 08:08 +0200, Carlos Alberto Lopez Perez wrote: Wishing to hear any comments. Oh, one more thing, how about a README.Debian explaining the situation with OpenSSL and how to rebuild the package with OpenSSL instead, for those users who want the extra speed? I have just re-introduced the README.Debian from the old package and added a new entry summarizing the changes introduced as also commenting how to rebuild the package with OpenSSL. I have re-uploaded it to mentors.debian.net Regards! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#642934: Sponsorship for aircrack-ng
On 18/06/12 14:45, Paul Wise wrote: On Mon, 2012-06-18 at 13:04 +0200, Carlos Alberto Lopez Perez wrote: I have re-uploaded it to mentors.debian.net Please make it -3 since -2 is already in NEW. Done... made a new changelog entry (-3) and re-uploaded to mentors Looks ok now? Thanks! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#642934: Sponsorship for aircrack-ng
Hello, I have just packaged and updated a new version of aircrack-ng. I have completely reworked the package. I switched to dh for debian/rules and also switched debian/copyright to machine-readable format. I backported the GnuTLS patch to aircrack-ng 1.1 and also I cherry-picked a few other patches from upstream that fixed some issues with the current codebase. Among the issues fixed, there are included all the Debian bugs with priority greater than Normal that were open against the last version of aircrack-ng on Debian. I have also enabled the hardening-flags. About the injection patches: I simply removed them from the package. Airdriver-ng downloads this patches from Internet, so this files never were an useful thing to have inside the package. About the airdrop-ng and airgraph-ng scripts: * Airdrop-ng depends on Pylorcon libraries that are not packaged on Debian. * Airgraph-ng seems to be still an early work-in-progress not ready for general use. (Ex: it overwrites the input file when the -o (output) parameter is not specified) So I am excluding this files from the package for the moment. I have uploaded the new package to mentors.debian.net http://mentors.debian.net/package/aircrack-ng The package is signed with my key that you can import with: gpg --keyserver pgp.mit.edu --recv-keys 965089CE6B95F882 If all looks ok, then I will need somebody to sponsor this package. Just hoping this is still on time to be included on Wheezy. Once it enters into Debian again, I would re-open the bugs that were automatically closed when the package was removed and that are not fixed by this upload. Wishing to hear any comments. Thanks! Best regards! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#642934: [PATCH] Add GnuTLS support to Aircrack-ng
On 08/06/12 18:35, intrigeri wrote: Hi, Thomas d'Otreppe wrote (08 Jun 2012 13:43:28 GMT) : Not yet as I'm solving another problem: http://aircrack-ng.blogspot.com/2012/05/forum-virus-details.html Good luck with that! I just need to test it but it looks good so I don't think it will need any modifications. As soon as trac/svn is up, I'll take care of this. Thanks for answering. Any kind of ETA? (Debian Wheezy should be frozen in the second part of June, so I'm trying to see what's blocking the inclusion of aircrack-ng in there. It'd be very sad to see Wheezy released without aircrack-ng, after all the awesome work that was put in it by you and others.) After a quick chat with Thomas on the IRC, he told me he is fine with Debian including this GnuTLS patch for aircrack-ng. So I have backported it to aircrack-ng 1.1 and I have the debian package of aircrack-ng 1.1 with the GnuTLS patch as also a few other patches that I cherry-picked from the development branch almost ready. I will be publishing the package to debian mentors this week (ASAP). I will need a sponsor for the package. Thanks! Best regards! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#642934: [PATCH] Add GnuTLS support to Aircrack-ng
Hello, Since the issue with the OpenSSL license seems to have reached a dead-end because the crc_chop_tbl table is copyrighted as GPL and the author is impossible to contact [1]... I have translated the OpenSSL functions used on Aircrack-ng to the GnuTLS counterparts. I did this using macro definitions. Therefore there was not needed any change on the actual code of Aircrack-ng apart from a few lines to include the wrapper header and also to make GnuTLS thread-safe on aircrack-ng, airodump-ng and airbase-ng. I am attaching here the patch (is on top of r2153) I hope you will find it OK to be included on Aircrack-ng. All tests that I did were successful. However further tests should be done. Anyway, if you accept the patch, this will be the default on Debian (Aircrack-ng built with GnuTLS), so I guess that Debian users will take care of testing this in deep. About speed, for example, breaking a WPA key, with OpenSSL I get ~ 2700 k/s and with GnuTLS ~ 2400 k/s. So, seems that OpenSSL performs better than GnuTLS, but don't seems to be a big deal (+12%). Best regards! - [1] http://trac.aircrack-ng.org/ticket/953 -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ From 150cd9bdf3eed81ac601d17662cc2835834d79d5 Mon Sep 17 00:00:00 2001 From: Carlos Alberto Lopez Perez clo...@igalia.com Date: Tue, 1 May 2012 06:24:59 +0200 Subject: [PATCH] Add support for GnuTLS * It adds a wrapper that translates the OpenSSL primitives to the GnuTLS counterparts using macro definitions. * Compile with: make gnutls=true * The following tests done with this patch were successful: * Cracking WEP key with Koreak attack * Cracking WEP key with PTW attack * Cracking WPA key (using a dictionary) * Aireplay-ng attacks: -1, -3, -4 (chopchop), -5 * Packetforge ARP generation and injection (based on xor file obtained with aireplay-ng chopchop attack) * This patch is on top of r2153 --- INSTALLING |7 +++- src/Makefile |8 +++- src/airbase-ng.c |9 + src/aircrack-ng.c|9 + src/airodump-ng.c|9 + src/crypto.h |4 ++ src/gnutls-openssl-wrapper.h | 76 ++ 7 files changed, 119 insertions(+), 3 deletions(-) create mode 100644 src/gnutls-openssl-wrapper.h diff --git a/INSTALLING b/INSTALLING index 5186dda..1440030 100644 --- a/INSTALLING +++ b/INSTALLING @@ -1,6 +1,6 @@ === Requirements === - * OpenSSL development package + * OpenSSL development package or GnuTLS development package * If you want to use airolib-ng and '-r' option in aircrack-ng, SQLite development package = 3.3.17 (3.6.X version or better is recommended): - libsqlite3-devel @@ -43,11 +43,16 @@ to compile and install the suite: Note: Experimental. Each script has its own dependences. Note: It's only required in install phase. +* gnutls: Use GnuTLS crypto library instead of the default OpenSSL. + Example: * Compiling: make sqlite=true unstable=true + * Compiling with GnuTLS +make gnutls=true + * Installing: make sqlite=true unstable=true install diff --git a/src/Makefile b/src/Makefile index 9bd87de..984debc 100644 --- a/src/Makefile +++ b/src/Makefile @@ -104,8 +104,12 @@ ifeq ($(OSNAME), cygwin) LIBS += -liphlpapi -lsetupapi -luuid endif LIBOSD = $(OSD)/lib$(OSD).a - -LIBSSL = -lssl -lcrypto +ifeq ($(gnutls), true) + LIBSSL = -lgnutls -lgcrypt + CFLAGS += -DUSE_GNUTLS +else + LIBSSL = -lssl -lcrypto +endif LIBSQL = ifeq ($(SQLITE), true) LIBSQL = -L/usr/local/lib -lsqlite3 diff --git a/src/airbase-ng.c b/src/airbase-ng.c index 8bbb73e..2470fe9 100644 --- a/src/airbase-ng.c +++ b/src/airbase-ng.c @@ -68,6 +68,10 @@ #include osdep/osdep.h #include osdep/common.h +#ifdef USE_GNUTLS + GCRY_THREAD_OPTION_PTHREAD_IMPL; +#endif + static struct wif *_wi_in, *_wi_out; #define CRYPT_NONE 0 @@ -3880,6 +3884,11 @@ int main( int argc, char *argv[] ) rCF = (pCF_t) malloc(sizeof(struct CF_packet)); memset(rCF, 0, sizeof(struct CF_packet)); +#ifdef USE_GNUTLS +// Register callback functions to ensure proper locking in the sensitive parts of libgcrypt. +gcry_control (GCRYCTL_SET_THREAD_CBS, gcry_threads_pthread); +gnutls_global_init(); +#endif pthread_mutex_init( mx_cf, NULL ); pthread_mutex_init( mx_cap, NULL ); diff --git a/src/aircrack-ng.c b/src/aircrack-ng.c index b06af6d..6c33224 100644 --- a/src/aircrack-ng.c +++ b/src/aircrack-ng.c @@ -76,6 +76,10 @@ sqlite3 *db; #endif +#ifdef USE_GNUTLS + GCRY_THREAD_OPTION_PTHREAD_IMPL; +#endif + extern int get_nb_cpus(); static uchar
Bug#642934: sponsorship for aircrack-ng
On 15/02/12 16:47, David Francos wrote: Hi, I've taken bug http://trac.aircrack-ng.org/ticket/953 at aircrack-ng. I've resolved almost all the license issues, except two files from hirte, whom I'm having trouble to contact, and the file crctable.h http://trac.aircrack-ng.org/svn/trunk/src/crctable.h whose author we have not yet identified. I was wondering if, because of the content of crctable.h, could be marked as uncopyrightable. [...] We're almost there, don't let this stop. Yes, seems that this issue with the license is finally being resolved. Thanks a lot for your work :) Also, I should say it, I'm making a package from the svn revision, and it's much easier to package, and has much less lintian warnings (if some), you can have a look at the source of the package at http://github.com/XayOn/Aircrack-ngDebian/ I've written a simpler (and I think better) rules file, installing also scripts and unstable tools and updated the recommends to fit with them, also, only one of the patches seemed necesary (the usrlocal one). I will take a look at it, thanks! I don't know if there is any policy inside Debian about packaging development branches of software, but I guess that most people would agree that is better to only package stable releases. So I wonder if once this issue with the license is completely addressed could you make a minor release to be packaged in debian? perhaps something like aircrack-ng-1.1.1 with this license issues fixed and some other fixes/features that you feel to be stable/tested enough to be used on production environments like, for example, the commits of r2008 and r2010. http://trac.aircrack-ng.org/changeset/2008 http://trac.aircrack-ng.org/changeset/2010 Thanks! -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#651093: ITP: libyui -- Qt, GTK+ and ncurses UI-Engine
This library looks very cool and is the first time I've heard about it :) Are you planning to package also the python bindings? http://www.slideshare.net/hedgehogpainter/3-uis-for-the-price-of-one-code -- ~~~ Carlos Alberto Lopez Perez http://neutrino.es Igalia - Free Software Engineeringhttp://www.igalia.com ~~~ signature.asc Description: OpenPGP digital signature
Bug#642934: sponsorship for aircrack-ng
On 03/12/11 05:52, Paul Wise wrote: Non-blockers that would be nice to have fixed: Reported upstream: http://trac.aircrack-ng.org/ticket/956 http://trac.aircrack-ng.org/ticket/957 signature.asc Description: OpenPGP digital signature
Bug#642934: sponsorship for aircrack-ng
On 26/11/11 04:45, Paul Wise wrote: On Sat, 2011-11-26 at 03:02 +0100, Carlos Alberto Lopez Perez wrote: dget -x http://mentors.debian.net/debian/pool/main/a/aircrack-ng/aircrack-ng_1.1-2.dsc Blockers for the upload: The OpenSSL and GPL licenses are incompatible. A number of files do not have the OpenSSL exception to the GPL. This means that we cannot distribute any executables that link against OpenSSL and are also built from those files. You will need to check which executables link against OpenSSL, then check the license for all the associated source files looking for ones licensed under the GPL without the exception. Once you have done these checks, please document the results in debian/copyright. If there are any binaries that have an issue, please delete those from the package and ask upstream to fix the licenses. Thanks for notifying this (my fault for not checked it in advance). I have scanned all the source code and I found two files that are linking with OpenSSL and are GPL licensed without an exception to allow this. I have just reported it to upstream and also contacted Thomas. http://trac.aircrack-ng.org/ticket/953 Non-blockers that would be nice to have fixed: You might want to adopt the machine-readable format for debian/copyright http://dep.debian.net/deps/dep5/ I will rewrite it with this format, thanks for the link ;) Please remove me from Uploaders, I only plan to sponsor you, not co-maintain the package. Then.. who should put in Uploaders? me? nobody? Please update to debhelper compat level 7 or higher. You may also want switch from a completely manual debian/rules to dh. debian/more-examples/README can be dropped from the source package since that is covered by the upstream README. debian/README.source can be dropped since you are using dpkg-source v3. There are quite a few complaints from lintian (see bottom of the mail). Please add DEP-3 headers to all of the patches: http://dep.debian.net/deps/dep3/ I note that airdrop-ng and airgraph-ng are not installed in the package. Please forward the patches upstream that haven't been forwarded yet. There are lots of compiler warnings, please notify upstream about those. Please ask upstream what the status of the next release is. As a longer-term project, please consider figuring out which of the injection patches are merged upstream, ask upstream to move those into old/, drop those from the Debian package and talk to upstream about merging the remainder into Linux mainline. lintian: I: aircrack-ng source: quilt-patch-missing-description 002-Fix_airodump-ng_manpage.diff I: aircrack-ng source: quilt-patch-missing-description 004-fix-license-sha1-sse2.diff W: aircrack-ng source: debian-rules-missing-recommended-target build-arch W: aircrack-ng source: debian-rules-missing-recommended-target build-indep P: aircrack-ng: copyright-refers-to-symlink-license usr/share/common-licenses/GPL X: aircrack-ng: duplicate-files usr/share/doc/aircrack-ng/injection-patches/ieee80211_inject.patch usr/share/doc/aircrack-ng/injection-patches/old/ieee80211_inject.patch I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:40 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:46 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:47 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:50 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:53 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:55 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:60 I: aircrack-ng: spelling-error-in-manpage usr/share/man/man1/airbase-ng.1.gz surpresses suppresses I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:78 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:81 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz:85 I: aircrack-ng: spelling-error-in-manpage usr/share/man/man1/airbase-ng.1.gz replys replies I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airbase-ng.1.gz 7 more occurrences not shown I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/aircrack-ng.1.gz:116 I: aircrack-ng: spelling-error-in-manpage usr/share/man/man1/aireplay-ng.1.gz allows to allows one to I: aircrack-ng: spelling-error-in-manpage usr/share/man/man1/airodump-ng.1.gz Allows to Allows one to I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airodump-ng.1.gz:45 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airodump-ng.1.gz:58 I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man/man1/airodump-ng.1.gz:151 I: aircrack-ng: spelling-error-in-manpage usr/share/man/man1/buddy-ng.1.gz runned ran I: aircrack-ng: hyphen-used-as-minus-sign usr/share/man
Bug#642934: sponsorship for aircrack-ng
On 27/11/11 03:35, Paul Wise wrote: I'm surprised there were only two such files. Indeed I would expect src/sha1-sse2.S to also be one such file (it is part GPL, part public domain), but you seem to have missed that. I was not sure about src/sha1-sse2.S since it contains only assembly code and don't calls any function from libssl. But later this file is linked with libssl to build the aicrack-ng binary So I would request this file to include also this exception. Looking at all files that are linked with libssl in the build process I have just found another file that link against OpenSSL and don't have the OpenSSL exception for GPL src/common.c I would request this file also to include the exception. Thanks! Best Regards! signature.asc Description: OpenPGP digital signature
Bug#642934: sponsorship for aircrack-ng
On 09/11/11 17:05, Paul Wise wrote: On Wed, 2011-11-09 at 13:27 +0100, Carlos Alberto Lopez Perez wrote: I wish to take care of the aircrack-ng package if it is still possible. Excellent! I would also like to seize this opportunity to become Debian Maintainer, a thing that has been in my TODO list for a long time. Also good :) Also I would be happy of joining the Debian wireless team. Please register an account on alioth if you do not have one and then click on the request to join link here: http://alioth.debian.org/projects/pkg-wpa Mention that you plan to maintain aircrack-ng within the team in your request and that I will sponsor you whenever needed. You may want to help them maintain wpasupplicant and other WiFi related packages. They use SVN and presumably svn-buildpackage so you might want to take a look at how they do that. I will be happy and thankful if you can guide me through this process. I would be happy to. What would be the first step? Signal your intention to package aircrack-ng. In Debian we do this by filing bugs against the wnpp pseudo-package. wnpp is explained here: http://www.debian.org/devel/wnpp/ The bugs filed against wnpp can be seen here: http://bugs.debian.org/wnpp http://wnpp.debian.net/ I would suggest you should reassign the removal bug (#642934) to the wnpp pseudo-package, retitle it to an ITP bug and change the severity to wishlist. You can find instructions for bug manipulation here: http://www.debian.org/Bugs/server-control You can CC the mail changing the bug into an ITP to debian-devel so that more folks are likely to notice and not duplicate your work. Probably the mail should explain why you are reintroducing aircrack-ng. Create a new package for aircrack-ng fixing the licensing issue? Take the last version of aircrack-ng that was available in Debian and update it to an upstream VCS snapshot that fixes the licensing issue (or just the latest one), closing the ITP bug with something like Re-upload to unstable (Closes: #642934) in the debian/changelog. A second line should say that the update fixes the licensing issue and close that bug too. The last version available in Debian is available from snapshot.d.o: http://snapshot.debian.org/package/aircrack-ng/1%3A1.1-1.1/ If you are unfamiliar with Debian packaging you will want to read this: http://www.debian.org/doc/manuals/maint-guide/ Some more links you may want to read: http://ftp-master.debian.org/REJECT-FAQ.html http://www.debian.org/doc/manuals/developers-reference/ http://www.debian.org/doc/debian-policy/ Re-open any bugs marked as fixed in a version that ends in +rm, if you have JavaScript turned on, click Toggle all extra information at the bottom of this page, then search the page for +rm and then reopen all those bugs and removed the +rm fixed versions using the notfixed command. This is unfortunately necessary because ftp-master close all the bugs when they remove a package. It would be better if debbugs knew a package was removed and acted appropriately, but debbugs maintenance is not as active as it used to be. Then put closes entries in debian/changelog for any bugs that are closed by the new upstream snapshot. http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;src=aircrack-ng If you have any questions, feel free to ask me directly or (preferably) on the #debian-mentors IRC channel or debian-mentors mailing list. I will reply as I am able and if others reply first then that works too. Once you have a package ready you can send an RFS to the debian-mentors list and I will take a look at it. The PTS page for aircrack-ng is here, you should keep an eye on it while you are the maintainer and look at the links there: http://packages.qa.debian.org/a/aircrack-ng.html Please also contact upstream to tell them you are the new maintainer and ask them about making a new release. Hello, I have just packaged and updated a new version of aircrack-ng based on the previous one from Adam Cécile. I uploaded it to mentors.debian.net http://mentors.debian.net/package/aircrack-ng Once it enters into debian again I would re-open the bugs that were automatically closed when the package was removed Wishing to hear any comments. Regards! signature.asc Description: OpenPGP digital signature
Bug#642934: sponsorship for aircrack-ng
On 25/11/11 21:47, Carlos Alberto Lopez Perez wrote: Hello, I have just packaged and updated a new version of aircrack-ng based on the previous one from Adam Cécile. I uploaded it to mentors.debian.net http://mentors.debian.net/package/aircrack-ng Once it enters into debian again I would re-open the bugs that were automatically closed when the package was removed Wishing to hear any comments. Regards! Just a quick note to let you know that the package is signed with mi recently created 4096RSA key that you can import with: gpg --keyserver pgp.mit.edu --recv-keys 965089CE6B95F882 Or with: curl key.neutrino.es | gpg --import Then you can download the package with: dget -x http://mentors.debian.net/debian/pool/main/a/aircrack-ng/aircrack-ng_1.1-2.dsc But, as I just discovered now, dscverify will give error unless you configure it to trust your local gpg keyring by setting: DSCVERIFY_KEYRINGS=~/.gnupg/pubring.gpg on the file ~/.devscripts Regards! signature.asc Description: OpenPGP digital signature
Bug#542166: RFP: python-jsonrpc -- A json-rpc package which implements JSON-RPC over HTTP
Any chance of getting this software into Debian? I really miss it signature.asc Description: OpenPGP digital signature
