Re: Call for volunteers: FTP Team
Le 17 août 2017 20:11:01 GMT+02:00, Joerg Jaspert a écrit : >Hello Debian world, > >it has been quite a while since the last call for volunteers, so here >is >an update: Yeah, we still need people, and we want you. Well, that is, >if you are a Debian Developer, for this. If you are not and want to >help, read the last paragraph please. > > >Ever felt compelled to do the hard groundwork? Ever wanted to help at a >nicely central place inside Debian? Or just want to write some Python >code and still look for a good place to stick it in? > >Here we are. Come join the Nav^Wteam. Just sign over there to the >right, >or even easier, mail us. We won't bite you, thats for sure. At least >not >right away. :) > >The criteria are the same as always: You need to be a DD (except for >coding only, though it helps to know the usual flow of a package) and >you need to be able to deal with the existing team members. > >An occasional flame should also not disturb you, if you are working in >the NEW queue you will stand between the people uploading and the >packages entering the archive, rejecting something is not always liked >much. (But you often get positive replies and thanks, to keep your >spirits up :) ). > >And - if you get headaches when reading legal texts - we all do. But it >is needed and things like NEW are mainly about that, the ftpteam is >*the* one place to decide if something is ok for Debian to distribute >or >not, and you will have to take this decision. (Yes, there is more, but >this is the main point you are going to check). > >Obviously the other points we made in earlier mails, like [1], still >apply too. > > > >Another good way helping the ftpteam is - by not joining us! Yvan eht >Nioj! (Or for people not watching Simpsons: Join the Navy!) >Err, no, of course not, but: Join the QA team! >There is a lot of work commonly associated to the QA group but not many >people doing it. You could help out there, which in turn will help us >again. On the qa front, with m'y lintian hat I could help you to do autoreject (thus decreasing tour work) but i need bug report on your side. Or even a mail. We want to reject some license some stuff will help. Bastien > > >[1] http://lists.debian.org/debian-devel-announce/2010/03/msg3.html > >Stay tuned for more news coming from the team soon. -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Re: Call for volunteers: FTP Team
On 14768 March 1977, Philip Hands wrote: >> ...Well, in keeping with the Toy Story theme, FTW Masters is >> worshipped by the Squeezes (packages alien to the archive) and at the >> time of a "Win" a package new to the archive is selected as for the >> "World". Finally, New Maintainers tremble with trepidation at the >> power of The Claw, as it is known internally. > I like "The Claw" -- responsible for picking up NEW packages, and giving > them to the kids, or dropping them. Don't you all have something more important to do? -- bye, Joerg
Bug#872534: ITP: spyder-reports -- Spyder-IDE plugin for Markdown reports using Pweave
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: spyder-reports Version : 0.1.1 Upstream Author : Spyder Project Contributors * URL : https://github.com/spyder-ide/spyder-reports * License : Expat Programming Lang: Python Description : Spyder-IDE plugin for Markdown reports using Pweave This package will be co-maintained by the Debian Science Team, alongside the rest of the Spyder ecosystem.
Re: Whether remotely running software is considered "software" for Debian.
On Tue, Aug 15, 2017 at 08:46:43AM +1000, Ben Finney wrote: > The language is clear that it is talking about dependency in the sense > of requiring the program installed on the system in order for the > program to build or execute. I think the mention of package dependencies is an incomplete list of examples. But even if it was meant to be complete, thinking for a moment about the purpose of Debian should make clear that your interpretation cannot be correct: The reason we have the rules is because we care about freedom. That doesn't suddenly end when a program runs on a different server. Consider the following: unrar-nonfree contains some software which is non-free and can therefore not be in main. The reason we don't put it in main is that we want users who care about freedom to not even see this software. Agreed? Now what would be the result of moving this non-free part to a network server? In terms of freedom there are no benefits to this. The user is still using the non-free software, but now they can also be tracked by the server admin, and they can't use a debugger to hack it, should they want to. So it is 100% bad for them. However, according to your logic, because it is no longer running on your own cpu, this change would allow unrar-nonfree to go into main. You do agree that this is not a sensible result of making software worse, right? > > I think they are equivalent; server software is still software and I > > don't see why it running remotely suddenly makes it acceptable to > > depend on it. > > You appear to be using “depend” here to mean “without this the program > *is not useful*”. Most programs in contrib can build and run without non-free software. They will just immediately produce an error message. Our users would describe that as depending on the non-free software. > The language in Policy §2.2 does not relate to any program's purpose at > all. What do you think the purpose of policy is, if not to ensure that our software gives freedom to our users? Thanks, Bas signature.asc Description: PGP signature
Re: apt-get dist-upgrade uninstalled most of KDE
On Wed, Aug 16, 2017 at 12:56:07PM -0700, nob...@gmail.com wrote: > Hello, > > I just upgraded my system (Debian sid with main, contrib, non-free) to > the most recent unstable version, running "apt-get update" and > "apt-get dist-upgrade". [...] >From what I've been told you should basically only use 'dist-upgrade' when you upgrade between different releases, eg. wheezy -> jessie, jessie -> stretch, stretch -> testing/unstable. If you upgrade the same release (eg. sid -> sid) you should normally only use 'apt upgrade'. By using 'apt dist-upgrade' you're telling apt that it's ok to remove things. If you do use dist-upgrade in sid while transitions is still ongoing/unfinished you will end up with lots of things removed. At the same time you might need to use dist-upgrade to upgrade things in sid after a transition has been made. You're basically expected to be able to understand what apt is asking you and answer correctly. Also when running sid you should be able to unbreak your own system. Regards, Andreas Henriksson
Re: fdisk becoming non-essential, dependencies needed.
On Thu, Aug 10, 2017 at 5:11 PM, Andreas Henriksson wrote: > Hello, > > A new version 2.29.2-3 of src:util-linux was recently uploaded to > experimental[1]. The plan is to ship those changes in Buster. > > In this version the fdisk, sfdisk and cfdisk utilities has been split > out into a separate 'fdisk' package. Any package that needs these > utilities should add a dependency on the fdisk package in Buster! > (Attempts will be made to track down and file bug reports, but > ultimately maintainers need to take the final responsibility for the > dependency being added before the Buster freeze.) > > Your new dependency declaration might look like this: > fdisk | util-linux (<< 2.29.2-3~) > See also the util-linux NEWS entry[2]. > > Currently (for Buster) the fdisk package is being made > 'pseudo-essential' via a dependency from the Essential util-linux > package, where the tools was split out from. (This is also to support > upgrades from Stretch to Buster.) > The plan is to drop this dependency (making fdisk no longer > pseudo-essential) for Buster+1 (Bullseye). The Priority field will > likely be set to important so fdisk utilities will still be part of any > normal installation, but will then be deinstallable. Why not setting in recommand ? It will be installed by default but could be deinstalled Bastien > > The reason for this split is to decrease the size of the Essential set. > Once fdisk is deinstallable so should libfdisk1 and libncursesw5 also > be. This helps keep the size of minimal chroots down, not to mention > people might prefer other partitioning tools like parted, etc. > Unfortunately the package will not be easily deinstallable for Buster, > but eager minds might be able to use equivs to create an empty fdisk > package to satisfy the transitional dependency while waiting for > Bullseye. > > For extra gold star please read up on fdisk/libfdisk1 enhancements like > supporting GPT (since Jessie), etc. Make sure to stop using any C/H/S- > adressing (on command line or elsewhere) since it's deprecated[4]. > > Regards, > Andreas Henriksson > > PS. See also 'mount' package NEWS[3] for similar changes. Strict > dependencies should be added where needed. > > [1]: https://tracker.debian.org/news/861509 > [2]: > https://anonscm.debian.org/cgit/collab-maint/pkg-util-linux.git/commit/?id=3114bfedb044fab22b0a865f6c2fae85b1207677 > [3]: > https://anonscm.debian.org/cgit/collab-maint/pkg-util-linux.git/commit/?id=c650149427862a7b3dfcbdf2355308d042d39629 > [4]: > http://sources.debian.net/src/util-linux/2.29.2-2/Documentation/deprecated.txt/ >
Bug#872548: ITP: node-pathval -- Node.js module for object value access from a path
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-pathval Version : 1.1.0 Upstream Author : Veselin Todorov * URL : https://github.com/chaijs/pathval * License : Expat Programming Lang: JavaScript Description : Node.js module for object value access from a path This module is a tool to access Object values given a string path, both retrieving and setting properties. . Node.js is an event-based server-side JavaScript engine. I plan to maintain it within the Debian Javascript Maintainers team, and I'm interested in it because updating node-chai requires it and the maintainer needs help. Cheers, Snark on #debian-js
Re: Call for volunteers: FTP Team
Hi, Am Donnerstag, den 17.08.2017, 23:02 +0200 schrieb Jonathan Carter (highvoltage): > On 17/08/2017 20:11, Joerg Jaspert wrote: > > it has been quite a while since the last call for volunteers, so here is > > an update: Yeah, we still need people, and we want you. Well, that is, > > if you are a Debian Developer, for this. If you are not and want to > > help, read the last paragraph please. > > If someone hypothetically joins, are they allowed to rename the FTP team > to something that doesn't include "FTP"? I don’t see a need to rename our beloved “Filtering The Packages Team”. SCNR, Joachim -- Joachim “nomeata” Breitner Debian Developer nome...@debian.org • https://people.debian.org/~nomeata XMPP: nome...@joachim-breitner.de • GPG-Key: 0xF0FBF51F https://www.joachim-breitner.de/ signature.asc Description: This is a digitally signed message part
Bug#872552: ITP: node-check-error -- Node.js module for error handling
Package: wnpp Severity: wishlist Owner: Julien Puydt X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-check-error Version : 1.0.1 Upstream Author : Jake Luer * URL : https://github.com/chaijs/check-error * License : Expat Programming Lang: JavaScript Description : Node.js module for error handling This module helps to retrieve an Error's information such as its message or constructor name, but also check whether two Errors are compatible based on various data. . Node.js is an event-based server-side JavaScript engine. I plan to maintain it within the Debian Javascript Maintainers team, and I'm interested in it because updating node-chai requires it and the maintainer needs help. Cheers, Snark on #debian-js
Re: Call for volunteers: FTP Team
On Thu, Aug 17, 2017 at 4:02 PM, Jonathan Carter (highvoltage) < j...@debian.org> wrote: > On 17/08/2017 20:11, Joerg Jaspert wrote: > > it has been quite a while since the last call for volunteers, so here is > > an update: Yeah, we still need people, and we want you. Well, that is, > > if you are a Debian Developer, for this. If you are not and want to > > help, read the last paragraph please. > > If someone hypothetically joins, are they allowed to rename the FTP team > to something that doesn't include "FTP"? > Archive Team. Or the A-Team for short. The only Debian team with a theme song. -m
Re: Call for volunteers: FTP Team
Hi, On Fri, 2017-08-18 at 08:24 -0500, Matt Zagrabelny wrote: ... > > > if you are a Debian Developer, for this. If you are not and want to > > > > > help, read the last paragraph please. > > > > > > > > If someone hypothetically joins, are they allowed to rename the FTP team > > > > to something that doesn't include "FTP"? > > > > Archive Team. Or the A-Team for short. The only Debian team with a theme song. Why Archive, maybe Queue is more accurate (Q-Team), isn't it? -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Re: Call for volunteers: FTP Team
Abou Al Montacir writes: > On Fri, 2017-08-18 at 08:24 -0500, Matt Zagrabelny wrote: > ... >> > If someone hypothetically joins, are they allowed to rename the FTP team >> > >> > to something that doesn't include "FTP"? >> >> Archive Team. Or the A-Team for short. The only Debian team with a theme >> song. > Why Archive, maybe Queue is more accurate (Q-Team), isn't it? An invitation to join the Q Continuum might be more attractive. Bjørn
Re: Call for volunteers: FTP Team
On Fri, Aug 18, 2017 at 03:54:55PM +0200, Bjørn Mork wrote: > Abou Al Montacir writes: > > On Fri, 2017-08-18 at 08:24 -0500, Matt Zagrabelny wrote: > >> > If someone hypothetically joins, are they allowed to rename the FTP team > >> > > >> > to something that doesn't include "FTP"? > >> > >> Archive Team. Or the A-Team for short. The only Debian team with a theme > >> song. > > Why Archive, maybe Queue is more accurate (Q-Team), isn't it? > > An invitation to join the Q Continuum might be more attractive. Don't they _assimilate_ packages into the archive... -- Luca Filipozzi
Re: Call for volunteers: FTP Team
On Fri, Aug 18, 2017 at 03:47:56PM +0200, Abou Al Montacir wrote: > Why Archive, maybe Queue is more accurate (Q-Team), isn't it? Several mails in this thread seem to assume that the main or even the only job of the ftp team is processing the NEW queue. This is not true. -- WBR, wRAR signature.asc Description: PGP signature
Re: Call for volunteers: FTP Team
Luca Filipozzi - 18.08.17, 13:57: > On Fri, Aug 18, 2017 at 03:54:55PM +0200, Bjørn Mork wrote: > > Abou Al Montacir writes: > > > On Fri, 2017-08-18 at 08:24 -0500, Matt Zagrabelny wrote: > > >> > If someone hypothetically joins, are they allowed to rename the FTP > > >> > team > > >> > > > >> > to something that doesn't include "FTP"? > > >> > > >> Archive Team. Or the A-Team for short. The only Debian team with a > > >> theme song.> > > > > Why Archive, maybe Queue is more accurate (Q-Team), isn't it? > > > > An invitation to join the Q Continuum might be more attractive. > > Don't they _assimilate_ packages into the archive... Weren´t that the Borgs? All your software belongs to everyone. And can this thread get any more ridiculous? :) Anyway… regarding any rename… I´d say the current FTP team… shall have a word ins this… and when they are happy with their current name… this thread is just one of the more funny episodes on debian-devel. Thanks, -- Martin
Re: openssl/libssl1 in Debian now blocks offlineimap?
On Tue, Aug 15, 2017 at 05:04:50PM +0200, Kurt Roeckx wrote: > My problem is that if we don't do something, TLS 1.0 will be used > for an other 10 year, and that's just not acceptable. My problem is that the cause you're fighting, while laudable, should not be fought in Debian. Debian is a general-purpose operating system, not a security-focused one. If we were, people would be right to expect that there might sometimes be problems with the software they're using in support of the "security" goal. Since we're not, people would rightly be upset if the complex environments they're trying to support are suddenly broken in the name of "security". > So I would like to do something so that hopefully by the time Buster > releases you can disable TLS 1.0 by default, and that almost no users > would need to enable it again. > > Having TLS 1.0 (and 1.1) enabled by default itself is not a > problem, it's actually using it that's a problem. There are > clearly still too many that don't support TLS 1.2, but it's > getting better. So ship a version of OpenSSL that ships with TLS1.0 and TLS1.1 (aka TLS1.old) disabled, but *allow people to re-enable it* if things break (without requiring them to compile their own version). By shipping a version of OpenSSL that has TLS1.old not even compiled in, you're not doing that. I have seen suggestions that the goal of this would be to re-enable TLS1.old before buster releases. If that is true, I fail to see the point; I think it makes *much* more sense to ship buster with TLS1.old disabled by default, but to allow for re-enabling it on a per-application basis. Having a policy configuration that can be modified by the system administrator through a mechanism inside libssl that cannot be disabled and that can be configured on a per-application basis would seem to be a much more interesting way to do this. > Disabling the protocols is the only way I know how to identify > all the problems. And I would like to encourage everybody to > contact the other side if things break and get them to upgrade. That latter part is certainly a good idea; and while "get the other side to upgrade" is often a reasonable course of action, just as often it is not, and then you need to have a way out. By not even compiling in the code to support TLS1.old, you're depriving people of that "way out". -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: fdisk becoming non-essential, dependencies needed.
On Fri, Aug 18, 2017 at 11:59:13AM +0200, Bastien ROUCARIES wrote:
> On Thu, Aug 10, 2017 at 5:11 PM, Andreas Henriksson wrote:
> > Hello,
> >
> > A new version 2.29.2-3 of src:util-linux was recently uploaded to
> > experimental[1]. The plan is to ship those changes in Buster.
> >
> > In this version the fdisk, sfdisk and cfdisk utilities has been split
> > out into a separate 'fdisk' package. Any package that needs these
> > utilities should add a dependency on the fdisk package in Buster!
> > (Attempts will be made to track down and file bug reports, but
> > ultimately maintainers need to take the final responsibility for the
> > dependency being added before the Buster freeze.)
> >
> > Your new dependency declaration might look like this:
> > fdisk | util-linux (<< 2.29.2-3~)
> > See also the util-linux NEWS entry[2].
> >
> > Currently (for Buster) the fdisk package is being made
> > 'pseudo-essential' via a dependency from the Essential util-linux
> > package, where the tools was split out from. (This is also to support
> > upgrades from Stretch to Buster.)
> > The plan is to drop this dependency (making fdisk no longer
> > pseudo-essential) for Buster+1 (Bullseye). The Priority field will
> > likely be set to important so fdisk utilities will still be part of any
> > normal installation, but will then be deinstallable.
>
> Why not setting in recommand ? It will be installed by default but
> could be deinstalled
I guess because debootstrap does not install Recommends?
--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
| Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline'). Thank you.
Bug#847003: ITP: connid -- framework for provisioning identities to repositories
Package: wnpp Followup-For: Bug #847003 Owner: Christopher Hoskin Work in progress here: https://anonscm.debian.org/cgit/pkg-java/connid.git/ Christopher
BONJOUR
Bonjour Vous avez un projet et besoin de financement, un mauvais dossier de crédit ou besoin d'argent pour payer des factures, fonds à investir sur les entreprises. Alors si vous avez besoin de prêt n'hésitez pas à me contacter pour en savoir plus sur nos conditions et pour toute autre information. Cordialement
Re: Improvement of sensible-utils
Am 11.08.2017 um 18:37 schrieb Bastien ROUCARIES: > Hi, > > I have done some work for sensible-utils but I am a little stuck due > to lack of documentation/policy. > > I want first to create desktop file for > sensible-editor/sensible-pager/sensible-browser in order to open from > firefox text file (fixing #780742). > > The main problem is to exec this in a terminal or not depending of the > context. > > I propose first to solve #594942 and to implement sensible-x-terminal > first. This program will > exec $XTERMINAL if set, then if configured $SENSIBLE_XTERMINAL and > lastly choose the terminal according to desktop running (maybe using > xdg-open /proc/self/1 < sensible-x-terminal > > Then nano for instance will provide sensible-editor-nano that will use > library provided by sensible-utils in order to run nano under a > terminal if run under X. > > What do you think ? Sounds good to me. *t
Re: openssl/libssl1 in Debian now blocks offlineimap?
]] Adrian Bunk > Or did this start as a coordinated effort of several major Linux > distributions covering all TLS implementations? While not speaking for Kurt, there's been a move towards getting rid of TLS < 1.2 for quite some time, by reasonably important players such as the PCI-DSS consortium which announced in 2015 that June 2016 would be the deadline for disabling older TLS versions. As we all know, we're past that date now, and TLS < 1.2 is still around and entirely too well-supported. The PCI consortium extended the deadline until June 2018. Assuming that deadline holds, people with older machines will not be able to access services such as online banking or pay online in general. I'm hoping they won't extend the deadline again, but they're pragmatic. As they write in their press release: “…in the field a lot of business issues surfaced…” said Stephen Orfei, General Manager, PCI SSC. “We want merchants protected against data theft but not at the expense of turning away business, so we changed the date.” > Nothing that Debian does alone will have any measurable impact > on TLS 1.0 usage. I think you're wrong on this point, having Debian make this change makes it a lot easier for me to go to company management and explain that TLS v1.2 is the only way forward and that we need to spend engineering resources to make sure any users on platforms where support for that is lacking get a proper notification and a chance to move to something newer. «We need to do this because this change is coming, whether we want it or not.» -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: openssl/libssl1 in Debian now blocks offlineimap?
Excerpts from Tollef Fog Heen's message of 2017-08-18 22:07:49 +0200: > ]] Adrian Bunk > > > Or did this start as a coordinated effort of several major Linux > > distributions covering all TLS implementations? > > While not speaking for Kurt, there's been a move towards getting rid of > TLS < 1.2 for quite some time, by reasonably important players such as > the PCI-DSS consortium which announced in 2015 that June 2016 would be > the deadline for disabling older TLS versions. As we all know, we're > past that date now, and TLS < 1.2 is still around and entirely too > well-supported. The PCI consortium extended the deadline until June > 2018. Assuming that deadline holds, people with older machines will not > be able to access services such as online banking or pay online in > general. > > I'm hoping they won't extend the deadline again, but they're pragmatic. > As they write in their press release: “…in the field a lot of business > issues surfaced…” said Stephen Orfei, General Manager, PCI SSC. “We want > merchants protected against data theft but not at the expense of turning > away business, so we changed the date.” > > > Nothing that Debian does alone will have any measurable impact > > on TLS 1.0 usage. > > I think you're wrong on this point, having Debian make this change makes > it a lot easier for me to go to company management and explain that TLS > v1.2 is the only way forward and that we need to spend engineering > resources to make sure any users on platforms where support for that is > lacking get a proper notification and a chance to move to something > newer. «We need to do this because this change is coming, whether we > want it or not.» > Businesses assess risk on every level as part of operating a business. If replacing Debian is cheaper than replacing whatever requires TLS 1.0, some companies will absolutely choose the former. It may not be wise to make business people choose between Debian and money.
Bug#872592: ITP: node-syntax-error -- detect and report syntax errors in source code strings
Package: wnpp Severity: wishlist Owner: ro...@debian.org X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-syntax-error Version : 1.3.0 Upstream Author : James Halliday (http://substack.net) * URL : https://github.com/substack/node-syntax-error * License : Expat Programming Lang: JavaScript Description : detect and report syntax errors in source code strings This module allow ones to emulate in pure javascript the behavior of Node.js for detecting syntax error. . This module allow ones to get a friendly error report about exactly where the syntax error is in a javascript file. . Node.js is an event-based server-side JavaScript engine.
Re: fdisk becoming non-essential, dependencies needed.
Quoting Julian Andres Klode (2017-08-19 00:18:54) > > > Currently (for Buster) the fdisk package is being made > > > 'pseudo-essential' via a dependency from the Essential util-linux > > > package, where the tools was split out from. (This is also to support > > > upgrades from Stretch to Buster.) > > > The plan is to drop this dependency (making fdisk no longer > > > pseudo-essential) for Buster+1 (Bullseye). The Priority field will > > > likely be set to important so fdisk utilities will still be part of any > > > normal installation, but will then be deinstallable. > > > > Why not setting in recommand ? It will be installed by default but > > could be deinstalled > > I guess because debootstrap does not install Recommends? Every package which requires fdisk would still need to be adjusted to add a Depends relationship exactly for the reason you cited: if fdisk becomes a Recommends then it can be de-installed, thus breaking packages that require it. Thus, making it a Recommends would not change the fact that now some packages have to be adjusted. cheers, josch signature.asc Description: signature
