Re: salsa.debian.org (git.debian.org replacement) going into beta

[Dr. Bas Wijnen]

On Fri, Dec 29, 2017 at 10:43:58PM +0100, Alexander Wirt wrote:
> On Fri, 29 Dec 2017, Philipp Kern wrote:
> > Put a mapping into a git repository that DDs can push to? Make sure that
> > it is fast-forwarded always? Then let people deal with it?
> I am currently working on such a mapping. 

I appreciate your work, but this doesn't seem all that useful to me.  If DDs
can push the mapping, can't they just as well upload a new package with the
fields in the control file updated?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Dr. Bas Wijnen]

On Fri, Dec 29, 2017 at 07:18:57PM +0100, Adam Borowski wrote:
> On Fri, Dec 29, 2017 at 05:57:21PM +, Dr. Bas Wijnen wrote:
> > So we need to decide what we want.  I think there probably is consensus 
> > about:
> > 
> > - We want people with non-free hardware to install Debian if they want to.
> > - We want people with non-free firmware installed to get updates for it.
> > 
> > I'm not entirely sure, but think there is also consensus that:
> > 
> > - We want to recommend people to use as little non-free software as 
> > reasonably
> >   possible.
> > 
> > I am planning to propose a GR that will clarify our position about this, and
> > that should result in enabling contrib and non-free in the default installer
> > image until non-free-firmware is somehow selectable for installation without
> > also enabling other non-free software.
> 
> I got the impression that the idea of having two installers for download,
> side to side, received least hate of what was proposed.

It doesn't get hate from me, but I do think it's suboptimal.  As I explain
below, I think we should recommend the image including non-free firmware to
pretty much everyone.  This means that if we design the website properly, the
image without the firmware is very hard to find.

> Having no purely free installer, or having it play second fiddle to the
> non-free one, would sacrifice too much of our principles in my opinion.

Therefore it should indeed play second fiddle, if it should play at all.  If
the hardware supports firmware updates and those are available in non-free form
only, I think it would be irresponsible of us to withhold them from our users.
So that means that if such hardware is present, we need to enable updates for
non-free firmware.  With the current repository layout, that means enabling all
of non-free.

Especially for new users, having two options where one has limitations (using
it may leave you with an insecure system, depending on your hardware) and the
other one doesn't (they've always used non-free software, continuing to do so
doesn't feel like a problem for them) will lead to many of them choosing the
installer which includes the non-free firmware.  So I don't think it's really
possible to avoid the free installer being almost unused.

Personally I think it doesn't really add any value to have an installer without
the non-free firmware.  As long as the installer doesn't install it on the
system unless it is needed, that is.  The value of having an installer image
that doesn't include the firmware is much lower than the value of users being
able to install a good system.  This is similar to how RMS originally used
non-free Unix systems to work on GNU.  As long as the non-free parts are
required, they can (and should) be used.

I would very much like to not enable all of non-free, but the proper solution
for that is splitting off the firmware parts so they can be selectively enabled
(or some other way to selectively enable part of an apt source) and that
requires work.  I don't have the time to do this work, so while I mention that
it should be done, I'm not proposing that it will be done.  That's not the sort
of thing that a GR or mailing list discussion can do.

However, I believe that the problem of our users being unable to install secure
systems, or being unable to install at all, is serious and deserves to be
solved.  Even if that means enabling all of non-free for every new install.

> Yet having such a "tainted" installer to its right/bottom would also
> satisfy the need of users with bad hardware.

The main issue is that the free image somehow needs to detect that non-free
updates are required to keep the machine secure, and then (request to) enable
non-free if they are.  My guess is that this can easily be done.  Enabling the
non-free repository is technically easy, but I expect disagreement over whether
this should be allowed.

> Would this be acceptable to you without employing all the hassle of a GR?

The reason I think a GR is useful is that this discussion comes up again and
again.  I'd prefer if we had consensus about it, and this may be the case.
However, nobody seems to know, so a GR would clearly record our opinion.  That
seems to be a good thing.

Just to clarify: my purpose of a GR isn't to "win" anything.  It's to clarify
what the project wants, so that people can work on this without too many
protests, and installing Debian can be a better experience for our users.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Andreas Tille]

On Fri, Dec 29, 2017 at 10:43:58PM +0100, Alexander Wirt wrote:
> > Put a mapping into a git repository that DDs can push to? Make sure that
> > it is fast-forwarded always? Then let people deal with it?
> I am currently working on such a mapping. 

Thanks a lot

 Andreas.

-- 
http://fam-tille.de

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Paul Wise]

On Fri, 2017-12-29 at 12:32 +0100, W. Martin Borgert wrote:

> You are right. It is just not easy to solve this, because this
> information must be available on Debian systems. So it would be
> something in parallel to downloaded Packages files, right? And
> who generates this file(?) based on which information?

No. Since debtags are imported into Packages/Sources, it shouldn't be
hard to do the same as debtags for other Packages/Sources fields too.

I would guess it would also be possible to use values from packages for
most of them and then add overrides that would be used until the value
from the package changes.

For watch files there was the sepwatch alioth project, but that is no
longer used since watch file processing was moved to udd.

https://wiki.debian.org/qa.debian.org/HowToHelpWithFixingWatchFiles

The same approach could be used for other fields, a git repository
containing the overrides, which is imported by ftp-master and merged
into the package information, which is then exported to the archive. 

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Alexander Wirt]

On Fri, 29 Dec 2017, Alexander Wirt wrote:

> On Fri, 29 Dec 2017, Marco d'Itri wrote:
> 
> > On Dec 29, Alexander Wirt  wrote:
> > 
> > > Please propose a solution for reusing the name without breaking renamed 
> > > and
> > > not yet migrated repos. 
> > Ignore the renamed repositories: if somebody renamed them then they 
> > obviously expected to have to update the VCS URLs anyway.
> > Switch the anonscm name when alioth will be shut down: the people who 
> > have already migrated can keep pushing to the old repository as well to 
> > keep it in sync.
> > This is not perfect, but it is still better than having to update 
> > countless packages.
> > 
> > > Of course you are now one year to late. 
> > I do not think that it is our fault to find out just now that a major 
> > feature of alioth would be broken.
> All discussions and logs were public and we asked several times for
> discussion and help. But I am already working on some
> redirect map generator. 
And just following your proposal would still leave us with several thousand
broken packages (Debian vs. collab-maint, teams have different paths and so
on). It just won't work, the solution has to be more sophisticated.

Alex



signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Alexander Wirt]

On Fri, 29 Dec 2017, Marco d'Itri wrote:

> On Dec 29, Alexander Wirt  wrote:
> 
> > Please propose a solution for reusing the name without breaking renamed and
> > not yet migrated repos. 
> Ignore the renamed repositories: if somebody renamed them then they 
> obviously expected to have to update the VCS URLs anyway.
> Switch the anonscm name when alioth will be shut down: the people who 
> have already migrated can keep pushing to the old repository as well to 
> keep it in sync.
> This is not perfect, but it is still better than having to update 
> countless packages.
> 
> > Of course you are now one year to late. 
> I do not think that it is our fault to find out just now that a major 
> feature of alioth would be broken.
All discussions and logs were public and we asked several times for
discussion and help. But I am already working on some
redirect map generator. 

Alex



signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Alexander Wirt]

On Fri, 29 Dec 2017, Philipp Kern wrote:

> On 12/29/2017 12:51 PM, Marco d'Itri wrote:
> > On Dec 29, Alexander Wirt  wrote:
> >> Please propose a solution for reusing the name without breaking renamed and
> >> not yet migrated repos. 
> > Ignore the renamed repositories: if somebody renamed them then they 
> > obviously expected to have to update the VCS URLs anyway.
> > Switch the anonscm name when alioth will be shut down: the people who 
> > have already migrated can keep pushing to the old repository as well to 
> > keep it in sync.
> > This is not perfect, but it is still better than having to update 
> > countless packages.
> 
> Put a mapping into a git repository that DDs can push to? Make sure that
> it is fast-forwarded always? Then let people deal with it?
I am currently working on such a mapping. 
> 
> Kind regards
> Philipp Kern
> 





signature.asc
Description: PGP signature

Bug#885788: ITP: node-pause-stream -- a Node.JS stream that can be paused into buffering mode

[Hilko Bengen]

Control: block 885722 by -1
Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: node-pause-stream
  Version : 0.0.11
  Upstream Author : Dominic Tarr 
* URL or Web page : https://github.com/dominictarr/pause-stream
* License : Expat
  Programming Lang: JavaScript
  Description : a Node.JS stream that can be paused into buffering mode

This package is needed for gulp-angular-templatecache which is needed
building a new version of GRR.

Bug#885779: ITP: node-from -- Create a Node.JS stream from arrays or functions

[Hilko Bengen]

Control: block 885722 by -1
Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: node-from
  Version : 0.1.7
  Upstream Author : Dominic Tarr 
* URL or Web page : https://github.com/dominictarr/from#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Create a Node.JS stream from arrays or functions

This package is needed for gulp-angular-templatecache which is needed
building a new version of GRR.

Re: ISO download difficult

[Russ Allbery]

Andrey Rahmatullin  writes:
> On Fri, Dec 29, 2017 at 12:16:01PM +0100, Toni Mueller wrote:

>> "Whatever". My main point is imho to both make it easier for people to
>> run Debian on their computers and educate them at the same time.

> My point is you shouldn't educate with lies and half-truths.

This is easily addressable with some care in how we phrase this on our web
page.  All we need is something like (and this is just off the top of my
head, and is way too wordy since that's my default):

The default install image contains only free software.

Unfortunately, most available hardware that can run Debian contains
substantial portions of non-free software in firmware.  This firmware
may need to be patched for security and functionality bugs.  The
operating system may even have to provide blobs of non-free software
to the hardware during boot in order for the hardware to work.  If you
have such hardware, you may need to use the non-free images to
successfully install Debian, enable all the features of your hardware,
or patch your firmware for security and critical functionality bugs.

We would prefer to provide you with an operating system that contains
only free software, intended to run on hardware with free firmware.
This is currently hard to do given the non-free software included even
in system processors (such as the Intel Management Engine), but
several companies are manufacturing hardware that approaches this
goal.  If you are interested, one resource is the Free Software
Foundation's Respects Your Freedom certification program, which
attempts to find and recognize hardware that does not require non-free
software to run.

-- 
Russ Allbery (r...@debian.org)   

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Andrey Rahmatullin]

On Fri, Dec 29, 2017 at 05:57:21PM +, Dr. Bas Wijnen wrote:
> > > they will most likely simply not understand the point, and what makes
> > > free hardware so much better. 
> > 
> > > massively encourage users to use non-free hardware
> > 
> > > link to a page suggesting free hardware over similar non-free hardware
> > 
> > There is no such thing. There is only non-free hardware without updates
> > for its software.
> 
> I'm not sure what you're trying to say.  
I'm trying to say that there is nothing to promote, and anyone who wants
to promote hardware that doesn't require loading non-free firmware must
understand that it's not "hardware that doesn't require non-free firmware
at all" and thus is not "free hardware".

> Toni's suggestion seems to be to tell those people that Debian can indeed
> install on their hardware, while educating them about the problems of it.
Yes, and I point at the problems in the "educating" part. If we want to
educate other people we should first educate ourselves.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Adam Borowski]

On Fri, Dec 29, 2017 at 05:57:21PM +, Dr. Bas Wijnen wrote:
> So we need to decide what we want.  I think there probably is consensus about:
> 
> - We want people with non-free hardware to install Debian if they want to.
> - We want people with non-free firmware installed to get updates for it.
> 
> I'm not entirely sure, but think there is also consensus that:
> 
> - We want to recommend people to use as little non-free software as reasonably
>   possible.
> 
> I am planning to propose a GR that will clarify our position about this, and
> that should result in enabling contrib and non-free in the default installer
> image until non-free-firmware is somehow selectable for installation without
> also enabling other non-free software.

I got the impression that the idea of having two installers for download,
side to side, received least hate of what was proposed.

Having no purely free installer, or having it play second fiddle to the
non-free one, would sacrifice too much of our principles in my opinion.
Yet having such a "tainted" installer to its right/bottom would also
satisfy the need of users with bad hardware.

Would this be acceptable to you without employing all the hassle of a GR?


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Dr. Bas Wijnen]

On Thu, Dec 28, 2017 at 10:13:52AM +0500, Andrey Rahmatullin wrote:
> On Wed, Dec 27, 2017 at 11:00:38PM +0100, Toni Mueller wrote:
> > they will most likely simply not understand the point, and what makes
> > free hardware so much better. 
> 
> > massively encourage users to use non-free hardware
> 
> > link to a page suggesting free hardware over similar non-free hardware
> 
> There is no such thing. There is only non-free hardware without updates
> for its software.

I'm not sure what you're trying to say.  Here are the facts:

- There are people who have non-free hardware that they would like to run
  Debian on.
- The current default installer image requires non-free firmware to install on
  those systems.
- The non-default images which include the firmware are hard to find.
- The method that the default image suggests (downloading the non-free firmware
  tarball and installing it in the installation system) is not something that
  all users should be expected to be able to do.

Toni's suggestion seems to be to tell those people that Debian can indeed
install on their hardware, while educating them about the problems of it.  The
result will be that more people run Debian, but as you seem to say the
education will not always work so it will also mean that either people are left
with hardware without updates, or they are pushed to using non-free software.
Neither of those options is nice.

So we need to decide what we want.  I think there probably is consensus about:

- We want people with non-free hardware to install Debian if they want to.
- We want people with non-free firmware installed to get updates for it.

I'm not entirely sure, but think there is also consensus that:

- We want to recommend people to use as little non-free software as reasonably
  possible.

I am planning to propose a GR that will clarify our position about this, and
that should result in enabling contrib and non-free in the default installer
image until non-free-firmware is somehow selectable for installation without
also enabling other non-free software.

Any comments are welcome.  I'll post to -vote when I have a proposed text.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Ben Hutchings]

On Fri, 2017-12-29 at 12:32 +0100, W. Martin Borgert wrote:
> On 2017-12-29 12:42, Paul Wise wrote:
> > This is just a symptom of a Debian design flaw that dates back to
> > before we started using VCSen for packaging. We include information in
> > the source package that can change independently of the source package
> > (such as Vcs-*, Homepage, debian/watch, Maintainer/Uploaders etc).
> > These should be stored externally to source packages and merged into
> > the Packages/Sources files by the archive software.
> 
> You are right. It is just not easy to solve this, because this
> information must be available on Debian systems. So it would be
> something in parallel to downloaded Packages files, right? And
> who generates this file(?) based on which information?

dak already maintains Section and Priority information ("override
file") and uses that information in the Packages file instead of what a
package's control file says.  I would hope that a similar approach
could be used for all the other fields that we may want to change
without an upload.

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.  It's the only way to be
sure.



signature.asc
Description: This is a digitally signed message part

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Andrey Rahmatullin]

On Fri, Dec 29, 2017 at 04:56:25PM +0100, Toni Mueller wrote:
> > My point is you shouldn't educate with lies and half-truths.
> Good point. Then you get to do it the correct way. Deal?
That's not how these things work though.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Antonio Terceiro]

On Fri, Dec 29, 2017 at 04:11:29PM +0100, Thomas Goirand wrote:
> On 12/28/2017 02:33 AM, Jeremy Bicha wrote:
> > On Wed, Dec 27, 2017 at 7:07 PM, Manuel A. Fernandez Montecelo
> >  wrote:
> >> If the idea is *not* to move those to @lists.d.o, I cannot see what we
> >> should be using instead.
> >>
> >> Any recommendation?
> > 
> > Someone on your team should create a Tracker Team. Add the packages
> > your team maintains.
> > 
> > https://tracker.debian.org/teams/
> > 
> > Then anyone can simply join that tracker team to easily get
> > notifications about bugs, commits, uploads, etc. Visit
> > https://tracker.debian.org/accounts/subscriptions/ and customize the
> > keywords to get the particular emails you want for particular packages
> > or teams.
> > 
> > Thanks,
> > Jeremy Bicha
> 
> Nice idea, but it doesn't scale. Am I suppose to add all of the
> (currently) 406 OpenStack maintained packages one by one, by hand? And
> then upload 406 times just to change the maintainer field? Gregor just
> pointed out the 3500 packages of the perl team. There will be others
> (think: javascript/nodejs, python, etc.). Even worse: some packages
> *will* be forgotten, and there *will* be bug reports that will go to
> nowhere because the fields were not addressed.
> 
> I don't understand that there's no consensus we'd be collectively
> wasting too much time doing this type of change, when it could simply be
> addressed by keeping the current lists. This is a major disruption of
> services that we're talking about here.

This manual adding is only needed if you don't use a single email
address as maintainer ... if you do have a single maintainer address for
all packages, you just provide it and the package tracker _will_ group
all the packages automatically.


signature.asc
Description: PGP signature

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Toni Mueller]

On Fri, Dec 29, 2017 at 04:22:23PM +0500, Andrey Rahmatullin wrote:
> My point is you shouldn't educate with lies and half-truths.

Good point. Then you get to do it the correct way. Deal?


Cheers,
--Toni++

Bug#885727: ITP: node-json-buffer -- JSON functions that can convert buffers.

[Manas Kashyap]

Package: wnpp
Severity: wishlist
Owner: Manas kashyap 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-json-buffer
  Version : 3.0.0
  Upstream Author : Dominic Tarr  (
http://dominictarr.c$
* URL : https://github.com/dominictarr/json-buffer
* License : Expat
  Programming Lang: JavaScript
  Description : JSON functions that can convert buffers
 JSON mangles buffers by converting to an array which isn't helpful.
 json-buffers converts to base64 instead, and deconverts base64
 to a buffer.
 .
 Node.js is an event-based server-side JavaScript engine.

 Praveen agreed to sponsor this package.

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Andreas Tille]

On Fri, Dec 29, 2017 at 12:06:17PM +0100, Alexander Wirt wrote:
> On Fri, 29 Dec 2017, Andreas Tille wrote:
> 
> > > This is just a symptom of a Debian design flaw that dates back to
> > > before we started using VCSen for packaging. We include information in
> > > the source package that can change independently of the source package
> > > (such as Vcs-*, Homepage, debian/watch, Maintainer/Uploaders etc).
> > > These should be stored externally to source packages and merged into
> > > the Packages/Sources files by the archive software.
> > 
> > Or more precisely it was a design flaw from the beginning which was
> > intended to be cured with the workaround of annonscm and now it seems
> > even this will be broken for no good reasons.
> if you think so, you have now idea. 
> Please propose a solution for reusing the name without breaking renamed and
> not yet migrated repos. 

Breaking not yet migrated repos *temporarily* instead in forcing several
thousands of packages to be uploaded is IMHO a solution as obvious that
it needs no extra mentioning.  But all discussion I've read was that it
is not planed.  So why not waiting until the majority is switched and
than redirect anonscm?
 
> Of course you are now one year to late. 

In how far is the suggestion above to late?

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Thomas Goirand]

On 12/28/2017 02:33 AM, Jeremy Bicha wrote:
> On Wed, Dec 27, 2017 at 7:07 PM, Manuel A. Fernandez Montecelo
>  wrote:
>> If the idea is *not* to move those to @lists.d.o, I cannot see what we
>> should be using instead.
>>
>> Any recommendation?
> 
> Someone on your team should create a Tracker Team. Add the packages
> your team maintains.
> 
> https://tracker.debian.org/teams/
> 
> Then anyone can simply join that tracker team to easily get
> notifications about bugs, commits, uploads, etc. Visit
> https://tracker.debian.org/accounts/subscriptions/ and customize the
> keywords to get the particular emails you want for particular packages
> or teams.
> 
> Thanks,
> Jeremy Bicha

Nice idea, but it doesn't scale. Am I suppose to add all of the
(currently) 406 OpenStack maintained packages one by one, by hand? And
then upload 406 times just to change the maintainer field? Gregor just
pointed out the 3500 packages of the perl team. There will be others
(think: javascript/nodejs, python, etc.). Even worse: some packages
*will* be forgotten, and there *will* be bug reports that will go to
nowhere because the fields were not addressed.

I don't understand that there's no consensus we'd be collectively
wasting too much time doing this type of change, when it could simply be
addressed by keeping the current lists. This is a major disruption of
services that we're talking about here.

Cheers,

Thomas Goirand (zigo)

Bug#885723: ITP: node-p-is-promise -- Check if something is a promise

[Manas Kashyap]

Package: wnpp
Severity: wishlist
Owner: Manas kashyap 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-p-is-promise
  Version : 1.1.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com
)
* URL : https://github.com/sindresorhus/p-is-promise#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Check if something is a promise
 Just pass your value to Promise.resolve() and let it handle it.
 .
 Can be useful if you need to create a fast path
 for a synchronous operation.
 .
 Node.js is an event-based server-side JavaScript engine.

 Praveen agreed to sponsor this package.

Bug#885722: ITP: node-event-stream -- a toolkit for easy creation and use of Node.JS streams

[Hilko Bengen]

Control: block 884833 by -1
Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: node-event-stream
  Version : 3.3.4
  Upstream Author : Dominic Tarr
* URL or Web page : http://github.com/dopminictarr/event-stream
* License : Expat
  Programming Lang: JavaScript
  Description : a toolkit for easy creation and use of Node.JS streams

This package is needed for gulp-angular-templatecache which is needed
building a new version of GRR.

Bug#885718: ITP: node-sleep-promise -- Resolves a promise after a specified delay

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-sleep-promise
  Version : 2.0.0
  Upstream Author : Jan Brummelte 
(http://jan-brummelte.de)
* URL : https://github.com/brummelte/sleep-promise
* License : Expat
  Programming Lang: JavaScript
  Description : Resolves a promise after a specified delay
 Promises represent the future result of async operations. This module helps
 to specify a delay after which the promise is to be resolved.
 .
 Node.js is an event-based server-side JavaScript engine.

 This module is a build dependency for node-promise-retry which is a
dependency of npm5.



signature.asc
Description: OpenPGP digital signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Philipp Kern]

On 12/29/2017 12:51 PM, Marco d'Itri wrote:
> On Dec 29, Alexander Wirt  wrote:
>> Please propose a solution for reusing the name without breaking renamed and
>> not yet migrated repos. 
> Ignore the renamed repositories: if somebody renamed them then they 
> obviously expected to have to update the VCS URLs anyway.
> Switch the anonscm name when alioth will be shut down: the people who 
> have already migrated can keep pushing to the old repository as well to 
> keep it in sync.
> This is not perfect, but it is still better than having to update 
> countless packages.

Put a mapping into a git repository that DDs can push to? Make sure that
it is fast-forwarded always? Then let people deal with it?

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Marco d'Itri]

On Dec 29, Alexander Wirt  wrote:

> Please propose a solution for reusing the name without breaking renamed and
> not yet migrated repos. 
Ignore the renamed repositories: if somebody renamed them then they 
obviously expected to have to update the VCS URLs anyway.
Switch the anonscm name when alioth will be shut down: the people who 
have already migrated can keep pushing to the old repository as well to 
keep it in sync.
This is not perfect, but it is still better than having to update 
countless packages.

> Of course you are now one year to late. 
I do not think that it is our fault to find out just now that a major 
feature of alioth would be broken.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: salsa.debian.org (git.debian.org replacement) going into beta

[W. Martin Borgert]

On 2017-12-29 12:42, Paul Wise wrote:
> This is just a symptom of a Debian design flaw that dates back to
> before we started using VCSen for packaging. We include information in
> the source package that can change independently of the source package
> (such as Vcs-*, Homepage, debian/watch, Maintainer/Uploaders etc).
> These should be stored externally to source packages and merged into
> the Packages/Sources files by the archive software.

You are right. It is just not easy to solve this, because this
information must be available on Debian systems. So it would be
something in parallel to downloaded Packages files, right? And
who generates this file(?) based on which information?

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Andrey Rahmatullin]

On Fri, Dec 29, 2017 at 12:16:01PM +0100, Toni Mueller wrote:
> > > link to a page suggesting free hardware over similar non-free hardware
> > 
> > There is no such thing. There is only non-free hardware without updates
> > for its software.
> 
> "Whatever". My main point is imho to both make it easier for people to
> run Debian on their computers and educate them at the same time.
My point is you shouldn't educate with lies and half-truths.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Toni Mueller]

On Thu, Dec 28, 2017 at 10:13:52AM +0500, Andrey Rahmatullin wrote:
> On Wed, Dec 27, 2017 at 11:00:38PM +0100, Toni Mueller wrote:
> > link to a page suggesting free hardware over similar non-free hardware
> 
> There is no such thing. There is only non-free hardware without updates
> for its software.

"Whatever". My main point is imho to both make it easier for people to
run Debian on their computers and educate them at the same time. I hope
that my approach would achieve that goal, but after spending a lot of
time with this thread, other approaches like including everything in an
ISO and then installing only the required bits also sound promising.


Cheers,
--Toni++

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Alexander Wirt]

On Fri, 29 Dec 2017, Andreas Tille wrote:

> Hi Paul,
> 
> On Fri, Dec 29, 2017 at 12:42:28PM +0800, Paul Wise wrote:
> > On Fri, Dec 29, 2017 at 10:21 AM, Guillem Jover wrote:
> > 
> > > I'm also growing some URL switching fatigue when it comes to Debian's
> > > git repos. And that's one of the reasons I moved all my packaging to
> > > my own server some time ago.
> > 
> > This is just a symptom of a Debian design flaw that dates back to
> > before we started using VCSen for packaging. We include information in
> > the source package that can change independently of the source package
> > (such as Vcs-*, Homepage, debian/watch, Maintainer/Uploaders etc).
> > These should be stored externally to source packages and merged into
> > the Packages/Sources files by the archive software.
> 
> Or more precisely it was a design flaw from the beginning which was
> intended to be cured with the workaround of annonscm and now it seems
> even this will be broken for no good reasons.
if you think so, you have now idea. 
Please propose a solution for reusing the name without breaking renamed and
not yet migrated repos. 

Of course you are now one year to late. 

Alex

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Andreas Tille]

Hi Paul,

On Fri, Dec 29, 2017 at 12:42:28PM +0800, Paul Wise wrote:
> On Fri, Dec 29, 2017 at 10:21 AM, Guillem Jover wrote:
> 
> > I'm also growing some URL switching fatigue when it comes to Debian's
> > git repos. And that's one of the reasons I moved all my packaging to
> > my own server some time ago.
> 
> This is just a symptom of a Debian design flaw that dates back to
> before we started using VCSen for packaging. We include information in
> the source package that can change independently of the source package
> (such as Vcs-*, Homepage, debian/watch, Maintainer/Uploaders etc).
> These should be stored externally to source packages and merged into
> the Packages/Sources files by the archive software.

Or more precisely it was a design flaw from the beginning which was
intended to be cured with the workaround of annonscm and now it seems
even this will be broken for no good reasons.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#885701: ITP: node-promise-retry -- Retries a function that returns a promise

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-promise-retry
  Version : 1.1.1
  Upstream Author : IndigoUnited 
(http://indigounited.com)
* URL :
https://github.com/IndigoUnited/node-promise-retry#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Retries a function that returns a promise
 Leverage the power of the retry module to the promises world.
 .
 Calls fn until the returned promise ends up fulfilled or rejected with
an error different than a retry error.
 .
 Node.js is an event-based server-side JavaScript engine.

This module is a dependency of npm5.



signature.asc
Description: OpenPGP digital signature

Re: udftools, pktsetup and init scripts

[Tollef Fog Heen]

]] Pali Rohár 

> What do you think about moving pktsetup into own binary package? Users
> who do not need packet writing configuration and only need tools for UDF
> filesystem would install only udftools package.

udftools is a tiny package, splitting it seems a bit meaningless.

> But such thing probably needs more discussion or announcement in
> changelog... etc... as existing system configurations needs to be
> updated.

If you do split it, udftools need to depend on pktsetup for the next
release at least so people don't lose that functionality.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: salsa.debian.org (git.debian.org replacement) going into beta

[Sean Whitton]

Hello,

On Wed, Dec 27 2017, Sean Whitton wrote:

> I think what would be ideal is having it disabled by default.  People
> can turn it on again for their non-packaging repos.
>
> Upstream's bug tracker suggests GitLab can do this[1] so I've filed a
> request.[2]

... which has now been fulfilled.  Issues are off by default.

Thanks Joerg!

-- 
Sean Whitton


signature.asc
Description: PGP signature