Bug#769641: ITP: barrnap -- rapid ribosomal RNA prediction

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: barrnap
  Version : 0.5 
  Upstream Author : Torsten Seemann 
* URL : http://www.vicbioinformatics.com/software.barrnap.shtml
* License : GPL
  Programming Lang: Perl
  Description : rapid ribosomal RNA prediction

Barrnap (BAsic Rapid Ribosomal RNA Predictor) predicts the location of
ribosomal RNA genes in genomes. It supports bacteria (5S,23S,16S), archaea
(5S,5.8S,23S,16S), mitochondria (12S,16S) and eukaryotes (5S,5.8S,28S,18S).
It takes FASTA DNA sequence as input, and writes GFF3 as output. It uses the
NHMMER tool that comes with HMMER 3.1 for HMM searching in RNA:DNA style.
Multithreading is supported and one can expect roughly linear speed-ups
with more CPUs.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115095539.21696.47603.reportbug@renard

Re: veto?

[Matthias Urlichs]

Hi,

Peter Samuelson:
> 
> Do you mean, perhaps, that the Further Discussion option in a GR should
> be weighted much more heavily than other options, so that it can beat
> another option if only a few people rank it higher?  I am not in favor
> of that.
> 
You can't give any one option more "weight" in a Condorcet election because
each input vote is a ranking of options. You _could_ require the Condorcet
winner to have a 2:1 (or 1.5:1 or …) supermajority over FD.

IMHO, doing this would not be good for Debian, for reasons already stated.

> Or perhaps you mean there should be an official platform where someone
> can say, effectively, "Before deciding to do X, you should take into
> account that I, someone directly involved in its implementation, will
> not help because I'm not convinced X is a good idea.  Also, this may
> demotivate me from related work Y and Z." But, well, anybody can
> already say that.
> 
Exactly. That platform already exists, it's called "debian-vote" (or -devel
or -project … take your pick).

> Anyway... I don't really see people leaving because of a decision they
> disagree with.
> 
I assume that some do, but they're doing it quietly.

If the systemd decision had gone the other way (i.e. pro Upstart), I would
have done the same thing.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: relative path in -dbg packages

[Jérémy Bobbio]

Mathieu Malaterre:
> While reading the wiki page for AutomaticDebugPackages, I was
> wondering if it is possible to post-processed object file to
> manipulate relatives path for debug info ?

As part of the reproducible builds effort [1], it has so far proven to
be very difficult to do so in a consistant manner. Be it with debugedit
or -fdebug-prefix-map. Building packages in the right directory from the
beginning is much more easier.

> 2. Is it possible to reserve a system path for debug information, eg
> all debug paths should start with "/usr/src/debug"

During discussions at DebConf14 [2], there was a consensus that a
canonical build path in (at least) pbuilder and sbuild would be a pretty
sensible requirement. We thought of `/usr/src/debian/hello-2.8-1`.
Users would then be able to unpack a source package in the same location
and have gdb happy without further configuration.

 [1]: https://wiki.debian.org/ReproducibleBuilds
 [2]: 
https://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20140901/000198.html

(Please Cc: me in replies, I am not subscribed to -devel.)

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Matthias Urlichs]

Hi,

Bernhard R. Link:
> I think such a document would do well to not say much about upstream
> branches or imply how they should be managed.
> 
It is helpful to base the Debian release on an Upstream release that is
actually tagged by Upstream, provided that the version thus tagged is the
basis for ongoing development (or fixes, for stable branches).

On the other hand, there are upstreams where "releasing" means "make a
release branch, run autotools and/or doxygen, add all these auto-gene-
rated files to the branch, and tag that". IMHO it's good practice to
discourage this.

> git-dpm creates some git branch head for the upstream branch. But I
> realized that I usually remove this git branch manually directly afterwards
> whenever it creates it.

Is there any advantage to doing so? If not: wouldn't it be easier,
long-term, to file a bug requesting to drop this behavior? ;-)

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Processed: Process (21 bugs archived): The new gift tag is newcomer

[Debian Bug Tracking System]

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

> unarchive 720980
Bug #720980 {Done: Lucas Nussbaum } [how-can-i-help] 
how-can-i-help: support execution by non-root users with listing of new 
opportunities
Unarchived Bug 720980
> unarchive 720985
Bug #720985 {Done: Lucas Nussbaum } [how-can-i-help] 
how-can-i-help: avoid downloading the opportunities list too frequently by 
adding some caching
Unarchived Bug 720985
> unarchive 764077
Bug #764077 {Done: Stefano Zacchiroli } [qa.debian.org] 
debsources: case-insensitive browsing by package prefix
Unarchived Bug 764077
> unarchive 64071
Bug #64071 {Done: Holger Levsen } [general] menu: 
Automatically generated files should not go to /etc
Unarchived Bug 64071
> unarchive 761863
Bug #761863 {Done: Stefano Zacchiroli } [qa.debian.org] 
debsources: use relative paths in cache/sources.txt
Unarchived Bug 761863
> unarchive 660710
Bug #660710 {Done: David Prévot } [www.debian.org] 
[www.debian.org] DebianUsers link to parked domain ("Miscellaneous GNU/Linux 
links")
Unarchived Bug 660710
> unarchive 450792
Bug #450792 {Done: Mehdi Dogguy } [camlidl] camlidl: Missing 
META file for findlib support
Unarchived Bug 450792
> unarchive 720981
Bug #720981 {Done: Lucas Nussbaum } [how-can-i-help] 
how-can-i-help: support execution in a cron job (and document it)
Unarchived Bug 720981
> unarchive 466907
Bug #466907 {Done: Y Giridhar Appaji Nag } 
[splint-doc-html] splint-doc-html: Manual is missing images and looks crummy
Unarchived Bug 466907
> unarchive 752149
Bug #752149 {Done: Dominique Dumont } 
[libconfig-model-dpkg-perl] libconfig-model-dpkg-perl: Please enable Testsuite 
in debian/control
Unarchived Bug 752149
> unarchive 497290
Bug #497290 {Done: Ana Beatriz Guerrero Lopez } [kde-i18n] 
debian/copyright misses information
Warning: Unknown package 'kde-i18n'
Unarchived Bug 497290
Warning: Unknown package 'kde-i18n'
> unarchive 302292
Bug #302292 {Done: Y Giridhar Appaji Nag } [dput] dput: 
provide a "delete" option to delete remote copies of files in .changes
Unarchived Bug 302292
> unarchive 493054
Bug #493054 {Done: Debian Qt/KDE Maintainers } 
[kdebase-runtime] missing manpage for /usr/bin/kioclient
Unarchived Bug 493054
> unarchive 470026
Bug #470026 {Done: Sylvestre Ledru } [worldwind] 
worldwind: Document how to use sun-java?-jre
Unarchived Bug 470026
> unarchive 720982
Bug #720982 {Done: Lucas Nussbaum } [how-can-i-help] 
how-can-i-help: support providing a list of additional packages to care about
Unarchived Bug 720982
> unarchive 722594
Bug #722594 {Done: Lucas Nussbaum } [how-can-i-help] 
how-can-i-help: unowned files after purge (policy 6.8, 10.8): 
/var/lib/how-can-i-help/seen.json
Unarchived Bug 722594
> unarchive 515204
Bug #515204 {Done: Bastien ROUCARIES } 
[imagemagick-doc] Documentation metabug
Unarchived Bug 515204
> unarchive 762931
Bug #762931 {Done: Stefano Zacchiroli } [qa.debian.org] 
debsources: flake8 compliance
Unarchived Bug 762931
> unarchive 599340
Bug #599340 {Done: Ivo De Decker } [qa.debian.org] UDD: 
ftp-master's lintian autorejects
Unarchived Bug 599340
> unarchive 448622
Bug #448622 {Done: Debian FTP Masters } 
[mnogosearch-sqlite] use a less generic name for the file 
/usr/lib/cgi-bin/search.cgi
Warning: Unknown package 'mnogosearch-sqlite'
Unarchived Bug 448622
Warning: Unknown package 'mnogosearch-sqlite'
> unarchive 606821
Bug #606821 {Done: Thorsten Glaser } [mksh] mksh: bash-style 
process substitution
Unarchived Bug 606821
> tag 720980 newcomer
Bug #720980 {Done: Lucas Nussbaum } [how-can-i-help] 
how-can-i-help: support execution by non-root users with listing of new 
opportunities
Added tag(s) newcomer.
> tag 720985 newcomer
Bug #720985 {Done: Lucas Nussbaum } [how-can-i-help] 
how-can-i-help: avoid downloading the opportunities list too frequently by 
adding some caching
Added tag(s) newcomer.
> tag 764077 newcomer
Bug #764077 {Done: Stefano Zacchiroli } [qa.debian.org] 
debsources: case-insensitive browsing by package prefix
Added tag(s) newcomer.
> tag 64071  newcomer
Bug #64071 {Done: Holger Levsen } [general] menu: 
Automatically generated files should not go to /etc
Added tag(s) newcomer.
> tag 761863 newcomer
Bug #761863 {Done: Stefano Zacchiroli } [qa.debian.org] 
debsources: use relative paths in cache/sources.txt
Added tag(s) newcomer.
> tag 660710 newcomer
Bug #660710 {Done: David Prévot } [www.debian.org] 
[www.debian.org] DebianUsers link to parked domain ("Miscellaneous GNU/Linux 
links")
Added tag(s) newcomer.
> tag 450792 newcomer
Bug #450792 {Done: Mehdi Dogguy } [camlidl] camlidl: Missing 
META file for findlib support
Added tag(s) newcomer.
> tag 720981 newcomer
Bug #720981 {Done: Lucas Nussbaum } [how-can-i-help] 
how-can-i-help: support execution in a cron job (and document it)
Added tag(s) newcomer.
> tag 466907 newcomer
Bug #466907 {Done: Y Giridhar Appaji Nag } 
[splint-doc-html] splint-doc-html: Manual is missing images and looks crummy
Added tag(s) newcomer.
> tag 752149 newcomer
Bug #752149 {

Re: veto?

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 15/11/14 11:52, Matthias Urlichs wrote:
> Hi,
> 
> Peter Samuelson:
>> 
>> Do you mean, perhaps, that the Further Discussion option in a GR
>> should be weighted much more heavily than other options, so that
>> it can beat another option if only a few people rank it higher?
>> I am not in favor of that.
>> 
> You can't give any one option more "weight" in a Condorcet election
> because each input vote is a ranking of options. You _could_
> require the Condorcet winner to have a 2:1 (or 1.5:1 or …)
> supermajority over FD.
> 
> IMHO, doing this would not be good for Debian, for reasons already
> stated.
> 
>> Or perhaps you mean there should be an official platform where
>> someone can say, effectively, "Before deciding to do X, you
>> should take into account that I, someone directly involved in its
>> implementation, will not help because I'm not convinced X is a
>> good idea.  Also, this may demotivate me from related work Y and
>> Z." But, well, anybody can already say that.
>> 
> Exactly. That platform already exists, it's called "debian-vote"
> (or -devel or -project … take your pick).
> 

As mentioned in another reply, how people vote doesn't give a good
insight into how they will or won't act

The things people write in debian-vote or debian-devel give more
insight but only for those people who take the time to write and even
then somebody has to read all of those opinions and potentially
summarize them.

E.g. if 10 people are going to stop or limit their maintenance of
essential packages because of some technical or policy change, that
would be very useful to know in advance of any GR.

>> Anyway... I don't really see people leaving because of a decision
>> they disagree with.
>> 
> I assume that some do, but they're doing it quietly.
> 
> If the systemd decision had gone the other way (i.e. pro Upstart),
> I would have done the same thing.
> 

It is not just about people formally resigning, people may simply
change the way they are working, may be less likely to volunteer for
things (like mentoring or helping the FTP masters with the NEW queue),
etc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJUZznvAAoJEGxlgOd711bEHecP/A5q5D1HFsf6SZn19dJBB/pl
suSTFJjxqkvWdoRW20ZWqeV8G9p422/BG4hw1z1dSUWIq8gCm49i5+lN0d/u+lme
oTKlFIGm2DKMGu6zHgBYIPL3ee1HBDwMpWWiHLB8ICqHaXFMy2sgIW/iXFFXC0oq
jGpRa1Yp7UPl4aXjwo067Lhmt5eQv4CNakkvLn99sHASCeQYsbbbXNUPG6iIcSyM
dfSyy6MuKhjsi8dsd9CLNkl57DLKAnnJFuGGIj5oQ2I1GCG/gwp9B5mmd1kaKeM0
9a6nxEg/plN9pTZHTY9H5EF50+qa8iVa5dRFPJRKlhtWPG/bNZxs74dti1N87uao
+RoUNW5xtMg6ta7Qdzz2Vm6ouxmxeQ+mxCDm3Tkx6VXVxXmSqCmpxvEny9l+MMjh
KDaMkOVwB/7JM95Rv/3/zJ3rAKnMVZ0zwqZH+E5WHOuhhj8GrH5NJkUiTl4PxvoT
QzQe3ZXuhr70BHwGRUKu8UfincYgLRGnotsYK6qidh8Im5cQ1r9r+YTU7af1SAVv
AEA+K0BWjg1+rTLwAoTz1k0Lht+N+Q//GMYcLLXJus5b1gCCSyaf8ZggENuQULFx
OnzugBAjVBPoBvFTJ1VsG3yky0IcXND+p3ulsrIy+FQaDZE2Cd1NVcuhBEdBOdLb
R61ORPN6dVUnOrfh5kOz
=WcsA
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546739ef.6080...@pocock.pro

Re: Being part of a community and behaving

[Raphaël Halimi]

Le 13/11/2014 18:58, Ralf Jung a écrit :
> How does having yet another NTP client shut off existing NTP clients?
> How does having yet another way to configure your network shut off
> existing alternatives?

How does having yet another web browser integrated in the OS shut off
existing web browsers ? ;)

> Even syslog is still working!

No, it's not:

raph@arche:~$ journalctl | grep Forwarding
nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
42 messages.
nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed
1 messages.
nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed
2 messages.
nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed
2 messages.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700

http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html

I know it may be biased since I'm the reporter of the bug, but I'm tired
of reading that systemd replaces all those components smoothly.

It does not.

Now on the technical side, when I reported this bug I looked at the
source code. In a nutshell, the comment said "If syslog is too slow,
drop the message" (IIRC it was even more condescending, like "we don't
have to wait for this" or something). Really ? The very piece of code
which is supposed to talk to syslog... doesn't wait for syslog ?

So if one can't afford to have crippled logs, what's the solution ?
Getting rid of syslog completely by turning on persistence in journald,
and go with binary logs ? Thanks, but no thanks.

I think Florian really has a point: Debian has changed. I use Debian
since Slink and I can confidently say that there was a time when such
software would never have reached stable, let alone become the default.
In those days, we would have waited for the RHEL admins to do the
beta-testing in production environments (which excludes toys like Fedora
or Arch or whatever distro that "use systemd for several years now
without any hassle") before adopting this bloatware as the default init
system.

-- 
Raphaël Halimi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546748f3.9000...@gmail.com

Re: Being part of a community and behaving

[Dimitrios Chr. Ioannidis]

On 15-11-2014 14:37, Raphaël Halimi wrote:


I think Florian really has a point: Debian has changed. I use Debian
since Slink and I can confidently say that there was a time when such
software would never have reached stable, let alone become the default.
In those days, we would have waited for the RHEL admins to do the
beta-testing in production environments (which excludes toys like 
Fedora

or Arch or whatever distro that "use systemd for several years now
without any hassle") before adopting this bloatware as the default init
system.


Those comments is exactly what I'm thinking for the last two weeks or 
so.


Systemd project used distro's as a testbed and that will be fine if 
debian
didn't join the "fun" but choosed to leave systemd in sid for as long as 
it
proved to be stable enough and at the same time implemented a 
alternative path to replace it.


Regards,
--
Dimitrios Chr. Ioannidis


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/7f7ec7476991599f33a736a8027bb...@nephelae.eu

Re: Being part of a community and behaving

[Ralf Jung]

Hi,

>> How does having yet another NTP client shut off existing NTP clients?
>> How does having yet another way to configure your network shut off
>> existing alternatives?
> 
> How does having yet another web browser integrated in the OS shut off
> existing web browsers ? ;)

There's a difference between a browser popping into every kind of
launcher and starter and telling people it should be used; and something
like systemd-networkd that I wouldn't even know existed if I wouldn't
follow the news.
You have a point here. But I think that the case is different for
services that the average user hardly ever faces. People who do manual
network configuration beyond NetworkManager, are more than capable of
installing another suite for that if necessary (not that it looks like
/etc/network/interfaces will cease to function anytime soon). Everybody
else uses whatever Gnome/KDE/... provides and doesn't care how the magic
happens in the background.

>> Even syslog is still working!
> 
> No, it's not:
[...]

Well, systemd has bugs, nobody doubts that. FWIW, I never saw this
happen on my machine.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5467528a.80...@ralfj.de

Re: Being part of a community and behaving

[Raphaël Halimi]

Le 15/11/2014 14:18, Ralf Jung a écrit :
> You have a point here. But I think that the case is different for
> services that the average user hardly ever faces. People who do manual
> network configuration beyond NetworkManager, are more than capable of
> installing another suite for that if necessary (not that it looks like
> /etc/network/interfaces will cease to function anytime soon). Everybody
> else uses whatever Gnome/KDE/... provides and doesn't care how the magic
> happens in the background.

That's precisely the point. If systemd is installed as default on every
jessie system, since it ships its own time syncing client, what's the
point of installing NTP (provided that the machine doesn't have to
provide time services to other hosts) ? That's exactly what a well-known
software company did to push its web browser by taking advantage of its
dominant position on the OS market. And that's what systemd is doing
with every component it intends to "offer" a replacement for.

>>> Even syslog is still working!
>>
>> No, it's not:
> [...]
> 
> Well, systemd has bugs, nobody doubts that. FWIW, I never saw this
> happen on my machine.

If you already ditched syslog, it obviously won't happen... You wouldn't
be of such bad faith, would you ? ;)

Just kidding. More seriously, you avoided to comment on the real issues:
is it a good sign of code quality (for the whole project) if the piece
of code which is supposed to communicate with syslog doesn't even wait
for it to be ready ? And more importantly, is it the quality level that
Debian has accustomed us to ?

We're not talking of an optional Perl library that will be used in a 100
lines home-made script, but of the basic foundations that every
jessie(+x) systems will be built upon.

We're not talking of a small bug in a maintainer's script that can be
fixed in a an update during the freeze, but of a design choice in
upstream code that results in crippled logs for people who don't want
binary logs.

That's not like Debian (or at least the Debian we all know and love) to
adopt this kind of software as the default init system.

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Re: Being part of a community and behaving

[Ralf Jung]

Hi,

> That's precisely the point. If systemd is installed as default on every
> jessie system, since it ships its own time syncing client, what's the
> point of installing NTP (provided that the machine doesn't have to
> provide time services to other hosts) ? That's exactly what a well-known
> software company did to push its web browser by taking advantage of its
> dominant position on the OS market. And that's what systemd is doing
> with every component it intends to "offer" a replacement for.

As I already mentioned, I think the issue is very different with a
browser vs. some low-level system component. Or would you say that the
fact that we force every user to use GNU libc is comparable?
What you say could also be read as a plea against any kind of
integration, as this integration naturally provides a "best" combination
of tools, and it will be harder to exchange some of them. I would argue
that this is a trade-off. Personally, I am happy to know that the
combination of tools that make up a part of the low-level system, has
been tested and designed in exactly this constellation - as opposed to
the giant exploding test matrix that results from supporting several
variants of each tool. I appreciate that others have other preferences,
and hence I think it is crucial that people can choose. Jessie is the
first Debian release that offers a choice of init systems.

>>> No, it's not:
>> [...]
>>
>> Well, systemd has bugs, nobody doubts that. FWIW, I never saw this
>> happen on my machine.
> 
> If you already ditched syslog, it obviously won't happen... You wouldn't
> be of such bad faith, would you ? ;)

Just to clarify, as you already suspected, I still have syslog
installed. ;-)

> Just kidding. More seriously, you avoided to comment on the real issues:
> is it a good sign of code quality (for the whole project) if the piece
> of code which is supposed to communicate with syslog doesn't even wait
> for it to be ready ? And more importantly, is it the quality level that
> Debian has accustomed us to ?

I didn't read the code. Depending on where and how this happens, I can
understand that someone doesn't want to make a call that blocks
arbitrary long. So if you get a timeout, what else could you do?

I also find it hasty to judge systemd's code quality from a single
example. The analysis of Russ and several others suggest that actually,
systemd has a fairly high code quality. That's not something I can
comment on; but they do seem to be eager to get rid of old cruft (many
say, too eager), which certainly helps keeping your code clean.
Considering the age and complexity of the software, I am also impressed
how well it works. And finally, what I can comment on is the amount of
documentation, and that's outstanding. I assume there is some
correlation between well-organized, well-documented code and
well-written (user-facing) documentation.

Kind regards
Ralf


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546765dc.50...@ralfj.de

Re: Being part of a community and behaving

[Svante Signell]

On Sat, 2014-11-15 at 13:37 +0100, Raphaël Halimi wrote:
> Le 13/11/2014 18:58, Ralf Jung a écrit :
> > How does having yet another NTP client shut off existing NTP clients?
> > How does having yet another way to configure your network shut off
> > existing alternatives?
> 
> How does having yet another web browser integrated in the OS shut off
> existing web browsers ? ;)
> 
> > Even syslog is still working!
> 
> No, it's not:
> 
> raph@arche:~$ journalctl | grep Forwarding
> nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
> 42 messages.
> nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed
> 1 messages.
> nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed
> 2 messages.
> nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed
> 2 messages.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700
> 
> http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html
> 
> I know it may be biased since I'm the reporter of the bug, but I'm tired
> of reading that systemd replaces all those components smoothly.
> 
> It does not.
> 
> Now on the technical side, when I reported this bug I looked at the
> source code. In a nutshell, the comment said "If syslog is too slow,
> drop the message" (IIRC it was even more condescending, like "we don't
> have to wait for this" or something). Really ? The very piece of code
> which is supposed to talk to syslog... doesn't wait for syslog ?
> 
> So if one can't afford to have crippled logs, what's the solution ?
> Getting rid of syslog completely by turning on persistence in journald,
> and go with binary logs ? Thanks, but no thanks.

One effect of having logs stored in binary format:
http://lists.freedesktop.org/archives/systemd-devel/2014-November/025203.html




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1416062783.2764.3.ca...@gmail.com

Re: Being part of a community and behaving

[Raphaël Halimi]

Le 15/11/2014 15:40, Ralf Jung a écrit :
> What you say could also be read as a plea against any kind of
> integration, as this integration naturally provides a "best" combination
> of tools, and it will be harder to exchange some of them. I would argue
> that this is a trade-off. Personally, I am happy to know that the
> combination of tools that make up a part of the low-level system, has
> been tested and designed in exactly this constellation - as opposed to
> the giant exploding test matrix that results from supporting several
> variants of each tool.

I understand, and in fact, despite what I may sound like, I'm not
against this type of integration. On the only machine I have with
systemd installed (a sid desktop), I ditched ntp because, well, what's
the point of having two packages doing the same thing, if the one that's
already present does its job well ?

But the haste to integrate so many things in such a short amount of
time, the stubbornness (wontfix) that some upstream developers have
sometimes exhibited (not unlike Gnome upstream), or the piece of code I
saw (I'm not a developer, more a sysadmin, so I rarely dive into C code,
only for debugging purposes), all of this gives me a bad feeling about
systemd. And, did I mention that I *really* don't want binary logs ? :-P

> I didn't read the code. Depending on where and how this happens, I can
> understand that someone doesn't want to make a call that blocks
> arbitrary long. So if you get a timeout, what else could you do?

I don't know, like I said, I'm no developer. But the comment was clear
on the fact that the developer deliberately chose not to wait on the
syslog. For a piece of code which is supposed to feed the syslog, I find
that choice illogic, to say the least.

> I also find it hasty to judge systemd's code quality from a single
> example. The analysis of Russ and several others suggest that actually,
> systemd has a fairly high code quality. That's not something I can
> comment on; but they do seem to be eager to get rid of old cruft (many
> say, too eager), which certainly helps keeping your code clean.

Sorry, english isn't my native language so maybe I wasn't clear. I
didn't *judge* all of systemd's code to be of poor quality; but as for
the little piece I looked at, I have a bad hunch about it. And the
general "wontfix" attitude of the developers just add to that hunch.

But again, we pull away from my first point - as a sysadmin, what I can
see is that my systemd box has crippled text logs, and the point is
that's not worthy of the quality that we're all accustomed to, and which
made me choose Debian 15 years ago.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Re: Being part of a community and behaving

[Tollef Fog Heen]

]] Raphaël Halimi 

> > I didn't read the code. Depending on where and how this happens, I can
> > understand that someone doesn't want to make a call that blocks
> > arbitrary long. So if you get a timeout, what else could you do?
> 
> I don't know, like I said, I'm no developer. But the comment was clear
> on the fact that the developer deliberately chose not to wait on the
> syslog. For a piece of code which is supposed to feed the syslog, I find
> that choice illogic, to say the least.

You have two choices: you can drop the oldest or the newest log entries
if syslog doesn't keep up.  Apparently, you prefer to ditch the newest
ones, the code ditches the oldest ones.

> > I also find it hasty to judge systemd's code quality from a single
> > example. The analysis of Russ and several others suggest that actually,
> > systemd has a fairly high code quality. That's not something I can
> > comment on; but they do seem to be eager to get rid of old cruft (many
> > say, too eager), which certainly helps keeping your code clean.
> 
> Sorry, english isn't my native language so maybe I wasn't clear. I
> didn't *judge* all of systemd's code to be of poor quality; but as for
> the little piece I looked at, I have a bad hunch about it. And the
> general "wontfix" attitude of the developers just add to that hunch.

Have you actually interacted with any systemd developers?  Your
experience doesn't match mine at all.

> But again, we pull away from my first point - as a sysadmin, what I can
> see is that my systemd box has crippled text logs, and the point is
> that's not worthy of the quality that we're all accustomed to, and which
> made me choose Debian 15 years ago.

How do you know that your old setup didn't lose logs too, but just
failed to record it?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9y0zcir@xoog.err.no

Re: Being part of a community and behaving

[Matthias Urlichs]

Hi,

Raphaël Halimi:
> raph@arche:~$ journalctl | grep Forwarding

try this instead:

$ journalctl _SYSTEMD_UNIT=systemd-journald.service

which will (most likely) also show messages like "Suppressed 1927 messages
from /PATH/FOO.slice". You can then use 

$ journalctl _SYSTEMD_SLICE=FOO.slice

to display the non-suppressed part of the spew that's responsible
for this overrun.

> nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
> 42 messages.

Presumably, systemd is not capable of changing the speed of your syslog
daemon. So what would happen otherwise? If it's stdout/err logging, the
information would not have been logged at all (daemons redirect it to
/dev/null when backgrounding), or it'd have been tossed when sendmsg()
returns an error due to a full buffer. Or, if it's an intermittent problem
with syslog rather than message spew, the fact that you now have one pipe
to syslogd instead of N of them, each 4k big may be relevant.

Thus, the fix is
(a) increase the kernel buffer size of the pipe to syslog,
(b) increase the speed of your syslogd, (c) decrease that daemon's latency,
(d) teach whatever program logged so much to Not Do That, and/or
(e) decrease journald's RateLimitBurst= config variable so that
it doesn't overload your syslog. Oh yes,
(f) if your syslog still sync()s a log file after every message, tell it
to not Do That.

(a) should be a straightforward patch. (b) to (d) are not systemd's
problem. (e) defaults to 1000 in 30 seconds, which may be too much
for your syslog to keep up with.

> drop the message" (IIRC it was even more condescending, like "we don't
> have to wait for this" or something). Really ? The very piece of code
> which is supposed to talk to syslog... doesn't wait for syslog ?
> 
Do you want to buffer an unbounded number of messages in RAM instead,
hoping that syslog will catch up eventually? Thanks, but no thanks.
(Implementing a _bounded_ message buffer in systemd doesn't make sense,
because you can get the exact same effect by simply doing (a), above.)

> So if one can't afford to have crippled logs, what's the solution ?

It's likely (though not certain) that your logs have been crippled in the
past, albeit in a different way, and you simply didn't notice because the
logging program didn't tell you. The standard syslog(3) code doesn't.

> Getting rid of syslog completely by turning on persistence in journald,
> and go with binary logs ? Thanks, but no thanks.
> 
Why not?

Seriously. I can do a whole lot more with this strange binary journal thing
than with a text file.

* All error messages from my web server setup, no matter which process
  logged them?
  One command.
* Get everything Joe User did last week (that resulted in a syslog entry)?
  One command.
* Post-process some logs without writing fragile regexps which need to make
  triple sure no random crap throws off your syslog parser?
  Export the entries you need (and only these) as JSON.
* Want a logger that will NOT fill your whole disk with logs, no matter what?
  No problem.
And you get all of this without sequentially scanning a couple of huge
syslog-written files with redundant data (just how many syslog files does a
WARN message from the kernel end up in?).

Yes, binary logs are somewhat less crash-proof. In theory. But in my
experience, a random crash which doesn't even sync() will also leave a big
fat spot of NULLs in the text log, so you don't have any useful information
about the crash in either case. And if it does sync successfully, well, the
text log will be OK, but so will be its binary counterpart.

Yes, this may sound fanboy-ish. But let me tell you, the simple fact is
that this evil buggy monolithic systemd stuff some people complain about
saves me a lot of time, not all of which I then spend on Debian mailing
lists fanboy-ing. :-P  (I'm also somewhat too old to be called "boy". :-/ )

Besides, I'm not blind to the fact that not all is well in systemd land.
But that's a different topic.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Raphael Hertzog]

On Fri, 14 Nov 2014, Ian Jackson wrote:
> Richard Hartmann writes ("Re: RFC: DEP-14: Recommended layout for Git 
> packaging repositories"):
> > Can you at least suggest, not require, that the NMUer should also send
> > a link to a publicly available branch with the patch(es) which are
> > based on the packaging branch's correct tag? That makes pulling in
> > changes from in-repo simpler and does not force you to download
> > patches, etc.
> > Also, it shows that a consistent pathway from a specific point exists.
> 
> This is a good suggestion.

But as I said it's unrelated to this DEP and should be part of the
developer's reference.

Unless you want to suggest a specific standardized name for a NMU patch
branch... but this does seem a bit premature given that nobody is
currently doing stuff like that. The few persons that I saw commit their
NMU to git just used the main branch for this (and not some
alternate/dedicated branch).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115170223.gd25...@home.ouaza.com

Re: Being part of a community and behaving

[Florian Lohoff]

Hi,

On Fri, Nov 14, 2014 at 09:46:08AM +1100, Brian May wrote:
> On 14 November 2014 09:30, Svante Signell  wrote:
> 
> > >From an irc:(16:06:44) xxx: udevd starts very slowly without systemd...
> > any chance i can speed it up?
>
>  Assuming that report is accurate, to me it sounds like a bug that should
> get fixed, as opposed to a clear indication that udevd is going to stop
> supporting non-systemd systems.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767363

There are other reports about 30 second delays on bootup
not yet linked to an absent systemd.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754987

which is already merged with

#755708, #755736, #756649, #760976, #763041

Open 4 months now ...

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: Being part of a community and behaving

[Holger Levsen]

forcemerge 754987 767363
# not sure why you mail devel about this instead of merging the bugs...
thanks


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

Re: Being part of a community and behaving

[Raphaël Halimi]

Le 15/11/2014 16:53, Tollef Fog Heen a écrit :
> You have two choices: you can drop the oldest or the newest log entries
> if syslog doesn't keep up.  Apparently, you prefer to ditch the newest
> ones, the code ditches the oldest ones.

When did you read that I prefer to ditch any of them ?

> Have you actually interacted with any systemd developers?  Your
> experience doesn't match mine at all.

No, but I read some bug reports, mailing lists, etc etc. And I saw a lot
of "wontfix", more than in other projects.

> How do you know that your old setup didn't lose logs too, but just
> failed to record it?

Of course I can't be sure, but the point isn't just the logging issue.
The point is that until now, systemd hasn't been tested in real huge
production environments. There are three big players in this segment:
RHEL, SLES, and Debian. RHEL7 was launched in June, SLES12 in October,
and only in the next months will we see what happens. Debian used to
wait carefully before integrating such new technologies at the heart of
the system. I don't consider that Fedora, OpenSuse or Arch are
enterprise-grade distros, so as far as I'm concerned, systemd is still a
new technology because the test in real production environments has
started only a few months ago with RHEL7, even if Fedora uses it since 2011.

Once again, to be clear: I may or may not like systemd, but my point is
not to tell if it's a good or bad choice for Debian; I'm just saying
that making it the default init system is too soon compared to the
conservative position that Debian has accustomed us to.

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Raphael Hertzog]

On Fri, 14 Nov 2014, Ian Jackson wrote:
> > What exactly is your use case you feel this is essential for?
> 
> I think this discussion is in danger of going round in circles.
> I'm going to leave it here and let Raphael get on with it.

I understand Ron's logic and there's certainly value in questioning the
need for something. But this is always a question of cost/value.

Even if we don't have an immediate need for this property, the problem
is that we can't always envision all the ways people will want to use
the repositories (isn't that what you were trying to tell me about
how upstream can use git?) and I'm pretty sure that dropping the epoch
will be annoying to someone at some point. And the cost of not dropping
the epoch is not very high.

YMMV.
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115171644.ge25...@home.ouaza.com

Pre-Depends: init-system-helpers

[Bastien ROUCARIES]

Hi,

In order to solve #769551 I need to Pre-Depends: init-system-helpers

Indeed preinst script need it:
/var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci/preinst:
deb-systemd-helper: not found

Thus I am asking to add a pre-depends to init-system-helpers


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cae2spazybwolhxcdmcu+xgqplryezvjdlp0d9sweaxxkqxt...@mail.gmail.com

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[gregor herrmann]

On Sat, 15 Nov 2014 18:02:23 +0100, Raphael Hertzog wrote:

> Unless you want to suggest a specific standardized name for a NMU patch
> branch... but this does seem a bit premature given that nobody is
> currently doing stuff like that. The few persons that I saw commit their
> NMU to git just used the main branch for this (and not some
> alternate/dedicated branch).

This is not completely correct; I know at least one DD who uses
separate branches for pushing NMU/DELAYED changes (Axel Beckert):
http://anonscm.debian.org/cgit/collab-maint/debsums.git/
http://anonscm.debian.org/cgit/collab-maint/wicd.git

The branch is called nmu in both cases, if I'm seeing this correctly.


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Dire Straits: Why Worry


signature.asc
Description: Digital Signature

Re: Being part of a community and behaving

[Ben Hutchings]

On Sat, 2014-11-15 at 13:37 +0100, Raphaël Halimi wrote:
> Le 13/11/2014 18:58, Ralf Jung a écrit :
> > How does having yet another NTP client shut off existing NTP clients?
> > How does having yet another way to configure your network shut off
> > existing alternatives?
> 
> How does having yet another web browser integrated in the OS shut off
> existing web browsers ? ;)
> 
> > Even syslog is still working!
> 
> No, it's not:
> 
> raph@arche:~$ journalctl | grep Forwarding
> nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
> 42 messages.
> nov. 14 01:02:44 arche systemd-journal[207]: Forwarding to syslog missed
> 1 messages.
> nov. 14 01:25:31 arche systemd-journal[207]: Forwarding to syslog missed
> 2 messages.
> nov. 14 01:26:36 arche systemd-journal[207]: Forwarding to syslog missed
> 2 messages.
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700
> 
> http://lists.freedesktop.org/archives/systemd-devel/2014-August/021897.html
> 
> I know it may be biased since I'm the reporter of the bug, but I'm tired
> of reading that systemd replaces all those components smoothly.
> 
> It does not.
> 
> Now on the technical side, when I reported this bug I looked at the
> source code. In a nutshell, the comment said "If syslog is too slow,
> drop the message" (IIRC it was even more condescending, like "we don't
> have to wait for this" or something). Really ? The very piece of code
> which is supposed to talk to syslog... doesn't wait for syslog ?
[...]

Unfortunately, syslog(3) has never guaranteed that messages actually end
up in the log (or are filtered out), nor does it return an error code.
Does the interposition of systemd-journald actually make it less
reliable?  Or, are you annoyed because it called attention to this
unreliability whereas messages were previously dropped silently?

openlog(3) *does* provide an option to log to the console in case of
failure, however, and this presumably won't (and can't) be honoured by
systemd-journald if it loses messages later.  I don't know whether this
option is widely used, or whether the fallback is actually useful in
practice.

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.


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

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Henrique de Moraes Holschuh]

On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > What exactly is your use case you feel this is essential for?
> > 
> > I think this discussion is in danger of going round in circles.
> > I'm going to leave it here and let Raphael get on with it.
> 
> I understand Ron's logic and there's certainly value in questioning the
> need for something. But this is always a question of cost/value.
> 
> Even if we don't have an immediate need for this property, the problem
> is that we can't always envision all the ways people will want to use
> the repositories (isn't that what you were trying to tell me about
> how upstream can use git?) and I'm pretty sure that dropping the epoch
> will be annoying to someone at some point. And the cost of not dropping
> the epoch is not very high.

I fully agree.  Please, lets just keep the epoch which is the safer design
choice anyway, and get done with it.

Also, we have a fully reversible, human-friendly mapping to deal with : and
~ already, it has been in use by git-buildpackage for years, it is tested,
and it works.  I suggest we remove the risk of making things worse by
gratuitous overengineering (URL-like %-encoding, etc), and mandate the use
of the simple 1:1 map already ( [:] maps to [%] and [~] maps to [_] ) for
the Debian-compatible git-tag version namespace.

Whether the upstram version string is compatible or not with the Debian
version namespace and the Debian git-tag version namespace is a non-problem:
the upstream version WILL have been reduced to something compatible to be
usable for the package version in debian/changelog already, anyway.

Therefore, there is no space for ambiguity here. % and _ are *illegal* in
the Debian version namespace, so they can be freely used to translate from
the Debian version namespace to the Debian version git-tag namespace.

And anything that compares the upstream version namespace and the Debian
version namespace directly (or via their git-tag namespaces) is Utterly
Broken in the general case anyway, even if it will often just work
(particular case).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115174956.ga9...@khazad-dum.debian.net

Re: Being part of a community and behaving

[Cameron Norman]

On Thu, Nov 13, 2014 at 2:02 AM, Bálint Réczey  wrote:
> Dear Josselin,
>
> I have just noticed your blog post on planet.debian.org:
> https://np237.livejournal.com/34598.html
>
> I would like to ask you to resist the temptation of publishing similar posts.
> It makes fun of part of our community which you are well aware of and
> it also shows corpses which probably did not ring a bell in you.
>
> None of those show good taste and by having it aggregated on
> planet.debian.org it shows the whole project in bad light, too.

I disliked the post because I felt like it would create an annoying
and circular discussion, possibly on debian-devel.

Well look what happened... we went through about 50 sometimes long
messages, and maybe (maybe!) five were useful (thinking about the
syslog-ng bug found).

Can we please stop? Active Debian developers are considering just
leaving -devel because of discussions like these.

Thanks,
--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFR+pec6=sPec4wmT0+JRTWdd5�wbkt16m4qeulm-0...@mail.gmail.com

Re: Being part of a community and behaving

[Cameron Norman]

On Thu, Nov 13, 2014 at 11:30 PM, Gergely Nagy
 wrote:
>> "Cameron" == Cameron Norman  writes:
>
> >>> OK, so the system has syslog-ng installed.  For what ever reason
> >>> syslog-ng
> >>> is not starting automatically, but starts manually by systemctl.
> >>
> >>> syslog-ng version 3.5.6-2
> >>> systemd version 215-5+b1
> >>
> >> Maybe some failure to sync status correctly?  syslog-ng does ship
> >> with a
> >> service file.  What does:
> >>
> >> systemctl status syslog-ng
> >>
> >> say?  Particularly the Loaded and Active fields should have some
> >> hint as
> >> to what's going on that's preventing the service from starting
> >> automatically.
>
> Cameron> Apparently this is a known issue, and another person has 
> experienced
> Cameron> it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426
>
> That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are
> closely related, and will be fixed in the next syslog-ng upload (likely
> early next week). I know how to fix both, but lacked the time to
> implement said fixes so far.

This is a great chance to use the 'newcomer' tag recently added as an
official tag. It is for relatively simple bugs that a fix is known
for, but the maintainer just does not have the time. Please do
consider it in the future!

Thanks,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFR+iWMJKEkSmo_=6ysf1-0r67tyzdc0sqw_bmxegdgn...@mail.gmail.com

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Simon McVittie]

On 12/11/14 22:07, Ron wrote:
> I am also interested to hear more
> about whatever the confusion was you had with this was when you
> started working with Tollef's systemd repo that you mentioned
> in the previous thread.

Having played with gitpkg some more, I'm reminded that the answer to
this is that unlike (AIUI) both gbp-pq and git-dpm, it did not meet my
assumption that the contents of the git tree were in a suitable form to
run dpkg-buildpackage and have a 3.0 (quilt) Debian package fall out. I
realise that's partly a property of 3.0 (quilt).

For gitpkg, you can commit in the normal git way, but the cost is that
you have to build in a way that isn't the normal dpkg thing (exporting
with gitpkg and building the result).

gbp-pq and git-dpm are the other way round: the tree can be built with
dpkg-buildpackage, but the cost is that you have to commit in a way that
isn't the normal git thing (either using a specific tool, or for the
gbp-pq layout, dropping in pre-prepared patches and hoping they don't
have conflicts, in the same way you might for svn-buildpackage).

I think I was also thrown by the fact that gitpkg does not encapsulate
its configuration in what you commit: if two developers build the same
tree, the debdiff might well be rather large, because one developer's
.git/config results in separate git-debcherry patches and the other's
.git/config results in a single large patch.

git-buildpackage reads both debian/gbp.conf and .git/gbp.conf, with the
latter taking precedence. That lets maintainers provide "executable
documentation, in debian/gbp.conf, for "here is how I intend this repo
to be used", which seems like something that could be rather useful for
gitpkg: for instance, filter patterns for non-DFSG tarball imports can
go in debian/gbp.conf as a way to avoid mistakes.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54679845.90...@debian.org

Re: Pre-Depends: init-system-helpers

[Bastian Blank]

On Sat, Nov 15, 2014 at 06:06:17PM +0100, Bastien ROUCARIES wrote:
> In order to solve #769551 I need to Pre-Depends: init-system-helpers
> Indeed preinst script need it:
> /var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci/preinst:
> deb-systemd-helper: not found

Why do you need deb-systemd-helper in preinst?

Bastian

-- 
The sight of death frightens them [Earthers].
-- Kras the Klingon, "Friday's Child", stardate 3497.2


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141115180044.gb12...@mail.waldi.eu.org

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Simon McVittie]

On 13/11/14 14:04, Ron wrote:
> I really do think that the names of the branches are actually going to
> be the least of your worries here, unfortunately.  Even with a naming
> scheme that's widely adopted, things just aren't going to be that sort
> of uniform outside of (a fairly large number of) fairly small subsets.

I agree that the expected contents of the branches are far more
important than their names. Unfortunately, while acting as "the Debian
expert" for Debian derivatives at $day_job, I keep finding that the
answer to "OK, I've cloned a package's git repository, I know what code
change I want, now do I change the upstream source or drop a patch into
debian/patches or what?" is "... I can't actually answer that until you
tell me which source package you're working on".

At the moment, I suspect Kali's approach - arbitrarily choosing one of
the popular approaches, only cloning packaging repositories from Debian
that happen to match that approach, and restarting a new packaging
repository for those that do not - is likely to be the only viable
solution to that. There's always going to be a certain amount of
re-importing in any case, because some packages in Debian are maintained
in a non-git VCS or in no VCS at all; but it's easier to inspect history
if it's possible to clone the existing packaging repository for "most"
Debian packages of interest.

One of my projects for the near future is to put together some simple
test-cases for packaging - a set of simple projects with a downstream
patch that gets applied in the next upstream release, a downstream patch
that doesn't get applied upstream, and a downstream patch that conflicts
with upstream changes - and try packaging them with each of gbp-pq,
git-dpm and gitpkg. To have the complete set, I think I need one project
where the upstream tarball is a simple git-archive of the upstream git
repository, one where the upstream tarball has extra detritus (e.g.
Autotools) and/or missing files (upstream's .gitignore not being in the
tarball is also common in Autotools), and one where the Debian
maintainer needs to filter out a non-free file. Anything else you can
think of?

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54679cdb.4090...@debian.org

Re: Pre-Depends: init-system-helpers

[Bastien ROUCARIES]

Le 15 nov. 2014 19:18, "Bastian Blank"  a écrit :
>
> On Sat, Nov 15, 2014 at 06:06:17PM +0100, Bastien ROUCARIES wrote:
> > In order to solve #769551 I need to Pre-Depends: init-system-helpers
> > Indeed preinst script need it:
> > /var/lib/dpkg/tmp.ci/preinst: 27: /var/lib/dpkg/tmp.ci/preinst:
> > deb-systemd-helper: not found
>
> Why do you need deb-systemd-helper in preinst?

See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730604#74

Bastien
> Bastian
>
> --
> The sight of death frightens them [Earthers].
> -- Kras the Klingon, "Friday's Child", stardate 3497.2
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmas...@lists.debian.org
> Archive: https://lists.debian.org/20141115180044.gb12...@mail.waldi.eu.org
>

Re: Being part of a community and behaving

[Philip Hands]

Matthias Urlichs  writes:

> Hi,
>
> Raphaël Halimi:
>> raph@arche:~$ journalctl | grep Forwarding
>
> try this instead:
>
> $ journalctl _SYSTEMD_UNIT=systemd-journald.service
>
> which will (most likely) also show messages like "Suppressed 1927 messages
> from /PATH/FOO.slice". You can then use 
>
> $ journalctl _SYSTEMD_SLICE=FOO.slice
>
> to display the non-suppressed part of the spew that's responsible
> for this overrun.
>
>> nov. 10 20:14:34 arche systemd-journal[207]: Forwarding to syslog missed
>> 42 messages.
>
> Presumably, systemd is not capable of changing the speed of your syslog
> daemon. So what would happen otherwise? If it's stdout/err logging, the
> information would not have been logged at all (daemons redirect it to
> /dev/null when backgrounding), or it'd have been tossed when sendmsg()
> returns an error due to a full buffer. Or, if it's an intermittent problem
> with syslog rather than message spew, the fact that you now have one pipe
> to syslogd instead of N of them, each 4k big may be relevant.
>
> Thus, the fix is
> (a) increase the kernel buffer size of the pipe to syslog,
> (b) increase the speed of your syslogd, (c) decrease that daemon's latency,
> (d) teach whatever program logged so much to Not Do That, and/or
> (e) decrease journald's RateLimitBurst= config variable so that
> it doesn't overload your syslog. Oh yes,
> (f) if your syslog still sync()s a log file after every message, tell it
> to not Do That.
>
> (a) should be a straightforward patch. (b) to (d) are not systemd's
> problem. (e) defaults to 1000 in 30 seconds, which may be too much
> for your syslog to keep up with.

How thoroughly refreshing to see some well reasoned sense talked about
systemd for a change.

I'm a total newbie to systemd.  I've had it on my laptop for a few
weeks, and just installed it on an old laptop for a friend.

My brief exposure to journalctl (while diagnosing a hardware fault on
the second machine) pretty much instantly convinced me that it's a much
better way of doing things than having to rummage through a heap of text
files, some compressed, rotated on varying schedules etc, where you're
always left with the sneaking suspicion that the bit of data you need to
see is hiding in some other file that you've forgotten about, or has for
some reason  simply never made it to a file.

If journald manages to do what it's designed to do then future Linux
sysadmins won't have to clog their brains up with this drivel.  I look
forward to forgetting it, as I'm very happy to have forgotten the
contents of the sendmail book.

It's annoying to realise that we've all been putting up with this
slightly shoddy solution to the problem simply because it wasn't quite
painful enough to motivate anyone to fix it -- until now.

Of course, I've also come across things that I don't like about our
systemd setup, which may turn into a bug report once I have time to
confirm that I didn't simply screw up the install somehow -- of course
this subject has now become so sensitive on all sides that some people
will probably assume that I'm reporting such a bug because I hate
systemd, so I'll have to be really careful about the wording -- how
depressing this mess is.

Thanks again for providing a brief moment of sanity.

Let the chaos resume  :-/

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


pgppilv4Et4Hi.pgp
Description: PGP signature

Re: Pre-Depends: init-system-helpers

[Thomas Goirand]

On 11/16/2014 05:14 AM, Bastien ROUCARIES wrote:
> 
> Le 15 nov. 2014 19:18, "Bastian Blank"  > a écrit :
>>
>> On Sat, Nov 15, 2014 at 06:06:17PM +0100, Bastien ROUCARIES wrote:
>> > In order to solve #769551 I need to Pre-Depends: init-system-helpers
>> > Indeed preinst script need it:
>> > /var/lib/dpkg/tmp.ci/preinst : 27:
> /var/lib/dpkg/tmp.ci/preinst :
>> > deb-systemd-helper: not found
>>
>> Why do you need deb-systemd-helper in preinst?
> 
> See
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730604#74
> 
> Bastien

By the way, this doesn't seem to support sysv-rc. I'm not trying to
debate init systems, but it's important to support it, because of
backports to Wheezy (I do use my own version of a libvirt backport to
Wheezy for OpenStack). Has this been solved yet?

Cheers,

Thomas Goirand (zigo)


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5467e25b.9000...@debian.org

Differences between git packaging tools (was: RFC: DEP-14: Recommended layout for Git packaging repositories)

[Nikolaus Rath]

Simon McVittie  writes:
> Having played with gitpkg some more, I'm reminded that the answer to
> this is that unlike (AIUI) both gbp-pq and git-dpm, it did not meet my
> assumption that the contents of the git tree were in a suitable form to
> run dpkg-buildpackage and have a 3.0 (quilt) Debian package fall out. I
> realise that's partly a property of 3.0 (quilt).
>
> For gitpkg, you can commit in the normal git way, but the cost is that
> you have to build in a way that isn't the normal dpkg thing (exporting
> with gitpkg and building the result).
>
> gbp-pq and git-dpm are the other way round: the tree can be built with
> dpkg-buildpackage, but the cost is that you have to commit in a way that
> isn't the normal git thing (either using a specific tool, or for the
> gbp-pq layout, dropping in pre-prepared patches and hoping they don't
> have conflicts, in the same way you might for svn-buildpackage).

This is such a nice summary that I have to quote it again just to make
it more visible.

I've been very confused by the proliferation of git packaging tools, but
this makes it a lot clearer.


Thanks!
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761egufce.fsf...@vostro.rath.org

Re: RFC: DEP-14: Recommended layout for Git packaging repositories

[Ron]

On Sat, Nov 15, 2014 at 03:49:56PM -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 15 Nov 2014, Raphael Hertzog wrote:
> > On Fri, 14 Nov 2014, Ian Jackson wrote:
> > > > What exactly is your use case you feel this is essential for?
> > > 
> > > I think this discussion is in danger of going round in circles.
> > > I'm going to leave it here and let Raphael get on with it.
> > 
> > I understand Ron's logic and there's certainly value in questioning the
> > need for something. But this is always a question of cost/value.
> > 
> > Even if we don't have an immediate need for this property, the problem
> > is that we can't always envision all the ways people will want to use
> > the repositories (isn't that what you were trying to tell me about
> > how upstream can use git?) and I'm pretty sure that dropping the epoch
> > will be annoying to someone at some point. And the cost of not dropping
> > the epoch is not very high.

Yes, absolutely.  I think this got kind of derailed through failing to
understand (and answer) the very simple question I asked.

When I asked "Why include the epoch in tags at all?", that was not some
politically correct euphemism for the statement "I object to including
them" (which I certainly do not), it was an actual question.

If the answer to that is simply "it's relatively harmless, has minimal
cost, some things already do it, and it may be a useful visual cue to
human users, and that's all", then that's a perfectly good reason.

If the answer is instead something like "I want automated tools to be
able to assume they can perfectly reverse the mangling and assume some
semantic meaning to the text in the tag", then we're into Broken By
Design territory and we really need to look more closely at *exactly*
what it is that people want to do and/or assume, and we probably need
to look at less fragile solutions that really do satisfy that need.
But we can't suggest things for that without some clear statements of
what exactly are the use cases people have in mind.


I'm never a fan of discarding information unless you're certain you
won't ever need it back.  But information that you can't trust is
always a mixed blessing, and epochs themselves bring their own extra
caveats too.  I was hoping to get people to think about this in a
bit more detail than they'd already appeared to and have a sensible
discussion to enumerate the pros and cons, and possibly any warnings
we ought to explicitly offer about this.  Having people dig trenches
for a simplistic "for or against" war isn't really going to solve
anything, or advance us to anything better than what we already have.


> I fully agree.  Please, lets just keep the epoch which is the safer design
> choice anyway, and get done with it.

Henrique, would you care to elaborate on your definition of "safer"?
I already pointed out some ways it's not.  A well reasoned middle
ground might let us offer people some actually useful advice about
this in a way that "just bury your head in the sand and pretend
everything is ok" would not.


> Also, we have a fully reversible, human-friendly mapping to deal with

Unless you really do something crazy, like URL encoding (which I don't
think we should do, the cost to humans is way higher than the benefit
to machines, and tags *are* for the benefit of humans), the manglings
to the allowed ref names have never been guaranteed to be reversible,
and we have a decade worth of existing practice where they definitely
were not.

They still aren't guaranteed to be so even with this convention,
because there's no hard guarantee that everyone or everything will
use them.  And even if they did, I still don't think you've covered
every combination of things that are illegal in a git refname which
might need to be mangled here.

The really crazy cases might be rare, but just because you've never
hit them doesn't mean they can't or won't ever exist in a way that
means someone one day will need to deal with them.  Why paint those
people into a corner when there are fairly easy ways to not do that?


> Whether the upstram version string is compatible or not with the Debian
> version namespace and the Debian git-tag version namespace is a non-problem:
> the upstream version WILL have been reduced to something compatible to be
> usable for the package version in debian/changelog already, anyway.
> 
> Therefore, there is no space for ambiguity here. % and _ are *illegal* in
> the Debian version namespace, so they can be freely used to translate from
> the Debian version namespace to the Debian version git-tag namespace.
> 
> And anything that compares the upstream version namespace and the Debian
> version namespace directly (or via their git-tag namespaces) is Utterly
> Broken in the general case anyway, even if it will often just work
> (particular case).

Anything that assumes you can always determine the exact release version
from a tag name is Utterly Broken in the general case too.

I don't think conflating these things