Re: dgit 1.0, available for all users
On Sun, Jul 19, 2015 at 11:28 PM, Ian Jackson < ijack...@chiark.greenend.org.uk> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I am pleased to announce dgit 1.0, which can be used, as applicable, > by all contributors and downstreams. > > dgit allows you to treat the Debian archive as if it were a git > repository, and get a git view of any package. If you have the > appropriate access rights you can do builds and uploads from git, and > other dgit users will see your git history. > > (dgit's git histories are often disjoint from the maintainer's > history; this is because the dgit git tree has exactly the same > content as the archive, which maintainers' histories often don't.) > Apologies if this has been answered elsewhere before, but I’d like to better understand how dgit fits into the workflow of working on packages which use git-buildpackage. Let’s assume I want to make an improvement to a package. I’d start by cloning it using dgit, then I’d make my modifications, but then what? Typically I’d use git format-patch and send the resulting file to the maintainer to get my changes reviewed, so I cannot use dgit push, because that would directly upload to the Debian archive, right? Even in the case where I am the maintainer and don’t deem it necessary to have my changes reviewed, I’d want to push my changes to the git-buildpackage repository, not directly to the archive, so that a more fine-grained history is preserved for future package archeology. Again, I cannot use dgit push, right? In case I’m correct about both of these points, what’s the advantage of using dgit over e.g. “apt-get source && git init && git add . && git commit -a -m "Initial import"”? Having the package history as seen by the Debian archive in git? Is dgit intended to be used only if the package does not already use e.g. git-buildpackage? Is dgit intended to be used as a replacement for tools like git-buildpackage? -- Best regards, Michael
Bug#794058: ITP: python-bandit -- security linter from OpenStack Security
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-bandit Version : 0.12.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/bandit * License : Apache-2.0 Programming Lang: Python Description : security linter from OpenStack Security Bandit is a tool designed to find common security issues in Python code. To do this Bandit processes each file, builds an AST from it, and runs appropriate plugins against the AST nodes. Once Bandit has finished scanning all the files it generates a report. This is a new python-keystonemiddleware dependency. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730075338.29618.69507.report...@buzig2.mirantis.com
Bug#794062: ITP: python-oslo.cache -- cache storage for Openstack projects
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-oslo.cache Version : 0.4.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/oslo.cache * License : Apache-2.0 Programming Lang: Python Description : cache storage for Openstack projects oslo.cache aims to provide a generic caching mechanism for OpenStack projects by wrapping the dogpile.cache library. The dogpile.cache library provides support memoization, key value storage and interfaces to common caching backends such as Memcached. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730081651.32328.13853.report...@buzig2.mirantis.com
Re: dgit 1.0, available for all users
Michael Stapelberg writes ("Re: dgit 1.0, available for all users"):
> Let’s assume I want to make an improvement to a package. I’d start by
> cloning it using dgit, then I’d make my modifications, but then what?
> Typically I’d use git format-patch and send the resulting file to the
> maintainer to get my changes reviewed, so I cannot use dgit push, because
> that would directly upload to the Debian archive, right?
Indeed. But if you don't get a reply from the maintainer, or the
maintainer says "yes please", or you're RC bug squashing during the
freeze, or the maintainer has already said "yes please NMU"
(generally, or for the specific problem) before you even made the
patch, you can then dgit push.
> Even in the case where I am the maintainer and don’t deem it necessary to
> have my changes reviewed, I’d want to push my changes to the
> git-buildpackage repository, not directly to the archive, so that a more
> fine-grained history is preserved for future package archeology. Again, I
> cannot use dgit push, right?
If you `dgit push' your changes to the archive, your fine grained
history is stored on the dgit git server and can be browsed, viewed,
and cloned, by anyone. See, for example:
https://browse.dgit.debian.org/dgit.git/log/
(Hmm, I see I failed to squash a fixup! commit in that history. Oh
well - too late now.)
> In case I’m correct about both of these points, what’s the advantage of
> using dgit over e.g. “apt-get source && git init && git add . && git commit
> -a -m "Initial import"”? Having the package history as seen by the Debian
> archive in git?
What you are describing is debcheckout.
dgit's advantage over debcheckout from the pov of an NMUer is that it
can be used to do the upload. It will make sure that what you are
uploading is exactly the git tree that you intend. And in the case of
a `3.0 (quilt)' package it will handle the quiltification for you. So
the workflow for an NMUer looks entirely git-based.
dgit's advantage for a maintainer is that it publishes your history in
a way where everyone can find and use it, without knowing about your
package's special arrangements.
This is useful to you because it means that another dgit user (for
example, an NMUer or a patch submitter - see above) who sends you git
branches (either out of band, or via dgit push) will send you git
branches based on your git history, not on some debcheckout. Or, more
likely, it means that they will send you a git branch at all - at the
moment an NMUer knows that even if they find your git repo it might
well have some special-snowflake structure, so they probably won't
bother looking for it, and will just make a patch.
And of course there is a benefit for everyone else, if you as
maintainer use dgit push to do your uploads: everyone else who uses
dgit clone will see your git history, which is likely to be much more
useful to them that the debcheckout-like stub dgit has to synthesise
otherwise.
> Is dgit intended to be used only if the package does not already use e.g.
> git-buildpackage?
No.
> Is dgit intended to be used as a replacement for tools like
> git-buildpackage?
No.
Use of dgit is mostly-orthogonal to the maintainer's git patch
management approach (if any). dgit is intended to complement existing
git packaging tools.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21946.518.932832.895...@chiark.greenend.org.uk
Re: Ad-hoc survey of existing Debian git integration tools
Vincent Bernat writes ("Re: Ad-hoc survey of existing Debian git
integration tools"):
> [Ian Jackson:]
> > Do your published git branches contain the patches-applied or
> > patches-unapplied tree ?
>
> Without using "gbp pq", the published git branches are patches-unapplied
> trees.
Then to use dgit push, you must use gbp pq.
Do you see why this is necessary, when the purpose is to provide a git
tree which is useful to someone who doesn't want to learn about your
specific patch system and workflow ?
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21946.630.353353.817...@chiark.greenend.org.uk
Re: How to deal with fixed but open bugs
* Steve Langasek , 2015-07-29, 20:48: Normally, such a bug is closed with 'close' rather than 'fixed'; the difference between these two commands being *whether* to continue showing the bug as a going concern. Normally, you should close a bug by sending a message to nn-d...@bugs.debian.org, not by the "close" control command. Reference: DevRef§5.8.2 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730110852.ga9...@jwilk.net
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Nicholas Breen wrote: If there is just the excrement of a fly adhered to a corner of the envelope (a null byte appended to an otherwise intact file, for example), xz will report that the data is corrupt and will not deliver the message. This test is inescapable. From xz(1): --single-stream Decompress only the first .xz stream, and silently ignore pos- sible remaining input data following the stream. Just try this command: xz -d --single-stream file_with_many_streams_and_null_byte.xz Xz decompresses the first stream in the file, then deletes the file, and finally exits with 0 status. I was wrong. In some cases the "Compressed data is corrupt" message can be silenced... at the cost of silent massive data loss. Best regards, Antonio. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55ba0a56.1020...@gnu.org
Bug#794088: ITP: axe-demultiplexer -- demultiplexes DNA sequencing reads based upon 5' read barcodes
Package: wnpp Severity: wishlist Owner: Kevin Murray * Package name: axe-demultiplexer Version : 0.2.8 Upstream Author : Kevin Murray * URL : https://github.com/kdmurray91/axe * License : GPL3+ Programming Lang: C Description : Axe demultiplexes DNA sequencing reads based upon 5' read barcodes Axe very rapidly selects the optimal barcode present in a sequence read, even in the presence of sequencing errors. The algorithm is able to handle combinatorial barcoding, barcodes of differing length, and several mismatches per barcode. As I am the upstream author, I'm not sure what Debian Med policy is regarding uploader-ship. But I have prepared a Debian package. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730114644.32561.58441.reportbug@localhost
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
On Thu, Jul 30, 2015 at 6:28 AM, Antonio Diaz Diaz wrote: > Nicholas Breen wrote: >>> >>> If there is just the excrement of a fly adhered to a corner of the >>> envelope (a null byte appended to an otherwise intact file, for >>> example), xz will report that the data is corrupt and will not >>> deliver the message. This test is inescapable. >> >> >> >>> From xz(1): >> >>--single-stream >> Decompress only the first .xz stream, and silently ignore >> pos- >> sible remaining input data following the stream. > > > Just try this command: > > xz -d --single-stream file_with_many_streams_and_null_byte.xz > > Xz decompresses the first stream in the file, then deletes the file, and > finally exits with 0 status. > > I was wrong. In some cases the "Compressed data is corrupt" message can be > silenced... at the cost of silent massive data loss. http://linux.die.net/man/1/xz -k, --keep Keep (don't delete) the input files. Regards, -- Robert Nelson https://rcn-ee.com/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caochtyjsv_ehbesjzbmevxmqoxxvigx1uugegus0e1zryhn...@mail.gmail.com
Re: sbuild just hangs
On Thu, 30 Jul 2015, Johannes Schauer wrote: > there are (unfortunately) a number of situations I encountered when sbuild > would just hang or just fail without any sensible error message. In my case, > the most common reason for that was that the chroot it was instructed to use > (via the configuration file in your case because you did not specify the -d > parameter) did not exist. That's the usual case with me too. However I don't have any distribution set in the configuration file... instead sbuild is smart enought to figure it out from debian/changelog (or maybe from the .changes built out of the current directory). So when I have "UNRELEASED" as target distribution and call "sbuild", I get this hang. The simple solutions is to indicate the desired distribution: sbuild -d unstable Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730124646.ga9...@home.ouaza.com
Re: Ad-hoc survey of existing Debian git integration tools
❦ 30 juillet 2015 11:54 +0100, Ian Jackson : >> > Do your published git branches contain the patches-applied or >> > patches-unapplied tree ? >> >> Without using "gbp pq", the published git branches are patches-unapplied >> trees. > > Then to use dgit push, you must use gbp pq. > > Do you see why this is necessary, when the purpose is to provide a git > tree which is useful to someone who doesn't want to learn about your > specific patch system and workflow ? On the other hand, since the previous workflow was quilt, still using quilt is useful for someone who doesn't want to learn about specific git workflows. Personally, I am waiting for the number of git-based workflows to decrease before settling for something else. -- Make it clear before you make it faster. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Re: How to deal with fixed but open bugs
On Jul 29 2015, Russ Allbery wrote: > Nikolaus Rath writes: > >> I'm looking at the bug overview page for src:python3-llfuse >> (https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=python-llfuse). The >> first thing it lists is the apparently nasty grave bug #775056. > >> However, this bug only exists in wheezy, it's fixed in both jessie and >> sid. As far as I can tell, the bug is correctly marked with found+fixed. > >> Therefore, it bothers me a lot that the bug features so prominently on >> the bug overview page. Every time I look at the page, I first think that >> there's something that needs my immediate attention. Is that normal / >> expected (the appearance, not my reaction :-)? This bug has essentially >> been resolved, so I would have hoped that this is somehow reflected more >> visibly in the bug overview. > > You should close this bug with the version in which the bug was fixed. It > sounds like you had made the mistake of setting the fixed version directly > instead of just closing the bug. That's not how this is designed to work; > normally, you should just close the bug with the version number that > contains the fix, and everything else will work properly. The commands to > manipulate the fixed version are there primarily to fix the version if it > was closed with an incorrect version or with no version. Ah, ok. The bug was already fixed in jessie at the time it was reported. So instead of just setting it to fixed in wheezy, I should have sent an email to nnn-d...@bugs.debian.org *and* set it to fixed in wheezy? Or is there a way to directly close with the right version number (I assume using the Changelog is one option, but I believe that doesn't work if the package with the fix is already uploaded). Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87bneteqmr@vostro.rath.org
Re: Metapackage dependencies: "Depends" or "Recommends"?
On Jul 30 2015, David Kalnischkies wrote: > On Wed, Jul 29, 2015 at 10:45:01AM -0700, Nikolaus Rath wrote: >> The only think it doesn't yet do is that if >> >> - a is automatically installed >> - b is automatically installed >> - c is manually installed and depends on a|b >> >> Either a or b can be removed. But I don't think apt* handled that either. > > This example makes it quite obvious that your requirements are "keep > a minimal set of packages installed" while the requirement of libapt's > autoremove is "suggest only packages for removal which are completely > safe to remove". Yes (though the main point of my email was to point out another way to get rid of dependencies after a metapackage has been uninstalled). > An algorithm can't reasonably decide if C is using A or B (or both) to > provide one of its features (the one which is the reason for the > depends, so that must be a pretty important feature as C is so useless > without it that it is better removed). Indeed. But debfoster is designed to be interactive, so it could easily ask if the user wants to remove one of them, or keep both. > Of course, a technically adapt user can decide which one is really > used/needed by C and/or revise his decision mistake later on by > reinstalling a package, but this is a maintenance cost – and a cost > libapt doesn't want to nor can force upon all its users. Yeah. This my hope that maybe this will be added to debfoster at some point. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« signature.asc Description: PGP signature
Re: Bug#790933: ITP: drive - Google Drive tool
Hi. Alexandre Detiste writes: > I think nobody mentioned it, but there is already "grive" > > https://packages.debian.org/jessie/grive . > > Which Btw seems to no longer work as per #783169 [0] :-/ Hope this helps. Best regards, [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783169 -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87zj2dogvm@inf-11879.int-evry.fr
Re: [buildd-tools-devel] sbuild just hangs
On 30/07/2015 15:56, Nikolaus Rath wrote: On Jul 30 2015, Raphael Hertzog wrote: On Thu, 30 Jul 2015, Johannes Schauer wrote: there are (unfortunately) a number of situations I encountered when sbuild would just hang or just fail without any sensible error message. In my case, the most common reason for that was that the chroot it was instructed to use (via the configuration file in your case because you did not specify the -d parameter) did not exist. That's the usual case with me too. However I don't have any distribution set in the configuration file... instead sbuild is smart enought to figure it out from debian/changelog (or maybe from the .changes built out of the current directory). So when I have "UNRELEASED" as target distribution and call "sbuild", I get this hang. The simple solutions is to indicate the desired distribution: sbuild -d unstable That was it! Thanks! In my case the problem was that "unstable" (as I specified in the changelog) would not work either, because my chroot is called "sid". So sbuild -d sid worked just fine. Note that you probably want -d unstable --chroot=sid (IIRC) since the distribution is also used when doing stuff that needs the correct distribution name, e.g. making NMUs which needs a valid changelog entry. The --chroot option selects a different chroot without altering the distribution in use. Note that you can add "aliases=unstable-amd64-sbuild" or equivalent for your distribution/arch to your schroot configuration, which will make it select the appropriate distribution when you use "-d unstable". Regards, Roger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55ba3f13.8050...@codelibre.net
Bug#794109: ITP: python-pypandoc -- Python wrapper for pandoc
Package: wnpp Severity: wishlist Owner: Elena Grandi * Package name: python-pypandoc Version : 0.9.9 Upstream Author : Juho Vepsäläinen * URL : https://github.com/bebraw/pypandoc * License : MIT Programming Lang: Python Description : Python wrapper for pandoc pypandoc provides a python interface to pandoc, a universal document converter with support for most markup languages. My plan is to start maintaining this package alone(ish), and move to team maintainance under the python-modules team as soon as the git migration will be ready. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730160357.2811.44548.report...@virginsteele.home.trueelena.org
Bug#794112: ITP: python-automaton -- friendly state machines
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-automaton Version : 0.5.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/automaton.git * License : Apache-2.0 Programming Lang: Python Description : friendly state machines Automaton is a friendly state machines for python. This state machine can be used to automatically run a given set of transitions and states in response to events (either from callbacks or from generator/iterator send() values, see PEP 342). On each triggered event, a on_enter and on_exit callback can also be provided which will be called to perform some type of action on leaving a prior state and before entering a new state. This is a new dependency for python-taskflow. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730170148.7917.47956.report...@buzig2.mirantis.com
Re: Ad-hoc survey of existing Debian git integration tools
On Thu, 30 Jul 2015 14:56:33 +0200, Vincent Bernat wrote: > ? 30 juillet 2015 11:54 +0100, Ian Jackson : > >>> > Do your published git branches contain the patches-applied or >>> > patches-unapplied tree ? >>> >>> Without using "gbp pq", the published git branches are patches-unapplied >>> trees. >> >> Then to use dgit push, you must use gbp pq. >> >> Do you see why this is necessary, when the purpose is to provide a git >> tree which is useful to someone who doesn't want to learn about your >> specific patch system and workflow ? > >On the other hand, since the previous workflow was quilt, still using >quilt is useful for someone who doesn't want to learn about specific git >workflows. Agreed. Additionally, my git/gbp workflow has blown up numerous times with the patches applied. Since switching to patches unapplied, things are just fine. >Personally, I am waiting for the number of git-based workflows to >decrease before settling for something else. Agreed. It's a real pain to have a new workflow twice for each stable release, it's killing valueable time and makes backporting a double pain. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1zkrzj-0008tn...@swivel.zugschlus.de
Re: Metapackage dependencies: "Depends" or "Recommends"?
Marvin Renich wrote: > * Josh Triplett [150729 17:18]: > > Ole Streicher wrote: > > > Other packages will never depend on this metapackage; they will rather > > > depend on the individual programs. > > > > Other packages *in Debian* will not. I actually build a pile of > > personal metapackages to set up systems, and many of their dependencies > > are metapackages. If metapackages start using Recommends, that would be > > quite inconvenient, as it would mean that I'd have to manually copy the > > list of dependencies into my metapackage (and update it if the set of > > needed packages changes) rather than just depending on the metapackage. > > I don't understand this. Why would having a Debian metapackage A which > _correctly_ uses Recommends [Considering that this is the whole point of this mail thread, "correctly" is a bit presumptuous.] > make your personal metapackage B which > Depends on A fail to install the recommended packages from A? The whole point of my metapackages is that absolutely everything *except* those metapackages is marked as "automatically installed". There's no programmatic way to distinguish between "Recommends that should be installed" and "Recommends that should not be installed"; that would be per-machine state information, which is exactly what I'm trying to avoid. So I turn off Recommends and make sure Depends reflect the packages I want installed. I suppose in theory I could turn Recommends back on and then add Conflicts in my metapackages for the Recommends that shouldn't be installed, but a quick check on my current system shows hundreds of uninstalled packages on my system that are Recommends of installed packages. That's more packages than I currently have in the Depends of my metapackages; maintaining that doesn't seem practical. Someday, perhaps I can turn Recommends back on, but for right now, there are far too many spurious recommends both in the core debootstrap set and in the average package to consider doing so. On the bright side, there's a lot of work going on right now to prune both the core debootstrap set and its Depends/Recommends. - Josh Triplett -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730175105.GA3700@jtriplet-mobl1
Re: Metapackage dependencies: "Depends" or "Recommends"?
Josh Triplett writes: > The whole point of my metapackages is that absolutely everything > *except* those metapackages is marked as "automatically installed". > There's no programmatic way to distinguish between "Recommends that > should be installed" and "Recommends that should not be installed"; that > would be per-machine state information, which is exactly what I'm trying > to avoid. What is "recommends that should not be installed"? It sounds a bit contradicting to me. Why don't you use "Suggests" for that? > So I turn off Recommends and make sure Depends reflect the packages I > want installed. I think this is abusing the dependencies. The Policy has the hint that Recommends: is for everything that is usually installed except in special situations. Why would one turn them off by default??? (... except for special situations) > I suppose in theory I could turn Recommends back on and then add > Conflicts in my metapackages for the Recommends that shouldn't be > installed, but a quick check on my current system shows hundreds of > uninstalled packages on my system that are Recommends of installed > packages. That's more packages than I currently have in the Depends of > my metapackages; maintaining that doesn't seem practical. At least, I don't get this. Can you make an example here? Best regards Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87twslr07i@debian.org
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
On Thu, Jul 30, 2015 at 05:48:25PM +0200, Antonio Diaz Diaz wrote: > Russ Allbery wrote: > >That doesn't mean your objections are wrong, and I certainly haven't > >looked at it in detail. But they don't seem to be widely shared. > It is software, a branch of mathematics, what is being discussed here. In > mathematics a proof outweights the opinion of the whole humankind. It > doesn't matter how much consensus you gather, pi won't become 3. My > objections to xz are based on proof that xz is wrong. No. Computer science is mathematics. Algorithms are mathematics. Software is something else. You cannot "prove" that a customer's priorities are wrong. > >I realize that you're quite confident in your expertise here, and quite > >possibly have reason to be confident, but it might be worth remembering > >that, to the rest of us, you're just some random person on a mailing list > >who has written some competing software and wants us to use it. No > >offense, but we see a *lot* of people like that, and most of them are > >significantly overstating their claims. So you're facing a fair bit of > >natural skepticism. > You continue speaking as if this were a political question that you can win > by obtaining the approval of the majority or something. There is no place > here neither for faith nor for scepticism. Just verify that my affirmations > are true, or refute them. > I am not writing here because I want you to use lzip. I am writing here > because I want you (Debian) to stop spreading FUD against lzip, like ".lz > only supports CRC32" (implying that lzip integrity is weak), or gratuitously > affirming that ".xz is superior to .lz". I am still waiting for anybody in > this list to tell us in what aspect is .xz superior to .lz. Please point us to where Debian is making these statements. You are not going to get all Debian developers to stop disapproving of lzip by having a protracted argument on debian-devel with some /other/ group of Debian developers. If a particular Debian developer is making such statements, you should probably take this up with them. That aside, in this thread you certainly have done much more in this thread than ask Debian to stop making unsubstantiated claims; you are insisting that Debian should accept your position that lzip is superior, and you have asserted that Debian should drop xz and adopt lzip. Denying that you have done this does nothing to help you appear more reasonable. > >Therefore, our community welcomes both, and does not > >react well to aggressive statements like this about how the other set of > >beliefs is obviously wrong. > Aggressive statement? I guess your community should change its own > documentation. I merely copied the description from there: > http://www.debian.org/intro/free > "Truly free software is always free. Software that is placed in the public > domain can be snapped up and put into non-free programs. Any improvements > then made are lost to society. To stay free, software must be copyrighted > and licensed." Thanks for bringing this to our attention. This is not an official position of the Debian project; I've reported this as a bug: http://bugs.debian.org/794116 -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#794125: ITP: mopidy-youtube -- Mopidy extension for playing music from YouTube
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: mopidy-youtube Version : 2.0.0 Upstream Author : Janez Troha * URL : https://github.com/dz0ny/mopidy-youtube * License : Apache-2.0 Programming Lang: Python Description : Mopidy extension for playing music from YouTube Mopidy is a music server which can play music from multiple sources, like your local hard drive, radio streams, and from Spotify and SoundCloud. This package provides a Mopidy extension for playing sound from YouTube videos. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730195059.6799.15288.report...@kih.jodal.no
Bug#794143: ITP: mopidy-local-sqlite -- Mopidy extension for keeping your local library in SQLite
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: mopidy-local-sqlite Version : 0.10.2 Upstream Author : Thomas Kemmer * URL : https://github.com/tkem/mopidy-local-sqlite * License : Apache-2.0 Programming Lang: Python Description : Mopidy extension for keeping your local library in SQLite Mopidy is a music server which can play music from multiple sources, like your local hard drive, radio streams, and from Spotify and SoundCloud. This package provides a Mopidy local library extension that uses an SQLitedatabase for keeping track of your local media. This extension lets you browse your music collection by album, artist, composer and performer, and provides full-text search capabilities based on SQLite's FTS modules. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730205556.31449.42167.report...@kih.jodal.no
Feature Debian in MeetAdvisors Blog!
Hi Ian, I am writing a blog at MeetAdvisors.com on companies that are driving their industries forward, I would love to include you! I'll be looking for why you do what you, what your passion is, and to gather a piece of advice you'd like to share with our community. Is there a time in the coming days that you are available to chat? Please get back to me as soon as possible so that I can get it scheduled with you. I look forward to speaking further. Thanks! -- Angela Lianza www.MeetAdvisors.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cafxkvdop8n3q-9tkg1n7g0pggl7+qcbalscqutyzhzoaocf...@mail.gmail.com
Bug#794151: ITP: python-uritools -- RFC 3986 compliant replacement for urlparse
Package: wnpp Severity: wishlist Owner: Stein Magnus Jodal * Package name: python-uritools Version : 1.0.1 Upstream Author : Thomas Kemmer * URL : https://github.com/tkem/uritools * License : Expat Programming Lang: Python Description : RFC 3986 compliant replacement for urlparse This module defines RFC 3986 compliant replacements for the most commonly used functions of the Python 2.7 Standard Library urlparse and Python 3 urllib.parse modules. For various reasons, the Python 2 urlparse module is not compliant with current Internet standards, does not include Unicode support, and is generally unusable with proprietary URI schemes. Python 3's urllib.parse improves on Unicode support, but the other issues still remain. This module aims to provide fully RFC 3986 compliant replacements for some commonly used functions found in urlparse and urllib.parse, plus additional functions for conveniently composing URIs from their individual components. python-uritools is a dependency for mopidy-local-sqlite (ITP #794143). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730213343.18517.47854.report...@kih.jodal.no
Re: Metapackage dependencies: "Depends" or "Recommends"?
Ole Streicher wrote: > Josh Triplett writes: > > The whole point of my metapackages is that absolutely everything > > *except* those metapackages is marked as "automatically installed". > > There's no programmatic way to distinguish between "Recommends that > > should be installed" and "Recommends that should not be installed"; that > > would be per-machine state information, which is exactly what I'm trying > > to avoid. > > What is "recommends that should not be installed"? It sounds a bit > contradicting to me. Why don't you use "Suggests" for that? I'm not talking about the dependencies of my metapackages; I only use Depends and Conflicts in those. I'm talking about the Recommends of packages in Debian. And there are quite a few of those that I do indeed think ought to use Suggests. > > So I turn off Recommends and make sure Depends reflect the packages I > > want installed. > > I think this is abusing the dependencies. The Policy has the hint that > Recommends: is for everything that is usually installed except in > special situations. Why would one turn them off by default??? > (... except for special situations) That's what Policy says, yes. That doesn't mean all Recommends are sensible, and in practice, it's more common that I *don't* want them than that I do. > > I suppose in theory I could turn Recommends back on and then add > > Conflicts in my metapackages for the Recommends that shouldn't be > > installed, but a quick check on my current system shows hundreds of > > uninstalled packages on my system that are Recommends of installed > > packages. That's more packages than I currently have in the Depends of > > my metapackages; maintaining that doesn't seem practical. > > At least, I don't get this. Can you make an example here? Sure. Here are a few packages that are Recommends of packages I do depend on, but that I don't want installed: - default-mta - ppp - valgrind-dbg (323MB of debug symbols) - xpdf - libltdl-dev (anything that needs this should have a Depends on it) - locales (not since libc-bin started shipping C.UTF-8) - mailx (as provided by bsd-mailx and similar) - Piles and piles of extra Perl modules - busybox-static Of those, only locales seems at all justifiable as something that should almost always be co-installed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730214842.GA20216@x
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
On Thu, 2015-07-30 at 11:47 -0700, Steve Langasek wrote: > On Thu, Jul 30, 2015 at 05:48:25PM +0200, Antonio Diaz Diaz wrote: > > Aggressive statement? I guess your community should change its own > > documentation. I merely copied the description from there: > > > http://www.debian.org/intro/free > > "Truly free software is always free. Software that is placed in the public > > domain can be snapped up and put into non-free programs. Any improvements > > then made are lost to society. To stay free, software must be copyrighted > > and licensed." > > Thanks for bringing this to our attention. This is not an official position > of the Debian project; I've reported this as a bug: > http://bugs.debian.org/794116 Incredible, Debian does no longer adopt to the world of free software (not opensource) :( I wonder how RMS feels about this? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1438295412.2785.5.ca...@gmail.com
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
On 06/13/2015 10:23 AM, Thomas Goirand wrote: > We use "git archive" within the PKG OpenStack team to generate this > tarball (which is more or less the same as pristine-tar, except we use > upstream tags rather than a pristine-tar branch). The fact that xz > produces a different result makes it not reproducible. As a consequence, > it is very hard for us to use this system across distributions (ie: use > that in both Debian and Ubuntu, or in Sid & Jessie). We need consistency. What you want to do neither works wit gzip nor xy. Use pristine-tar, it was made for that. I can't see why one would not want to use it. bzed@think /tmp % mkdir foo bzed@think /tmp % touch foo/bar bzed@think /tmp % tar cvfz foo1.tar.gz foo foo/ foo/bar bzed@think /tmp % tar cvfz foo2.tar.gz foo foo/ foo/bar bzed@think /tmp % md5sum foo*.tar.gz daae33f08d992cd29cb2040d4709bc32 foo1.tar.gz ab9be3584f38ffe4791a33bf25ed5cfc foo2.tar.gz bzed@think /tmp % gunzip foo*.tar.gz bzed@think /tmp % md5sum foo*.tar dfbf1eec4f1a73686fc5bac4d5f82725 foo1.tar dfbf1eec4f1a73686fc5bac4d5f82725 foo2.tar bzed@think /tmp % lzip foo*.tar bzed@think /tmp % md5sum foo*.tar.lz 84393a8d1883f250e44ab66410c0f462 foo1.tar.lz 84393a8d1883f250e44ab66410c0f462 foo2.tar.lz lzip indeed does what you'd like to have, but imho it is much easier for you (and with you I mean the openstack people) to use pristine-tar instead of trying to implement lzip support in dpkg, dak and friends... -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55baa591.8070...@bzed.de
Bug#794167: ITP: python-oslo.reports -- reports serialized in various data types
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-oslo.reports Version : 0.3.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/oslo.reports * License : Apache-2.0 Programming Lang: Python Description : reports serialized in various data types This package/module provides mechanisms for defining reports which may then be serialized into various data types. Each report is composed of one or more report sections, which contain generators which generate data models, which are then serialized by views. This is a new dependency of OpenStack compute (aka: nova). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150730223044.15419.91248.report...@buzig2.mirantis.com
Bug#794173: ITP: libdist-zilla-plugin-metaprovides-perl -- Dist::Zilla plugin generating and populating "provides" in your META.yml
Package: wnpp Owner: Axel Beckert Severity: wishlist * Package name: libdist-zilla-plugin-metaprovides-perl Version : 2.001002 Upstream Author : Kent Fredric * URL : https://metacpan.org/release/Dist-Zilla-Plugin-MetaProvides * License : Artistic or GPL-1+ Programming Lang: Perl Description : Dist::Zilla plugin generating and populating "provides" in your META.yml Dist::Zilla::Plugin::MetaProvides is a Dist::Zilla plugin which generates and populates the "provides" field in the META.yml of your Dist::Zilla using Perl distribution. The package will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87lhdxntbn@c-cactus.ontheroad.deuxchevaux.org
Bug#794174: ITP: libdist-zilla-util-configdumper-perl -- Dist::Zilla helper utility to dump configurations
Package: wnpp Owner: Axel Beckert Severity: wishlist Control: block 794173 by -1 * Package name: libdist-zilla-util-configdumper-perl Version : 0.003006 Upstream Author : Kent Fredric * URL : https://metacpan.org/release/Dist-Zilla-Util-ConfigDumper * License : Artistic or GPL-1+ Programming Lang: Perl Description : Dist::Zilla helper utility to dump configurations Dist::Zilla::Util::ConfigDumper provides functions for extracting the "plugin" configuration data with Dist::Zilla's "around dump_config". (This package description is far from perfect, but upstream's is worse, see https://github.com/kentnl/Dist-Zilla-Util-ConfigDumper/issues/3) The package is a dependency for libdist-zilla-plugin-metaprovides-perl (see #794173) and will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87io91nsw2@c-cactus.ontheroad.deuxchevaux.org
Bug#794175: ITP: libdist-zilla-util-test-kentnl-perl -- Module to write tests for Dist::Zilla plugins
Package: wnpp Owner: Axel Beckert Severity: wishlist Control: block 794173 by -1 Control: block 794174 by -1 * Package name: libdist-zilla-util-test-kentnl-perl Version : 1.005012 Upstream Author : Kent Fredric * URL : https://metacpan.org/release/Dist-Zilla-Util-Test-KENTNL * License : Artistic or GPL-1+ Programming Lang: Perl Description : Module to write tests for Dist::Zilla plugins Dist::Zilla::Util::Test::KENTNL is a helper module by KENTNL to write tests for Dist::Zilla plugins. This package is a build-dependency of libdist-zilla-util-configdumper-perl (#794174) and libdist-zilla-plugin-metaprovides-perl (#794173) and will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fv45nr66@c-cactus.ontheroad.deuxchevaux.org
Bug#794177: ITP: librecommended-perl -- Load recommended Perl modules on demand when available
Package: wnpp Owner: Axel Beckert Severity: wishlist Control: block 794175 by -1 * Package name: librecommended-perl Version : 0.003 Upstream Author : David Golden * URL : https://metacpan.org/release/recommended * License : Apache-2.0 Programming Lang: Perl Description : Load recommended Perl modules on demand when available recommended gathers a list of recommended modules and versions and provides means to check if they are available. It is a thin veneer around Module::Runtime. There are two major benefits over using Module::Runtime directly: * Self-documents recommended modules together with versions at the top of your code, while still loading them on demand elsewhere. * Dies if a recommended module exists but fails to compile, but doesn't die if the module is missing or the version is insufficient. This is not something that Module::Runtime offers in a single subroutine. The package is a dependency of libdist-zilla-util-test-kentnl-perl (#794175) and will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d1z9nqxb@c-cactus.ontheroad.deuxchevaux.org
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Svante Signell writes ("Re: Adding support for LZIP to dpkg, using that instead
of xz, archive wide"):
> On Thu, 2015-07-30 at 11:47 -0700, Steve Langasek wrote:
> > > http://www.debian.org/intro/free
> > > "Truly free software is always free. Software that is placed in the public
> > > domain can be snapped up and put into non-free programs. Any improvements
> > > then made are lost to society. To stay free, software must be copyrighted
> > > and licensed."
> >
> > Thanks for bringing this to our attention. This is not an
> > official position of the Debian project; I've reported this as a
> > bug: http://bugs.debian.org/794116
>
> Incredible, Debian does no longer adopt to the world of free software
> (not opensource) :( I wonder how RMS feels about this?
Note that nowhere do Steve or Neil say that they disagree with the
quote. The quoted statement is one I might well have posted myself,
on my own website or in my own writing.
But Steve is quite right in everything he says in #794116 and Neil was
quite write to remove it. I applaud Steve's courteous, practical and
neutral comments in #794116, and Neil's prompt and appropriate
response.
I don't think there is much point having a conversation here on -devel
about the validity of the quote. And if you really want it put back,
please take it to -project, at the very least.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21946.47804.725246.143...@chiark.greenend.org.uk
Bug#794179: ITP: libdata-dpath-perl -- DPath is like XPath but for Perl data structures
Package: wnpp Owner: Axel Beckert Severity: wishlist Control: block 794175 by -1 * Package name: libdata-dpath-perl Version : 0.53 Upstream Author : Steffen Schwigon * URL : https://metacpan.org/release/Data-DPath * License : Artistic or GPL-1+ Programming Lang: Perl Description : DPath is like XPath but for Perl data structures With Data::DPath you can address points in a Perl data structure by describing a "path" to it using hash keys, array indexes or some wildcard-like steps. It is inspired by XPath but differs from it. This package is a dependency of libdist-zilla-util-test-kentnl-perl (#794175) and will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a8udnqaa@c-cactus.ontheroad.deuxchevaux.org
Bug#794180: ITP: libiterator-util-perl -- Useful functions for creating and manipulating iterator objects
Package: wnpp Owner: Axel Beckert Severity: wishlist Control: block 794179 by -1 * Package name: libiterator-util-perl Version : 0.02 Upstream Author : Eric J. Roode * URL : https://metacpan.org/release/Iterator-Util * License : Artistic or GPL-1+ Programming Lang: Perl Description : Useful functions for creating and manipulating iterator objects Iterator::Util implements many useful functions for creating and manipulating iterator objects. An "iterator" is an object, represented as a code block that generates the "next value" of a sequence, and generally implemented as a closure. For further information, including a tutorial on using iterator objects, see the Iterator documentation. The package is a dependency of libdata-dpath-perl (#794179) and will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/877fphnp5u@c-cactus.ontheroad.deuxchevaux.org
Bug#794181: ITP: libiterator-perl -- Perl implementation of iterators
Package: wnpp Owner: Axel Beckert Severity: wishlist * Package name: libiterator-perl Version : 0.03 Upstream Author : Eric J. Roode * URL : https://metacpan.org/release/Iterator * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl implementation of iterators Iterator is meant to be the definitive implementation of iterators, as popularized by Mark Jason Dominus's lectures and recent book (Higher Order Perl, Morgan Kauffman, 2005). An "iterator" is an object, represented as a code block that generates the "next value" of a sequence, and generally implemented as a closure. When you need a value to operate on, you pull it from the iterator. If it depends on other iterators, it pulls values from them when it needs to. Iterators can be chained together (see Iterator::Util for functions that help you do just that), queueing up work to be done but not actually doing it until a value is needed at the front end of the chain. At that time, one data value is pulled through the chain. This package is a dependency of libiterator-util-perl (#794180) and will be maintained under the umbrella of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/874mklnoml@c-cactus.ontheroad.deuxchevaux.org
Work-needing packages report for Jul 31, 2015
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: 678 (new: 3) Total number of packages offered up for adoption: 181 (new: 2) Total number of packages requested help for: 50 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: album (#794001), orphaned yesterday (non-free) Description: HTML photo album generator with theme support Reverse Depends: album-data Installations reported by Popcon: 203 album-data (#794002), orphaned yesterday (non-free) Description: themes, plugins and translations for album Installations reported by Popcon: 183 hapm (#793799), orphaned 3 days ago Description: light and fast high availability port monitor Installations reported by Popcon: 3 675 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: dwm (#793985), offered yesterday Description: dynamic window manager Installations reported by Popcon: 750 imagination (#794048), offered today Description: DVD slide show maker Reverse Depends: imagination Installations reported by Popcon: 412 179 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: apt-xapian-index (#567955), requested 2005 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: ept-cache goplay muon muon-discover packagesearch Installations reported by Popcon: 49183 athcool (#278442), requested 3929 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 31 awstats (#755797), requested 372 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4133 balsa (#642906), requested 1404 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 710 cardstories (#624100), requested 1557 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 7 cups (#532097), requested 2245 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (68 more omitted) Installations reported by Popcon: 139172 debtags (#567954), requested 2005 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2012 developers-reference (#759995), requested 334 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 14163 ejabberd (#767874), requested 269 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib Installations reported by Popcon: 794 fbcat (#565156), requested 2024 days ago Description: framebuffer grabber Installations reported by Popcon: 163 freeipmi (#628062), requested 1526 days ago Description: GNU implementation of the IPMI protocol Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev libfreeipmi16 libipmiconsole-dev libipmiconsole2 (6 more omitted) Installations reported by Popcon: 6345 gnat-gps (#496905), requested 2527 days ago Description: co-maintainer needed Reverse Depends: gnat-gps gnat-gps-dbg Installations reported by Popcon: 491 gnokii (#677750), requested 1139 days ago Description: Datasuite for mobile phone management Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6 xgnokii Installations reported by Popcon: 1311 gridengine (#703256), requested 865 days ago Description: Distributed resource management Reverse Depends: gridengine-client gridengine-drmaa-dev gridengine-exec gridengine-master gridengine-qmon Installations reported by Popcon: 1057 grub2 (#248397), requested 4098 days ago Description: GRand Unified Bootloader Reverse Depends: debootstick grml-rescueboot grml2usb grub-coreboot grub-coreboot-bin grub-co
Re: Adding support for LZIP to dpkg, using that instead of xz, archive wide
Hallo, * Andrew Shadura [Fri, Jul 31 2015, 12:32:15AM]: > On 31 July 2015 at 00:30, Svante Signell wrote: > > Incredible, Debian does no longer adopt to the world of free software > > (not opensource) :( I wonder how RMS feels about this? > > Open source is free software. Free software is open source. No open > source software isn't also free software. No free software isn't also > open source. > > For more information, see also: > http://jordi.inversethought.com/blog/5-things-we-have-forgotten-about-open-source/ In an ideal world. In ours, "Open" can be like OpenGL consortium or Open Automomotive Alliance or Open Mobile Alliance. Yeah, fully open, just pay a little fee and don't disclose anything unless they are also "true open"... Regards, Eduard. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150731064534.ga13...@rotes76.wohnheim.uni-kl.de
