Bug#868512: ITP: node-cyclist -- efficient cyclic list implementation for Javascript

[Amruth Lal]

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

* Package name: node-cyclist
  Version : 1.0.1
  Upstream Author : Mathias Buus Madsen 
* URL : https://github.com/mafintosh/cyclist
* License : Expat
  Programming Lang: JavaScript
  Description : efficient cyclic list implementation for Javascript

 cyclist creates a list of fixed size that is cyclic. In a list
 the element following the last one is the first one.
.
This is a dependency for npm, Node.js package manager.
Node.js is an event-based server-side Javascript engine.
.
 I plan to join Javascript package team. Pirate Praveen has agreed to
 sponser this package.

Bug#868516: ITP: node-run-queue -- promise based dynamic priority queue runner

[icyfire]

Package: wnpp
Severity: wishlist
Owner: Rajeev R Menon 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-run-queue
  Version : 1.0.3
  Upstream Author : Rebecca Turner  (http://re-becca.org/)
* URL : https://npmjs.com/package/run-queue
* License : ISC
  Programming Lang: JavaScript
  Description : promise based dynamic priority queue runner

 A promise based, dynamic priority queue runner, with concurrency limiting.
 .
 The concurrency means that processes don't finish in order, because some take 
 longer than others. Each priority level must finish entirely before the 
 next priority level is run. Priorities essentially represent distinct job 
 queues. All jobs in a queue must complete before the next highest priority job 
 queue is executed. Lowest is executed first.  
 .
 Node.js is an event-based server-side JavaScript engine.

It is a dependency of npm.

Pirate Praveen has agreed to sponsor this package. I am interested to
join the Debian Javascript Maintainers Team.

Re: Inclusion of best practices for packaging database applications in Debian policy

[Paul Gevers]

Hi,

It has been pointed out to me that I didn't reply to the message below.

On 06/25/17 17:42, Marc Haber wrote:
> On Sun, 25 Jun 2017 16:05:09 +0200, Paul Gevers 
> wrote:
>> Packages may provide support for removing underlying databases, but it
>> is highly recommended that the administrator is prompted with a chance
>> to preserve the data before doing so.
> 
> It was mentioned that the document in question was written 12 years
> ago. In this time, it has become increasingly uncool to bother the
> local admin with debconf questions during package installation or
> removal. I won't comment on whether I find this tendency reasonable or
> not.
> 
> This being said, does this document still reflect the current "spirit
> of Debian"?

I don't have any experience with writing or reviewing policy documents
and as the current maintainer of dbconfig-common am not sure if I have a
neutral mind on the current text. Therefore, I wasn't sure how to respond.

What I like to achieve is to have something in the policy. If the
current document is outdated, then let's update it and put it in policy.
The current document is the best we have now. How would be start a
review now that is likely to end up in policy? The review of 12 years
ago led to a stand-alone document that didn't receive much attention
later on.

Paul



signature.asc
Description: OpenPGP digital signature

ITP: node-path-is-inside -- Tests whether one path is inside another path

[olive]

Package: wnpp
Severity: wishlist
Owner: Olive Sara Thomas 
X-Debbugs-CC: debian-devel@lists.debian.org 
(mailto:debian-devel@lists.debian.org)

* Package name : node-path-is-inside
Version : 1.0.2
Upstream Author : Domenic Denicola  (https://domenic.me (https://domenic.me))
* URL : https://github.com/domenic/path-is-inside#readme 
(https://github.com/domenic/path-is-inside#readme)
* License : (WTFPL OR MIT)
Programming Lang: JavaScript
Description : Tests whether one path is inside another path

The **path-is-inside** package will give you a robust, cross-platform
way of detecting whether a given path is inside another path.
.
Like Node's built-in path module, path-is-inside treats all file paths on
Windows as case-insensitive, whereas it treats all file paths on
*-nix operating systems as case-sensitive. Keep this in mind especially
when working on a Mac, where, despite Node's defaults, the OS usually treats
paths case-insensitively.
.
This is a dependency of npm,node package manager.
.
Node.js is an event-based server-side JavaScript engine.

Pirate Praveen has agreed to sponsor this package.

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Sat, Jul 15, 2017 at 10:25:22PM -0300, Henrique de Moraes Holschuh wrote:

> > > This will match any interface that has MAC address 01:23:45:67:89:ab,
> > > and will use the "foo" stanzas to configure it.
> > 
> > Awesome!  This sounds like the best solution so far.

As Adam discovered, there was still a bug preventing this from actually
working for allow-* interfaces, but a fix has just been uploaded.

> It is indeed Very Cool, but it might not solve one little thing:
> iptables firewalling.
> 
> Is that a way to trigger an ifrename using this, so that the network
> device ends up being named "foo" ?

That's indeed an interesting issue. Currently, ifupdown doesn't rename
interfaces. You could add a line like:

post-up ip link set $IFACE name $LOGICAL

Which will do what you want, except ifupdown doesn't track interface
renames this way and will get very confused. In particular, ifdown will
not work anymore. So some code should be added to ifupdown to support
interface renaming.

Note that there is a package called "ifrename" that has a nice way of
configuring interface renaming, and works independently of your init
system, udev et cetera. But I can see how it would be nice to have
renaming integrated in ifupdown.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

ITP: node-genfun -- fast, prototype-friendly multimethods

[archana]

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

* Package name : node-genfun
 Version : 4.0.1
 Upstream Author : Kat Marchán 
* URL : http://github.com/zkat/genfun
* License : CC0-1.0
 Programming Lang: JavaScript
 Description : fast, prototype-friendly multimethods
 Fast, prototype-friendly multimethods.
 .
 Be aware that most upstream package descriptions are not written to
 conform with Debian package guidelines. You need to explain the role
 of this package for a Debian audience.
 A genfun is a regular function object with overridden function
 call/dispatch behavior.genfun is a Javascript library that lets
 you define generic functions: regular-seeming functions that can be
 invoked just like any other function, but that automatically dispatch
 methods based on the combination of arguments passed to it when it's
 called, also known as multiple dispatch.
 .
 This package is a dependency of npm, Node.js package manager.
 Node.js is an event-based server-side JavaScript engine.
 I plan to join Javascript packaging team. Pirate Praveen has agreed to sponsor 
this package.

Re: Naming of network devices - how to improve it in buster

[Ben Hutchings]

On Sun, 2017-07-16 at 13:54 +0200, Guus Sliepen wrote:
> On Sat, Jul 15, 2017 at 10:25:22PM -0300, Henrique de Moraes Holschuh wrote:
> 
> > > > This will match any interface that has MAC address 01:23:45:67:89:ab,
> > > > and will use the "foo" stanzas to configure it.
> > > 
> > > Awesome!  This sounds like the best solution so far.
> 
> As Adam discovered, there was still a bug preventing this from actually
> working for allow-* interfaces, but a fix has just been uploaded.
> 
> > It is indeed Very Cool, but it might not solve one little thing:
> > iptables firewalling.
> > 
> > Is that a way to trigger an ifrename using this, so that the network
> > device ends up being named "foo" ?
> 
> That's indeed an interesting issue. Currently, ifupdown doesn't rename
> interfaces. You could add a line like:
> 
>   post-up ip link set $IFACE name $LOGICAL
> 
> Which will do what you want, except ifupdown doesn't track interface
> renames this way and will get very confused.
[...]

Linux doesn't allow renaming an interface while it's up.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.



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

Bug#868548: ITP: ruby-cocaine -- library for running command line commands in Ruby

[Amruth Lal]

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

* Package name: ruby-cocaine
  Version : 0.5.8
  Upstream Author : Jon Yurek 
* URL : https://github.com/thoughtbot/cocaine
* License : Expat
  Programming Lang: Ruby
  Description : library for running command line commands in Ruby
 cocaine is used to run command line commands in Ruby. Commands are run
 using backticks(Ruby 1.8) or Process.spawn(Ruby 1.9).
 .
 This library supports interpolated arguments and prevents attempts
 to break system. This library throws exception if the command returns
 errors.
 .
 Performance can be increased by installing posix-spawn gem.
 ---

Bug#868562: ITP: sddm-config-editor -- Graphical editor for SDDM

[Alf Gaida]

Package: wnpp
Severity: wishlist
Owner: Alf Gaida 

* Package name: sddm-config-editor
  Version : 0.1
  Upstream Author : Yaohan Chen 
* URL : https://github.com/hagabaka/sddm-config-editor
* License : ASL
  Programming Lang: C++
  Description : Graphical editor for SDDM

Qt implementation of an graphical editor for SDDM. KDE has a KCM for
SDDM configuration. Other environments have no such things - vi and nano 
excluded.

Debian built from non-Debian sources

[Jonas Smedegaard]

Hi,

I wonder it can be that our netinst image uses a version of libisofs 
which seemingly was never packaged for Debian:

$ isoinfo -d -i firmware-9.0.0-amd64-netinst.iso 
CD-ROM is in ISO 9660 format
System id: 
Volume id: Debian 9.0.0 amd64 n
Volume set id: 
Publisher id: 
Data preparer id: XORRISO-1.3.6 2014.04.08.18, LIBISOBURN-1.3.6, 
LIBISOFS-1.3.6, LIBBURN-1.3.6
Application id: 
Copyright File id: 
Abstract File id: 
Bibliographic File id: 
Volume set size is: 1
Volume set sequence number is: 1
Logical block size is: 2048
Volume size is: 165888
El Torito VD version 1 found, boot catalog is in sector 995
Joliet with UCS level 3 found
Rock Ridge signatures version 1 found
Eltorito validation header:
Hid 1
Arch 0 (x86)
ID ''
Key 55 AA
Eltorito defaultboot header:
Bootid 88 (bootable)
Boot media 0 (No Emulation Boot)
Load segment 0
Sys type 0
Nsect 4
Bootoff 3E4 996


Liiking at https://tracker.debian.org/pkg/libisofs version 1.3.6 of 
libisofs never entered our archive.

Is our install images excepmt from our Policy that all dependencies must 
be in Debian, or am I mistaken that we have such Policy?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Debian built from non-Debian sources

[Andrey Rahmatullin]

On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
> Is our install images excepmt from our Policy that all dependencies must 
> be in Debian, or am I mistaken that we have such Policy?
Do we?  The Debian Policy covers only debs.
Also, dak isn't in the archive either.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian built from non-Debian sources

[Jonas Smedegaard]

Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
> > Is our install images excepmt from our Policy that all dependencies must 
> > be in Debian, or am I mistaken that we have such Policy?
> Do we?  The Debian Policy covers only debs.
> Also, dak isn't in the archive either.

I thought Policy covered what we distribute - which excludes dak but 
includes libisofs code embedded in installer images.

Do we have any Policy on installer images?  If e.g. our netinst or live 
images contain non-DFSG-but-free-to-distribute code would that be only a 
wishlist bug, not a Policy violation?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Debian built from non-Debian sources

[Andrey Rahmatullin]

On Sun, Jul 16, 2017 at 08:12:55PM +0200, Jonas Smedegaard wrote:
> > > Is our install images excepmt from our Policy that all dependencies must 
> > > be in Debian, or am I mistaken that we have such Policy?
> > Do we?  The Debian Policy covers only debs.
> > Also, dak isn't in the archive either.
> 
> I thought Policy covered what we distribute - which excludes dak but 
> includes libisofs code embedded in installer images.
https://www.debian.org/doc/debian-policy/ch-archive.html#s-sections
Note that it speaks about the archive.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Debian built from non-Debian sources

[Steve McIntyre]

Jonas wrote:
>Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
>> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
>> > Is our install images excepmt from our Policy that all dependencies must 
>> > be in Debian, or am I mistaken that we have such Policy?
>> Do we?  The Debian Policy covers only debs.
>> Also, dak isn't in the archive either.
>
>I thought Policy covered what we distribute - which excludes dak but 
>includes libisofs code embedded in installer images.

Can you identify any code at all from libisofs which is embedded in
the images? I'm honestly not aware of any.

I've been using upstream versions of xorriso on-and-off over the last
few years, accepting assistance from the (very helpful!) upstream
author Thomas Schmitt when trying to debug thorny issues like hybrid
BIOS/UEFI booting.

The exact behaviour that we've worked out in some cases has needed
upstream tweaks, and we've needed those tweaks from time to time in
what we've released.

>Do we have any Policy on installer images?  If e.g. our netinst or live 
>images contain non-DFSG-but-free-to-distribute code would that be only a 
>wishlist bug, not a Policy violation?

That would be a serious bug IMHO - please raise any as you find them.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Re: Debian built from non-Debian sources

[Jonas Smedegaard]

Quoting Steve McIntyre (2017-07-16 22:14:29)
> Jonas wrote:
> >Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
> >> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
> >> > Is our install images excepmt from our Policy that all dependencies must 
> >> > be in Debian, or am I mistaken that we have such Policy?
> >> Do we?  The Debian Policy covers only debs.
> >> Also, dak isn't in the archive either.
> >
> >I thought Policy covered what we distribute - which excludes dak but 
> >includes libisofs code embedded in installer images.
> 
> Can you identify any code at all from libisofs which is embedded in
> the images? I'm honestly not aware of any.

I believe the embedded MBR is part of the libisofs project.


> I've been using upstream versions of xorriso on-and-off over the last 
> few years, accepting assistance from the (very helpful!) upstream 
> author Thomas Schmitt when trying to debug thorny issues like hybrid 
> BIOS/UEFI booting.
> 
> The exact behaviour that we've worked out in some cases has needed 
> upstream tweaks, and we've needed those tweaks from time to time in 
> what we've released.

No doubt the particular version of libisofs was used for good reasons.

My concern is the ability to replicate and derive the least possible 
from Debian resources like the install images.

Concretely The Debian derivative PureOS is having trouble booting their 
homemade live image on some hardware, but boots fine on both Debian 
netinst image and Debian live image.  Looking at the properly working 
images I noticed that the live image for stable was produced using 
newer-than-stable libisofs, and that the stable netinst image was 
produced using a never-in-Debian release of libisofs.

A related issue is bug#807168.


> >Do we have any Policy on installer images?  If e.g. our netinst or 
> >live images contain non-DFSG-but-free-to-distribute code would that 
> >be only a wishlist bug, not a Policy violation?
> 
> That would be a serious bug IMHO - please raise any as you find them.

Thanks for clarifying the severity of such theoretic bug specifically.

It was just an example, however, and my real question was generally what 
governs code we distribute outside packages - i.e. our install images, 
if Debian Policy covers only packages.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Debian built from non-Debian sources

[Christian Seiler]

On 07/16/2017 11:12 PM, Jonas Smedegaard wrote:
> It was just an example, however, and my real question was generally what 
> governs code we distribute outside packages - i.e. our install images, 
> if Debian Policy covers only packages.

I don't know if this is actually in Policy or not, but in my opinion
any tool used to create any official Debian images should also be
part of Debian itself - for precisely the reasons you were mentioning
in your email: downstreams should be able to reproduce Debian images.
In the short term only in functionality and not bit-by-bit, but I
would consider reproducible image builds a worthwhile long-term goal
after fully reproducible package builds throughout the archive have
been achieved.

Actually, I'm extremely surprised that the tools used to create the
official Debian images are not part of the corresponding Debian
stable version. I don't doubt there's a good reason for using these
specific versions of those tools, but in that case they should also
be packaged for the release in question.

Regards,
Christian

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Roger Lynn]

On 13/07/17 12:40, Adam Borowski wrote:
> On Thu, Jul 13, 2017 at 05:17:57AM -0400, Tom H wrote:
> > On Wed, Jul 12, 2017 at 2:40 PM, Roger Lynn  wrote:
> > > SUBSYSTEM=="net", ATTR{address}=="1c:1b:0d:9a:34:98", NAME="eth0"
> > 
> > It's simpler to use (for example)
> > 
> > # cat /etc/systemd/network/77-en0.link
> > [Match]
> > MACAddress=1c:1b:0d:9a:34:98
> > [Link]
> > Name=en0

/etc/systemd/network/ doesn't exist on my system. I presume I would just
need to create it for this to work? I haven't been able to persuade
packages.debian.org to tell me which package it belongs to.

> There's apparently also a package "ifrename" which makes writing these
> rules more user friendly. And doesn't place them in obscure places that
> change every release.

Thank you to both of you and to others for all your suggestions. Of course
if I'd read the release notes first I could have saved myself some time, but
they are usually aimed at upgrades rather than new installations and I
haven't performed any upgrades yet. I am curious as to what mechanism will
be used to preserve names on upgrades when reusing the kernel names is such
a bad idea.

Is everyone using their own custom naming schemes actually a good idea, or
would it be preferable to have some standardised names?

Roger

PS Feel free to tell me to go to Debian-User. I hoped the experience of a
"hobbyist" user would be a useful contribution.

Re: Debian built from non-Debian sources

[Steve McIntyre]

Jonas wrote:
>Quoting Steve McIntyre (2017-07-16 22:14:29)
>> Jonas wrote:
>> >Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
>> >> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard wrote:
>> >> > Is our install images excepmt from our Policy that all dependencies 
>> >> > must 
>> >> > be in Debian, or am I mistaken that we have such Policy?
>> >> Do we?  The Debian Policy covers only debs.
>> >> Also, dak isn't in the archive either.
>> >
>> >I thought Policy covered what we distribute - which excludes dak but 
>> >includes libisofs code embedded in installer images.
>> 
>> Can you identify any code at all from libisofs which is embedded in
>> the images? I'm honestly not aware of any.
>
>I believe the embedded MBR is part of the libisofs project.

No, the MBR is generated from the isolinux/syslinux packages. xorriso
(libisofs) just updates some pointers in there to point at the El
Torito bootable images, to add a fake partition table, etc.

>> I've been using upstream versions of xorriso on-and-off over the last 
>> few years, accepting assistance from the (very helpful!) upstream 
>> author Thomas Schmitt when trying to debug thorny issues like hybrid 
>> BIOS/UEFI booting.
>> 
>> The exact behaviour that we've worked out in some cases has needed 
>> upstream tweaks, and we've needed those tweaks from time to time in 
>> what we've released.
>
>No doubt the particular version of libisofs was used for good reasons.
>
>My concern is the ability to replicate and derive the least possible 
>from Debian resources like the install images.

ACK, understood.

>Concretely The Debian derivative PureOS is having trouble booting their 
>homemade live image on some hardware, but boots fine on both Debian 
>netinst image and Debian live image.  Looking at the properly working 
>images I noticed that the live image for stable was produced using 
>newer-than-stable libisofs,

Sorry, wrong. It was built using the standard xorriso and libisofs
versions in stretch. From the stretch-based VM used to build it:

root@STRETCH-debian-live-builder:~# dpkg -s xorriso | grep Version
Version: 1.4.6-1+b1
root@STRETCH-debian-live-builder:~# dpkg -s libisofs6 | grep Version
Version: 1.4.6-1

If the PureOS folks are having problems, they could ask on the
debian-cd list?

>and that the stable netinst image was produced using a
>never-in-Debian release of libisofs.

Right, I'll give you that one. But there's *seriously* nothing special
there any more than what you'd find in any backport to jessie.

>A related issue is bug#807168.
>
>> >Do we have any Policy on installer images?  If e.g. our netinst or 
>> >live images contain non-DFSG-but-free-to-distribute code would that 
>> >be only a wishlist bug, not a Policy violation?
>> 
>> That would be a serious bug IMHO - please raise any as you find them.
>
>Thanks for clarifying the severity of such theoretic bug specifically.
>
>It was just an example, however, and my real question was generally what 
>governs code we distribute outside packages - i.e. our install images, 
>if Debian Policy covers only packages.

Go argue with the Policy folks, I guess.

But a *lot* of the infrastructure we use to run Debian is not exactly
what's been packaged, as already mentioned. Look at dak. debian-cd,
live-wrapper et al *are* packaged, but we're not *necessarily* using
the exact code that's in the stable archive at any point. We're
typically using code from git on the build machines, to allow for more
flexibility in terms of changes to build scripts as problems arise. We
release things to the archive periodically as a convenience to users,
but serious use often necessitates using git too. This isn't going to
change any time soon.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Re: Debian built from non-Debian sources

[Russ Allbery]

Steve McIntyre  writes:
> Jonas wrote:

>> It was just an example, however, and my real question was generally
>> what governs code we distribute outside packages - i.e. our install
>> images, if Debian Policy covers only packages.

> Go argue with the Policy folks, I guess.

Speaking as one of the Policy folks

> But a *lot* of the infrastructure we use to run Debian is not exactly
> what's been packaged, as already mentioned. Look at dak. debian-cd,
> live-wrapper et al *are* packaged, but we're not *necessarily* using
> the exact code that's in the stable archive at any point.

...this has been the position of the project for as long as I've been part
of it, and it's not the place of Policy to change that position, only to
reflect project consensus.

I think it would be interesting to strive for making available all Debian
infrastructure in our archives (although I think you may find that you'll
need a separate archive that doesn't correspond to stable or unstable,
based on having done similar things in the past), but it would be
premature to put a requirement into Policy until we actually *did* decide
to do that.  Which would affect a ton of different teams, and would be
quite a bit of work.

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

Re: P.S. Re: Debian 9 in a VM with Proxmox 5 system

[Russ Allbery]

Roger Lynn  writes:

> /etc/systemd/network/ doesn't exist on my system. I presume I would just
> need to create it for this to work? I haven't been able to persuade
> packages.debian.org to tell me which package it belongs to.

Yeah, you just create the directory; there isn't anything included in it
in a default Debian install.  The documentation for these files is in
systemd.network(5) and systemd.link(5).

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

what's the latest on the update of moving from alioth to pagure.

[shirish शिरीष]

Dear all,

While I love and loved alioth, I know for probably newish people the
interface is somewhat ugly.

>From what I did see in https://lwn.net/Articles/724986/ it seems there
were lots of pros and cons which were discussed. I was also able to
converse with Alexander Wirt and download the survey which wasn't
available anymore for public consumption.

Can somebody tell/share which forge are the developers looking forward
to replace alioth with, pagure or something else .

The choices seem to be to do lot of coding if some project/product is
taken which is not mature enough or has features that we want and in
some cases there is restrictive licensing or/and have two products,
one which has foss licensing and the other which has commercial
aspects but more features.

While there doesn't seem to be any hurry to replace alioth today, the
clock is ticking.

There is/was some discussion about it in May 2017
https://lists.debian.org/debian-devel/2017/05/msg00095.html, the
thread I'm reading right now. Would be nice though if somebody can
share what is/are the possible scenarios.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Re: Naming of network devices - how to improve it in buster

[Adam Borowski]

On Sun, Jul 16, 2017 at 01:54:27PM +0200, Guus Sliepen wrote:
> On Sat, Jul 15, 2017 at 10:25:22PM -0300, Henrique de Moraes Holschuh wrote:
> > It is indeed Very Cool, but it might not solve one little thing:
> > iptables firewalling.
> > 
> > Is that a way to trigger an ifrename using this, so that the network
> > device ends up being named "foo" ?
> 
> That's indeed an interesting issue. Currently, ifupdown doesn't rename
> interfaces. You could add a line like:
> 
>   post-up ip link set $IFACE name $LOGICAL
> 
> Which will do what you want, except ifupdown doesn't track interface
> renames this way and will get very confused. In particular, ifdown will
> not work anymore. So some code should be added to ifupdown to support
> interface renaming.

This is what I assumed your new code does -- it seemed an obvious and
natural thing to do.

As Ben noticed, the post-up stanza above can't work as Linux doesn't allow
renaming interfaces at that point.  It can't work in pre-up either as
ifupdown wouldn't know about the rename.

Thus, what about this:
auto mac/00:16:0a:26:99:c6/=en0
iface en0 inet6 static
address 3:1415:9265:3589:7932:3846:2643:3832/64
gateway 3:1415:9265:3589::1
rename

With the rename command taking an optional argument (the new name) that
defaults to the logical name (ie, after =).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Re: what's the latest on the update of moving from alioth to pagure.

[Alexander Wirt]

On Mon, 17 Jul 2017, shirish शिरीष wrote:

> Dear all,
> 
> While I love and loved alioth, I know for probably newish people the
> interface is somewhat ugly.
> 
> >From what I did see in https://lwn.net/Articles/724986/ it seems there
> were lots of pros and cons which were discussed. I was also able to
> converse with Alexander Wirt and download the survey which wasn't
> available anymore for public consumption.
> 
> Can somebody tell/share which forge are the developers looking forward
> to replace alioth with, pagure or something else .
> 
> The choices seem to be to do lot of coding if some project/product is
> taken which is not mature enough or has features that we want and in
> some cases there is restrictive licensing or/and have two products,
> one which has foss licensing and the other which has commercial
> aspects but more features.
> 
> While there doesn't seem to be any hurry to replace alioth today, the
> clock is ticking.
> 
> There is/was some discussion about it in May 2017
> https://lists.debian.org/debian-devel/2017/05/msg00095.html, the
> thread I'm reading right now. Would be nice though if somebody can
> share what is/are the possible scenarios.
We created a mailinglist [1] for those discussions. 

Alex

[1] https://lists.alioth.debian.org/mailman/listinfo/alioth-staff-replacement