Bug#886463: ITP: centrifuge -- rapid and memory-efficient system for classification of DNA sequences

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: centrifuge
  Version : 1.0.3~beta
  Upstream Author : Daehwan Kim, Li Song, Florian P. Breitwieser and Steven L. 
Salzberg
* URL : https://github.com/infphilo/centrifuge/
* License : GPL
  Programming Lang: C++
  Description : rapid and memory-efficient system for classification of DNA 
sequences
 Centrifuge is a very rapid and memory-efficient system for the
 classification of DNA sequences from microbial samples, with better
 sensitivity than and comparable accuracy to other leading systems. The
 system uses a novel indexing scheme based on the Burrows-Wheeler
 transform (BWT) and the Ferragina-Manzini (FM) index, optimized
 specifically for the metagenomic classification problem. Centrifuge
 requires a relatively small index (e.g., 4.3 GB for ~4,100 bacterial
 genomes) yet provides very fast classification speed, allowing it to
 process a typical DNA sequencing run within an hour. Together these
 advances enable timely and accurate analysis of large metagenomics data
 sets on conventional desktop computers.


Remark: This package will be maintained by the Debian Med team at
https://anonscm.debian.org/git/debian-med/centrifuge.git

Bug#886238: Please introduce official nosystemd build profile

[Chris Lamb]

Hleb,

> > (accusing Debian to "vandalize" open source by supporting systemd)
[…]
> 1) Proofs please. DDG & Google find only your words.

I was accused of this on the "dng" mailing list. It should be easy to
find the relevant threads.


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb, Debian Project Leader 2017
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Re: package mail aliases

[Jonas Meurer]

Am 04.01.2018 um 12:54 schrieb Raphael Hertzog:
> On Tue, 26 Dec 2017, W. Martin Borgert wrote:
>> In case of packaging plugins or additional programs to some kind of
>> "main" program, that are all maintained by the same team, it might
>> make sense to use the name of then main program, not the name of the
>> plugin or additional tool.
> 
> This might create more problems... getting BTS emails for two different
> source packages at the same @packages.debian.org alias might create
> problems at the package tracker level. It will see bug reports for "foo"
> received at an email address tagged for "bar" and it might be
> misclassified.
> 
> Really $sou...@packages.debian.org should be used for single packages. As
> soon as you have a set of related packages, you need to use the concept of
> a packaging team.

I see. So for now, there's no good way to give one similar
packages.debian.org address as maintainer contact to different source
packages under a team umbrella?

> I will work on offering a team-based email address at the package tracker
> level for this kind of need.

That would be very helpful indeed.

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Enchant transition 1.6.0 -> 2.1.2

[Timo Jyrinki]

Hello,

This is just to formally note that there is a major Enchant transition
[1] upcoming and possible to work on. Right now there is no dedicated
driver for the transition, but feel free to work on it. I'm mostly
interested in it for my Voikko [2] maintainership for which Enchant
has a plugin. I've packaged and uploaded the new enchant [3] to
experimental with blessing from enchant maintainer.

The new enchant brings among else multi-language support to the Voikko
plugin, which brings HFST [4] based dictionary support to Enchant.
HFST dictionaries are available for languages like Northern Sami (in
giella-sme package, to be split away from the big package) and
Greenlandic.

Possibly GNOME and KDE teams might want to try out compiling their
respective libraries and see if they spot or can fix any issues? I did
note back in November that gspell failed some tests, for example.

We will need co-operation over many teams regardless, but enchant
itself is now LowNMU if anyone wants to fix something there or upload
even newer versions which I see have recently appeared in upstream.

Possible participants/helpers include prach (enchant), me (voikko),
tino and kartik (hfst people).

-Timo (Mirv @ OFTC)

[1] https://release.debian.org/transitions/html/auto-enchant.html
[2] https://tracker.debian.org/pkg/libvoikko
[3] https://tracker.debian.org/pkg/enchant
[4] https://tracker.debian.org/pkg/hfst

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Sat, 06 Jan 2018 at 05:18:09 +0100, Simon Richter wrote:
> We still need a non-systemd ecosystem for everything that is out of
> scope for systemd.

If this is important to you (and when I say "you" here I mean
everyone who agrees with that statement, not just you personally), then
src:sysvinit and the ecosystem around it could really benefit from your
help. initscripts currently has an RC bug open, its most recent maintainer
upload was almost a year ago, and most of the uploads in the last couple
of years were from systemd maintainers keeping it on life-support;
systemd-shim is unmaintained upstream and in Debian; cgmanager is
unmaintained upstream and RFA in Debian; and libnih is unmaintained
upstream and in Debian (and currently uninstallable and fails to rebuild,
although there's a patch in the BTS for that).

In the longer term, elogind (a standalone fork of systemd-logind)
might well be a more sustainable way to provide systemd-logind APIs on
sysvinit-booted systems than the current approach of combining the current
systemd-logind with systemd-shim, an incomplete emulation of the systemd
manager (pid 1) that needs to keep up with whatever manager APIs logind
currently makes use of. After all, it seems more likely that third-party
software can cope with an old version of the logind APIs than that
systemd-logind can cope with an old version of the systemd manager API,
when logind and the manager are normally part of the same source tree
and so are upgraded together.

Either way, if you want sysvinit (and the stack around it) to continue to
be supported, it's necessary for someone who thinks the same way to do
the work to support it. Expecting the rest of Debian (and in particular
the systemd maintainers, ironically) to keep propping up sysvinit is
not really sustainable.

smcv

Re: Salsa Beta - Updates

[Martín Ferrari]

On 06/01/18 00:30, Joerg Jaspert wrote:


> Alexander (formorer) is running an Irker instance on one of its own
> VMs. Irker can send push events to an IRC channel. Please check the
> wiki[2] for details on how to use it.
> 
> We are not entirely happy with irker and are working on a better
> solution that will also  support Issues, Merge Requests and other
> gitlab events. Until that is ready, you are invited to use the Irker
> instance.

I have started working on adding webhook support to KGB, which is the
tool that many projects are already using for years.

Ideally, this would be a service plugin in gitlab, so projects could use
templates for configuration, and to be able to configure what is now
done in the kgb.conf file. But to get this out quicker, I will just add
simple webhook parsing.

On a side note, I only learnt about the idea to replace KGB with irker
last week, during the CCC congress. I think that contacting the KGB
maintainers beforehand would have been a better way of dealing with this.

-- 
Martín Ferrari (Tincho)

Re: Salsa Beta - Updates

[Alexander Wirt]

On Sat, 06 Jan 2018, Martín Ferrari wrote:

> On 06/01/18 00:30, Joerg Jaspert wrote:
> 
> 
> > Alexander (formorer) is running an Irker instance on one of its own
> > VMs. Irker can send push events to an IRC channel. Please check the
> > wiki[2] for details on how to use it.
> > 
> > We are not entirely happy with irker and are working on a better
> > solution that will also  support Issues, Merge Requests and other
> > gitlab events. Until that is ready, you are invited to use the Irker
> > instance.
> 
> I have started working on adding webhook support to KGB, which is the
> tool that many projects are already using for years.
> 
> Ideally, this would be a service plugin in gitlab, so projects could use
> templates for configuration, and to be able to configure what is now
> done in the kgb.conf file. But to get this out quicker, I will just add
> simple webhook parsing.
> 
> On a side note, I only learnt about the idea to replace KGB with irker
> last week, during the CCC congress. I think that contacting the KGB
> maintainers beforehand would have been a better way of dealing with this.
I think what you learned is wrong. We use irker because it is the only thing
we have. And how could we replace something that we aren't running? KGB is
not and will probably not run by salsa. 

Alex
 

Re: Bug#886238: Please introduce official nosystemd build profile

[Simon Richter]

[Possible candidate for a move to debian-project]

Hi,

On 06.01.2018 14:42, Simon McVittie wrote:

> If this is important to you (and when I say "you" here I mean
> everyone who agrees with that statement, not just you personally), then
> src:sysvinit and the ecosystem around it could really benefit from your
> help.

As it is now, we have a lot of people who are maintaining their own
packages outside of Debian. Can we get enough support to reintegrate
both the people and the code?

This is a social more than a technical problem at the moment.

Case in point: the subthread[1] starting with Marco D'Itri's

> This would be a lot of work for the benefit of a tiny audience: the
disturbed people who hate systemd so much that they cannot accept even
that libsystemd is installed on their computers.

Two well-known DDs chimed in in support, and all replies from DDs to
critical replies were completely dismissive of the criticism. Previous
instances of this have been similar.

What should I tell the people who are now maintaining these packages
outside of Debian will happen if they return? As of now, I have no
answer that would not be met with "see, that is why we left."

   Simon

[1] https://lists.debian.org/debian-devel/2018/01/msg00088.html



signature.asc
Description: OpenPGP digital signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Marco d'Itri]

On Jan 06, Simon Richter  wrote:

> As it is now, we have a lot of people who are maintaining their own
> packages outside of Debian. Can we get enough support to reintegrate
> both the people and the code?
I will ignore for the time being the reasons why these packages are 
outside of Debian, and focus on the obvious prerequisite.
As it is now, and as Simon is patiently trying to explain, sysvinit in 
Debian is basically unmaintained because no Debian developer cares 
enough about it.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Russ Allbery]

Simon Richter  writes:

> Two well-known DDs chimed in in support, and all replies from DDs to
> critical replies were completely dismissive of the criticism. Previous
> instances of this have been similar.

> What should I tell the people who are now maintaining these packages
> outside of Debian will happen if they return? As of now, I have no
> answer that would not be met with "see, that is why we left."

Did you see the other thread that Adrian Bunk and I were participating
about viable paths forward?

What you're seeing is a project which is quite patient with, and willing
to support, ways to maintain a viable sysvinit infrastructure, or some
replacement with a similar design goal but updated software that solves
some of the newer problems.  But a project that is extremely *impatient*
with grandstanding nonsense that does nothing to achieve these goals and
is just a troll to waste our time, energy, and good will, like trying to
eliminate an inert shared library dependency or relitigate Debian's
default init system discussion.

Yes, this does require some navigation, and there are still raw feelings,
so picking a few people to do some of the social debates who are
reasonably good at it might be a good move.  But you can maintain plenty
of packages in Debian without participating in these debian-devel
discussions at all, and I can assure you that Debian Policy is quite open
to continuing to document and standardize how to build a sysvinit or
similar infrastructure.  There just need to be people to do the actual
work, of course.

It would also be nice if these folks would show a bit of basic politeness
and say thank you to the systemd maintainers, who have been a big part of
keeping an ecosystem alive in Debian that they don't even use, in the face
of a bunch of vitriol, just because it's the right thing to do.

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

Bug#886238: marked as done (Please introduce official nosystemd build profile)

[Britton Kerin]

> -- Forwarded message --
> From: Bastian Blank 
> To: 886238-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 5 Jan 2018 11:50:23 +0100
> Subject: Re: Bug#886238: Please introduce official nosystemd build profile
> On Wed, Jan 03, 2018 at 03:12:51PM +0300, Hleb Valoshka wrote:
>> Please introduce official nosystemd build profile so downstream
>> distributions can send patches to package maintainers with
>> systemd-less build instead of keep them in home.
>
> As you have been already told by several people, Debian supports
> systemd-less systems.  If you find bugs running in this mode, please
> file bug reports.
>
> Apart from that, I don't see that you managed to describe what a
> "nosystemd" profile would actually do.  This would be the least we would
> need from such a bug report.
>
> However what I see is, that you and others instead of actually engaging
> in discussions just referred to personal attacks.  I and others consider
> this unacceptable behaviour on our technical mailing lists and our bug
> tracker.  Please be adviced that I will ask both the BTS owner and the
> list masters to block you from ever posting again if this behaviour
> continues.
>
> As I don't think anything new will come up, I'm closing this bug report.
> Don't reopen it, this might just expedite your fate.

Yeah no more debian for me in future.  That last comment is priceless.

Britton

Processed: forcibly merging 886238 886493

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forcemerge 886238 886493
Bug #886238 {Done: Bastian Blank } [general] Please introduce 
official nosystemd build profile
Bug #886493 [general] general: debian should support nosystemd build profile
Severity set to 'wishlist' from 'normal'
Marked Bug as done
Merged 886238 886493
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
886238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886238
886493: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886493
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#886493: general: debian should support nosystemd build profile

[Britton Kerin]

Package: general
Severity: normal

If debian is remotely serious about keeping non-systmed use an option,
is should support a nosystemd build profile.  There's no other real
way to guarantee that packages don't use it.  Sure they don't *have*
to link against it, but in practice many will and this is the obvious
clean way to ensure that none do so.

As a long-time user I'm highly interested in this feature, and
preventing others from working on it for idealogical reasons is
indefensible.

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.4
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.5.emp3 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Processed: severity of 886493 is wishlist

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 886493 wishlist
Bug #886493 {Done: Bastian Blank } [general] general: debian 
should support nosystemd build profile
Bug #886238 {Done: Bastian Blank } [general] Please introduce 
official nosystemd build profile
Ignoring request to change severity of Bug 886493 to the same value.
Ignoring request to change severity of Bug 886238 to the same value.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
886238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886238
886493: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886493
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Salsa Beta - Updates

[Jonas Smedegaard]

Quoting Andrew Shadura (2018-01-06 20:25:35)
> On 6 January 2018 at 17:18, Alexander Wirt  wrote:
> > On Sat, 06 Jan 2018, Martín Ferrari wrote:
> >
> >> On 06/01/18 00:30, Joerg Jaspert wrote:
> >>
> >>
> >> > Alexander (formorer) is running an Irker instance on one of its own
> >> > VMs. Irker can send push events to an IRC channel. Please check the
> >> > wiki[2] for details on how to use it.
> >> >
> >> > We are not entirely happy with irker and are working on a better
> >> > solution that will also  support Issues, Merge Requests and other
> >> > gitlab events. Until that is ready, you are invited to use the Irker
> >> > instance.
> >>
> >> I have started working on adding webhook support to KGB, which is the
> >> tool that many projects are already using for years.
> >>
> >> Ideally, this would be a service plugin in gitlab, so projects could use
> >> templates for configuration, and to be able to configure what is now
> >> done in the kgb.conf file. But to get this out quicker, I will just add
> >> simple webhook parsing.
> >>
> >> On a side note, I only learnt about the idea to replace KGB with irker
> >> last week, during the CCC congress. I think that contacting the KGB
> >> maintainers beforehand would have been a better way of dealing with this.
> > I think what you learned is wrong. We use irker because it is the only thing
> > we have. And how could we replace something that we aren't running? KGB is
> > not and will probably not run by salsa.
> 
> Or maybe we can use Matrix's IRC gateway; with Matrix, you don't need
> to run a daemon, you just execute a webhook or use a simple Python
> wrapper for it; see e.g.
> https://kallithea-scm.org/repos/integration/matrix/files/tip/__init__.py

Please let's self-host, not rely on resources outside our control. 
Matrix service is in Debian package matrix-synapse (if you really want: 
Running a full Matrix node need more ressources¹ than running a bot).


 - Jonas

¹ Externalizing still consumes ressources, just hidden.

-- 
 * 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

Bug#886502: ITP: libpath-iter-perl -- module for simple efficient path iteration

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libpath-iter-perl
  Version : 0.2
  Upstream Author : Daniel Muey 
* URL : https://metacpan.org/release/Path-Iter
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module for simple efficient path iteration

Path::Iter allows one to iterate through the contents of a given path without
having to build the entire list first.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: Bug#886238: Please introduce official nosystemd build profile

[Adam Borowski]

On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote:
> On Jan 06, Simon Richter  wrote:
> 
> > As it is now, we have a lot of people who are maintaining their own
> > packages outside of Debian. Can we get enough support to reintegrate
> > both the people and the code?
> I will ignore for the time being the reasons why these packages are 
> outside of Debian, and focus on the obvious prerequisite.
> As it is now, and as Simon is patiently trying to explain, sysvinit in 
> Debian is basically unmaintained because no Debian developer cares 
> enough about it.

Ian Jackson and Benda Xu are nobodies?
(Somehow Ian mistakenly versioned an upload as NMU.)

I can't think of any pressing issue (#872039 has bogus severity), the
package is mature, and any recent breakage happened due to systemd changes.

This is not to say all is fine -- the package really could take some extra
work, but it is functional.


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: Bug#886238: Please introduce official nosystemd build profile

[Simon McVittie]

On Sat, 06 Jan 2018 at 23:35:09 +0100, Adam Borowski wrote:
> I can't think of any pressing issue (#872039 has bogus severity)

If that's the case, please could someone with a suitably well-informed
opinion downgrade it? (Preferably a maintainer, of course, but failing
that, anyone else who's sure about the correct severity.)

Thanks,
smcv

Re: Bug#886238: marked as done (Please introduce official nosystemd build profile)

[Adam Borowski]

On Fri, Jan 05, 2018 at 10:51:08AM +, Debian Bug Tracking System wrote:
> On Wed, Jan 03, 2018 at 03:12:51PM +0300, Hleb Valoshka wrote:
> > Please introduce official nosystemd build profile so downstream
> > distributions can send patches to package maintainers with
> > systemd-less build instead of keep them in home.
> 
> As you have been already told by several people, Debian supports
> systemd-less systems.

Server loads yes.  Anything GUI (beyond last-millenium stuff like fvwm)? 
Nope.  You can find hard dependencies on systemd from core packages of all
desktop environments; requests for fixing those dependencies have been
repeatedly ignored.  It takes just a single maintainer to add such a
dependency and stick with it.

And I for one did such a profile rebuild, exactly as Hleb is asking for.

> If you find bugs running in this mode, please file bug reports.

After enough of such bugs were closed with angry messages (even when
accompanied by tested patches), no one bothers filing new ones anymore.

Especially -shim is a bad joke, even an equivs dummy package seems to work
better (although for basic functionality like suspend or shutdown, you need
to recompile against consolekit -- which is not that good either).

d-i is another place where installing a non-systemd system is pretty hard
for most users, with patches fixing obvious bugs (such as --exclude
not working as documented) rotting in the BTS.


But, not everyone is as hostile as you.  Looks like we have a plan that
might lead to making logind-depending packages work well without systemd
again.

Being no tuits factory, I've done only mechanical preparatory work so far
(unfit for use yet packages: deb https://angband.pl/debian logind main,
so you can't accuse me of only talk no action).  Unfortunately, I got a pile
of responses to FTBFS bugs I filed for an armhf archive rebuild that would
be extremely rude to keep waiting any longer, only after that is dealt with
I'll be able to do more.

WIP elogind packages have surfaced recently, I haven't taken a look yet.
Also, someone else is evaluating CK2.


> Apart from that, I don't see that you managed to describe what a
> "nosystemd" profile would actually do.  This would be the least we would
> need from such a bug report.

This is why we're having this thread: people have already pointed out that
avoiding libsystemd0 is a waste of time.  Worthy idea would be to take a
subset of profile builds some of us have already done, and implement them
inside Debian proper using that fancy new "profile build" syntax.

But, Simon McVittie proposed something better.  As the effort is supposed
to be done by those asking for the change, sounds like time for talk is over
for now[1].  Once the work is done, we'll come back, either presenting
patches or discussing an alternative.


> However what I see is, that you and others instead of actually engaging
> in discussions just referred to personal attacks.  I and others consider
> this unacceptable behaviour on our technical mailing lists and our bug
> tracker.  Please be adviced that I will ask both the BTS owner and the
> list masters to block you from ever posting again if this behaviour
> continues.

You mean, like MikeeUSA references?  Note that he also trolled LKML in the
very same way about grsecurity.  Thus, according to your logic any
grsecurity haters including Linus have no place on LKML and should be
blocked, as they expressed the same opinion as MikeeUSA.

> As I don't think anything new will come up, I'm closing this bug report.
> Don't reopen it, this might just expedite your fate.

It's sad to see suggestions that would fix the problem (such as the build
profile) see such a response.

I'll see if the alternate solution will be enough, but if even some packages
would still benefit from a profile build (pretty likely), I'll reopen this
bug myself -- as having a common profile name would allow a mechanical
rebuild.  Please ban me from the BTS then.


Meow!

[1]. Some details are worth talking about already, like apt reacting badly
to schemes like:

a-addon Depends: a
b-addon Depends: b
c Depends: a-addon | b-addon
User has b installed, wants c -- yet apt insists on replacing b with a.
We need a way to tell apt that b-addon is the better solution.

But installation troubles are orthogonal to the packages actually working.
-- 
// 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: Bug#886238: Please introduce official nosystemd build profile

[Ansgar Burchardt]

Adam Borowski writes:
> On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote:
>> On Jan 06, Simon Richter  wrote:
>>
>> > As it is now, we have a lot of people who are maintaining their own
>> > packages outside of Debian. Can we get enough support to reintegrate
>> > both the people and the code?
>> I will ignore for the time being the reasons why these packages are 
>> outside of Debian, and focus on the obvious prerequisite.
>> As it is now, and as Simon is patiently trying to explain, sysvinit in 
>> Debian is basically unmaintained because no Debian developer cares 
>> enough about it.
>
> Ian Jackson and Benda Xu are nobodies?
> (Somehow Ian mistakenly versioned an upload as NMU.)

I think Marco wants to suggest that they don't seem to actively maintain
sysvinit and therefore the package is in practice unmaintained.

> I can't think of any pressing issue (#872039 has bogus severity), the
> package is mature, and any recent breakage happened due to systemd
> changes.

No maintainer has replied for almost half a year (when the bug was
filed)...  sysvinit probably only stays in testing because systemd
depends on sysv-rc for compatability with LSB init scripts...

> This is not to say all is fine -- the package really could take some extra
> work, but it is functional.

And the remaining packages of the sysvinit ecosystem are unmaintained
too, for example insserv (#834284) and startpar (#834283).  Or
systemd-shim if you want to consider desktop systems too.

Ansgar

Re: Bug#886238: Please introduce official nosystemd build profile

[Michael Biebl]

Am 06.01.2018 um 23:35 schrieb Adam Borowski:
> On Sat, Jan 06, 2018 at 07:17:14PM +0100, Marco d'Itri wrote:
>> On Jan 06, Simon Richter  wrote:
>>
>>> As it is now, we have a lot of people who are maintaining their own
>>> packages outside of Debian. Can we get enough support to reintegrate
>>> both the people and the code?
>> I will ignore for the time being the reasons why these packages are 
>> outside of Debian, and focus on the obvious prerequisite.
>> As it is now, and as Simon is patiently trying to explain, sysvinit in 
>> Debian is basically unmaintained because no Debian developer cares 
>> enough about it.
> 
> Ian Jackson and Benda Xu are nobodies?
> (Somehow Ian mistakenly versioned an upload as NMU.)

Afaics sysvinit is basically unmaintained atm given that neither Ian nor
Benda did any significant work on sysvinit in the last year which is why
I reopened #811377

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

[Fwd: Bug#886238: marked as done (Please introduce official nosystemd build profile)]

[Svante Signell]

reopen 886238
thanks

Did you see this? I thought this was not discussed through yet! Very nice
attitude from Debian DD's indeed :(--- Begin Message ---
> -- Forwarded message --
> From: Bastian Blank 
> To: 886238-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Fri, 5 Jan 2018 11:50:23 +0100
> Subject: Re: Bug#886238: Please introduce official nosystemd build profile
> On Wed, Jan 03, 2018 at 03:12:51PM +0300, Hleb Valoshka wrote:
>> Please introduce official nosystemd build profile so downstream
>> distributions can send patches to package maintainers with
>> systemd-less build instead of keep them in home.
>
> As you have been already told by several people, Debian supports
> systemd-less systems.  If you find bugs running in this mode, please
> file bug reports.
>
> Apart from that, I don't see that you managed to describe what a
> "nosystemd" profile would actually do.  This would be the least we would
> need from such a bug report.
>
> However what I see is, that you and others instead of actually engaging
> in discussions just referred to personal attacks.  I and others consider
> this unacceptable behaviour on our technical mailing lists and our bug
> tracker.  Please be adviced that I will ask both the BTS owner and the
> list masters to block you from ever posting again if this behaviour
> continues.
>
> As I don't think anything new will come up, I'm closing this bug report.
> Don't reopen it, this might just expedite your fate.

Yeah no more debian for me in future.  That last comment is priceless.

Britton

--- End Message ---

Processed: [Fwd: Bug#886238: marked as done (Please introduce official nosystemd build profile)]

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reopen 886238
Bug #886238 {Done: Bastian Blank } [general] Please introduce 
official nosystemd build profile
Bug #886493 {Done: Bastian Blank } [general] general: debian 
should support nosystemd build profile
Bug reopened
Ignoring request to alter fixed versions of bug #886238 to the same values 
previously set
Ignoring request to alter fixed versions of bug #886493 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
886238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886238
886493: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886493
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#886493: marked as done (general: debian should support nosystemd build profile)

[Debian Bug Tracking System]

Your message dated Sun, 7 Jan 2018 00:59:24 +0100
with message-id <20180106235924.evasx5ptotiic...@shell.thinkmo.de>
and subject line Re: [Fwd: Bug#886238: marked as done (Please introduce 
official nosystemd build profile)]
has caused the Debian Bug report #886238,
regarding general: debian should support nosystemd build profile
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
886238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886238
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal

If debian is remotely serious about keeping non-systmed use an option,
is should support a nosystemd build profile.  There's no other real
way to guarantee that packages don't use it.  Sure they don't *have*
to link against it, but in practice many will and this is the obvious
clean way to ensure that none do so.

As a long-time user I'm highly interested in this feature, and
preventing others from working on it for idealogical reasons is
indefensible.

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 8.4
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.5.emp3 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
On Sun, Jan 07, 2018 at 12:31:10AM +0100, Svante Signell wrote:
> reopen 886238
> thanks
> 
> Did you see this? I thought this was not discussed through yet! Very nice
> attitude from Debian DD's indeed :(

As I said: don't.

Bastian

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!--- End Message ---

Bug#886238: marked as done (Please introduce official nosystemd build profile)

[Debian Bug Tracking System]

Your message dated Sun, 7 Jan 2018 00:59:24 +0100
with message-id <20180106235924.evasx5ptotiic...@shell.thinkmo.de>
and subject line Re: [Fwd: Bug#886238: marked as done (Please introduce 
official nosystemd build profile)]
has caused the Debian Bug report #886238,
regarding Please introduce official nosystemd build profile
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
886238: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886238
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: wishlist

Please introduce official nosystemd build profile so downstream
distributions can send patches to package maintainers with
systemd-less build instead of keep them in home.
--- End Message ---
--- Begin Message ---
On Sun, Jan 07, 2018 at 12:31:10AM +0100, Svante Signell wrote:
> reopen 886238
> thanks
> 
> Did you see this? I thought this was not discussed through yet! Very nice
> attitude from Debian DD's indeed :(

As I said: don't.

Bastian

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!--- End Message ---

Re: Bug#886493: marked as done (general: debian should support nosystemd build profile)

[Svante Signell]

Incredible: What's going on in Debian??

On Sun, Jan 07, 2018 at 12:31:10AM +0100, Svante Signell wrote:
> reopen 886238
> thanks
> 
> Did you see this? I thought this was not discussed through yet! Very nice
> attitude from Debian DD's indeed :(

As I said: don't.

Bastian

Bug#886519: ITP: node-asap -- The asap function executes a task as soon as possible but not before it returns, waiting only for the completion of the current event and previously scheduled tasks.

[Manas Kashyap]

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

* Package name    : node-asap
  Version : 2.0.6
  Upstream Author : Kris Kowal
* URL : https://github.com/kriskowal/asap#readme
* License : Expat
  Programming Lang: JavaScript
  Description : The asap function executes a task as soon as
possible but not before it returns,
  waiting only for the completion of the current event and previously
scheduled tasks.
 .
 ASAP strives to schedule events to occur before yielding for IO,
reflow, or redrawing.
 ASAP provides a fast event queue that will execute tasks until it is
empty before yielding to the JavaScript engine's underlying event-loop.
When a task gets added to a previously
 empty event queue, ASAP schedules a flush event, preferring for that
event to occur before the JavaScript engine has an opportunity to
perform IO tasks or rendering, thus
 making the first task and subsequent tasks semantically
indistinguishable. ASAP uses a variety of techniques to preserve this
invariant on different versions of browsers and Node.js.
 .
 Node.js is an event-based server-side JavaScript engine.

 Praveen agreed to sponsor the package.