Bug#770915: ITP: utox -- uTox is a lightweight audio/video chat client based on the secure tox protocol.

[gaffa]

Package: wnpp
Severity: wishlist
Owner: gaffa 

* Package name: utox
  Version : 0+git20141121
  Upstream Author : notsecure
* URL : https://github.com/notsecure/uTox/
* License : GPL-3
  Programming Lang: C
  Description : uTox is a lightweight audio/video chat client based on the 
secure tox protocol.

Tox is a free P2P audio/video protocol that requires no configuration. Using 
torrent-style DHT, peers can find the IP of other peers by using their Tox ID. 
Once the IP is obtained, peers can initiate a secure connection with each 
other and exchange messages, send files, start video chats, etc. using 
encrypted communications.

I have already created a package for the version mentioned above. There are
no official source tarballs and no version tags on the VCS.

This package depends on libtoxcore. I've packaged libtoxcore and is currently
waiting for replies to the ITP bug report, before I request a sponsor.

The package is uploaded to mentors.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/20141125081853.19678.78272.reportbug@einstein.einstein

enforced systemd services (was: Misc Developer News (#37))

[Arturo Borrero Gonzalez]

On 25 November 2014 at 02:22, Paul Wise  wrote:
>
> Making packages secure with systemd service files
> -
>
>  Packagers of Debian software, who are needing to create systemd service
>  files would benefit from learning from Lennart Poettering's recent
>  presentation (video[12], slides[13]) detailing various security features you
>  can enable in your package's service files. Many of these features are
>  simple to add, and would greatly enhance the overall security of Debian.
>
> -- Joe Hill
>
>  [12] 
> http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm
>  [13] http://0pointer.net/public/systemd-nluug-2014.pdf
>

This seems pretty interesting.

Is there a Debian-specific policy on how to apply these directives?

-- 
Arturo Borrero González


--
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/caoksjbifytdnatwsaxu+ss-_cgbr+og5hwfoc0pphgmmcp8...@mail.gmail.com

Re: enforced systemd services (was: Misc Developer News (#37))

[Marc Haber]

On Tue, 25 Nov 2014 10:04:06 +0100, Arturo Borrero Gonzalez
 wrote:
>On 25 November 2014 at 02:22, Paul Wise  wrote:
>>
>> Making packages secure with systemd service files
>> -
>>
>>  Packagers of Debian software, who are needing to create systemd service
>>  files would benefit from learning from Lennart Poettering's recent
>>  presentation (video[12], slides[13]) detailing various security features you
>>  can enable in your package's service files. Many of these features are
>>  simple to add, and would greatly enhance the overall security of Debian.
>>
>> -- Joe Hill
>>
>>  [12] 
>> http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm
>>  [13] http://0pointer.net/public/systemd-nluug-2014.pdf
>>
>
>This seems pretty interesting.

Indeed. Do we really have to pull that from a video or presentation
slides? Is this part of the official systemd docs anywhere?

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/e1xtcpt-0003oe...@swivel.zugschlus.de

Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2

[Anthony F McInerney]

I noticed that my last mail about 766187 being related to 768657
didn't actually go to the bug report. (which was about this bug being
related)
Anyway, both of these bugs seem to be about providing /etc/inittab in
one form or another.
Please see KiBi's last entry about providing it via D-I which has gone
unanswered.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768657
I'm only sharing this as it would appear there are two separate
conversations happening about the same problem. (and i'm assuming that
a solution should / would solve both)


-- 
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/calokicp+a_4ho0o7efvxjk4qvujtjlwvttzatgs2ok1ov6p...@mail.gmail.com

Re: enforced systemd services (was: Misc Developer News (#37))

[Toni Mueller]

Hi Marc,

On Tue, Nov 25, 2014 at 10:54:39AM +0100, Marc Haber wrote:
> On Tue, 25 Nov 2014 10:04:06 +0100, Arturo Borrero Gonzalez 
>  wrote:
> >On 25 November 2014 at 02:22, Paul Wise  wrote:
> >>  [13] http://0pointer.net/public/systemd-nluug-2014.pdf
> >This seems pretty interesting.
> 
> Indeed. Do we really have to pull that from a video or presentation
> slides? Is this part of the official systemd docs anywhere?

yes, this is in the official docs, somewhere. I had the "pleasure" to
plough through them a few weeks ago.


Kind regards,
--Toni++


-- 
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/20141125103300.ga17...@lappi1.office.oeko.net

Re: enforced systemd services

[Vincent Bernat]

 ❦ 25 novembre 2014 10:54 +0100, Marc Haber  :

>>>  [12] 
>>> http://ftp.nluug.nl/video/nluug/2014-11-20_nj14/zaal-2/5_Lennart_Poettering_-_Systemd.webm
>>>  [13] http://0pointer.net/public/systemd-nluug-2014.pdf
>>>
>>
>>This seems pretty interesting.
>
> Indeed. Do we really have to pull that from a video or presentation
> slides? Is this part of the official systemd docs anywhere?

man systemd.exec
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Age of built packages to be part of the jessie release?

[Dimitri John Ledkov]

On 24 November 2014 at 18:56, Manuel A. Fernandez Montecelo
 wrote:
> 2014-11-23 14:27 Stuart Prescott:
>>
>> Svante Signell wrote:
>>
>>> I wonder how old a package build can be to be part of the release. Some
>>> packages are built up to a year ago, and rebuilding them now FTBFS.
>>
>>
>> As others have noted already, there are period archive rebuilds to check
>> what would now ftbfs.
>>
>> Slightly orthogonal to your question, "up to a year ago" doesn't come
>> close,
>> actually... 42% of source packages in jessie were uploaded over a year
>> ago,
>> 25% over two years ago, 15% over three years ago, 9% over four years ago.
>> Fun fact: there are 64 source packages in jessie that are over 10 years
>> old.
>>
>> Age of source packages in each release:
>>
>> http://ircbots.debian.net/stats/package_ages.png
>>
>> (note: this is based on source package uploads; binNMUs not included)
>
>
> Not nicely backed with hard data as you have here, but from my random
> observations looking at the state of many packages over many years (in BSPs,
> architecture bootstrapping, etc), I reached similar conclusions.
>
>
> Would it make sense to trigger rebuilds (or binNMUs, or actions to the same
> effect) for all packages in a given architecture when there are important
> changes in the toolchain, e.g. the default GCC bumps to a new major version
> [1]?
>
> For me it makes a lot of sense to have most of the archive rebuilt at that
> time,
> and these newly compiled packages migrated at some point to testing to be
> present in the next release.
>
> With the current method it seems that we only check if it FTBFS, and
> packages
> only get recompiled if there are new uploads or binNMUs.  But actually
> recompiling and moving it to the archive will reveal changes in runtime
> behaviour, and thus bugs might be caught/reported/hopefully-fixed sooner.
> In
> some occasions there might even be some bugs fixed (if the compiler of years
> ago
> was buggy) or performance improvements.
>
> I do not know if there are significant drawbacks, for example if it would be
> very taxing to have everything built in a short period of time (especially
> for
> less powerful architectures) -- not only for hardware, but delays to other
> packages who are uploaded at the same time.  Or if there are other
> fundamental
> problems that I did not consider.
>
> In summary, if there's a cheap (esp. in humanpower) way to achieve this, I
> think
> that it would be worth doing it.
>

Part of OBS (open build service) there is a tool called
"build-compare" which does end comparison to see if things are really
different, it does analyse disassembly to see if things are different.
E.g. I've been fiddling with a toolchain and e.g. enabling AVX by
default did show me all binaries that gained / changed their
instructions because of that and build were kept/publish as modified
instead of discarding them as "identical" to previous.

Imho it would make sense to rebuild locally binaries which are the
same since stable, and compare generated maintainer scripts and/or run
the binaries through build-compare to see if there are worthwhile
differences. And if there are, request release team to binNMU those.
(Or do no change uploads, in case of changes in arch:all packages)

-- 
Regards,

Dimitri.


-- 
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/canbhlugh-kovek8hwf1vzemg-a4iyi9dpbjzo-d-nt2xntk...@mail.gmail.com

Re: enforced systemd services

[Bjørn Mork]

Marc Haber  writes:

> Indeed. Do we really have to pull that from a video or presentation
> slides? Is this part of the official systemd docs anywhere?

I don't know of any collection of all security related directives, but
you can find an index of all unit file directives in
systemd.directives(7) with pointers to the man pages where they are
described further. If anyone ever doubted that systemd is bloated with
far too many features, then I do recommend reading systemd.directives(7)
;-)

You'll find the Private* and Protect* directives described in
systemd.exec(5) for a start.

Container services are of course nice features to have, and it is so
elegant to just configure them with a few keywords in a configuration
file. But this mix-it-all-together design does not come for free...


Bjørn


--
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/878uiz8rgg@nemi.mork.no

Re: enforced systemd services (was: Misc Developer News (#37))

[Marco d'Itri]

On Nov 25, Arturo Borrero Gonzalez  wrote:

> Is there a Debian-specific policy on how to apply these directives?
We are working on one, but the general idea is "please enable as many 
security features as feasible". :-)

-- 
ciao,
Marco


pgpfFub5bB57R.pgp
Description: PGP signature

Bug#770945: ITP: libemail-stuffer-perl -- A more casual approach to creating and sending Email:: emails

[Dominique Dumont]

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

* Package name: libemail-stuffer-perl
  Version : 0.009
  Upstream Author : Adam Kennedy , Ricardo SIGNES 

* URL : https://metacpan.org/release/Email-Stuffer
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : A more casual approach to creating and sending Email:: 
emails

The basics should all work, but this module is still subject to name and/or
API changes

Email::Stuffer, as its name suggests, is a fairly casual module used to stuff
things into an email and send them. It is a high-level module designed for
ease of use when doing a very specific common task, but implemented on top of
the light and tolerable Email:: modules.

Email::Stuffer is typically used to build emails and send them in a single
statement, as seen in the synopsis. And it is certain only for use when
creating and sending emails. As such, it contains no email parsing
capability, and little to no modification support.

To re-iterate, this is very much a module for those "slap it together and
fire it off" situations, but that still has enough grunt behind the scenes to
do things properly.

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.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/2832838.gyHz36bd29@ylum

Bug#770948: ITP: bdbvu -- simple GUI tool to browse Berkeley DB databases

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 

* Package name: bdbvu
  Version : 0~svn20100509
  Upstream Author : Ferruccio Barletta 
* URL : https://code.google.com/p/bdbvu/
* License : GPL-3
  Programming Lang: C++
  Description : simple GUI tool to browse Berkeley DB databases

There is no activity on the upstream project lately, but I do not consider it a
problem, because this application is quite small.


-- 
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/20141125131551.21821.31483.report...@konstrukt.pb.local

Re: Technical committee acting in gross violation of the Debian constitution

[Enrico Weigelt, metux IT consult]

On 22.11.2014 02:13, Troy Benjegerdes wrote:

> Someone will find a hole in something, and there will be fire when sysadmins
> have to upgrade in the middle of the night and now are running systemd
> instead of what they are used to.

Well, in that case, I'd say a rain of fire isn't entirely what's going
to happen here ... would be more like a rain of transphasic torpedos ...

I think, the latest decision was really bad. Not because I personally
dont like Lennartware, but because we should leave people the choice.
At lot of people have lots of reasons why they never ever wont let
systemd on their machines, and would even switch whole datacenters
to Gentoo, LFS or BSD, before accepting systemd.

Most of the people I know personally (and that are quite a lot), many
of them traditional *nix operators, integrators, developers from
embedded to enterprise, people who're maintaining missing criticial
systems, large datacenters, etc, give a clear and absolute NO to
systemd. Can't tell how representative that is, but my gutts tell me
Debian will immediately loose 30..50% user base, if systemd becomes
mandatory (or even worse: silently injects it via an upgrade).

That would be desastreos, and directly lead into a fork (in fact,
the preparations for that are already on the way).

I think it would be very wise having a fundamental decision, that:

a) individual (usual) packages do _not_ depend on a specific init
   system (eg. making the systemd-specific stuff has to optional)
b) we will continue to provide the existing alternatives, including
   fresh installation (choosable at installation time, or separate
   installer images)
c) the init system will never be switched w/o _explicit_ order
   by the operator
d) this decision stands until explicitly revoked


cu
--
Enrico Weigelt,
metux IT consulting
+49-151-27565287


-- 
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/547495e0.7040...@gr13.net

Re: Technical committee acting in gross violation of the Debian constitution

[Philip Hands]

"Enrico Weigelt, metux IT consult"  writes:

> On 22.11.2014 02:13, Troy Benjegerdes wrote:

> ... we should leave people the choice.

de·fault (d-fôlt)
n.
  a. /Computer Science/

 A particular setting or value for a variable that is assigned
 automatically by an operating system and remains in effect unless
 canceled or overridden by the operator.

How is it that Debian changing the default for something on some of our
architectures has spawned the rumour that we've travelled back in time
and slaughtered all the ancestors of all the authors of all alternatives
to that default?

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


pgpxF1Sk3lRH0.pgp
Description: PGP signature

Re: Technical committee acting in gross violation of the Debian constitution

[Matthias Urlichs]

Hi,

Enrico Weigelt, metux IT consult:
> people who're maintaining missing criticial systems, large datacenters,
> etc, give a clear and absolute NO to systemd.

Care to tell us why? Other than "ugh, it's written by Lennart"??

> Debian will immediately loose 30..50% user base

Could we PLEASE stop the systemd FUD now?

-- 
-- Matthias Urlichs


-- 
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/20141125160359.gb6...@smurf.noris.de

Re: Technical committee acting in gross violation of the Debian constitution

[Thorsten Glaser]

Matthias Urlichs  urlichs.de> writes:

> Care to tell us why? Other than "ugh, it's written by Lennart"??

The “why” does not matter. Users do not have to justify why they
need to use something. I worked in for company that had a strict
“no PHP” policy once. I have encountered other more or less weird
scenarios in the “enterprise” (bah, this sounds like a four-letter
word) world about having to use something, or do something, despite
it being nōn-free, while otherwise embracing OSS. (We had a case of
someone wanting to put proprietary software they have to use inside
a .deb so it can be easilier managed and integrated well with Debian
and removed cleanly, recently, on some mailing list.)

Let me quote:

 4. Our priorities are our users and free software
We will be guided by the needs of our users and the free software
community. We will place their interests first in our priorities.
We will support the needs of our users for operation in many
different kinds of computing environments. We will not object to
non-free works that are intended to be used on Debian systems, or

So stop this already!

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.20141125t174344-...@post.gmane.org

Re: Technical committee acting in gross violation of the Debian constitution

[Sascha Mester]

I have never really understood the reasons for this discussion.

I am not a system administrator ( at least none of a datacenter - just
for my home infrastructure, containing 3 machines ), and although I also
have a distribution running on one of those ( Arch ) which is using
systemd, I never realized any differences. In fact, if nobody ever told
me that Arch uses systemd - I wouldn't yet know that.

I am sorry if I reanimate any old discussions right now, but:

Can someone tell me the advantages ( and disadvantages ) of systemd ?
I'm about to leave Debian as an user - not because of systemd, but
because of that discussion.

The Debian distribution has actually lost 3 or 4 people. Devs,
TC-Members, ... and as I said in my first phrase, I didn't ever
understand why this discussion exists at all.


Am 25.11.2014 um 17:47 schrieb Thorsten Glaser:
> Matthias Urlichs  urlichs.de> writes:
>
>> Care to tell us why? Other than "ugh, it's written by Lennart"??
> The “why” does not matter. Users do not have to justify why they
> need to use something. I worked in for company that had a strict
> “no PHP” policy once. I have encountered other more or less weird
> scenarios in the “enterprise” (bah, this sounds like a four-letter
> word) world about having to use something, or do something, despite
> it being nōn-free, while otherwise embracing OSS. (We had a case of
> someone wanting to put proprietary software they have to use inside
> a .deb so it can be easilier managed and integrated well with Debian
> and removed cleanly, recently, on some mailing list.)
>
> Let me quote:
>
>  4. Our priorities are our users and free software
> We will be guided by the needs of our users and the free software
> community. We will place their interests first in our priorities.
> We will support the needs of our users for operation in many
> different kinds of computing environments. We will not object to
> non-free works that are intended to be used on Debian systems, or
>
> So stop this already!
>
> bye,
> //mirabilos
>
>




signature.asc
Description: OpenPGP digital signature

please help test proposed patch for bug#668001

[Jonas Smedegaard]

August 8th, Debian began supporting¹ choice among several init systems.
August 21st, Debian changed² default init.

To me, flexibility is an important feature of Debian.  I am excited that 
Debian extends its flexibility to cover several init systems.

Others agree, apparently³: Among those testing our system while this new 
flexibility is in place, ~20% use a non-default init system.

For fresh installs, picking a non-default init requires a workaround: 
First install default init system, then replace with your own choice.  
Remember to also check for and purge any cruft pulled in by that detour.

October 17th a fix was proposed at .

@Testers of Debian: Please test debootstrap with that patch applied and 
report your experiences, good and bad, to <668...@bugs.debian.org>.

@Debian-installer team: Please reconsider applying that patch.  If not 
targeted Jessie then in another suite: Any degree of adoption eases 
ability to test, which in turn eases ability to adopt further.


Kind regards,

 - Jonas

¹ Package "sysvinit" stopped being flagged as essential, causing package 
managers to no longer treat alternative choices as breach of Policy.  
That changes entered unstable 2014-08-06 and testing 2014-08-12.

² Package "init" switched to favor "systemd-sysv" over "sysvinit-core". 
That changes entered unstable 2014-08-21 and testing 2014-08-26.

³ According to 


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

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


signature.asc
Description: signature

Re: Technical committee acting in gross violation of the Debian constitution

[Stephen Gran]

This one time, at band camp, Thorsten Glaser said:
> Matthias Urlichs  urlichs.de> writes:
> 
> > Care to tell us why? Other than "ugh, it's written by Lennart"??
> 
> The “why” does not matter. Users do not have to justify why they
> need to use something. I worked in for company that had a strict
> “no PHP” policy once. I have encountered other more or less weird
> scenarios in the “enterprise” (bah, this sounds like a four-letter
> word) world about having to use something, or do something, despite
> it being nōn-free, while otherwise embracing OSS. (We had a case of
> someone wanting to put proprietary software they have to use inside
> a .deb so it can be easilier managed and integrated well with Debian
> and removed cleanly, recently, on some mailing list.)

Excellent.  I'm sure that if they can create a deb, they can install
sysvinit, or runit, or some BSD, or whatever else they want.  A default
is only a default, after all.

I can't argue against nebulous "lots of people are scared" arguments.
Lots of people are always scared about something, and we can't do
anything to make them less scared except perhaps give them a glass of
warm milk and a nice bedtime story.

Can we stick to technical arguments?  If the only argument to make is
"my sister's uncle's cousin knows a guy who has a friend who runs a lot
of machines and might leave Debian because systemd makes him so sad",
please don't bother.  The plural of anecdote is still not data.

> Let me quote:
> 
>  4. Our priorities are our users and free software
[...]

Reducto ad DFSGum.  Almost but not quite as much fun as Reducto ad
Hitlerum.

> So stop this already!

You take the words out of my mouth.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Bug#668001: please help test proposed patch for bug#668001

[Cyril Brulebois]

Jonas Smedegaard  (2014-11-25):
> August 8th, Debian began supporting¹ choice among several init systems.
> August 21st, Debian changed² default init.
> 
> To me, flexibility is an important feature of Debian.  I am excited that 
> Debian extends its flexibility to cover several init systems.
> 
> Others agree, apparently³: Among those testing our system while this new 
> flexibility is in place, ~20% use a non-default init system.
> 
> For fresh installs, picking a non-default init requires a workaround: 
> First install default init system, then replace with your own choice.  
> Remember to also check for and purge any cruft pulled in by that detour.
> 
> October 17th a fix was proposed at .
> 
> @Testers of Debian: Please test debootstrap with that patch applied and 
> report your experiences, good and bad, to <668...@bugs.debian.org>.
> 
> @Debian-installer team: Please reconsider applying that patch.  If not 
> targeted Jessie then in another suite: Any degree of adoption eases 
> ability to test, which in turn eases ability to adopt further.

I'm not sure why people seem to believe that broadcasting a call for
tests through their blog, Planet Debian, various Debian mailing lists,
etc. is going to change anything here.

I've already mentioned that having debootstrap stop pulling an init
system might make sense at some point. In the meanwhile, debootstrap is
not going to receive any patching in the dependency resolving area.


KiBi.


-- 
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/20141125173133.gk6...@mraw.org

Re: Technical committee acting in gross violation of the Debian constitution

[Michael Banck]

On Tue, Nov 25, 2014 at 06:01:38PM +0100, Sascha Mester wrote:
> Can someone tell me the advantages ( and disadvantages ) of systemd ?
> I'm about to leave Debian as an user - not because of systemd, but
> because of that discussion.

Wait, you are asking for a discussion about the advantages and
disadvantages of systemd, and in the same paragraph say you are about to
leave Debian because of exactly this?

In any case, your question is off-topic on debian-devel, please reask it
on debian-user.


Michael


-- 
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/20141125174432.gc31...@raptor.chemicalconnection.dyndns.org

Re: Bug#668001: please help test proposed patch for bug#668001

[Jonas Smedegaard]

Hi Cyril,

Quoting Cyril Brulebois (2014-11-25 18:31:33)
> Jonas Smedegaard  (2014-11-25):
>> August 8th, Debian began supporting¹ choice among several init 
>> systems. August 21st, Debian changed² default init.
>>
>> To me, flexibility is an important feature of Debian.  I am excited 
>> that Debian extends its flexibility to cover several init systems.
>>
>> Others agree, apparently³: Among those testing our system while this 
>> new flexibility is in place, ~20% use a non-default init system.
>>
>> For fresh installs, picking a non-default init requires a workaround: 
>> First install default init system, then replace with your own choice.  
>> Remember to also check for and purge any cruft pulled in by that 
>> detour.
>>
>> October 17th a fix was proposed at 
>> .
>>
>> @Testers of Debian: Please test debootstrap with that patch applied 
>> and report your experiences, good and bad, to 
>> <668...@bugs.debian.org>.
>>
>> @Debian-installer team: Please reconsider applying that patch.  If 
>> not targeted Jessie then in another suite: Any degree of adoption 
>> eases ability to test, which in turn eases ability to adopt further.
>
> I'm not sure why people seem to believe that broadcasting a call for 
> tests through their blog, Planet Debian, various Debian mailing lists, 
> etc. is going to change anything here.

You don't follow how raising exposure to a bugreport have the potential 
to boost contributions getting that bug resolved?


> I've already mentioned that having debootstrap stop pulling an init 
> system might make sense at some point. In the meanwhile, debootstrap 
> is not going to receive any patching in the dependency resolving area.

Thanks for clarifying.  I guess now (reading again a couple times very 
slowly) that you are referring to "this late in the release cycle" in 
.

I am sorry that until now I read that as simply "go away, too late!"

Quite possibly I was distracted by the mud you threw right after that in 
same sentence.  I find no pleasure digesting mud so only read that 
sentence quickly at first.

Just to be clear: Are you saying that the patch is perfect and just - as 
already more than adequately pointed out by you (except evidently still 
so for think-headed folks like me) - will not under any possible 
circumstances be touched _before_ Jessie is released, but _after_ the 
release will be applied as-is with no need for further testing nor 
discussion from your peer Debian developers or anyone else?

If so, then why not release it now for experimental?  If because you are 
too busy releasing Debian, would you perhaps be ok with me doing so as 
an NMU?


 - Jonas

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

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


signature.asc
Description: signature

Re: Technical committee acting in gross violation of the Debian constitution

[Andrei POPESCU]

On Ma, 25 nov 14, 18:44:33, Michael Banck wrote:
> On Tue, Nov 25, 2014 at 06:01:38PM +0100, Sascha Mester wrote:
> > Can someone tell me the advantages ( and disadvantages ) of systemd ?
> > I'm about to leave Debian as an user - not because of systemd, but
> > because of that discussion.
> 
> Wait, you are asking for a discussion about the advantages and
> disadvantages of systemd, and in the same paragraph say you are about to
> leave Debian because of exactly this?
> 
> In any case, your question is off-topic on debian-devel, please reask it
> on debian-user.

This has been (and still is) discussed on -user as well, so you might 
want to read the archives before reposting there.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Bug#668001: please help test proposed patch for bug#668001

[Cyril Brulebois]

Jonas Smedegaard  (2014-11-25):
> Quoting Cyril Brulebois (2014-11-25 18:31:33)
> > I'm not sure why people seem to believe that broadcasting a call for
> > tests through their blog, Planet Debian, various Debian mailing
> > lists, etc. is going to change anything here.
> 
> You don't follow how raising exposure to a bugreport have the
> potential to boost contributions getting that bug resolved?

Since the decision was made that no, it won't be touched for jessie, no,
I frankly do not follow.

> > I've already mentioned that having debootstrap stop pulling an init 
> > system might make sense at some point. In the meanwhile, debootstrap 
> > is not going to receive any patching in the dependency resolving area.
> 
> Thanks for clarifying.  I guess now (reading again a couple times very 
> slowly) that you are referring to "this late in the release cycle" in 
> .
> 
> I am sorry that until now I read that as simply "go away, too late!"

I'm no native English speaker/writer, so I try to stick to non
convoluted wordings, but I guess I can easily fail at doing so.

> Quite possibly I was distracted by the mud you threw right after that
> in same sentence.  I find no pleasure digesting mud so only read that
> sentence quickly at first.

I'm sorry you see mud throwing in my considering this a non-problem, I
really don't follow you there either.

> Just to be clear: Are you saying that the patch is perfect and just -
> as already more than adequately pointed out by you (except evidently
> still so for think-headed folks like me) - will not under any possible
> circumstances be touched _before_ Jessie is released, but _after_ the
> release will be applied as-is with no need for further testing nor
> discussion from your peer Debian developers or anyone else?

No, I didn't write that either. Please stop making up stuff. It won't be
considered for jessie, that's all.

> If so, then why not release it now for experimental?  If because you
> are too busy releasing Debian, would you perhaps be ok with me doing
> so as an NMU?

To be crystal clear: no, this patch needs to be considered, reviewed,
whatever, and not randomly uploaded to experimental. Feel free to ping
this bug report once jessie is released.


KiBi.


signature.asc
Description: Digital signature

Re: Technical committee acting in gross violation of the Debian constitution

[Noel Torres]

On Monday, 17 de November de 2014 20:45:19 Josselin Mouette escribió:
> -- 
>  .''`.  Josselin Mouette
> : :' :
> `. `'
>   `-
On Tuesday, 25 de November de 2014 17:30:38 Stephen Gran escribió:
> Cheers,
> -- 
>  -
> 
> |   ,''`.Stephen Gran |
> |  : :' :sg...@debian.org |
> |  `. `'Debian user, admin, and developer |
> |`- http://www.debian.org |
> 
>  -

Why is it that systemd proponents are the ones using this kind of signature? 
Are they trying to insinuate that Debian is theirs?

Transformig Debian in something different than Debian (the community-driven 
rock-solid Universal distribution we loved to put on our servers) may be 
allowed by being a majority of DDs, but it is not loving Debian.

Systemd is a wonderful system. For laptops. Gnome is a great Desktop. For 
novel-users laptops. And Debian uses to be a great and wonderful distribution, 
for servers, desktops, laptops and embedded systems. And it is about to stop 
being wonderful for servers and embedded systems.

This is not a defense of sysvinit. It is venerable, and that implies it is 
old. Not suitable for some modern tasks. But it happens that those modern 
tasks are not those needed on servers. I definitely do not want automount nor 
binary logs on a server. I want an independent time daemon on the server. I 
want static, trustable network configuration. I want the server not to stop 
booting if some disk goes wild. I want to be able to SSH into a headless 
machine as soon as possible, to debug its booting process if necessary. And 
all that is not the default in the next Debian release (with the exception of 
binary logs). And I'm not alone with all those "I want".

So, forget the question about the signatures. It was just a teaser. Answer the 
real question. Forget about who our developers are.

Who our users are?


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

Re: Bug#668001: please help test proposed patch for bug#668001

[Svante Signell]

On Tue, 2014-11-25 at 19:50 +0100, Cyril Brulebois wrote:
> Jonas Smedegaard  (2014-11-25):
> > Quoting Cyril Brulebois (2014-11-25 18:31:33)
> > > I'm not sure why people seem to believe that broadcasting a call for
> > > tests through their blog, Planet Debian, various Debian mailing
> > > lists, etc. is going to change anything here.

> No, I didn't write that either. Please stop making up stuff. It won't be
> considered for jessie, that's all.

And the reason is the freeze?

> > If so, then why not release it now for experimental?  If because you
> > are too busy releasing Debian, would you perhaps be ok with me doing
> > so as an NMU?
> 
> To be crystal clear: no, this patch needs to be considered, reviewed,
> whatever, and not randomly uploaded to experimental. Feel free to ping
> this bug report once jessie is released.


>From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#60

Is this command something in debootstrap or the installer?
preseed/late_command="in-target apt-get install -y sysvinit-core"



-- 
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/1416945074.11764.290.ca...@g3620.my.own.domain

Re: Technical committee acting in gross violation of the Debian constitution

[Axel Wagner]

Noel Torres  writes:
> Why is it that systemd proponents are the ones using this kind of signature? 
> Are they trying to insinuate that Debian is theirs?

Wow! A dipshit crazy conspiracy theory about systemd and its
proponents. Haven't seen one of those in a long time… 


--
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/87bnnv12lj.fsf@rincewind.i-did-not-set--mail-host-address--so-tickle-me

Re: Technical committee acting in gross violation of the Debian constitution

[Noel Torres]

On Tuesday, 25 de November de 2014 19:50:48 Axel Wagner escribió:
> Noel Torres  writes:
> > Why is it that systemd proponents are the ones using this kind of
> > signature? Are they trying to insinuate that Debian is theirs?
> 
> Wow! A dipshit crazy conspiracy theory about systemd and its
> proponents. Haven't seen one of those in a long time… 

Sarcasm welcomed :) Anyway, I would like to read your answer to the REAL 
question written at the end of the message.

Regards
er Envite


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

Re: Technical committee acting in gross violation of the Debian constitution

[Andrey Rahmatullin]

On Tue, Nov 25, 2014 at 08:03:44PM +, Noel Torres wrote:
> > > Why is it that systemd proponents are the ones using this kind of
> > > signature? Are they trying to insinuate that Debian is theirs?
> > 
> > Wow! A dipshit crazy conspiracy theory about systemd and its
> > proponents. Haven't seen one of those in a long time… 
> 
> Sarcasm welcomed :) Anyway, I would like to read your answer to the REAL 
> question written at the end of the message.
I think I'm not the only one who stopped reading your email after that and
so didn't see that question.
Please stop.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Proposal for upgrades to jessie

[Svante Signell]

Hello,

Below is a proposal for a (partial) solution for the upgrade problem of
keeping the installed init system:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765803

This has been discussed privately among selected users/DM/DDs and since
the deadline for the ctte is December 4, it has to be known to them (and
-devel for comments).

(another partial? solution is to change order of the (pre-)depends of
the init package, as proposed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194
with preliminary results in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762194#142)

1) Heavily advertise (release-notes?) that doing an upgrade from
wheezy/etc to jessie will give you systemd as init system and inform
about the apt pinning solution.

2) In case you missed doing the above, you get a debconf prompt when
installing the init package that if you want to keep sysv/openrc/etc
continue with the installation, get systemd-sysv installed and after
that install sysvinit-core and do the pinning. (This is suboptimal, many
peoples systems could be broken at first reboot, we will find out in due
time).

Another issue is upgrading from testing/sid?/etc (different status) to
jessie:
3) Heavily advertise (again in release notes?) that you need to install
sysvinit-core and add the pinning file _before_ dist-upgrading.

Note that the only technical in the above is the creation of a debconf
prompt in pre/post-inst of the init package. All the rest is just a
matter of writing.

Sincerely!


-- 
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/1416947368.11764.312.ca...@g3620.my.own.domain

Re: Age of built packages to be part of the jessie release?

[Manuel A. Fernandez Montecelo]

2014-11-25 11:14 Dimitri John Ledkov:

On 24 November 2014 at 18:56, Manuel A. Fernandez Montecelo
 wrote:


Would it make sense to trigger rebuilds (or binNMUs, or actions to the same
effect) for all packages in a given architecture when there are important
changes in the toolchain, e.g. the default GCC bumps to a new major version
[1]?

For me it makes a lot of sense to have most of the archive rebuilt
at that time, and these newly compiled packages migrated at some
point to testing to be present in the next release.

With the current method it seems that we only check if it FTBFS,
and packages only get recompiled if there are new uploads or
binNMUs.  But actually recompiling and moving it to the archive
will reveal changes in runtime behaviour, and thus bugs might be
caught/reported/hopefully-fixed sooner.  In some occasions there
might even be some bugs fixed (if the compiler of years ago was
buggy) or performance improvements.

I do not know if there are significant drawbacks, for example if it
would be very taxing to have everything built in a short period of
time (especially for less powerful architectures) -- not only for
hardware, but delays to other packages who are uploaded at the same
time.  Or if there are other fundamental problems that I did not
consider.

In summary, if there's a cheap (esp. in humanpower) way to achieve
this, I think that it would be worth doing it.


Part of OBS (open build service) there is a tool called
"build-compare" which does end comparison to see if things are really
different, it does analyse disassembly to see if things are different.
E.g. I've been fiddling with a toolchain and e.g. enabling AVX by
default did show me all binaries that gained / changed their
instructions because of that and build were kept/publish as modified
instead of discarding them as "identical" to previous.

Imho it would make sense to rebuild locally binaries which are the
same since stable, and compare generated maintainer scripts and/or run
the binaries through build-compare to see if there are worthwhile
differences. And if there are, request release team to binNMU those.
(Or do no change uploads, in case of changes in arch:all packages)



I found these interesting links.  First one a bit old but explaining
OBS, build-compare and the openSUSE approach.  Second one is a sample
of people caring about reproducible builds, which is somewhat related.

 https://news.opensuse.org/2009/02/05/more-efficient-factory-development/

 https://blogs.kde.org/2013/06/19/really-source-code-software



From the first link, Debian seems to mostly follow "1) Trigger builds

manually" (uploads or binNMUs), while openSUSE follows "2) Full
Automated Build Triggering" to build packages whenever their
dependencies change.

It seems that we already have some infrastructure in place or which
could be adapted, with jenkins.debian.net and the CI -- at least they
detect if there are problems building packages with the new
dependencies.  openSUSE link explains that by getting rid of
timestamps in built packages, they get more accurate results, effort
that Lunar and Holger (and more people?) are doing as part of
Reproducible Builds:

 https://wiki.debian.org/ReproducibleBuilds

And about build-compare, the openSUSE article says what you point out,
that "The openSUSE Build Service will just drop the build result if
the new build are essentially the same and calculate the build
dependencies based on the old build result".  I think that it's
accurate because it only checks if the binary is different, and the
openSUSE folks (at least at that time) triggered builds in that case.


Doing what you say, if I understood it correctly, would require
significant human intervention, and if not that, at least a lot of
bandwith, local storage and computing power, I think?

One possibility to minimise extra work would be to do that as part of
the mass builds to detect FTBFS which happens ~twice a year, an extra
analysis step of "this package does not FTBFS, but would benefit from
being rebuilt with this toolchain versions".  After the analysis, it
would be a matter of gathering the list of packages in a single list,
and ask Release Team (or similar) to schedule the builds.  Or extract
the list at regular intervals from jenkins or CI instance, if they can
add this extra step of analysies.


To me, what openSUSE guys do seems to be optimal, but I don't know how
hard would be to integrate that in our existing processes and who
would volunteer to do the work (I might help if there are more people
involved, but cannot commit right now to new big efforts).

On the other hand, triggering rebuilds by demand every now and then
(e.g. when important bits of the toolchain changes, 2-4 times in
between releases at most, so also ~twice a year), and setting the
priority low when requesting packages being built again (so they don't
make new uploads to "starve"), might perhaps be a very cheap solution,
in terms of humanpower and changes needed in t

Re: Technical committee acting in gross violation of the Debian constitution

[Noel Torres]

On Tuesday, 25 de November de 2014 20:15:36 Andrey Rahmatullin escribió:
> On Tue, Nov 25, 2014 at 08:03:44PM +, Noel Torres wrote:
> > > > Why is it that systemd proponents are the ones using this kind of
> > > > signature? Are they trying to insinuate that Debian is theirs?
> > > 
> > > Wow! A dipshit crazy conspiracy theory about systemd and its
> > > proponents. Haven't seen one of those in a long time… 
> > 
> > Sarcasm welcomed :) Anyway, I would like to read your answer to the REAL
> > question written at the end of the message.
> 
> I think I'm not the only one who stopped reading your email after that and
> so didn't see that question.
> Please stop.

*Now* that you know there is a real question beyond the sarcasm, which is your 
answer to it?

Citing myself:

Answer the real question. Forget about who our developers are.

Who our users are?


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

Re: Bug#668001: please help test proposed patch for bug#668001

[Philip Hands]

Svante Signell  writes:
...
> Is this command something in debootstrap or the installer?
> preseed/late_command="in-target apt-get install -y sysvinit-core"

  https://wiki.debian.org/systemd#Installing_without_systemd

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


pgpMjMbFfzmy5.pgp
Description: PGP signature

Re: Age of built packages to be part of the jessie release?

[Dimitri John Ledkov]

On 25 November 2014 at 20:33, Manuel A. Fernandez Montecelo
 wrote:
> 2014-11-25 11:14 Dimitri John Ledkov:
>>
>> On 24 November 2014 at 18:56, Manuel A. Fernandez Montecelo
>>  wrote:
>>>
>>>
>>> Would it make sense to trigger rebuilds (or binNMUs, or actions to the
>>> same
>>> effect) for all packages in a given architecture when there are important
>>> changes in the toolchain, e.g. the default GCC bumps to a new major
>>> version
>>> [1]?
>>>
>>> For me it makes a lot of sense to have most of the archive rebuilt
>>> at that time, and these newly compiled packages migrated at some
>>> point to testing to be present in the next release.
>>>
>>> With the current method it seems that we only check if it FTBFS,
>>> and packages only get recompiled if there are new uploads or
>>> binNMUs.  But actually recompiling and moving it to the archive
>>> will reveal changes in runtime behaviour, and thus bugs might be
>>> caught/reported/hopefully-fixed sooner.  In some occasions there
>>> might even be some bugs fixed (if the compiler of years ago was
>>> buggy) or performance improvements.
>>>
>>> I do not know if there are significant drawbacks, for example if it
>>> would be very taxing to have everything built in a short period of
>>> time (especially for less powerful architectures) -- not only for
>>> hardware, but delays to other packages who are uploaded at the same
>>> time.  Or if there are other fundamental problems that I did not
>>> consider.
>>>
>>> In summary, if there's a cheap (esp. in humanpower) way to achieve
>>> this, I think that it would be worth doing it.
>>
>>
>> Part of OBS (open build service) there is a tool called
>> "build-compare" which does end comparison to see if things are really
>> different, it does analyse disassembly to see if things are different.
>> E.g. I've been fiddling with a toolchain and e.g. enabling AVX by
>> default did show me all binaries that gained / changed their
>> instructions because of that and build were kept/publish as modified
>> instead of discarding them as "identical" to previous.
>>
>> Imho it would make sense to rebuild locally binaries which are the
>> same since stable, and compare generated maintainer scripts and/or run
>> the binaries through build-compare to see if there are worthwhile
>> differences. And if there are, request release team to binNMU those.
>> (Or do no change uploads, in case of changes in arch:all packages)
>
>
>
> I found these interesting links.  First one a bit old but explaining
> OBS, build-compare and the openSUSE approach.  Second one is a sample
> of people caring about reproducible builds, which is somewhat related.
>
>  https://news.opensuse.org/2009/02/05/more-efficient-factory-development/
>
>  https://blogs.kde.org/2013/06/19/really-source-code-software
>
>
>> From the first link, Debian seems to mostly follow "1) Trigger builds
>
> manually" (uploads or binNMUs), while openSUSE follows "2) Full
> Automated Build Triggering" to build packages whenever their
> dependencies change.
>
> It seems that we already have some infrastructure in place or which
> could be adapted, with jenkins.debian.net and the CI -- at least they
> detect if there are problems building packages with the new
> dependencies.  openSUSE link explains that by getting rid of
> timestamps in built packages, they get more accurate results, effort
> that Lunar and Holger (and more people?) are doing as part of
> Reproducible Builds:
>
>  https://wiki.debian.org/ReproducibleBuilds
>
> And about build-compare, the openSUSE article says what you point out,
> that "The openSUSE Build Service will just drop the build result if
> the new build are essentially the same and calculate the build
> dependencies based on the old build result".  I think that it's
> accurate because it only checks if the binary is different, and the
> openSUSE folks (at least at that time) triggered builds in that case.
>
>
> Doing what you say, if I understood it correctly, would require
> significant human intervention, and if not that, at least a lot of
> bandwith, local storage and computing power, I think?
>

not really. filtering out and looking only that have not been rebuild
since stable in jessie will minimise amount of packages (e.g. all of
haskell, texlive, openoffice, kernels, etc have been rebuild). locally
rebuilding a package and comparing versus old one will need only
minimal local storage, or computing power (it doesn't matter how long
it will take to rebuild/compare) and once reports are published they
can be made public for others to analyse.

Note i'm not proposing to do the full OBS thing and rebuild / trigger
rebuilds like crazy. Just a one-off rebuild of old debian packages and
comparison using the build-compare tool.

> One possibility to minimise extra work would be to do that as part of
> the mass builds to detect FTBFS which happens ~twice a year, an extra

i had the impression that debian is rebuild more than twice a year,
given the cloud credits we 

Bug#771010: ITP: btest -- simple driver for basic unit tests

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: btest
  Version : 0.53
  Upstream Author : Bro Development Team 
* URL or Web page : http://www.bro.org/
* License : BSD
  Description : simple driver for basic unit tests

This is a prerequisite for building bro, a network analysis framework
(#752546)


-- 
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/87mw7ezzy7@msgid.hilluzination.de

Bug#771012: ITP: proj-rdnap -- RDNAP grid correction files for PROJ.4

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: proj-rdnap
  Version : 2008
  Upstream Author : RDNAP
* URL : 
https://www.kadaster.nl/web/Themas/Registraties/Rijksdriehoeksmeting/Transformatie-van-coordinaten.htm
* License : RDNAPTRANS2008-NTv2
  Programming Lang: N/A
  Description : RDNAP grid correction files for PROJ.4

Kadaster and Rijkswaterstaat CIV, working together under the name RDNAP,
developed RDNAPTRANS™2008, the precise and official transformation
between ETRS89 and the dutch national horizontal and vertical coordinate
reference systems the Stelsel van de Rijksdriehoeksmeting (RD) and the
Normaal Amsterdams Peil (NAP). A ‘simplified’ procedure has been
devolped which uses a NTv2-grid for the transformation between ETRS89
and RD as well as a VDatum-grid for the transformation between ETRS89
and NAP. This ‘simplified’ procedure has the following limitations:

 1) The rdtrans2008 NTv2-grid can only give identical results to
RDNAPTRANS™2008 within 1 millimeter at ground level onshore and at
mean seal level offshore. The horizontal deviation is approximately
1 millimeter per 50 meter height difference from ground level or mean
sea level.
 2) An exception to 1) is the border of the RDNAPTRANS™2008 correction
grid. Transformation results within cells of the rdtrans2008 NTv2-grid
that are intersected by the border of the RDNAPTRANS™2008 correction
grid can result in deviations of up to 20 centimeter.
 3) The naptrans2008 VDatum-grid cannot be used to determine deflections
of the vertical. For this the NLGEO2004 geoid model has to be used.
 4) The naptrans2008 VDatum-grid is referenced to the Bessel-1841 ellipsoid
and cannot be used stand-alone, it has to be used in combination with
the rdtrans2008 NTv2-grid.

Taking into account the limitations listed above, the rdtrans2008 NTv2-grid
and naptrans2008 VDatum-grid can be used as an alternative to
RDNAPTRANS™2008 to transform geographic ETRS89-coordinates to
projected RD-coordinates with grid correction applied and NAP-heights.
The figure in appendix 1 shows the precise and official RDNAPTRANS™2008
flow-chart on the left and on the right the flow-chart for the ‘simplified’
procedure.

Note that, although the resulting RD/NAP and ETRS89 coordinates from the
transformation will be correct, geographic Bessel-1841 coordinates will
differ in both procedures and should only be considered as an intermediate
result.

The package will be maintained within the Debian GIS team.


-- 
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/20141125222553.5588.34676.report...@osiris.linuxminded.xs4all.nl

Re: Bug#668001: please help test proposed patch for bug#668001

[Jonas Smedegaard]

Quoting Cyril Brulebois (2014-11-25 19:50:48)
> Jonas Smedegaard  (2014-11-25):
>> Quoting Cyril Brulebois (2014-11-25 18:31:33)
>>> I'm not sure why people seem to believe that broadcasting a call for 
>>> tests through their blog, Planet Debian, various Debian mailing 
>>> lists, etc. is going to change anything here.
>> 
>> You don't follow how raising exposure to a bugreport have the 
>> potential to boost contributions getting that bug resolved?
>
> Since the decision was made that no, it won't be touched for jessie, 
> no, I frankly do not follow.

Why do you talk about Jessie?  I do not talk about Jessie, I talk about 
a bug in Debian and how we can fix it.

I believe that the only time I mentioned "Jessie" in this thread (till 
now) was in a sentence where I explicitly propose to *not* target that 
suite if needed to move forward with this bug.

Do you understand my question now?


>>> I've already mentioned that having debootstrap stop pulling an init 
>>> system might make sense at some point. In the meanwhile, debootstrap 
>>> is not going to receive any patching in the dependency resolving 
>>> area.
>>
>> Thanks for clarifying.  I guess [...] that you are referring to "this 
>> late in the release cycle" in .
[mutual apologies snipped]
>> Quite possibly I was distracted by the mud you threw right after that 
>> in same sentence.  I find no pleasure digesting mud so only read that 
>> sentence quickly at first.
> 
> I'm sorry you see mud throwing in my considering this a non-problem, I 
> really don't follow you there either.

What I call throwing mud is your introducing dislikes of systemd when 
that's not what the bug is about.

(Heck, the title of the bug is even the opposite - stemming from the era 
past 4 months ago when systemd was not the default).

Back to my question: Did I guess correctly that your "this late in the 
release cycle" in  is what you mean 
by "already mentioned"?

(Again, let me emphasize that I am talking about a bug, not a release 
and no specific init system).


>> Just to be clear: Are you saying that the patch is perfect and just - 
>> as already more than adequately pointed out by you (except evidently 
>> still so for think-headed folks like me) - will not under any 
>> possible circumstances be touched _before_ Jessie is released, but 
>> _after_ the release will be applied as-is with no need for further 
>> testing nor discussion from your peer Debian developers or anyone 
>> else?
>
> No, I didn't write that either. Please stop making up stuff. It won't 
> be considered for jessie, that's all.

"Either"?!?

So I guessed wrong further up, or what?  Sorry if that's the case - it 
was unintentional.  Perhaps it helps if you spell out to me what you are 
talking about, instead of only making remarks that $stuff has already 
been discussed $enough.  Seems _your_ $stuff is init-specific and _your_ 
$enough is suite-specific, and you then impose that on my $stuff and 
$enough which are different ones.  Seems you are reading between the 
lines of what I wrote and then get upset when I do the same.

You mention Jessie again - that's besides the point!


>> If so, then why not release it now for experimental?  If because you 
>> are too busy releasing Debian, would you perhaps be ok with me doing 
>> so as an NMU?
>
> To be crystal clear: no, this patch needs to be considered, reviewed, 
> whatever, and not randomly uploaded to experimental. Feel free to ping 
> this bug report once jessie is released.

You have made it quite clear that you do not believe putting more 
attention to this bug is "going to change anything here."  How then do 
_you_ propose to get it "considered, reviewed, whatever"?


 - Jonas

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

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


signature.asc
Description: signature

Re: Bug#668001: please help test proposed patch for bug#668001

[Cyril Brulebois]

Jonas Smedegaard  (2014-11-26):
> Quoting Cyril Brulebois (2014-11-25 19:50:48)
> > Jonas Smedegaard  (2014-11-25):
> >> Quoting Cyril Brulebois (2014-11-25 18:31:33)
> >>> I'm not sure why people seem to believe that broadcasting a call for 
> >>> tests through their blog, Planet Debian, various Debian mailing 
> >>> lists, etc. is going to change anything here.
> >> 
> >> You don't follow how raising exposure to a bugreport have the 
> >> potential to boost contributions getting that bug resolved?
> >
> > Since the decision was made that no, it won't be touched for jessie, 
> > no, I frankly do not follow.
> 
> Why do you talk about Jessie?  I do not talk about Jessie, I talk about 
> a bug in Debian and how we can fix it.
> 
> I believe that the only time I mentioned "Jessie" in this thread (till 
> now) was in a sentence where I explicitly propose to *not* target that 
> suite if needed to move forward with this bug.

Because jessie is what matters now, then we can look at init-less
debootstrap, and figure out whether this bug makes sense at all, and if
it needs fixing. The only occurrence (I'm aware of) is in init context
(forced sysvinit then forced systemd).

> Do you understand my question now?

No.

> >>> I've already mentioned that having debootstrap stop pulling an init 
> >>> system might make sense at some point. In the meanwhile, debootstrap 
> >>> is not going to receive any patching in the dependency resolving 
> >>> area.
> >>
> >> Thanks for clarifying.  I guess [...] that you are referring to "this 
> >> late in the release cycle" in .
> [mutual apologies snipped]
> >> Quite possibly I was distracted by the mud you threw right after that 
> >> in same sentence.  I find no pleasure digesting mud so only read that 
> >> sentence quickly at first.
> > 
> > I'm sorry you see mud throwing in my considering this a non-problem, I 
> > really don't follow you there either.
> 
> What I call throwing mud is your introducing dislikes of systemd when 
> that's not what the bug is about.

That's very much not true, see above.

> (Heck, the title of the bug is even the opposite - stemming from the era 
> past 4 months ago when systemd was not the default).

Addressed above as well.

> Back to my question: Did I guess correctly that your "this late in the 
> release cycle" in  is what you mean 
> by "already mentioned"?
> 
> (Again, let me emphasize that I am talking about a bug, not a release 
> and no specific init system).

I do mean that, and mails to debian-boot@, and mails to debian-ctte@,
and mails to debian-devel@, and mails to debian-private@. Pick your
favourite.

> >> Just to be clear: Are you saying that the patch is perfect and just - 
> >> as already more than adequately pointed out by you (except evidently 
> >> still so for think-headed folks like me) - will not under any 
> >> possible circumstances be touched _before_ Jessie is released, but 
> >> _after_ the release will be applied as-is with no need for further 
> >> testing nor discussion from your peer Debian developers or anyone 
> >> else?
> >
> > No, I didn't write that either. Please stop making up stuff. It won't 
> > be considered for jessie, that's all.
> 
> "Either"?!?
> 
> So I guessed wrong further up, or what?  Sorry if that's the case - it 
> was unintentional.  Perhaps it helps if you spell out to me what you are 
> talking about, instead of only making remarks that $stuff has already 
> been discussed $enough.  Seems _your_ $stuff is init-specific and _your_ 
> $enough is suite-specific, and you then impose that on my $stuff and 
> $enough which are different ones.  Seems you are reading between the 
> lines of what I wrote and then get upset when I do the same.

I've rephrased it (again) in my first paragraph.

> You mention Jessie again - that's besides the point!

No, that's very relevant, again, see above.

> >> If so, then why not release it now for experimental?  If because you 
> >> are too busy releasing Debian, would you perhaps be ok with me doing 
> >> so as an NMU?
> >
> > To be crystal clear: no, this patch needs to be considered, reviewed, 
> > whatever, and not randomly uploaded to experimental. Feel free to ping 
> > this bug report once jessie is released.
> 
> You have made it quite clear that you do not believe putting more 
> attention to this bug is "going to change anything here."  How then do 
> _you_ propose to get it "considered, reviewed, whatever"?

All mentioned in the first paragraph.


I'll probably stop replying here since I feel like I'm repeating myself
over and over and over and over again.


Bottom lines:
 - debootstrap in jessie is not going to get changed WRT this bug.
 - and since you're not specifically interested in jessie, please don't
   touch debootstrap in unstable or experimental either; instead, let
   people figure out what to do with it after the jessie release.


KiBi.


signature.asc
Description: Di

Re: Bug#668001: please help test proposed patch for bug#668001

[Jonas Smedegaard]

Quoting Cyril Brulebois (2014-11-26 00:31:18)
> I'll probably stop replying here since I feel like I'm repeating 
> myself over and over and over and over again.

You didn't repeat youself.  Thanks for spelling out your opinions to me.


 - Jonas

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

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


signature.asc
Description: signature

Re: Technical committee acting in gross violation of the Debian constitution

[Matthias Urlichs]

Hi,

Noel Torres:
> > [ largish .sig ]
> Why is it that systemd proponents are the ones using this kind of signature? 

Signatures like this one may or may not be welcome here, but they are not a
new phenomenon and have nothing whatsoever to do with systemd.

Frankly, IMHO this is approaching paranoia territory.

> Who our users are?

This question ungrammatical is.

To answer it anyway: Hopefully, our users are people who will not buy into
the FUD about systemd people like you are flinging about, and who instead
will consider the pros and cons somewhat rationally.  :-/

In other words: Please stop.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Technical committee acting in gross violation of the Debian constitution

[Paul Wise]

On Wed, Nov 26, 2014 at 3:41 AM, Noel Torres wrote:

> Who our users are?

Debian's users are the set of people and organisations who use Debian.
That is changing every day as people discover Debian, discover other
systems they like better, discover something about Debian they don't
like, try a system that is new etc. Since there are no monetary or
other restrictions on downloading and installing Debian, we can't know
the exact set of people and organisations who use Debian but there are
some indicators of who they are (see below).

I expect you don't actually want to know who uses Debian but who the
people involved in Debian want or don't want to be using Debian.
Debian's motto has been "The Universal Operating System" for a long
time and Debian folks often talk of world-domination; I think it is
safe to say that Debian folks want Debian to be used by everyone,
including those who have a particular preference of init systems.

Here are the set of Debian contributors, presumably most of them use
Debian in some capacity:

https://contributors.debian.org/

Here are some examples of organisations using Debian:

https://www.debian.org/users/

Here are some indicators of how many systems run Debian:

http://popcon.debian.org/
http://w3techs.com/technologies/details/os-debian/all/all
http://linuxcounter.net/distributions/stats.html
http://linuxcounter.net/distribution/Debian+GNU_S_Linux.html
https://wiki.debian.org/Statistics#mirrors

-- 
bye,
pabs

https://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/CAKTje6ECfcV=f5qou3ojxntqn23u6hv9ohyyxhaarmy5sjf...@mail.gmail.com

Bug#771031: ITP: r-cran-kernlab -- GNU R package for kernel-based machine learning lab

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-kernlab
  Version : 0.9-19
  Upstream Author : Alexandros Karatzoglou, Alex Smola, Kurt Hornik
* URL or Web page : http://cran.r-project.org/web/packages/kernlab/index.html
* License : GPL-2
  Description : GNU R package for kernel-based machine learning lab

This is an older and very stable package which has also become a
Build-Depends: of r-cran-fportfolio.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@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/873896oeyd@max.nulle.part