Bug#733922: ITP: libgit-cpan-patch-perl -- Git commands for CPAN distributions
Package: wnpp Owner: Stefan Hornburg (Racke) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libgit-cpan-patch-perl Version : 1.3.1 Upstream Author : Yanick Champoux * URL : https://metacpan.org/release/Git-CPAN-Patch * License : Artistic or GPL-1+ Programming Lang: Perl Description : Git commands for CPAN distributions Git::CPAN::Patch provides a suite of git commands aimed at making trivially easy the process of grabbing any distribution off CPAN, stuffing it in a local git repository and, once gleeful hacking has been perpetrated, sending back patches to its maintainer. -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team -- 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/52c51ae5.4020...@linuxia.de
Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
On Mon, Dec 30, 2013 at 12:27:29PM +0100, Guillem Jover wrote: > * signing would get rafactored into a new program so that users do >not need to manually mangle the .changes file, rebuild or require >devscripts for something that was possible out-of-the-box. I chose to read that as "debsign will move from devscripts to src:dpkg" and felt happier. I actually don't care if debsign is reimplemented, but I'd prefer if the Debian package development brain space was not further complicated with more command line tools to learn[1], so I suggest that the existing name and arguments are preserved. [1] or ignore -- 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/20140102092455.ga25...@bryant.redmars.org
Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
Hi! On Thu, 2014-01-02 at 09:24:55 +, Jonathan Dowland wrote: > On Mon, Dec 30, 2013 at 12:27:29PM +0100, Guillem Jover wrote: > > * signing would get rafactored into a new program so that users do > >not need to manually mangle the .changes file, rebuild or require > >devscripts for something that was possible out-of-the-box. > > I chose to read that as "debsign will move from devscripts to src:dpkg" > and felt happier. I actually don't care if debsign is reimplemented, but > I'd prefer if the Debian package development brain space was not further > complicated with more command line tools to learn[1], so I suggest that > the existing name and arguments are preserved. I'd feel very uncomfortable doing that, because it would mean, at least: * introducing a core dpkg tool within a different namespace * having to parse a devscripts specific configuration file * having to support DAK specific .commands signing * having to support remote signing IMO having debsign become a thiner wrapper around this new tool would be the goal, as it would simplify its code, people not wanting to use debsign could use the dpkg tool directly, and people not wanting to learn new stuff could keep using the wrapper w/o regressions. Thanks, Guillem -- 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/20140102100304.ga10...@gaara.hadrons.org
Bug#733922: ITP: libmoosex-app-perl
Package: wnpp Owner: Stefan Hornburg (Racke) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmoosex-app-perl Version : 1.22 Upstream Author : Maroš Kollár * URL : https://metacpan.org/pod/MooseX::App * License : Artistic or GPL-1+ Programming Lang: Perl Description : Write user-friendly Perl/Moose command line apps with even less suffering MooseX-App is a highly customizeable helper to write user-friendly command line applications without having to worry about most of the annoying things usually involved. Just take any existing Moose class, add a single line (use MooseX-App qw(PluginA PluginB ...);) and create one class for each command in an underlying namespace. Needed for Git::CPAN::Patch. Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team -- 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/52c53e8e.50...@linuxia.de
Bug#733937: ITP: fonts-google-crosextra-caladea -- Caladea is metric-compatible with Cambria
Package: wnpp Severity: wishlist Owner: Fabian Greffrath * Package name: fonts-google-crosextra-caladea Version : 20130214 * URL : http://gsdview.appspot.com/chromeos- localmirror/distfiles/crosextrafonts-20130214.tar.gz * License : Apache Description : Caladea is metric-compatible with Cambria This is a font that I am going to package under the umbrella of the pkg-fonts team. It is a drop-in replacement for the Cambria font shipped with Microsoft Windows 7. It is part of the Google Crosextra fonts which are meant as a supplement to the Google Croscore fonts, which are drop-in replacements for Arial, Courier New and Times New Roman (similar to the Liberation fonts, but not yet packaged for Debian). It is accompanied by the Carlito font, which is a drop-in replacement for Calibri, but is released under a different license (OFL 1.1). I am currently indifferent if I should file a separate ITP for it. -- 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/20140102123609.11574.16849.report...@kff50.ghi.rwth-aachen.de
Re: Move awk implementations from /usr/bin to /bin
On Tue, Dec 31, 2013 at 01:12:36PM +, Dimitri John Ledkov wrote: > On 31 December 2013 08:11, Vincent Bernat wrote: > > ❦ 31 décembre 2013 01:30 CET, m...@linux.it (Marco d'Itri) : > > > >>> Any thoughts? > >> The correct solution is completing #652459, which mounts /usr in the > >> initramfs. > > > > It is quite unclear why this bug is stalled. It just needs doing. But it requires coordinated uploads of initramfs-tools sysvinit util-linux to get all the bits in place. lamont was going to upload a new util-linux to unstable in December but it hasn't happened yet. I was going to upload a test version of all three to experimental for testing, which I can look at doing this weekend. > I believe there were reservations about /etc portions of the patch > series, which were asked to be "unbundled" and to be considered > separately. I don't know if this was done, if not I guess I should > come up with such patch on top of the proposed patch series, as one of > the interested parties to get this resolved. The patch series includes the /etc bits in separate patches. These can just be ignored if not wanted; there is no further work required from that point of view, I think. Given that they won't be used by default and are harmless, but do add interesting new capabilities, I would like to see them used though. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20140102125354.gw13...@codelibre.net
Bug#733941: ITP: jenkins-constant-pool-scanner -- Simple utility to scan Java bytecode for class references in the constant pool
Package: wnpp Severity: wishlist Owner: James Page * Package name: jenkins-constant-pool-scanner Version : 1.2 * URL : http://github.com/jenkinsci/constant-pool-scanner * License : GPL-2 Programming Lang: Java Description : Utility for detecting class references in the Java constant pool A utility used by jenkins-remoting for detecting class references in the Java constants pool. -- 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/20140102133421.24023.33600.reportbug@armstrong.shouse.local
Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
You raise some very valid points and §I appreciate your concerns and perhaps should rephrase my request so that I'm suggesting subsuming the most common used features of debsign and perhaps as part of a staged migration (compat symlink to debsign binary name in the phase 1, real name dpkg-sign or whatever), to try and avoid further complicating the debian package development universe. On Thu, Jan 02, 2014 at 11:03:04AM +0100, Guillem Jover wrote: > I'd feel very uncomfortable doing that, because it would mean, at least: > > * introducing a core dpkg tool within a different namespace So dpkg-sign (or dpkg sign if you ever decided to move to internal namespacing, which seems to be fashionable) with a compatibility symlink to debsign would resolve this one, > * having to parse a devscripts specific configuration file That's more awkward, I'd agree, but you could support the command-line arguments without supporting the devscripts configuration file. It could be confusing for those who have relied upon it, though. A more considered migration would be necessary. > * having to support DAK specific .commands signing That could be awkward, although the format is very similar (if not identical) to debian/control and only one header is of interest. I imagine most people use dcut/dput nowadays[1] > * having to support remote signing It would be fair enough to stderr "not supported, please use the older tool in devscripts" and error 1 if such an argument was provided. That would be pragmatic if (as I suspect) -r is rarely used. > IMO having debsign become a thiner wrapper around this new tool would > be the goal, as it would simplify its code, people not wanting to use > debsign could use the dpkg tool directly, and people not wanting to > learn new stuff could keep using the wrapper w/o regressions. That would not address the concern I raise: the surface area of debian package development tools would continue to grow, meaning people would use the non-recommended tool if they did not know better (or relied on documentation which had not been updated). [1] haven't checked whether they, in turn, rely on debsign. -- 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/20140102172233.ga7...@bryant.redmars.org
Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
On Mon, Dec 30, 2013 at 12:27:29PM +0100, Guillem Jover wrote: > I guess it's probably a good idea to switch the default, becuse I > assume most maintainers do more test builds than final ones. Or users > who either don't have gpg installed or don't have a gpg key. Although > with the current no-signing-UNRELEASED behaviour, the need for -us -uc > should have dropped in many cases. On the sbuild/buildd side, we have run dpkg-buildpackage with "-us -uc" by default for years. If you do enable signing, as is the case for buildd uploads, we run debsign explicitly after dpkg-buildpackage completed. This avoids any need for GPG keys to be present in the build chroot. So from the POV of making "-us -uc" the default, I think that's a good plan and matches the requirements of the majority of both manual and automated builds. And from the POV of having a replacement for debsign, we can conditionally switch to using it as soon as it becomes available. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Removing packages from unofficial repositories
Hi all, I recently decided to migrate my Debian system away from deb-multimedia.org, where official packages exist. I used apt preferences to help me downgrade packages from deb-multimedia back to Debian testing, where an alternative version from testing exists. However, I would expect that most users would not have the patience to do this via apt preferences, and if there is an easier way, I was not aware of it. I'm writing to suggest that in the long term, Debian's package management should have a general, user-friendly way to deal with situations like this, such as a mechanism to remove a repository subscription, and all package versions that came from it, while uninstalling as few as possible of the reverse dependencies. Can anyone suggest which Debian package it would be appropriate to file this as a bug on?
Re: Removing packages from unofficial repositories
Simon, On 01/02/2014 01:52 PM, Simon Ruggier wrote: > I'm writing to suggest that in the long term, Debian's package > management should have a general, user-friendly way to deal with > situations like this, such as a mechanism to remove a repository > subscription, and all package versions that came from it, while > uninstalling as few as possible of the reverse dependencies. I don't think there is any appropriate package to file such a bug on as, there can be no general way to downgrade, ever. To quote from our infobot on irc: "Downgrading is not, nor will ever be supported by apt. Programs change their data in a way that can't be rolled back, and package maintainer scripts support upgrades to new config file formats but not downgrades." The infobot further suggests in order to remove deb-multimedia.org packages: If you want to remove the packages from deb-multimedia.org and reinstall the packages from Debian repositories, one could do this: dpkg --remove --force-depends $(aptitude search '?narrow(?version(CURRENT),?origin(Unofficial Multimedia Packages))' --disable-columns -F%p); remove the dmm repository from sources.list; apt-get update; apt-get install -f; install the still missing packages which were removed in the former process ... It is an unfortunate consequence of using third party repositories that the process is so unfriendly to users. Since the state of the official multimedia packages in Debian has vastly improved in recent releases, fortunately fewer and fewer users have to go through this unpleasant process. Ben -- 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/52c5aa1a.90...@sanctuary.nslug.ns.ca
libtool: please mark libtool multi-arch: allowed
The correct solution is for libtool package to be marked as "multi-arch: allowed" without splitting this tiny package into two even smaller packages. Here is the reasoning: libtool binary package can be used in both native and cross compilation cases, when used correctly. That is in cross-case at the moment one typically uses libtoolize portions of the package. If one needs something for the DEB_BUILD architecture, one can also use /usr/bin/libtool binary. The same way /usr/bin/cc, is a DEB_BUILD architecture specific binary. Multi-arch annotations are not indication if a package, libraries or tools within are meant for build/host/target architectures. Annotating something with multi-arch headers, should be considered for correct dependency resolution and to either relax co-installability for multiple architectures (common case for shared libraries) or to relax arch qualification (e.g. declare and require that one architecture satisfies any dependency types (foreign), or that at times it can be treated as such (allowed)). Precisely because libtool package has dual-nature/purpose, it should be allowed to, at times, satisfy a cross-architecture dependency. This is the most common-case, which we should optimise for. If one requires a host architecture /usr/bin/libtool, one would then explicitly state libtool:native build-dependcy, which I believe is a distinct minor corner case which warrants manual changes as part of cross-build enablement. multi-arch:allowed will not impact satisfying native dependencies in the most common case (e.g. when only a single arch is enabled in the host/chroot/builldd) Please mark libtool as Multi-arch: Allowed. Please do not split libtool into two tiny packages. -- Regards, Dimitri. -- 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/CANBHLUgVv+5wzz4ABmZq8Gh-gf84bQH0Uqvyniw+QApG=kc...@mail.gmail.com
Re: Architecture: all versus linux-any
Jerome BENOIT writes ("Re: Architecture: all versus linux-any"):
> On 27/12/13 21:17, Steve Langasek wrote:
> > On Fri, Dec 27, 2013 at 09:02:49PM +0100, Jerome BENOIT wrote:
> >> Because debcheck complains.
> >
> > Then perhaps debcheck should be fixed.
I just wanted to expand on this from Steve. I get perhaps the feeling
that you might feel you were being dismissed here. I don't think
that's the case. You were right to ask the question here, and indeed
right to provide the answer you did to Steve's question.
But I concur with Steve's technical point.
> I got the point: I let Architecture to all
Excellent, thank you. Also, would you please file a bug against
debcheck ? That will hopefully eventually save the more people from
having the same question.
Thanks,
Ian.
--
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/21189.44981.291436.886...@chiark.greenend.org.uk
Re: GPLv2-only considered harmful
Florian Weimer writes ("Re: GPLv2-only considered harmful"):
> ASL 2.0 compatibility is nice, but the GPLv3 also contains this clause
> which (in my opinion) substantially weakens its copyleft effect:
>
> | You may convey covered works to others for the sole purpose of
> | having them make modifications exclusively for you, or provide you
> | with facilities for running those works, provided that you comply
> | with the terms of this License in conveying all material for which
> | you do not control copyright. Those thus making or running the
> | covered works for you must do so exclusively on your behalf, under
> | your direction and control, on terms that prohibit them from making
> | any copies of your copyrighted material outside their relationship
> | with you.
>
> Several ISPs claim that the GPLv2 has a similar loophole and refuse to
> provide kernel sources for the router they give to you as part of the
> Internet service, so it's not just nitpicking.
These ISPs are simply wrong. They need to be reported to
gpl-violations and sat on by SFLC.
The whole Busybox v. Verizon lawsuit was about exactly this situation.
>From http://en.wikipedia.org/wiki/Software_Freedom_Law_Center:
| On December 7, 2007 SFLC filed a lawsuit against Verizon
| Communications, Inc.[12] alleging that Verizon had violated GPLv2 by
| distributing BusyBox in the Actiontec MI424WR MoCA wireless routers
| bundled with the FiOS fiber optic bandwidth service, without providing
| corresponding source code. A settlement announced on March 17, 2008
| included an agreement to comply with the GPL and an undisclosed sum
| paid to the plaintiffs.[13]
> It makes me seriously doubt that the anti-Tivoization measures in
> the GPLv3 have any teeth at all.
The GPLv3 text you quote above clearly doesn't apply in this
situation. The ISP are not "[conveying the router firmware] for the
sole purpose of having [the customer] ... provide facilities for
running" the firmware.
Perhaps this is a question of English grammar. The only reasonable
parse of the text you quote is
You may convey covered works to others for the sole purpose
of having them
(a) make modifications exclusively for you, or
(b) provide you with facilities for running those works,
provided that [etc.]
Gramatically, "provide [something]" must be preceded (of the bits of
text available) by "you", "you may", or "having them". None of the
other fragments fit.
The least implausible alternative is:
X You may
X (a) convey covered works to others for the sole purpose
X of having them make modifications exclusively for you,
X or
X (b) provide you with facilities for running those works,
X provided that [etc.]
i.e. "You may provide you with facilities".
Ian.
--
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/21189.46274.199473.670...@chiark.greenend.org.uk
Re: Architecture: all versus linux-any
* Jerome BENOIT , 2013-12-27, 21:02: I am maintaining a package, FireHOL not to name it, which basically contains bash sources. So it Architecture was set up to all by one of my predecessor. Meanwhile, kfreebsd support emerged. As FireHOL is meant to manage iptables, it is de facto meant for linux: http://qa.debian.org/debcheck.php?dist=unstable&package=firehol (bottom) Therefore, may I restrict Architecture to linux-any ? You *may* do so, but why bother? Because debcheck complains. Well, debcheck is a tool, not a deity you have to appease. :) The package already depends on the architecture-dependent iptables, and is therefore uninstallable on kfreebsd. So there doesn't seem to be any harm to having the package be Architecture: all. Will setting Architecture to linux-all create more harm ? Perhaps you meant "linux-any", because "linux-all" doesn't exist. "linux-all" would be the perfect solution to your problem if it existed. -- Jakub Wilk -- 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/20140102185724.ga22...@jwilk.net
Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)
Roger Leigh writes ("Re: Bug#733029: dpkg-buildpackage: disable signing by
default (-us -uc should be the default)"):
> On the sbuild/buildd side, we have run dpkg-buildpackage with
> "-us -uc" by default for years. If you do enable signing, as is
> the case for buildd uploads, we run debsign explicitly after
> dpkg-buildpackage completed.
Likewise dgit, which does the signing only in "dgit push". It does it
by itself without the use of debsign or anything from dpkg-dev.
I have no objection to the proposed change to dpkg-buildpackage, or
the moving of functionality from devscripts.
I do of course want debsign's command line interface and functionality
to continue to work in its entirity. But I also need the arrangements
for making the signature remain part of the defined interface, so that
dgit keeps working: i.e. even if this functionality becomes part of
dpkg-dev, its use should not be mandatory.
Thanks,
Ian.
--
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/21189.47230.191871.195...@chiark.greenend.org.uk
Re: Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
Philip Rinn: > Hi, > > I think it's important to add also the paragraph about actual usability for > the > homepage: > > Dear God, please don't use Pond for anything real yet. I've hammered out > nearly > 20K lines of code that have never been reviewed. Unless you're looking to > experiment you should go use something that actually works (e.g. GnuPG).[0] > > > I general I'd ask if it's not better to wait for code reviews before > packaging it. > > Best, > Philip > > [0] https://pond.imperialviolet.org > > I use Pond regularly on machines that run Debian and Tails. I'd also be happy to give it a shot at packaging it in about a month. I think it is fine to package but it should include the warning from the author. All the best, Jacob -- 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/52c5b757.5030...@appelbaum.net
Bug#733978: ITP: libmousex-configfromfile-perl -- abstract Mouse role for setting attributes from a configfile
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmousex-configfromfile-perl Version : 0.05 Upstream Author : NAKAGAWA Masaki * URL : https://metacpan.org/release/MouseX-ConfigFromFile * License : Artistic or GPL-1+ Programming Lang: Perl Description : abstract Mouse role for setting attributes from a configfile MouseX::ConfigFromFile is an abstract role which provides an alternate constructor for creating objects using parameters passed in from a configuration file. The actual implementation of reading the configuration file is left to concrete subroles. It declares an attribute configfile and a class method new_with_config, and requires that concrete roles derived from it implement the class method get_config_from_file. Attributes specified directly as arguments to new_with_config supercede those in the configfile. -- 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/20140102195148.ga26...@jadzia.comodo.priv.at
can i have the main os files in zip file?
i want to make my own oprating system from debian system for a certain usb device. however, trying to accses the files from a disc, i cant find them. can you give me a copy of the files for the os? if so, in zip file as well? --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- 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/52c5c59d.8020...@aspects.net
Re: Architecture: all versus linux-any
Hello List, On 02/01/14 19:57, Jakub Wilk wrote: > * Jerome BENOIT , 2013-12-27, 21:02: I am maintaining a package, FireHOL not to name it, which basically contains bash sources. So it Architecture was set up to all by one of my predecessor. Meanwhile, kfreebsd support emerged. As FireHOL is meant to manage iptables, it is de facto meant for linux: http://qa.debian.org/debcheck.php?dist=unstable&package=firehol (bottom) Therefore, may I restrict Architecture to linux-any ? >>> You *may* do so, but why bother? >> Because debcheck complains. > > Well, debcheck is a tool, not a deity you have to appease. :) > >>> The package already depends on the architecture-dependent iptables, and is >>> therefore uninstallable on kfreebsd. So there doesn't seem to be any harm >>> to having the package be Architecture: all. >> >> Will setting Architecture to linux-all create more harm ? > > Perhaps you meant "linux-any", because "linux-all" doesn't exist. > > "linux-all" would be the perfect solution to your problem if it existed. Indeed, I meant linx-any :-) Jerome > -- 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/52c5dbf3.8060...@rezozer.net
Re: can i have the main os files in zip file?
2014/1/3 freddie simmonds : > i want to make my own oprating system from debian system for a certain usb > device. > however, trying to accses the files from a disc, i cant find them. Majority of files are in "packages", see http://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics > > can you give me a copy of the files for the os? if so, in zip file as well? To create your custom OS from Debian you can start learning Debootstrap: https://wiki.debian.org/Debootstrap -- 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/call-q8y_vb4dbqjm-5vtuaorgcbof_44eg_xrxdebc+uc7d...@mail.gmail.com
Bug#733989: ITP: r-cran-testthat -- GNU R testsuite
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-testthat Version : 0.7.1 Upstream Author : Hadley Wickham * URL : http://cran.r-project.org/web/packages/testthat * License : GPLv2+ Programming Lang: R Description : GNU R testsuite Testthat code. Tools to make testing fun. . A testing package specifically tailored for R that's fun, flexible and easy to set up. This testsuite is used by the r-cran-ggplot2 package and thus should be packaged to add autopkgtest feature. It is maintained by Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-testthat/trunk/ -- 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/20140102223157.22207.64448.report...@mail.an3as.eu
Work-needing packages report for Jan 3, 2014
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 541 (new: 18) Total number of packages offered up for adoption: 156 (new: 2) Total number of packages requested help for: 55 (new: 1) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: buxon (#733528), orphaned 4 days ago Description: SIOC forums browser Installations reported by Popcon: 6 gaffitter (#733530), orphaned 4 days ago Description: File subsets extractor based on genetic algorithms Installations reported by Popcon: 32 genisovh (#733692), orphaned 2 days ago Description: Make CD-ROMs bootable for SGI MIPS machines Installations reported by Popcon: 18 libapp-info-perl (#733549), orphaned 4 days ago Description: Provide metadata about software packages installed Installations reported by Popcon: 41 libclass-contract-perl (#733548), orphaned 4 days ago Description: Design-by-Contract OO in Perl Installations reported by Popcon: 23 libclass-delegator-perl (#733550), orphaned 4 days ago Description: Perl module for a simple and fast object-oriented delegation Installations reported by Popcon: 20 libconvert-ber-perl (#733552), orphaned 4 days ago Description: Perl implementation of Basic Encoding Rules (BER) Installations reported by Popcon: 345 libnet-smtpauth-perl (#733553), orphaned 4 days ago Description: Perl module that provides SMTP authentication (Net::SMTP_auth) Installations reported by Popcon: 174 libsvn-notify-perl (#733558), orphaned 4 days ago Description: Subversion activity notification Reverse Depends: libsvn-hooks-perl libsvn-notify-mirror-perl Installations reported by Popcon: 111 libtest-cmd-perl (#733559), orphaned 4 days ago Description: perl module which provides a testing framework Installations reported by Popcon: 38 libtext-trac-perl (#733560), orphaned 4 days ago Description: format text with Trac Wiki Style Installations reported by Popcon: 93 libtext-worddiff-perl (#733561), orphaned 4 days ago Description: Track changes between documents Installations reported by Popcon: 26 metacafe-dl (#733531), orphaned 4 days ago Description: download videos from metacafe.com Installations reported by Popcon: 73 pdfcrack (#733525), orphaned 4 days ago Description: PDF files password cracker Installations reported by Popcon: 1036 pysesame (#733533), orphaned 4 days ago Description: Python wrapper for Sesame's REST HTTP API Installations reported by Popcon: 15 shell-fm (#733534), orphaned 4 days ago Description: console based player for last.fm radio streams Installations reported by Popcon: 82 sks-ecc (#733536), orphaned 4 days ago Description: Cryptographic tool based on ECC Installations reported by Popcon: 25 swaml (#733540), orphaned 4 days ago Description: Semantic Web Archive of Mailing Lists Installations reported by Popcon: 9 523 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: cvs2cl (#733321), offered 5 days ago Description: CVS-log-message-to-ChangeLog conversion script Installations reported by Popcon: 145 dxflib (#733823), offered 2 days ago Reverse Depends: libdxflib-2.5.0.0-dbg libdxflib-dev Installations reported by Popcon: 44 154 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: [NEW] software-center (#733233), requested 6 days ago Description: Utility for browsing, installing, and removing software Installations reported by Popcon: 14173 apt-xapian-index (#567955), requested 1431 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache fuss-launcher goplay packagesearch Installations reported by Popcon: 76561 athcool (#278442), requested 3355 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 54 balsa (#642906), requested 830 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 806 cardstories (#624100), requested 983 days ago Description: Find out a card using a sentence made up by another player Installations reported
Re: Registering a media type for Debian binary packages ?
Le Mon, Dec 30, 2013 at 02:23:00AM +0100, Guillem Jover a écrit : > > This sounds great in theory, but I'm worried that in practice this > might just make the situation worse, by making applications having > to support not two, but three media types for undetermined periods > of time? > > OTOH, this might make it clearer for developers, what's the proper > media type to use, so I will note down to possibly prepare a draft > for this in the coming weeks, if it ends up making sense to do it. Hi Guillem and everybody, I could not help giving it a try. What do you think of the following ? (see http://www.iana.org/form/media-types for background). Type name: application Subtype name: vnd.debian.binary-package Required parameters: None. Optional parameters: None. Encoding considerations: binary Security considerations: Debian binary packages can contain arbitrary commands that will be executed with administrator privileges during installation. It is therefore essential to trust the origin of the package. The recommended way is to download packages from APT (Advanced Packaging Tool) archives that are authenticated with a trusted cryptographic key (see the manual page of apt-secure for details). As a lesser alternative for cases where APT tools are not available, the package should be downloaded with secured protocols such as HTTPS. There also exists a mechanism for signing packages directly (called ‘debsigs’), but it is not deployed. The contents of the Debian binary packages are compressed (see the ‘deb’ manual page for details on the format); it is therefore possible to inspect them without actually install the package. An estimate of the uncompressed size of the package may be available in its ‘control’ file, but it can only be trusted if the package itself is trusted. Since the Debian packages vehiculate programs to be installed on a computer, the monitoring of a user's downloads over non-secured transport protocols such as HTTP or FTP may reveal information pertaining to the user's privacy, or suggest information related to the system's security such as the precise version numbers of programs in use. Interoperability considerations: Arbitrary Debian binary packages can be installed on any system where the ‘dpkg’ package manager is used, but it is recommended to only install packages that have been built for a given release of Debian or a Debian derivative. Published specification: http://manpages.debian.org/deb Applications that use this media type: The Debian binary packages are manipulated by system programs such as ‘dpkg’, ‘apt-get’, graphical front-ends such as ’Synaptic’ but also generic archive decompressors such as ‘File Roller’. After downloading a package with a web browser or after clicking on its icon, front-ends or decompressors are usually started. Fragment identifier: None. Restrictions on usage: None. Additional information: Deprecated alias names for this type: None. Magic number(s): Files usually start with the following string: ! File extension(s): deb Macintosh file type code(s): None. Object Identifier(s) or OID(s): None. Intended usage: Common Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20140103014209.gb22...@falafel.plessy.net
Processed: Re: Bug#733651: general: Any USB card reader works only after being replugged.
Processing commands for cont...@bugs.debian.org: > severity 733651 important Bug #733651 [general] general: Any USB card reader works only after being replugged. Severity set to 'important' from 'grave' > reassign 733651 src:linux Bug #733651 [general] general: Any USB card reader works only after being replugged. Bug reassigned from package 'general' to 'src:linux'. Ignoring request to alter found versions of bug #733651 to the same values previously set Ignoring request to alter fixed versions of bug #733651 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 733651: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733651 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.138871538718020.transcr...@bugs.debian.org
Re: Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
On Fri, Jan 3, 2014 at 12:30 AM, Jacob Appelbaum wrote:
>> [0] https://pond.imperialviolet.org
>
> I use Pond regularly on machines that run Debian and Tails. I'd also be
> happy to give it a shot at packaging it in about a month. I think it is
> fine to package but it should include the warning from the author.
Suitable for experimental for sure. I'll be happy to help in packaging
if needed.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
--
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/capdygeyobiu9o3uph8ahn4rc71nz8n5969bpkgbe15ec6hx...@mail.gmail.com
Re: Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
Hi, Kartik Mistry wrote (03 Jan 2014 04:45:02 GMT) : > Suitable for experimental for sure. I'll be happy to help in > packaging if needed. Great, three candidate packagers for a single ITP :) I'm re-adding the ITP bug to the Cc list. Please keep it copied so that the discussion is archived there. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85lhyx63ky@boum.org
Bug#734033: ITP: libmoosex-app-perl
Package: wnpp Owner: Stefan Hornburg (Racke) Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmoosex-app-perl Version : 1.22 Upstream Author : Maroš Kollár * URL : https://metacpan.org/pod/MooseX::App * License : Artistic or GPL-1+ Programming Lang: Perl Description : Write user-friendly Perl/Moose command line apps with even less suffering MooseX-App is a highly customizeable helper to write user-friendly command line applications without having to worry about most of the annoying things usually involved. Just take any existing Moose class, add a single line (use MooseX-App qw(PluginA PluginB ...);) and create one class for each command in an underlying namespace. Needed for Git::CPAN::Patch. Regards Racke -- LinuXia Systems => http://www.linuxia.de/ Expert Interchange Consulting and System Administration ICDEVGROUP => http://www.icdevgroup.org/ Interchange Development Team -- 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/52c6687d.9030...@linuxia.de
