Re: dist-upgrade strangeness: dependencies not deconfigured

[Norbert Preining]

Hi Steve,

thanks for the answer.

On Tue, 25 Mar 2014, Steve Langasek wrote:
> I think your root cause analysis is wrong.  If you want help understanding
> why your dist-upgrade didn't work, you should show the output of the actual
> apt command.

Which is very very long, unfortunately.

> What you're showing here is a snapshot at some point in the middle of an
> upgrade, when texlive-common has been removed (because the package no longer
> exists, and the new texlive-base conflicts with it) and texlive-base has not
> yet been upgraded.  It's legitimate to do this during an upgrade; in fact,
> normally the very next step is for apt to unpack the new version of
> texlive-base which had declared the Conflicts: with texlive-common.  But
> something else stopped apt before it got that far.

Yes indeed, a trigger action was called for tex-common, that called
a program that is in texlive-base but needs files from texlive-common.

In the trigger program we already check that texlive base is in proper
state (ii in dpkg listing), but that seems not to be enough.

> For the record, the removal of texlive-common without the deconfiguring of
> texlive-base is because apt will pass --force-depends to dpkg.  It does this

Ok, but that means that in some cases where triggers are involved,
checks for the proper functionality cannot be done by checking
on the status of a package. Is this right?

> itself in a catch-22 on dist-upgrades.  So apt deliberately lets the
> dependencies be broken, with the expectation that it can fix them up again
> afterwards.

But in the meantime triggers are called that might mess up the whole,
right?

To repeat:
in TeX Live 2012:
perl modules are in texlive-common
updmap script is in texlive-base
tex-common trigger on package installs calls updmap when
fonts are installed, before doing this, it checks
whether texlive-base is fully installed and configured (ii).

in TeX Live 2013
perl modules and updmap are in texlive-base
tex-common does the same

the code in tex-common is:
# dpkg-query has two defects wrt not existing packages
# - it is noisy to stderr
# - it returns 1
# so shut both errors up
stat=$(dpkg-query -W -f='${Status}' context 2>/dev/null || true)
case "$stat" in
"install ok installed")
do_it=1
;;
*)
do_it=0
;;
esac


As a consequence I have added
Breaks: texlive-base (<< current-version)
to *all* texlive packages. Doing this upgrade now succeeds.

Is there anything else that can be done?

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
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/20140326064355.gs31...@auth.logic.tuwien.ac.at

Re: dist-upgrade strangeness: dependencies not deconfigured

[Steve Langasek]

On Wed, Mar 26, 2014 at 11:01:24AM +0900, Norbert Preining wrote:
> Dear all,

> during upgrade tests from stable to sid I found that upgrading
> TeX Live does not work.

> The reason is that although texlive-common is uninstalled,
> and texlive-base (2012) *depends* on texlive-common,
> texlive-base is still in installed and proper state:

> un  texlive-common   (no description available)
> ii  texlive-base   2012.2012061 all  TeX Live: Essential programs and 

> Is this *supposed* to be? If yes, how can I guarantee that a package
> is *deconfigured* when some of the dependencies are uninstalled?

I think your root cause analysis is wrong.  If you want help understanding
why your dist-upgrade didn't work, you should show the output of the actual
apt command.

What you're showing here is a snapshot at some point in the middle of an
upgrade, when texlive-common has been removed (because the package no longer
exists, and the new texlive-base conflicts with it) and texlive-base has not
yet been upgraded.  It's legitimate to do this during an upgrade; in fact,
normally the very next step is for apt to unpack the new version of
texlive-base which had declared the Conflicts: with texlive-common.  But
something else stopped apt before it got that far.

For the record, the removal of texlive-common without the deconfiguring of
texlive-base is because apt will pass --force-depends to dpkg.  It does this
because in various scenarios, dpkg when left to its own devices can find
itself in a catch-22 on dist-upgrades.  So apt deliberately lets the
dependencies be broken, with the expectation that it can fix them up again
afterwards.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: ca-certificates: no more cacert.org certificates?!?

[Dmitry Smirnov]

On Tue, 25 Mar 2014 15:29:12 Marc Haber wrote:
>  wrote:
> >I just want to note that Startcom is no match to cacert.org in regards to
> >free SSL certificates. Some years ago I got free certificate from Startcom
> >but a year later Startcom refused to renew it for free.
> 
> They renew their certificates only in the last (two?) weeks of the
> lifetime. You cannot renew them ad your convenience, you have to do it
> at theirs.

It had nothing to do with timing. I got usual email notice "renew your 
certificate before it expire", submitted renewal request and got "Certificate 
Declined" response. When I asked why they explained that "Class 1 certificates 
are not meant to be used for e-commerce" despite that it was not a problem 
when they issued original certificate one year prior to that. They refused to 
renew certificate in January 2011 so my guess is that they've changed their 
policy some time in 2010...

-- 
All the best,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


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

dist-upgrade strangeness: dependencies not deconfigured

[Norbert Preining]

Dear all,

during upgrade tests from stable to sid I found that upgrading
TeX Live does not work.

The reason is that although texlive-common is uninstalled,
and texlive-base (2012) *depends* on texlive-common,
texlive-base is still in installed and proper state:

un  texlive-common   (no description available)
ii  texlive-base   2012.2012061 all  TeX Live: Essential programs and 

Is this *supposed* to be? If yes, how can I guarantee that a package
is *deconfigured* when some of the dependencies are uninstalled?

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13



-- 
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/20140326020124.gr31...@auth.logic.tuwien.ac.at

Re: jquery debate with upstream

[Paul Wise]

On Wed, Mar 26, 2014 at 6:16 AM, Philipp Kern wrote:

> To be honest I'd rather like to see a "ruling" which is codified in a policy
> than random guesswork we do on -devel from observing FTP masters' actions.
> This is not Mao.

Figuring out what the source is and where it is can be hard, even for
code. For example, xserver-xorg-video-nv was in Debian for 3 months
before #383465 was filed and the code was in xserver-xfree86 for a
couple of releases before that.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6HTa5OELZVLgQVDhmS=qvo8wuyyruu22a4waxj_jqd...@mail.gmail.com

Re: jquery debate with upstream

[Paul Tagliamonte]

On Tue, Mar 25, 2014 at 11:16:12PM +0100, Philipp Kern wrote:
> To be honest I'd rather like to see a "ruling" which is codified in
> a policy than random guesswork we do on -devel from observing FTP
> masters' actions. This is not Mao.

There was an ftpteam meeting last week, and this was discussed. I think
there was internal consensus and the team is midway through drafting a
statement.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte   |   Proud Debian Developer
: :'  : 4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
`. `'`  http://people.debian.org/~paultag
 `- http://people.debian.org/~paultag/conduct-statement.txt


signature.asc
Description: Digital signature

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Kevin Chadwick]

previously on this list Brett Parker contributed:

> Maybe you should do some more investigation, get some better clue of
> what you're talking about, and come back with a better, more thought
> out, set of arguments that actually have merit.

Right, by arguing on the basis of the definition of Linux rather than
the meaning of his arguments, or as often is the case on this
subject dividing and conquering or ignoring the valid points and
changing the subject to the 100th *needed* functionality that every
system apparently should have by default but actually turns out to
already exist but optionally installed and actually means little or
just gets in the way of better implementations.

There is another reason why Unix consisting of parts that do one thing
well is so valuable and that is because arguing over the best way of
doing it can't be polluted or crap forced in the back door with the
good.

Your response is actually closer to trolling.

Why is it the the word troll gets so abused. Naming people trolls when
they are not is worse than trolling in my opinion.

I really haven't the time right now to look over the links having took
a break from work to watch a footy match but assuming I didn't miss the
sarcasm then if Thorsten Glazer sees even an ounce of merit then I can
almost guarantee he is not trolling.


p.s. systemd being a bad design for an OS which aims to be so cross
platform is simply obvious to me on many levels, at the very least it
calls for extra oil/work/code depending on the scenario to meet that aim
and with little/no *real/truly beneficial* reason.

Still maybe it will be the death of Linux on the desktop atleast for
techies and I wouldn't mind to be honest as without grsecurity the linux
*kernel* actually has less security features than Windows or even
FreeBSD now and FreeBSD was trailing behind for a long time. The
userland security is much better than windows but with the exception
of apt repos being the only well used thing that springs to mind (which
is a valuable security feature) this was basically inherited from good
designers.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/815696.92264...@smtp145.mail.ir2.yahoo.com

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Cameron Norman]

El Tue, 25 de Mar 2014 a las 3:11 PM, Cameron Norman 
 escribió:
See the documentation for the following if they are not familiar to 
you:
* dependencies: Wants/WantedBy, Requires/RequiredBy (in 
man::systemd.unit)
* states: ConditionFileExists, ConditionFileExecutable, Condition* 
(probably in man::systemd.service)
* events: man::systemd.device, man::systemd.socket, 
Alias=dbus-org.foo.bar.service (in man::systemd.install)

* chronology: Before, After (probably in man::systemd.service)



Sorry, pretty much all of that except the device and socket stuff is in 
systemd.unit.

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Cameron Norman]

El Mon, 24 de Mar 2014 a las 9:42 AM, Kevin Toppins 
 escribió:

To all debian developers:


-> systemd is *fundamentally incompatible* with linux


Now, I realize that's a bold claim, but if you are up for some 
reading, I will prove it.




I'll bite.


I even went to Lennart Poettering's google+ page and 

 -> tried to warn everyone there that systemd was headed for failure

 -> asked *Poettering* (in a different way) if he *could answer* what 
role systemd was to serve in linux



I said -> I have a question for you. If you can answer it with one, 
and ONLY one, concept that describes fully what systemd is I will 
consider I might have misjudged this.


He replied...

 -> systemd is a suite of basic building blocks to build an OS from



Maybe he was talking about the systemd project as a whole. systemd's 
source tree includes a number of different pieces of software, from 
udev to networkd. They are the basic building blocks. I will talk about 
systemd, the init system, specifically. This includes the journal 
(because it is mandatory and cannot be used without systemd) and the 
systemd binary, but not logind, udev, or anything else.


systemd starts, supervises, controls, and stops software according to 
dependencies, state, events, and chronology.


* start: simple execution, with optional environment and pre-created 
sockets. Decides to start when certain events occur (including device, 
socket, and bus events) or it is wanted by a starting unit, its own 
wants and dependencies are satisfied, its own conditions are true, and 
the "moment is right" (chronology is correct).

* supervise: monitors the process and optionally restarts it on failure.
* control: allows resource limits with cgroups, oom, nice, rlimit, and 
probably more. Hooks up its stdin/out/err.
* stop: stops the process and, optionally, that process's children 
(uses cgroups for this).


See the documentation for the following if they are not familiar to you:
* dependencies: Wants/WantedBy, Requires/RequiredBy (in 
man::systemd.unit)
* states: ConditionFileExists, ConditionFileExecutable, Condition* 
(probably in man::systemd.service)
* events: man::systemd.device, man::systemd.socket, 
Alias=dbus-org.foo.bar.service (in man::systemd.install)

* chronology: Before, After (probably in man::systemd.service)

I have heard you question why systemd recommends daemons to not 
fork/double fork. This is a pretty simple answer: it is costly and 
unnecessary, and systemd has less. To fork or daemonize is needless 
computation power that systemd does not require to be notified of the 
process's readiness. Furthermore, this makes it harder to supervise 
(track the PID and collect the stdout/err) the process. Lastly, it is a 
fair bit of unnecessary code on the daemon's part.


Any other questions?
--
Cameron Norman

Re: jquery debate with upstream

[Philipp Kern]

On 2014-03-24 17:23, Thorsten Glaser wrote:

I don’t have the source of it at hand (and IANAftpmaster), but
right now, the answer is NO because the promise of the DFSG and
surrounding documents also extends to not just the source pak-
kages but also the distfiles (*.orig.tar.*) isolated. Basically,
it extends to every single file in the distribution.


I wouldn't be surprised if that would make a bunch of packages RC-buggy.

(Well, I have one. I was tempted to upload another tarball with some 
source files which might happen to be usable to regenerate some files if 
you have the right non-free tools. But then figured that everyone 
interested in that will just look up the sources on the upstream website 
instead. In the end the developers want to get their job done and 
release something free. Also those files are not code, but resources. 
Some might classify a minified jquery similar, though.)


To be honest I'd rather like to see a "ruling" which is codified in a 
policy than random guesswork we do on -devel from observing FTP masters' 
actions. This is not Mao.


Kind regards
Philipp Kern


--
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/06e99434f56c4eaf224d712bd4cb1...@hub.kern.lc

Re: FTPMaster position statement about package contents

[Joerg Jaspert]

On 13526 March 1977, Ming-ting Wei wrote:
> Distributing pornography in academic network in Taiwan seems like a gray
> area. http://edu.law.moe.gov.tw/EngLawContent.aspx?Type=E&id=2

Nice for them, but thats a minority.

> If it can be distributed from a separate repo it should be fine, but I also
> wonder how many mirrors are under the place where pornography is not
> allowed to distribute.

Too many to count. We dont want it, not even in an own repo (provided by
us, other people are free to do as they like).

-- 
bye, Joerg
Kill my boss? Do I dare live out the American dream?


-- 
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/87zjke6imf@gkar.ganneff.de

Re: FTPMaster position statement about package contents

[Joerg Jaspert]

On 13525 March 1977, Mathieu Malaterre wrote:
>> If you can answer these questions with a yes or even a maybe - don't
> While I did agree mostly with this. I believe the last sentence should
> be reworded. Because aircrack-ng, crack or rarcrack could 'maybe' harm
> Debian/mirrors or derivatives.
> 'maybe' feels like too broad.

Nope, I disagree.  While you might interpret it this way, the only thing
that will happen is that the maintainer asks FTPMasters (and/or admins)
if its ok to upload/push to a VCS.

-- 
bye, Joerg
I think there's a world market for about five computers.
 -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943


-- 
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/874n2m7xik@gkar.ganneff.de

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Jonathan Dowland]

On Tue, Mar 25, 2014 at 01:31:44PM -0500, Kevin Toppins wrote:
> Jonathan we've been through this before.
> 
>  -> https://lists.debian.org/debian-devel/2012/11/msg00565.html
> 
>  -> https://lists.debian.org/debian-devel/2012/11/msg00604.html

Thanks for the trip down memory lane. This is not quite the same, I
giving considerably more benefit of the doubt back then, and some honest
advice on how to improve your ability to communicate on this list,
advice which you appear to have sadly ignored.

> You think I'm retarded or a troll.

I didn't think you were a troll back in November.

-- 
Jonathan Dowland


-- 
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/20140325213334.ga2...@bryant.redmars.org

Bug#742639: ITP: python-expyriment -- Python library for cognitive and neuroscientific experiments

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: python-expyriment
  Version : 0.7.0
  Upstream Author : Oliver Lindemann 
* URL : http://www.expyriment.org
* License : GPL-3.0+
  Programming Lang: Python
  Description : Python library for cognitive and neuroscientific experiments

Expyriment is a light-weight Python library for designing and conducting
timing-critical behavioural and neuroimaging experiments. The major goal is
to provide a well-structured Python library for a script-based experiment
development with a high priority on the readability of the resulting
programme code. Due to the availability of an Android runtime environment,
Expyriment is also suitable for the development of experiments running on
tablet PCs or smart-phones.

Filing ITP on behalf of the upstream (Oliver) who is preparing the package.


-- 
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/20140325203503.28619.45453.report...@novo.onerussian.com

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Kevin Toppins]

On Tuesday, March 25, 2014 11:40:02 AM UTC-5, Jonathan Dowland wrote:
> I was very proud of my fellow colleagues for not feeding the troll a
> full 24 hours later. Thanks for breaking the record :(


Jonathan we've been through this before.

 -> https://lists.debian.org/debian-devel/2012/11/msg00565.html

 -> https://lists.debian.org/debian-devel/2012/11/msg00604.html


You think I'm retarded or a troll.

Believe it or not, I can actually sympathize with why you think that.

I too, would find myself to be a huge pain in the ass if I threw a
wrench into something as big as systemd.

I recognize the frustration, I really do.


But I am not trolling you here.


There is something that you fundamentally don't get

 -> if I present a question regarding the interaction of linux and systemd

 -> and you get pissed with me because it's too exhausting or
difficult to formulate a response

 -> that means you don't really understand how the interaction between
linux and systemd works


Yes. That's the point (not to piss you off, but to test what you comprehend).


That's why engineering has the phrase to begin with...

 -> if you can't put it in writing, then you don't understand it well enough


Because it's pissing you off, it's telling me that we have a problem
with the design of systemd.

It's underthought.  Dangerously underthought.


This entire time, my concerns were never about the features of either program.

It was always about the design.

Features don't make good software.good design makes good software.

systemd is its own project (operating system?).  It does not have any
design blueprint for how it works with linux.

That's why you need to pull it out of linux, because it's trashing all
the good designs for crap that we can't even explain very well in
writing.  Which means that we don't really know what this is doing.

And when we don't really understand what something is doing, we are
extremely vulnerable to a symphony of problems waiting to occur.

I would say that trying to resolve the default init system hassle
is one example of a problem that could have been easily avoided if we
had a blueprint for how systemd is designed.

Please try to look past my failings with using lists, and see that we
really do have a nightmare situation on our hands.


-Kev


-- 
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/cadkoaximadsjomvwd1xihlglp3v8utfyb4bqrpa+u0bypz3...@mail.gmail.com

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Milan P. Stanic]

On Tue, 2014-03-25 at 16:15, Jonathan Dowland wrote:
> I was very proud of my fellow colleagues for not feeding the troll a
> full 24 hours later. Thanks for breaking the record :(

I had a hope that the no one will answer OP. :(


-- 
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/20140325173351.ga6...@arvanta.net

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Brett Parker]

On 25 Mar 11:36, Kevin Toppins wrote:
> On 25 March 2014 11:25, William Unruh  wrote:
> [...]
> > And if they are there, together with all the boldfacing, people tend to
> > think that you are a complete kook. So you makes your choices...
> 
> Okay, my apologies.
> 
> I am not very experienced with lists and the expectations that run within 
> them.
> 
> Here is a plaintext version stripped of asterisks.
> 
> I do think the arrows help though.

Weird, I just think they clutter up the place, make the text harder to
read and are annoying as hell...

Also, you keep talking about "linux" as if "linux" is an operating
system in its own right... it's not, it's a kernel.

GNU Linux is the linux kernel + GNU userland, the change to systemd is
mostly just a change to the underlying init, *and* Debian is only
changing the *default* not enforcing you to use it.

Maybe you should do some more investigation, get some better clue of
what you're talking about, and come back with a better, more thought
out, set of arguments that actually have merit.

Thanks,
-- 
Brett Parker


-- 
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/20140325172952.GC4308@miranda

Re: Bug#741930: reportbug: add current init system information

[Michael Biebl]

Am 25.03.2014 17:14, schrieb Russ Allbery:
> Sandro Tosi  writes:
>> On Fri, Mar 21, 2014 at 10:19 PM, Sandro Tosi  wrote:
> 
>>> Ok, I think we need a wider audience - what d-d thinks about it? bonus
>>> points if - in case we come out to add init info to every bug report -
>>> a proper way to retrieve the init running is provided :)
> 
>> could we please stop talking about shell & stuff and concentrate on
>> whether we want the init information in every report or not? thanks :)
> 
> I vote yes, but not in any great detail, just a single line like the
> current information about /bin/sh. 

Nod.

 It is going to at least be potentially
> relevant to any package with an init script plus anything that uses logind
> or the rest of the desktop infrastructure, which is enough packages
> combined that I think it would save effort all around.

I do think it might be useful information, at least during the
transition period. We can always revisit this decision in jessie+X, if
by that time the vast majority is running systemd.


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

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Paul Tagliamonte]

On Tue, Mar 25, 2014 at 04:15:25PM +, Jonathan Dowland wrote:
> I was very proud of my fellow colleagues for not feeding the troll a
> full 24 hours later. Thanks for breaking the record :(

I agree -> I even *told* people on #-devel to not even -> bother
replying -> since I figured no one would *post* to this.



But seriously; is it really this easy to bring the project to a halt?


signature.asc
Description: Digital signature

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Kevin Toppins]

On 25 March 2014 11:25, William Unruh  wrote:
[...]
> And if they are there, together with all the boldfacing, people tend to
> think that you are a complete kook. So you makes your choices...

Okay, my apologies.

I am not very experienced with lists and the expectations that run within them.

Here is a plaintext version stripped of asterisks.

I do think the arrows help though.

-Kev


--

To all debian developers:


-> systemd is fundamentally incompatible with linux


Now, I realize that's a bold claim, but if you are up for some reading, I
will prove it.


First -> a little history just to put this into a context that's easier to
follow


Over a year ago (Nov 2012), I tried to warn you that systemd was a
disaster in progress.

It started out over a discussion about udev, and some of the reasons people
were giving for using systemd seemed to be woefully naive.

I tried to explain this simple point at first, but it became increasingly
evident that -> none of the people who were advocating systemd -> because
they claimed it would solve certain problems -> seemed to understand what
systemd would do to linux

So, I took some of the problems systemd was supposed to fix, and wrote a
response that primarily did three things.


1 -> explain why linux had certain mechanisms, and what would happen if
you removed them

2 -> show how those problems could be solved without stripping out very
important pieces of the architecture (which systemd would do, knowingly or
not)

3 -> the most important one -> probe how much the systemd people really
understood about what they were doing to the rest of linux


Now, I'm sure many people will jump on that last one right there and
declare -> how can you possibly judge what they understand if you don't
understand it yourself?!!


And this is how...


There is a well known saying that runs in every engineering discipline,
including software engineering...

 -> if you can't put it in writing, then you don't understand it well enough

Einstein had another version...

 -> if you can't explain it simply, you don't understand it well enough


So, I presented a series of technical questions, that I asked to be
answered without references for me to go read documentation.

Those questions are not there because I'm clueless as to how systemd
works.

Those questions are there to see if anyone (including systemd people) had
any clue how systemd would interoperate with -> the rest of linux.


And I got my answer.

 -> nope


I even said -> the point of this post was to see if these questions
could be answered -> because if they couldn't -> that was a very strong
signal that they didn't understand it


And I got several responses, many of them saying I was...

 -> ignorant

 -> unhelpful

 -> wasting everyone's time because I didn't read the documentation

 -> weird (lol)

 -> and in some places elsewhere over the internet -> autistic


I even went to Lennart Poettering's google+ page and 

 -> tried to warn everyone there that systemd was headed for failure

 -> asked Poettering (in a different way) if he could answer what role
systemd was to serve in linux


I said -> I have a question for you. If you can answer it with one, and
ONLY one, concept that describes fully what systemd is I will consider I
might have misjudged this.

He replied...

 -> systemd is a suite of basic building blocks to build an OS from


Okay -> right there he gives two important pieces of information...

1 -> there is nothing about how it works with linux

2 -> his answer is so vague, it should tell you he hasn't really thought
this out


systemd will wreck linux, I am certain of it.



Without some kind of design blueprint of some sort -> systemd ended up
being built by programming blindly in the dark.

There is no boundary where systemd stops and linux begins.

They will keep on absorbing pieces of linux until systemd is the entire
operating system -> and there is no coherent design to how it does / should
work.


I think everyone here knows how this is going to end.


I tried to get this point across back in Nov 2012 -> however, I don't think
systemd caused enough chaos back then to really register with people what
was coming their way.

Now that systemd has wrecked all kinds of previously working stuff, and
many are beginning to realize the impossibility of getting systemd to
work with linux -> I think this might have some effect this time around.


  -> Debian needs to cut all ties to systemd


It is not possible to save it unless a design blueprint for how it
works with linux can be expressed in writing -> and I seriously doubt
anyone can (I sure as hell can't).

 -> revert every program systemd took over to its pre-systemd state

 -> cut your losses while you still can technically achieve a reversion


While systemd might one day work flawlessly on its own -> it has
absolutely no business being in linux.


And you might ask -> why did I put this

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Federico Di Gregorio]

On 25/03/2014 16:46, Kevin Toppins wrote:
> On 25 March 2014 08:54, Federico Di Gregorio  wrote:
> [...]
>> > Lots of asterisks won't make a point.
> The asterisks are there to specifically focus your attention on those words.
> 
> Because -> I find that if I don't use them -> people tend to misread
> what I write (or more so at least)

You're missing the *point* of my reply.

federico

p.s. I know, I know, "don't feed ..."
But sometimes one just can't resist.

-- 
Federico Di Gregorio federico.digrego...@dndg.it
Di Nunzio & Di Gregorio srl   http://dndg.it
  Qu'est ce que la folie? Juste un sentiment de liberté si
   fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra


-- 
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/5331ac72.6050...@dndg.it

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Jonathan Dowland]

I was very proud of my fellow colleagues for not feeding the troll a
full 24 hours later. Thanks for breaking the record :(


-- 
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/20140325161525.ga25...@bryant.redmars.org

Re: Bug#741930: reportbug: add current init system information

[Russ Allbery]

Sandro Tosi  writes:
> On Fri, Mar 21, 2014 at 10:19 PM, Sandro Tosi  wrote:

>> Ok, I think we need a wider audience - what d-d thinks about it? bonus
>> points if - in case we come out to add init info to every bug report -
>> a proper way to retrieve the init running is provided :)

> could we please stop talking about shell & stuff and concentrate on
> whether we want the init information in every report or not? thanks :)

I vote yes, but not in any great detail, just a single line like the
current information about /bin/sh.  It is going to at least be potentially
relevant to any package with an init script plus anything that uses logind
or the rest of the desktop infrastructure, which is enough packages
combined that I think it would save effort all around.

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


-- 
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/87fvm69rwk@windlord.stanford.edu

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Kevin Toppins]

On 25 March 2014 08:54, Federico Di Gregorio  wrote:
[...]
> Lots of asterisks won't make a point.

The asterisks are there to specifically focus your attention on those words.

Because -> I find that if I don't use them -> people tend to misread
what I write (or more so at least)

-Kev


-- 
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/cadkoaxjot59abrb-+ihutqf6g8e8mdto5n3vcbwf9zuxzh6...@mail.gmail.com

Re: Bug#741930: reportbug: add current init system information

[Sandro Tosi]

On Fri, Mar 21, 2014 at 10:19 PM, Sandro Tosi  wrote:
> Ok, I think we need a wider audience - what d-d thinks about it? bonus
> points if - in case we come out to add init info to every bug report -
> a proper way to retrieve the init running is provided :)

could we please stop talking about shell & stuff and concentrate on
whether we want the init information in every report or not? thanks :)

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


-- 
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/CAB4XWXynG0Y7omhiN=mb+gwckfb8jevjr3ijkgzv6x-x0ho...@mail.gmail.com

Re: ca-certificates: no more cacert.org certificates?!?

[Cyril Brulebois]

Marc Haber  (2014-03-25):
> They renew their certificates only in the last (two?) weeks of the
> lifetime.

Correct, two weeks.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: ca-certificates: no more cacert.org certificates?!?

[Marc Haber]

On Mon, 24 Mar 2014 12:22:53 +1100, Dmitry Smirnov
 wrote:
>I just want to note that Startcom is no match to cacert.org in regards to free 
>SSL certificates. Some years ago I got free certificate from Startcom but a 
>year later Startcom refused to renew it for free.

They renew their certificates only in the last (two?) weeks of the
lifetime. You cannot renew them ad your convenience, you have to do it
at theirs.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
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/e1wsslo-0008mk...@swivel.zugschlus.de

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Federico Di Gregorio]

On 24/03/2014 17:42, Kevin Toppins wrote:
> To all debian developers:
[snip]
> -Kev

Lots of asterisks won't make a point.

federico

-- 
Federico Di Gregorio federico.digrego...@dndg.it
Di Nunzio & Di Gregorio srl   http://dndg.it
 If nobody understand you, that doesn't mean you're an artist.
-- anonymous


-- 
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/53318aa0.3000...@dndg.it

Bug#742613: ITP: ocaml-ctypes -- library for binding to C libraries using pure OCaml

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: ocaml-ctypes
  Version : 0.2.3
  Upstream Author : Jeremy Yallop
* URL : https://github.com/ocamllabs/ocaml-ctypes
* License : Expat
  Programming Lang: C, OCaml
  Description : library for binding to C libraries using pure OCaml

 The ocaml-ctypes library makes it possible to call C functions
 directly from OCaml without writing or generating C code.  The core
 of the library is a set of combinators for describing C types --
 scalars, functions, structs, unions, arrays, and pointers to values
 and functions.  Type descriptions can then be used to bind native
 functions and values.


-- 
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/20140325135918.28645.16598.report...@wencory.loria.fr

Re: [cjwatson debian.org: Accepted grub2 2.02~beta2-7 (source i386)]

[Raphael Hertzog]

Hi,

On Tue, 25 Mar 2014, Thorsten Glaser wrote:
> On the other hand, porters are often packagers, and many packagers are
> much more familiar with cowbuilder or pbuilder as it’s *much* simpler
> to set up, and also provides good isolation.

How so? With sbuild-createchroot, sbuild is really simple to setup.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ 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/20140325140737.gb3...@x230-buxy.home.ouaza.com

Re: [cjwatson debian.org: Accepted grub2 2.02~beta2-7 (source i386)]

[Thorsten Glaser]

Simon McVittie  debian.org> writes:

> (I would recommend that porters doing manual builds use sbuild if at all
> possible, though, to be as close as possible to what a buildd would have
> done.)

On the other hand, porters are often packagers, and many packagers are
much more familiar with cowbuilder or pbuilder as it’s *much* simpler
to set up, and also provides good isolation.

The chroots themselves are mostly identical – especially if the
pbuilder-satisfydepends-apt patch will be applied by the maintainer,
please, to get rid of aptitude. (There’s pbuilder-satisfydepends-classic
which also does not use aptitude, but is slower. But useful for when
aptitude is not installable for some time.)


Porter uploads are usually done when the archive is in a state such
that buildds cannot work. In these states, getting sbuild and schroot
to work is virtually impossible; see their build- and runtime dependencies
for why. Especially Boost is… not a nice thing.

Just food for thought.

bye,
//mirabilos


-- 
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/loom.20140325t142205-...@post.gmane.org

Re: systemd and Linux are *fundamentally incompatible* -> and I can prove it

[Thorsten Glaser]

On Mon, 24 Mar 2014, Kevin Toppins wrote:

>   -> Debian needs to *cut all ties* to systemd
[…]
>  -> revert every program systemd took over to its pre-systemd state
> 
>  -> cut your losses while you still can technically achieve a reversion

Seconded (especially the last bullet point).

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
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/alpine.deb.2.10.1403251418120.3...@tglase.lan.tarent.de

Re: Bug#741930: reportbug: add current init system information

[brian m. carlson]

On Tue, Mar 25, 2014 at 08:12:06AM +0100, Thomas Weber wrote:
> The fact that a lot of people use a variety of shells does not mean that
> it makes sense to include it in *every* bug report. How important is the
> user's shell for every database-, web- or fileserver? How for every office
> application? How important is it for requests to the release team?
> Every single bug report for these (pseudo)packages will include this
> information, so it better be important.

As Russ pointed out, it's one line.  My suggestion was to avoid people
wasting time troubleshooting when a small bit of information might help.
I know that I prefer having a little extra information than not enough
when trying to fix a bug.

> > It's much better to have this information up front than to have to guess
> > about it, especially since many reporters won't think to mention it.
>
> If you know that your package might break by using a certain shell, you
> can use reportbug's scripts.

I don't think the maintainers even considered whether debconf would be
broken under zsh.  I certainly didn't think it would be, or I wouldn't
have set zsh as /bin/sh.

Also, it doesn't make sense to make hundreds of packages duplicate the
same (or worse, slightly different and potentially subtly broken) code,
when it could be in one single place.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Glom DEBIAN packaging

[Oscar Tark]

Thank you for the suggesions

-- Forwarded message --
From: Oscar Tark 
Date: 2014-03-21 19:04 GMT+01:00
Subject: Glom DEBIAN packaging
To: debian-devel@lists.debian.org


Hello,

I am having problems building the glom debian .deb package so that we may
easily install glom on all our computer's I have followed all the rules
here https://wiki.debian.org/IntroDebianPackaging but at step 4 after
starting the command "$ *debuild* -us -uc"I get an error:

configure: exit 127
dh_auto_configure: ./configure --build=i686-linux-gnu --prefix=/usr
--includedir=${prefix}/include --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--libdir=${prefix}/lib/i386-linux-gnu
--libexecdir=${prefix}/lib/i386-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking returned exit code 127
make: *** [build] Error 255
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Thanks for the help in advance!

Bug#742599: ITP: python-termstyle -- console colouring for python

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-termstyle
  Version : 0.1.10
  Upstream Author : Tim Cuthbertson 
* URL : http://gfxmonk.net/dist/0install/python-termstyle.xml
* License : BSD-3-clause
  Programming Lang: Python
  Description : console colouring for python

 Termstyle is a simple python library for adding coloured output to terminal
 (console) programs. The definitions come from ECMA-048, the "Control Functions
 for Coded Character Sets" standard.

Note: This package is needed by python-rednose (I've just opened an ITP for
it), rednose is needed by python-sure, sure is needed by httpretty, and
finally, httpretty is needed by python-keystoneclient (the OpenStack auth
client).


-- 
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/20140325102858.12618.6516.report...@buzig.gplhost.com

Bug#742597: ITP: casperjs -- a navigation scripting & testing utility for PhantomJS and SlimerJS written in Javascript

[Xavier Claude]

Package: wnpp
Severity: wishlist
Owner: Xavier Claude 

* Package name: casperjs
  Version : 1.0.4
  Upstream Author : Nicolas Perriault 
* URL : http://casperjs.org/
* License : MIT
  Programming Lang: JavaScript, Python
  Description : a navigation scripting & testing utility for PhantomJS and
SlimerJS written in Javascript


-- 
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/20140325101726.17706.56442.report...@ambiorix.office.conostix.com

Re: ca-certificates: no more cacert.org certificates?!?

[Raphael Geissert]

Edward Allcutt wrote:
>>> Le 24/03/2014 14:23, Raphael Geissert a écrit :
 If only people actually used DNSSEC and DANE - Chromium/Google Chrome
 dropped support for the latter due to the lack of use[1].

 [1]https://www.imperialviolet.org/2011/06/16/dnssecchrome.html
> 
> I believe you are mistaken. That blog post is about Google's own design
> for "DNSSEC stapled certificates" . Not DANE.

Yes, my bad. The actual reference for DANE is:
https://www.imperialviolet.org/2012/10/20/dane-stapled-certificates.html

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


-- 
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/lgrjvk$bvb$1...@ger.gmane.org

Bug#742593: ITP: wcslib-contrib -- Draw and label curvilinear coordinate grids with pgplot

[Ole Streicher]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
X-Debbugs-CC: debian-as...@lists.debian.org
X-Debbugs-CC: debian-scie...@lists.debian.org

* Package name: wcslib-contrib
  Version : 4.21
  Upstream Author : Mark Calabretta 
* URL : http://www.atnf.csiro.au/people/mcalabre/WCS/
* License : LGPL-3
  Programming Lang: C, Fortran
  Description : Draw and label curvilinear coordinate grids with pgplot

 This package builds the parts of wcslib that need pgplot5 to compile
 and therefore cannot be put into main: libpgsbox and the wcsgrid tool.
 .
 WCSLIB is a C library, supplied with a full set of Fortran wrappers,
 that implements the "World Coordinate System" (WCS) standard in FITS
 (Flexible Image Transport System).
 .
 The FITS data format is widely used within the international
 astronomical community, from the radio to gamma-ray regimes, for data
 interchange and archive, and also increasingly as an online format.


-- 
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/53315172.8040...@liska.ath.cx

Bug#742540: general: Get the "Oh no!" message after moving the top menu bar to the left side of then screen

[Josselin Mouette]

reassign 742540 gnome-panel
thanks

Le lundi 24 mars 2014 à 16:22 -0500, Lowell a écrit : 
> After moving the top menu bar to the left side of the screen I am forced to
> logout, and then on every login I am forced to logout.
> If I knew which config files to edit I could login as another user and repair
> the problem.
> 
> This install is in a VirtualBox, and the gnomes is in fallback mode. I don't
> know what else might help reproduce this bug.

This is most probably caused by a crash in gnome-panel itself.

You can reset it to its previous behavior using dconf, but the
interesting part would be a stack trace.

Thanks,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1395737883.21499.1827.camel@dsp0698014

Processed: Re: Bug#742540: general: Get the "Oh no!" message after moving the top menu bar to the left side of then screen

[Debian Bug Tracking System]

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

> reassign 742540 gnome-panel
Bug #742540 [general] general: Get the "Oh no!" message after moving the top 
menu bar to the left side of then screen
Bug reassigned from package 'general' to 'gnome-panel'.
Ignoring request to alter found versions of bug #742540 to the same values 
previously set
Ignoring request to alter fixed versions of bug #742540 to the same values 
previously set
> thanks
Stopping processing here.

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


--
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/handler.s.c.139573788921740.transcr...@bugs.debian.org

Bug#742586: ITP: python-rednose -- coloured output for nosetests

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-rednose
  Version : 0.4.1
  Upstream Author : Tim Cuthbertson 
* URL : http://gfxmonk.net/dist/0install/rednose.xml
* License : BSD-3-clause
  Programming Lang: Python
  Description : coloured output for nosetests

 rednose is a nosetests plugin for adding colour (and readability) to nosetest
 console results. Rednose by default uses auto-colouring, which will only use
 colour if you're running it on a terminal (i.e not piping it to a file).


-- 
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/20140325081940.8538.46256.report...@buzig.gplhost.com

Re: Bug#741930: reportbug: add current init system information

[Russ Allbery]

Thomas Weber  writes:

> The fact that a lot of people use a variety of shells does not mean that
> it makes sense to include it in *every* bug report. How important is the
> user's shell for every database-, web- or fileserver? How for every
> office application? How important is it for requests to the release
> team?  Every single bug report for these (pseudo)packages will include
> this information, so it better be important.

It's potentially important for any bug report involving a package
containing a shell script, if the bug report involves that shell script,
which is hard to determine in advance.  There are shell scripts in just
about every package we have, given that many packages contain maintainer
scripts.  It's also a single line in the bug report, so I'm having a hard
time understanding why people think it's important enough to even debate.

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


-- 
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/8761n2pvy2@windlord.stanford.edu

Re: Bug#741930: reportbug: add current init system information

[Thomas Weber]

On Sun, Mar 23, 2014 at 05:03:00PM +, brian m. carlson wrote:
> On Sun, Mar 23, 2014 at 08:41:48AM +0100, Thomas Weber wrote:
> > And while we are at it, do we *really* need the information about
> > /bin/sh in at least a significant share of today's bug reports?
> 
> You probably want it, because a decent number of people use a shell
> other than bash or dash as /bin/sh.  For example, one might use
> mksh-static because it's statically linked.  Also, someone might try to
> use zsh as /bin/sh, which doesn't work (it breaks debconf).

The fact that a lot of people use a variety of shells does not mean that
it makes sense to include it in *every* bug report. How important is the
user's shell for every database-, web- or fileserver? How for every office
application? How important is it for requests to the release team?
Every single bug report for these (pseudo)packages will include this
information, so it better be important.
 
> It's much better to have this information up front than to have to guess
> about it, especially since many reporters won't think to mention it.

If you know that your package might break by using a certain shell, you
can use reportbug's scripts. 

Thomas


-- 
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/20140325071206.GA17855@t61

Re: ca-certificates: no more cacert.org certificates?!?

[Peter Palfrader]

On Tue, 25 Mar 2014, Wouter Verhelst wrote:

> > > Lack of use? No kidding. TLSA RRs have been promoted to IETF proposed
> > > standard in August 2012[1]. And DNS servers haven't support for them
> > > since recently (I'd say 6 months to 1 year).
> > 
> > DNS servers have supported them for years;  RFC3597 is over a decade old
> > by now.
> 
> RFC3597 does not specify TLSA records, it only specifies how DNS servers 
> should
> handle RRs with unknown (to them) RDATA format. It is essential to allow new
> features to be propagated over the DNS network, but it does not necessarily
> implement TLSA at the signing zone -- and that, apart from widespread
> user agent support, is a pretty critical prerequisite for actually
> starting to use DANE.

The claim was that DNS servers didn't support it.  All you need is
RFC3597 support to add TLSA records to your zone.

e.g.:
} _443._tcp.www.debian.org. IN TYPE52 \# 35 
03010124b4287bf05f884f844373ac21f5afd3f74a31881c907c1e2712248e7ade9ab1

-- 
   |  .''`.   ** Debian **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
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/20140325065627.gt1...@anguilla.noreply.org