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

[Matthias Urlichs]

Hi,

Martin Steigerwald:
> Am Donnerstag, 27. November 2014, 22:30:15 schrieb Vincent Bernat:
> >  ❦ 27 novembre 2014 22:02 +0100, Martin Steigerwald  :
> > > And well, I also wonder why systemd --user functionality is in the *same*
> > > binary than the PID 1 stuff… but well…
> > 
> > Wild guess: because it manages processes like PID 1?
> 
> That kind of exchange isn´t productive

You mean the "wild guess" part? Yes, it's not, but you have to admit that
"I wonder why systemd --user is the same binary as systemd --system" kindof
asks for that kind of response – after all, the answer should be obvious;
it's not as if we started discussing what systemd does (and how) yesterday.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: successful upgrade to jessie - thanks!

[Matthias Urlichs]

Hi,

Marc Haber:
> Updating of such systems has always been a pain, but this time it's
> going to be a gazillion times more painful.
> 
Why? (Seriously.)

-- 
-- 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/20141128083000.gg6...@smurf.noris.de

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

[Svante Signell]

On Fri, 2014-11-28 at 08:45 +0100, Josselin Mouette wrote:
> Le jeudi 27 novembre 2014 à 21:29 +0100, Marc Haber a écrit : 
> > On Thu, 27 Nov 2014 01:19:14 +0100, Josselin Mouette 

> If you want to help our users, you
> can contribute to debianfork, or you can improve your packages in
> Debian. 

The official name of the Debian fork is devuan: https://devuan.org
It will be interesting to see how many Debian Maintainers and Developers
will jump the ship and join them (in addition to the users). Future will
tell...  


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

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

[Matthias Urlichs]

Hi,

Marc Haber:
> On Thu, 27 Nov 2014 11:53:18 +0100, Matthias Urlichs
>  wrote:
> >Yes, the logind-related parte _could_ be provided elsewhere, but part of
> >the features logind needs is already implemented in systemd. So using that
> >instead of rolling your own from scratch is simply common sense.
> 
> It would be common sense to move the shared code to a library.
> 
That shared piece of code needs to either run in only one process, or
coordinate with other copies of itself (if any).

The systemd people decided on the first option, and on using dbus to tell
the one copy that's running in PID-1 what to do.

Works for me. (Except for the fact that the dbus API between systemd and
logind should be public – but given the changes that interface has seen
lately, a freeze would have been premature, and systemd-shim wasn't on the
horizon then.)

If you want to convince the systemd people to split that part of systemd-
-as-pid1 off to a separate library, and/or to properly version that API,
you should submit an appropriate patch – but I don't think that telling
_them_ to do work that's outside their usecase is reasonable.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Javascript trigger design

[Tomas Pospisek]

Am 28.11.2014 um 08:19 schrieb Matthias Urlichs:
> Hi,
> 
> Tomas Pospisek:
>> At least the Ruby On Rails framework notices an updated JS and will
>> re-compress the whole JS blob from its parts.
> 
> Does it call stat() on every constituent of these packed JS files on every
> web request, or does it do that with a periodic background checker?

I do not know. Now that I am reading the answers in this thread I'm
noticing that RoR might be checking the newness of JS scripts depending
on the mode it's running in (production, testing, dev). In which case
the trigger mechanism could come into play again. So maybe my statement
was mistaken. In case anybody intends to make conclusions, s/he really
needs to look these detail up in the RoR docu.
*t


-- 
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/547840c0.4050...@sourcepole.ch

Re: Javascript trigger design

[Jérémy Lal]

Le vendredi 28 novembre 2014 à 06:16 +, olivier sallou a écrit :
> Le Fri Nov 28 2014 at 01:55:26, Tomas Pospisek  a
> écrit :
> 
> > Am 28.11.2014 um 00:04 schrieb Thomas Goirand:
> > > Hi,
> > >
> > > Web application have evolved into monsters that needs lots of
> > > javascript. It's very common that these javascript applications are
> > > collecting all the .js library they use, concatenate them into a single
> > > file, and compress the result using all sorts of tools (node uglify is
> > > one of the implementation, but that's not the only one).
> > >
> > > As much as possible, as good Debian citizens, we do package each and
> > > every javascript library into a separate package. But then, if there's
> > > an update of that JS library, the Web application package has to somehow
> > > know about it, and redo the concatenate & compress job. Otherwise, the
> > > web app would continue to use the old version.
> > >
> > > I have this issue with the OpenStack dashboard (ie: Horizon), but also
> > > with a second web app which I'm currently packaging (OpenStack Fuel,
> > > which is a deployment software for OpenStack). Though this could of
> > > course be generalize to any JS app.
> > >
> > > It's been a long time I've been thinking about it, and I believe that
> > > the only way to do this, would be to use triggers. Though I have never
> > > used triggers, and I thought it was a good idea to ask my DD friends and
> > > this list about it. Should there be one trigger per web app? How would
> > > this work?
> > >
> > > Thoughts anyone? Jonas maybe, who did lots of JS packaging?
> >
> > At least the Ruby On Rails framework notices an updated JS and will
> > re-compress the whole JS blob from its parts. I don't know about other
> > server side frameworks, but they _should_ be able to do the same. - ?
> 
> Unfortunalty no. Many "frameworks" help you build such things but with no
> update detection. Many frameworks are not running server like RoR but only
> build tools (Grunt, Yeoman, ...)
> These tools concat/minify/uglify etc... at build time and then you just put
> your app under Apache/Nginx and a different language server (to manage the
> GUI).
> So there is no awy for all these tools to detect a change and automatically
> do the modification.
> 
> 1) A trigger mechanism could indeed inform an additional script (that
> Debian developper/maintainer should develop per app) and this script could
> do the job, but on "production" system, I do not think that you would want
> to do automatically this because this may imply other things, and/or many
> compilation on your server at the same time (think of a jquery update
> triggering update of all dependent platforms...).
> 
> 2) One thing could be that a dependency update triggers a rebuilt of the
> package with a kinda automatic minor version upgrade and you would
> benefit from it at next system/app update.
> 
> >From a deveopper point of view (which I am), I would like idea 1, but from
> an admin point of view I think it would be idea 2.


The debian side is in no way able / fit to take care of *live* updating
js/css bundles. This is up to the web framework you're using - like you
mentioned for example RoR.
What is needed for debian-packaged webapps is to be able to regenerate a
bundle made of several other packages files (supporting concatenation,
browserification, whatever else...) when one of them changes at install
time. This requires it knows reverse build-dependencies of the package
that contains the file that changed, and call some trigger of each of
these package so it can itself call the proper script that is specific
for each of these packages.

Jérémy.



-- 
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/1417168319.8304.1.ca...@melix.org

Re: Javascript trigger design

[Paul Wise]

On Fri, Nov 28, 2014 at 5:51 PM, Jérémy Lal wrote:

> The debian side is in no way able / fit to take care of *live* updating
> js/css bundles. This is up to the web framework you're using - like you
> mentioned for example RoR.
> What is needed for debian-packaged webapps is to be able to regenerate a
> bundle made of several other packages files (supporting concatenation,
> browserification, whatever else...) when one of them changes at install
> time. This requires it knows reverse build-dependencies of the package
> that contains the file that changed, and call some trigger of each of
> these package so it can itself call the proper script that is specific
> for each of these packages.

I believe that Thomas is talking about dpkg triggers, which could
allow each web app to regenerate their bundle of javascript whenever
one of the libjs-* packages is updated.

https://wiki.debian.org/DpkgTriggers

-- 
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/CAKTje6HSU�LdmnttjrPizQnvyw6g1ARyYxS9v8xUXhxB=j...@mail.gmail.com

Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Svante Signell]

Hello,

In the (last) hope that the CTTE will bring this issue on the agenda
next meeting on December 4. Additional information below and a short
summary.

On Wed, 2014-11-26 at 09:56 +0100, Thorsten Glaser wrote:
> On Tue, 25 Nov 2014, Svante Signell wrote:
> 
> > (another partial? solution is to change order of the (pre-)depends of
> > the init package, as proposed in
> 
> No, that breaks due to the bug in debootstrap’s dependency “resolver”
> (see #557322, #668001, #768062) and the unwillingness of KiBi to fix
> that. That is, it breaks fresh installs.

Note, this (long-time) refusal to make changes to that package has to be
weighted in when the CTTE is discussing this issue: There are very small
patches available before the freeze Wed, 5 Nov 2014 (Sun, 22 Nov 2009
and  Fri, 17 Oct 2014) that has not been addressed by the maintainer:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557322#24
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#20
and reported working
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001#50

And according to
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
the order of pre-depends for int init package should change from
Pre-Depends: systemd-sysv | sysvinit-core | upstart
to
Pre-Depends: sysvinit-core | systemd-sysv | upstart

(I hope I made the correct links and conclusions)

> > 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.
> 
> That should be a given, a minimum, independent of the others.

I'll file a bug against release notes about the release-notes!

In summary:
a) Upgrades should _not_ change init: whatever is installed should be
kept.
b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

More detailed:
1) Fix debootstrap bugs
2) Add a (non-aborting) debconf message referring to release-notes on
how to install sysvinit-core when installing from scratch.
3) Add information in release-notes on how to:
- Upgrade from stable/testing/sid to jessie to avoid getting
systemd-sysv installed (this should not strictly be needed if the ctte
chooses to decide that upgrades will _not_ switch init)
- Install sysvinit-core after installation and reboot after getting
systemd-sysv as default.

3.1) I'll file a bug against release-notes as written above.


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

Bug#771306: ITP: libjs-autonumeric -- jQuery plugin that automatically formats currency and numbers

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-autonumeric
  Version : 1.9.12
  Upstream Author : Robert J. Knothe 
* URL : https://github.com/BobKnothe/autoNumeric
* License : Expat
  Programming Lang: Javascript
  Description : jQuery plugin that automatically formats currency and 
numbers

 autoNumeric is a jQuery plugin that automatically formats currency and numbers
 as you type on form inputs. It supports most International numeric formats and
 currency signs including those used in Europe, North and South America, Asia
 and India lakhs (Lakhs values supported below 1 billion).
 .
 Any number of currency formats can reside on the same page and are configured
 by settings/options that can be placed as HTML5 data attribute or passed as an
 argument. These settings can easily be changed at any time using the new
 update method or via the callback feature. autoNumeric to many other elements,
 allowing you to place formatted numbers and currency on just about any part of
 the page.
 .
 Seven built in methods gives you the flexibility needed to use autoNumeric to
 its maximum potential. You can now easily start and stop autoNumeric, update
 the settings and remove the formatting from multiple inputs, preparing the
 values for manipulation or form submission.

This is a dependency for OpenStack Fuel


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

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Thorsten Glaser]

On Fri, 28 Nov 2014, Svante Signell wrote:

> the order of pre-depends for int init package should change from
> Pre-Depends: systemd-sysv | sysvinit-core | upstart
> to
> Pre-Depends: sysvinit-core | systemd-sysv | upstart

That would probably require changes in d-i to ensure that
systemd is, indeed, installed by default on fresh installs,
but otherwise has the most chance of keeping existing systems
running properly, so I think that this change is fair, yes.

> a) Upgrades should _not_ change init: whatever is installed should be
> kept.

Are there any upgrade paths where software existing in wheezy
requires systemd in jessie? If so, these are corner cases where
switching init may or may not be avoidable; if not, present a
debconf message here. But the vast majority probably should not
(need to; even GNOME can work with the shim) switch, yes.

> b) New installs should get systemd-sysv as default init with a debconf
> message about alternative init systems.

I think this is not fair, though. CTTE decided that systemd be
the default init system for Linux in jessie “period”. That means
no debconf message required here.

Do note that new installs of kFreeBSD and Hurd should not get
systemd, but what exactly is probably up to the porters for lack
of a CTTE decision in that.

> 1) Fix debootstrap bugs

Yesplease!

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!


--
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.11.1411281257100.10...@tglase.lan.tarent.de

Bug#771308: ITP: libjs-backbone-deep-model -- improved support for models with nested attributes

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-backbone-deep-model
  Version : 0.10.4
  Upstream Author : Charles Davison, Pow Media Ltd, 
* URL : https://github.com/powmedia/backbone-deep-model
* License : Expat
  Programming Lang: Javascript
  Description : Improved support for models with nested attributes

 Deep model is a plugin for the Backbone javascript library, which allows to
 get and set nested attributes with path syntax, e.g. `user.type`. It Triggers
 change events for changes on nested attributes.


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

Bug#771311: ITP: libjs-backbone.stickit -- Backbone data binding plugin that binds Model attributes to View elements

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-backbone.stickit
  Version : 0.7.0
  Upstream Author : The New York Times, Matthew DeLambo 
* URL : https://github.com/NYTimes/backbone.stickit
* License : Expat
  Programming Lang: Javascript
  Description : Backbone data binding plugin that binds Model attributes to 
View elements

 Stickit is a Backbone data binding plugin that binds Model attributes to View
 elements with a myriad of options for fine-tuning a rich app experience.
 Unlike most model binding plugins, Stickit does not require any extra markup
 in your html; in fact, Stickit will clean up your templates, as you will need
 to interpolate fewer variables (if any at all) while rendering. In Backbone
 style, Stickit has a simple and flexible api which plugs in nicely to a View's
 lifecycle.

This is another dependency for OpenStack Fuel.


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

Bug#771313: ITP: libjs-cocktail -- implementation of Backbone mixins

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-cocktail
  Version : 0.5.7
  Upstream Author : Onsi Fakhouri 
* URL : https://github.com/onsi/cocktail
* License : Expat
  Programming Lang: Javascript
  Description : implementation of Backbone mixins

 With Cocktail, it is possible to break out a shared Backbone.js
 model/collection/view behaviors into separate modules and mix them into
 classes with. Cocktail is an implementation of Backbone mixins. Mixins are
 simply bare-bones JavaScript objects that provide additional functionality to
 Backbone objects. Think of them as bags of methods that will get added to all
 instances of objects.

This is another dependency of OpenStack Fuel.


-- 
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/20141128121113.8746.53242.report...@mx.xen01.node0184.gplhost.com

Re: Javascript trigger design

[Thorsten Glaser]

On Fri, 28 Nov 2014, Thomas Goirand wrote:

> It's been a long time I've been thinking about it, and I believe that
> the only way to do this, would be to use triggers. Though I have never

Look at libjs-protoaculous which combines prototype and
scriptaculous into one (possibly minified) js file. In
(our inhouse version of) FusionForge, we just depend on
it, and it contains all the trigger and dependency magic
needed for that.


On Fri, 28 Nov 2014, Ben Finney wrote:

> My understanding is that the Debian JavaScript team is converging on a
> standard for compiling JavaScript (using uglify, I think) as a routine

That’s not good. Various upstreams recommend/require various
minifier tools and say they have had issues with other tools,
e.g. due to the minifiers differing in what they require from
the source code to work without failure.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
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.11.1411281316540.10...@tglase.lan.tarent.de

Bug#771314: ITP: libjs-i18next -- easy way to translate a website on clientside

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-i18next
  Version : 1.7.1
  Upstream Author : Jan Muehlemann 
* URL : http://github.com/i18next/i18next
* License : Expat
  Programming Lang: Javascript
  Description : easy way to translate a website on clientside

 i18next provides an easy way to translate a website on clientside:
  * fetch resources from server
  * fetch each resource file individually (static) or all once via dynamicRoute
  * apply translation to HTML tags with the _data-i18n_ attribute
  * post missing key-value pairs to server (for easy development, just
translate the new keys)
  * search for key en-US first, then in en, then in fallback language (or
de-DE, de, fallback).

This is another dependency of OpenStack Fuel.


-- 
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/20141128121322.8772.29724.report...@mx.xen01.node0184.gplhost.com

Bug#771318: ITP: libjs-requirejs -- uses plain script tags to load modules/files

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-requirejs
  Version : 2.1.9
  Upstream Author : jrburke 
* URL : https://github.com/jrburke/requirejs
* License : BSD-or-MIT
  Programming Lang: Javascript
  Description : uses plain script tags to load modules/files

 RequireJS uses plain script tags to load modules/files, so it should allow for
 easy debugging. It can be used simply to load existing JavaScript files so one
 can add it to existing project without having to re-write JavaScript files.
 .
 RequireJS includes an optimization tool one can run as part of packaging steps
 for deploying code. The optimization tool can combine and minify JavaScript
 files to allow for better performance.

This is another dependency of OpenStack Fuel.


-- 
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/20141128122216.8800.68049.report...@mx.xen01.node0184.gplhost.com

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

[Thorsten Glaser]

On Fri, 28 Nov 2014, Svante Signell wrote:

> It will be interesting to see how many Debian Maintainers and Developers
> will jump the ship and join them (in addition to the users). Future will

I’ll tell you in the present.

Github? Ugh! http://mako.cc/copyrighteous/free-software-needs-free-tools
The rest is just as bad (mailinglists hosted somewhere in the wild too,
etc). And the website is illegible, and I curiously wonder who is behind
all that. But mostly rhetorically, as I’m not really interested…

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)


--
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.11.1411281329280.10...@tglase.lan.tarent.de

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

[Simon Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 28.11.2014 09:43, Svante Signell wrote:

> The official name of the Debian fork is devuan: https://devuan.org 
> It will be interesting to see how many Debian Maintainers and
> Developers will jump the ship and join them (in addition to the
> users). Future will tell...

Well, not me.

While the situation sucks for embedded systems, I doubt this project
will gain sufficient traction to provide a better alternative, so the
result is basically going back to square one and providing the
necessary tools for embedded system development from emdebian.org.

   Simon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iJwEAQECAAYFAlR4cmYACgkQ0sfeulffv7vPKwP+LfoVtVuR9tscjavkpP86A3lL
0ep9JouCVcKir/IYfL4Yl/hpmwMtqerak7KqhGvfLrPogB1VV19oBCC/pU0Cxr8e
ud9CNY7J422dUocr7cD0FEFF7PrRrZHCQ7Jx+v+/y4WmeTg1p/5UGlGuPtEHn5ht
PRVzMQFmvGfUAX74FyA=
=q5r6
-END PGP SIGNATURE-


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

Re: ArchitectureSpecificsMemo

[Riku Voipio]

Hi,

On Thu, Nov 27, 2014 at 10:50:26AM +, Edmund Grimley Evans wrote:
> http://wiki.debian.org/ArchitectureSpecificsMemo
> 
> Some suggestions for improving this table:
> 
> 1. About half of the table is taken up with sizeof information, some
> of which could be expressed more concisely. (Are all Debian
> architectures ILP32 or LP64? Any rare exceptions could be described in
> a footnote.)

Right. Also the recently added float/double/long double columns can be
reduced to to a "float parameters passed via" column, since all three
kind of floats are passed same way.

> 2. Perhaps it would be better to reverse the axes, particularly if the
> sizeof information is simplified and as more and more architectures
> are added.

Ok, makes sense - it also easier to see what arch the actual edit
touched when getting wiki notifications.

I also approve how you changed char,endian and stack direction back
to words instead of single letters. now one doesn't have to read the
legend all the time!

> 3. A link to a list of system calls might be useful for some people.

probably for some other page.

> 4. I'd like to see some information about va_list added as this
> sometimes causes portability problems. For example:

I think it's unwise - to rephrase what Thorsten said, we shouldn't
encourage people to depend on the internals of va_list but use the
va_list api functions and not make assumptions.

Another page documenting va_list differences on architectures might
make sense.

Riku


-- 
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/20141128125024.ga6...@afflict.kos.to

Thank you for the remarkable work on Jessie

[lumin]

Hi debian-devel,

I'm glad to say I just upgraded my machine[1] from wheezy (7.4~5)
directly to current Jessie, and I found this progress is just
painless at all, and no dependency problems remains after upgrade.

There indeed are some configuration issues which I resolved
easily, and I think those issue is not bug.
Besides, I noticed that the init system has been changed from sysvinit
to systemd, and it works very well.

However there's a issue:
Once started the Xorg, it Segfaults right away.
Seems that this is caused by xserver-xorg-video-siliconmotion[3].

For wheezy, I downloaded a tarball[4] from a forum,
and Xorg would not Segfault anymore after applied its contents.
I don't know how to resolve this issue on Jessie to let Xorg work again.
(Please let me know what log/file should I send if someone is interested
in looking into this problem.)

Nevertheless, Thank you for your hard work,
so that Debian users can enjoy those smooth dist-upgrade.

Hurra Debian!

[1] loongson-2f, mipsel architecture
[2] i'm not sure
[3] This problem exists on wheezy too
[4] content: xorg.conf and modified xserver-xorg-video-siliconmotion.deb
-- 
Regards,
  C.D.Luminate


-- 
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/1417179844.2022.1.ca...@gmail.com

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Marco d'Itri]

On Nov 28, Svante Signell  wrote:

> a) Upgrades should _not_ change init: whatever is installed should be
> kept.
I disagree: upgrades should get the default init system unless the 
system administrator chooses otherwise.

> b) New installs should get systemd-sysv as default init with a debconf
> message about alternative init systems.
It would be totally unacceptable to waste the time of every Debian user 
with pointless advertisement.
This can be documented in the release notes, if needed.

-- 
ciao,
Marco


pgpa3iMNK8pLZ.pgp
Description: PGP signature

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Martin Read]

On 28/11/14 11:56, Svante Signell wrote:

3) Add information in release-notes on how to:
- Upgrade from stable/testing/sid to jessie to avoid getting
systemd-sysv installed (this should not strictly be needed if the ctte
chooses to decide that upgrades will _not_ switch init)


This part has already been done; the release notes contain instructions 
on how to pin systemd-sysv to never be installed:


https://www.debian.org/releases/jessie/amd64/release-notes/ch-information.en.html#systemd-upgrade-default-init-system


- Install sysvinit-core after installation and reboot after getting
systemd-sysv as default.


This bit, however, does appear to still need documenting in the Release 
Notes and Installation Guide.



--
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/54787c99.9050...@zen.co.uk

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Niels Thykier]

On 2014-11-28 14:41, Marco d'Itri wrote:
> On Nov 28, Svante Signell  wrote:
> 
> [...]
>> b) New installs should get systemd-sysv as default init with a debconf
>> message about alternative init systems.
> It would be totally unacceptable to waste the time of every Debian user 
> with pointless advertisement.
> This can be documented in the release notes, if needed.
> 

I suspect it would fit better in the "installation-guide".  The
release-notes concerns itself mainly with upgrades and not with "fresh
installs".

~Niels



-- 
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/54787d58.3090...@thykier.net

Bug#771326: ITP: libjs-requirejs-text -- loader plugin for loading text resources

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-requirejs-text
  Version : 2.0.9
  Upstream Author : James Burke 
* URL : https://github.com/requirejs/text
* License : BSD-or-MIT
  Programming Lang: Javascript
  Description : loader plugin for loading text resources

 It is nice to build HTML using regular HTML tags, instead of building up DOM
 structures in script. However, there is no good way to embed HTML in a
 JavaScript file. The best that can be done is using a string of HTML, but that
 can be hard to manage, particularly for multi-line HTML.
 .
 The text.js AMD loader plugin can help with this issue. It will automatically
 be loaded if the text! prefix is used for a dependency.

This is the hopefully last Javascript dependency for OpenStack Fuel.


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

Bug#771325: ITP: libjs-require-css -- requiring and optimization with almond support

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: libjs-require-css
  Version : 0.1.0
  Upstream Author : Guy Bedford 
* URL : https://github.com/guybedford/require-css
* License : Expat
  Programming Lang: Javascript
  Description : requiring and optimization with almond support

 This Javascript library allows the construction of scripts that can require
 CSS, using the simple RequireJS syntax. Require-css is fully compatible with
 IE 6+, Chrome 3+, Firefox 3.5+, Opera 10+, iOS.

This is another dependency of OpenStack Fuel.


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

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Simon Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 28.11.2014 14:41, Marco d'Itri wrote:

>> a) Upgrades should _not_ change init: whatever is installed
>> should be kept.

> I disagree: upgrades should get the default init system unless the
>  system administrator chooses otherwise.

I disagree: This is not safe and can break systems.

I have a system where the network connection is so important that the
pppd is invoked via the inittab, which is a published interface of the
init system and has been for decades. When an upgrade installs
systemd, this machine will simply drop off the network.

Other systems I have have serial consoles only, also configured via
inittab. Installing systemd there will lock me out.

I gladly support systemd as default for new installations, but I think
upgrades should remain safe to install as far as possible.

   Simon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iJwEAQECAAYFAlR4gLkACgkQ0sfeulffv7ts4AQAiLYVwGKyhUpVAvMMpM1aHY/J
mnCjhPhhTr3TgDP5raQUF5PjpYbjD5wTvdPQlN0inq+2cThcLg9oWLTd8Jm1z2mg
CHLItGDJ1VoIFA3Xb2JJtTwb3KVdpd2x6m9+Ibm6Hjvjj/JQKkwdKQ+TVpmL+C2K
r3P87zHHV9sWcSGqlvI=
=N+z1
-END PGP SIGNATURE-


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

Re: Javascript trigger design

[Antonio Terceiro]

On Fri, Nov 28, 2014 at 10:30:40AM +0100, Tomas Pospisek wrote:
> Am 28.11.2014 um 08:19 schrieb Matthias Urlichs:
> > Hi,
> > 
> > Tomas Pospisek:
> >> At least the Ruby On Rails framework notices an updated JS and will
> >> re-compress the whole JS blob from its parts.
> > 
> > Does it call stat() on every constituent of these packed JS files on every
> > web request, or does it do that with a periodic background checker?
> 
> I do not know. Now that I am reading the answers in this thread I'm
> noticing that RoR might be checking the newness of JS scripts depending
> on the mode it's running in (production, testing, dev). In which case
> the trigger mechanism could come into play again. So maybe my statement
> was mistaken. In case anybody intends to make conclusions, s/he really
> needs to look these detail up in the RoR docu.
> *t

In development mode, it will always serve the latest version of those
files in a way that is transparent to the developer, but of course that
has a cost.

For production usage, Rails provides a build-time task that you run to
compile/minify the static assets. So a packaged app should probably run
such task during its postinst; using triggers is a perfect way of
solving this.

Note however that this feature (calle assets pipeline) is optional and
not all Rails apps will use it. Redmine for instance doesn't, partially
because it exists since before the asset pipeline was introduced and
migrating to use it is not always super convenient.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Thorsten Glaser]

On Fri, 28 Nov 2014, Marco d'Itri wrote:

> On Nov 28, Svante Signell  wrote:
> 
> > a) Upgrades should _not_ change init: whatever is installed should be
> > kept.
> I disagree: upgrades should get the default init system unless the 
> system administrator chooses otherwise.

I disagree with you, and so does CTTE, this time: they said
that existing installations should retain their init system
– which goes along with “upgrades should not change the sy‐
sytem state” generall – as much as possible.

> > b) New installs should get systemd-sysv as default init with a debconf
> > message about alternative init systems.
> It would be totally unacceptable to waste the time of every Debian user 
> with pointless advertisement.

I actually have to agree here.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general


--
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.11.1411281511270.10...@tglase.lan.tarent.de

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Matthias Urlichs]

Hi,

Simon Richter:
> I have a system where the network connection is so important that the
> pppd is invoked via the inittab, which is a published interface of the
> init system and has been for decades. When an upgrade installs
> systemd, this machine will simply drop off the network.
> 
> Other systems I have have serial consoles only, also configured via
> inittab. Installing systemd there will lock me out.
> 
Non-standard inittab entries should surely be displayed and warned about,
but IMHO that's not sufficient reason to not switch the other 99.99%
who never touched their inittab.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Ansgar Burchardt]

On 11/28/2014 03:16 PM, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Marco d'Itri wrote:
>> I disagree: upgrades should get the default init system unless the 
>> system administrator chooses otherwise.
> 
> I disagree with you, and so does CTTE, this time: they said
> that existing installations should retain their init system
> – which goes along with “upgrades should not change the sy‐
> sytem state” generall – as much as possible.

No, the ctte did not say that. We had a flamewar about that
interpretation before.

Ansgar


-- 
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/5478853d.3010...@debian.org

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Thorsten Glaser]

On Fri, 28 Nov 2014, Ansgar Burchardt wrote:

> No, the ctte did not say that. We had a flamewar about that
> interpretation before.

That was almost word by word from
https://lists.debian.org/debian-devel-announce/2014/11/msg0.html

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel


--
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.11.1411281523530.10...@tglase.lan.tarent.de

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Stephan Seitz]

On Fri, Nov 28, 2014 at 02:41:23PM +0100, Marco d'Itri wrote:

On Nov 28, Svante Signell  wrote:

a) Upgrades should _not_ change init: whatever is installed should be
kept.

I disagree: upgrades should get the default init system unless the
system administrator chooses otherwise.


Of course not. syslog-ng was not replaced by rsyslog when Debian changed 
the default syslog. The grub1 bootloader was not replaced when Debian 
changed to grub2. If Debian changed from exim to postfix the existing MTA 
would not be changed.


So keep your hands of the init system on upgrades.


b) New installs should get systemd-sysv as default init with a debconf
message about alternative init systems.

It would be totally unacceptable to waste the time of every Debian user
with pointless advertisement.


This question could be part of the expert menu.

Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


signature.asc
Description: Digital signature

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Ansgar Burchardt]

On 11/28/2014 03:24 PM, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Ansgar Burchardt wrote:
>> No, the ctte did not say that. We had a flamewar about that
>> interpretation before.
> 
> That was almost word by word from
> https://lists.debian.org/debian-devel-announce/2014/11/msg0.html

See [1] and [2] and possibly other places.

Ansgar

  [1] https://lists.debian.org/debian-ctte/2014/11/msg00046.html
  [2] https://lists.debian.org/debian-ctte/2014/11/msg00049.html


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

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Neil McGovern]

On Fri, Nov 28, 2014 at 03:24:18PM +0100, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Ansgar Burchardt wrote:
> 
> > No, the ctte did not say that. We had a flamewar about that
> > interpretation before.
> 
> That was almost word by word from
> https://lists.debian.org/debian-devel-announce/2014/11/msg0.html
> 

Hi Thorsten,

I think you may be misreading the text there. They /did not/ say that
the init system should not be switched. I'll try a simplified version
of the resolution below.

0) This is advice, it's non-binding.
1) The previous resolution was silent on automatic switching.
2) We've been asked to decide about automatic switching and...
3) We don't want to decide this while there's a GR going on.
4) Please propose changes which would make new installations get
systemd, and upgrades retain existing init so that...
5) We can decide what to do after the GR is over.

Hope this clarifies.

Neil


-- 
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/20141128143245.go17...@halon.org.uk

Re: Re: systemd, fstab, noauto and nofail

[Jonathan de Boyne Pollard]

 Simon McVittie:

If sshd uses (or can be made to  use) IP_FREEBIND to remove the

> potential dependency on bringing up network interfaces, then
> /lib/systemd/system/ssh.service could have DefaultDependencies=no,
> RequiresMountsFor=/usr /lib /etc, and drop its dependency on
> network.target.

Altering sshd is altering the wrong thing.  This is what FreeBind=true 
in a socket unit and the --bind-to-any option in nosh's 
tcp-socket-listen program are for.



--
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/547887e9.1080...@ntlworld.com

Re: Bug#769907: A small suggestion on constructive engagement [Was, Re: Bug#769907: general: non-sysvinit init systems are made of fail]

[Jonathan de Boyne Pollard]

Octavio Alvarez:

Question: is it safe to say  that systemd doesn't yet support the

> full /etc/fstab specification from util-linux [1]?

Yes; it's safe.  It's also wrong.  But it's quite safe.  (-:


--
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/5478885f.9020...@ntlworld.com

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Marco d'Itri]

On Nov 28, Simon Richter  wrote:

> I disagree: This is not safe and can break systems.
Everything is not safe and can break systems, so this is not a very 
compelling argument.

> I have a system where the network connection is so important that the
> pppd is invoked via the inittab, which is a published interface of the
> init system and has been for decades. When an upgrade installs
> systemd, this machine will simply drop off the network.
I want to warn about non-standard inittab entries with a debconf notice, 
but I have not started working on it yet.

-- 
ciao,
Marco


pgplQ47iFnvR9.pgp
Description: PGP signature

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Thorsten Glaser]

On Fri, 28 Nov 2014, Stephan Seitz wrote:

> Of course not. syslog-ng was not replaced by rsyslog when Debian changed the
> default syslog.

Note that syslog-ng was not the default, but sysklogd (which was)
wasn’t replaced either. Thankfully.

> The grub1 bootloader was not replaced when Debian changed to
> grub2.

Actually, it was, unless you installed the fresh “grub-legacy”
package before upgrading, which was mostly a no-op though. And
forgetting to do so *did* hose some obscure systems.

So, the GRUB 0.x → GRUB2 change is actually a g̲o̲o̲d̲ example of
why the init system ought to be kept on upgrade.

I’ve attached the company-internal documentation (minus one
person name) of the process I used to upgrade virtually all
of our lenny machines straight to wheezy (we mostly skipped
squeeze altogether). It’s MediaWiki syntax. It’s German but
you’ll get rough ideas, enough LC_ALL=C dpkg/apt in there.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg= Debian Lenny → Wheezy Upgrade =
[[Category:HowTos]]

 sudo su -
 exec mksh -l

== Vorab zu prüfen ==

Wenn irgendwelche Software händisch installiert ist, die Python < 2.6 braucht, 
abbrechen oder vorher sicherstellen, daß die Software hinterher mit Python 2.7 
ⓐ noch läuft und ⓑ man die auch dagegen neukompilieren und installieren kann!

== Sicherstellen, daß das lenny komplett up-to-date ist ==

* '''Mindestens einen 2.6.32 Kernel, ggfs. aus lenny-backports, booten!'''

* Nachgucken, welche PostgreSQL-Version(en) installiert und/oder aktiv sind.

* System aktualisieren und aufräumen:

 agus
 apt-get --purge dist-upgrade
 apt-get --purge autoremove
 apt-get --purge clean
 dpkg --audit

Gern auch „von Hand“ mit '''dselect''' interaktiv.

== ggfs. Pakete auf „hold“ setzen ==

 for x in mailman; do print $x hold; done | dpkg --set-selections

== squeeze sources.list draufkopieren ==

Je nach Location (extern vs. im tarent-Netz):

* admin/unix/sources.list/squeeze
* admin/unix/sources.list/squeeze.tarent

Die '''/etc/apt/sources.list''' hierdurch ersetzen. Alle lokalen Anpassungen 
sind eh’ in '''/etc/apt/sources.list.d/*.list'''.

Außerdem die /etc/apt/preferences und ggfs. /etc/apt/preferences.d/** 
leeren/reviewen.

== dpkg aktualisieren, grub-legacy beibehalten, apt-listbugs entfernen ==

apt-listbugs entfernen – es geht während des Upgrades von squeeze auf wheezy 
zwischendrin kaputt, weil seine Dependencies nicht korrekt sind und die Ruby 
1.8 → 1.9.1(really-1.9.3) Migration im Weg ist. Außerdem nervt das eh immer nur.

 agus
 apt-get --purge install dpkg apt-listbugs- grub- grub-legacy

== apt aktualisieren ==

Potentiell ein bißchen tricky, durch einen Bug in APT selber.

 apt-get --purge install apt
 agus

Wenn das nicht klappt:

 apt-get --purge install apt -o APT::Immediate-Configure=no
 agus

== System temporär auf squeeze heben ==

Potentiell ein bißchen tricky, durch einen Bug in APT selber.

 apt-get --purge dist-upgrade

Falls Fehler auftreten, iterativ so lösen:

* E: Could not perform immediate configuration on 'perl'. Please see man 5 
apt.conf under APT::Immediate-Configure for details. (2)
* E: Could not perform immediate configuration on 'perl-modules'. Please see 
man 5 apt.conf under APT::Immediate-Configure for details. (2)

 apt-get --purge install perl -o APT::Immediate-Configure=no
 apt-get --purge dist-upgrade

* E: Could not perform immediate configuration on 'g++-4.4'. Please see man 5 
apt.conf under APT::Immediate-Configure for details. (2)

 apt-get --purge install build-essential -o APT::Immediate-Configure=no
 apt-get --purge dist-upgrade

== Platz schaffen ==

'''Achtung:''' (hier noch) keine postgresql-* Pakete von „autoremove“ entfernen 
lassen!

 apt-get --purge autoremove
 apt-get --purge clean

== ggfs. Pakete auf „hold“ setzen ==

''(wo nötig, Beispiel siehe oben)''

== wheezy sources.list draufkopieren ==

Je nach Location (extern vs. im tarent-Netz):

* admin/unix/sources.list/wheezy
* admin/unix/sources.list/wheezy.tarent

Die '''/etc/apt/sources.list''' ersetzen. Alle lokalen Anpassungen sind eh’ in 
'''/etc/apt/sources.list.d/*.list'''.

Außerdem ''erneut'' die /etc/apt/preferences und ggfs. 
/etc/apt/preferences.d/** leeren/reviewen (da tarent-server für squeeze sie 
noch mit Leben füllen könnte).

== tar und danach(!) dpkg aktualisieren ===

 agus
 apt-get --purge install tar
 apt-get --purge install dpkg
 dpkg --audit

Manchmal mag dpkg nicht, das sieht dann so aus:

 The following packages have unmet dependencies:
  libc6-dev : Breaks: gcc-4.4 (< 4.4.6-4) but 4.4.5-8 is to be installed
 E: Broken packages

Demfalls hilft i.d.R. ein Entfernen von gcc-4.4 (braucht das noch wer? in 
wheezy nichtmals m68k…):

 apt-get --purge install dpkg gcc-4.4-base- -o APT::Immediate-Configure=no
 dpkg --audit

gc

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Stephan Seitz]

On Fri, Nov 28, 2014 at 04:00:42PM +0100, Thorsten Glaser wrote:

On Fri, 28 Nov 2014, Stephan Seitz wrote:
Of course not. syslog-ng was not replaced by rsyslog when Debian 
changed the default syslog.

Note that syslog-ng was not the default, but sysklogd (which was)
wasn’t replaced either. Thankfully.


Are you sure that we didn’t have syslog-ng between sysklogd and rsyslog?  
I’m getting old…



The grub1 bootloader was not replaced when Debian changed to
grub2.

Actually, it was, unless you installed the fresh “grub-legacy”
package before upgrading, which was mostly a no-op though. And
forgetting to do so *did* hose some obscure systems.


Hm, I got the info that a new menu entry was added to the grub1 menu to 
chainload into grub2 (not the boot default). After some testing you had 
to enter a command to install the grub2 bootloader. Without it grub1 was 
active with its menu.lst.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Re: systemd, fstab, noauto and nofail

[Jonathan de Boyne Pollard]

Vincent Danjean:

I found another issue with  systemd and noauto.

> [...]
> Do you think I should do a bugreport ?

Not until you've constructed a far better description, because your 
current description is this:


1. I have several lines in /etc/fstab that all have "noauto".
2. systemd is obeying my "noauto" instruction.
3. "and, at runtime, my photos are not mounted under /media/photos or 
not with the options I specify (I need to check that exactly)"


It should be obvious that this is going to be rejected as a systemd 
bug.  You should (in addition to describing the computer's behaviour 
properly, as you note) find out what part of your system is responsible 
for enacting the mounts, since you explicitly instructed systemd not to 
be, and file the bug against that, if it is indeed a bug.


 * 
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/problem-report-standard-litany.html



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

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

[Svante Signell]

On Fri, 2014-11-28 at 13:48 +0100, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Svante Signell wrote:
> 
> > It will be interesting to see how many Debian Maintainers and Developers
> > will jump the ship and join them (in addition to the users). Future will
> 
> I’ll tell you in the present.
> 
> Github? Ugh! http://mako.cc/copyrighteous/free-software-needs-free-tools
> The rest is just as bad (mailinglists hosted somewhere in the wild too,
> etc). And the website is illegible, and I curiously wonder who is behind
> all that. But mostly rhetorically, as I’m not really interested…

(about devuan)
This has just started, give them some time, please.

>From a comment on the thread about upgrades (that don't belong to the
ctte bugs):
https://lists.debian.org/debian-devel/2014/11/msg01265.html

> Do note that new installs of kFreeBSD and Hurd should not get
> systemd, but what exactly is probably up to the porters for lack
> of a CTTE decision in that.

Maybe it would be a better place for the non-linux debian-ports to be
hosted by devuan (they are currently not release candidates for Jessie):

If Debian ditch all non-linux ports, that would make life easier for all
DMs and DDS:

- no non-linux ports needing other any init than systemd, remove
alternatives
- no requirement for portable code upstream, previously forwarded by DMs
and/or bug reporters.
- no annoying bug reports for patches addressing portability, see above
(mostly ignored anyway).
- ditch all other desktop systems, just go with Gnome
- etc
- 

BTW: why not rename Debian 8 Jessie to Debian Lendows(tm) 1, and perhaps
the whole distribution (Lindows was acquired by M$, that name is taken
already) Note, I'm just kidding, or? Is the Universal OS ship sinking?



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

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Thorsten Glaser]

On Fri, 28 Nov 2014, Stephan Seitz wrote:

> On Fri, Nov 28, 2014 at 04:00:42PM +0100, Thorsten Glaser wrote:
> > On Fri, 28 Nov 2014, Stephan Seitz wrote:
> > > Of course not. syslog-ng was not replaced by rsyslog when Debian changed
> > > the default syslog.
> > Note that syslog-ng was not the default, but sysklogd (which was)
> > wasn’t replaced either. Thankfully.
> 
> Are you sure that we didn’t have syslog-ng between sysklogd and rsyslog?  I’m

Yes.

Although, for most use cases, they’re both too bloated.
On Guillem’s recommendation I’ve switched to inetutils-syslogd
now, and like it so far. When sending to a logserver, you have
to enable that in /etc/default/inetutils-syslogd (for security
reasons), and the logserver can then be e.g. an rsyslogd with
all of its advanced functionality.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
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.11.1411281636390.10...@tglase.lan.tarent.de

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

[Thorsten Glaser]

On Fri, 28 Nov 2014, Svante Signell wrote:

> > Github? Ugh! http://mako.cc/copyrighteous/free-software-needs-free-tools

> This has just started, give them some time, please.

No. If they even consider things like this, there is something
seriously wrong right in the beginning.

> Maybe it would be a better place for the non-linux debian-ports to be
> hosted by devuan (they are currently not release candidates for Jessie):

No. There’s always debian-ports, which I’m told is moving closer
to Debian itself, but for now, keeping those who already are there
in Debian unstable itself is better.

> If Debian ditch all non-linux ports, that would make life easier for all
> DMs and DDS:
> 
> - no non-linux ports needing other any init than systemd, remove
> alternatives
[…]

Uhm… that is not a good idea.

Hey, there are *still* bugs found because of s390 (not s390x).
Portability and variety is g̲o̲o̲d̲!

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


--
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.11.1411281638380.10...@tglase.lan.tarent.de

Re: Thank you for the remarkable work on Jessie

[Paul Wise]

On Fri, Nov 28, 2014 at 9:04 PM, lumin wrote:

> However there's a issue:
> Once started the Xorg, it Segfaults right away.
> Seems that this is caused by xserver-xorg-video-siliconmotion[3].

Please file a bug (severity serious):

http://x.debian.net/howto/report-bugs.html

> (Please let me know what log/file should I send if someone is interested
> in looking into this problem.)

You will need to include the gdb backtrace:

http://x.debian.net/howto/use-gdb.html

-- 
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/caktje6eqbhsv2npjkwmzy0mpmcprezrxl9jtajhxjluoqxh...@mail.gmail.com

Bug#771337: init-scripts: iptables-persistent initialized after psad

[Sven Herzberg]

Package: general
Severity: important

I installed the psad in order to detect port scanning attempts and
– according to the recommendations from https://wiki.debian.org/iptables –
installed my initial set of rule to be loaded by iptables-persistent.

However, in the init script order, psad has priority 20 and
iptables-persistent has 37, which will trigger a warning email because psad
does not find the logging rules in iptables when it starts.

My expectation would be that iptables-persistent gets initialized before
psad.

Kind regards,
Sven

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-042stab093.5 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20141128155500.22460.45910.report...@vm-a.i.cluepunk.com

Bug#771337: init-scripts: iptables-persistent initialized after psad

[gregor herrmann]

Control: reassign -1 psad

On Fri, 28 Nov 2014 16:55:00 +0100, Sven Herzberg wrote:

> I installed the psad in order to detect port scanning attempts and
> – according to the recommendations from https://wiki.debian.org/iptables –
> installed my initial set of rule to be loaded by iptables-persistent.
> 
> However, in the init script order, psad has priority 20 and
> iptables-persistent has 37, which will trigger a warning email because psad
> does not find the logging rules in iptables when it starts.
> 
> My expectation would be that iptables-persistent gets initialized before
> psad.

Sounds like a bug in psad's init script (missing requirement). I'm
reassigning the bug report to the psad package.

Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Various Artists: Fernando Sor Variations Sur Malbrough S En Va T En 
Guerre


signature.asc
Description: Digital Signature

Processed: Re: Bug#771337: init-scripts: iptables-persistent initialized after psad

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 psad
Bug #771337 [general] init-scripts: iptables-persistent initialized after psad
Bug reassigned from package 'general' to 'psad'.
Ignoring request to alter found versions of bug #771337 to the same values 
previously set
Ignoring request to alter fixed versions of bug #771337 to the same values 
previously set

-- 
771337: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771337
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.b771337.14171929962929.transcr...@bugs.debian.org

Re: Bug#771269: ITP: jnr-ffi -- Java library for loading native libraries without writing writing JNI code

[Emmanuel Bourg]

Hi Tim,

I believe we already have that one:

https://packages.qa.debian.org/j/jffi.html


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

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

[Sascha Mester]

The mailinglist of Devuan is not hosted "elsewhere" - it's hosted on the
infrastructure of another GNU/Linux Distribution.

Just call dyne.org in the browser ...





signature.asc
Description: OpenPGP digital signature

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

[Marc Haber]

On Fri, 28 Nov 2014 10:20:22 +0100, Matthias Urlichs
 wrote:
>If you want to convince the systemd people to split that part of systemd-
>-as-pid1 off to a separate library, and/or to properly version that API,
>you should submit an appropriate patch 

You see, I have been an architect and a sysadmin for almost 20 years.
That means that I have a pretty clear image about how I want my
systems to look like and how I want to be able to run my system.

That does not mean that I am able to provide a patch to coax any piece
of software into doing what I want it to do. That's a developer's job.

And even acknowledging those facts does not take away my privilege of
voicing my opinion about how I want my systems to look like and how I
want to be able to run my system. I became a member of Debian thirteen
years ago[1] to be able to bring some of my ideas into Debian proper.

It's not that anybody needs to listen, but nobody is going to tell me
to shut up just because I only know how the result of a job should
look like without being able to do the job myself.

Greetings
Marc

[1] yes, and I know that you were already around when I arrived
-- 
-- !! 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/e1xupsw-0002yu...@swivel.zugschlus.de

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

[Marc Haber]

On Thu, 27 Nov 2014 14:25:46 -0800, Nikolaus Rath 
wrote:
>Would you stop using (random example) apache if it started shipping with
>some often-useful CGI scripts?

I am pretty sure that the apache people would include them with a way
to disable them just in case one does not want them.

And I am also pretty sure that they would not de-implement the Common
Gateway Interface just because people still like to run vulnerable
Matt Wright Scripts from 2002.

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/e1xupus-0002za...@swivel.zugschlus.de

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

[Marc Haber]

On Fri, 28 Nov 2014 08:45:29 +0100, Josselin Mouette 
wrote:
>There is nothing in the FUD that’s still being spread that hasn’t been
>entirely debunked almost a year ago in
>https://wiki.debian.org/Debate/initsystem/systemd
>I have nothing to add to what we wrote at that time.
>
>And I’m tired of people rehashing the same crap just because they can’t
>admit they have been wrong. Systemd is here in jessie, the world didn’t
>fall down like you predicted, and those “bitter rearguard battles” Ian
>warned us about only achieve a single goal: pissing people off,
>including three of those who made this possible by their tireless work. 
>
>This is nothing short of bullying. If you want to help our users, you
>can contribute to debianfork, or you can improve your packages in
>Debian. But spreading your bitterness on development forums is only
>about hurting people.

Your way of communicating is hurting people as usual. Please stop.

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/e1xupvt-0002zi...@swivel.zugschlus.de

Re: successful upgrade to jessie - thanks!

[Marc Haber]

On Fri, 28 Nov 2014 09:30:01 +0100, Matthias Urlichs
 wrote:
>Marc Haber:
>> Updating of such systems has always been a pain, but this time it's
>> going to be a gazillion times more painful.
>> 
>Why? (Seriously.)

Because this time fixing those things is more than just minor changes
in some init script. It's learning and understanding more than just a
few bizarre new concepts.

And this facing a mostly hostile upstream and a Fedora-Centric
community.

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/e1xupxh-0002zs...@swivel.zugschlus.de

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

[Christoph Anton Mitterer]

On Fri, 2014-11-28 at 19:05 +0100, Marc Haber wrote: 
> And I am also pretty sure that they would not de-implement the Common
> Gateway Interface just because people still like to run vulnerable
> Matt Wright Scripts from 2002.

For many things, CGI is actually the only way to run them securely,
since it's the only way to run foreign processes in a container
environment (chroots, etc.) or with user privilege separation.

The poor man alternatives like mod-php5 are nothing which a security
conscious admin would ever use.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Russ Allbery]

Matthias Urlichs  writes:

> Non-standard inittab entries should surely be displayed and warned about,
> but IMHO that's not sufficient reason to not switch the other 99.99%
> who never touched their inittab.

In the server world, I'm pretty sure you are significantly underestimating
the number of systems with a custom inittab, although automatic handling
of all the various ways to spawn a useful serial console would cut down
the numbers somewhat.  But we're pretty late in the release cycle to do
enough analysis to try to figure out what those all are.  (Where I've
worked, this has always been custom, replacing /etc/inittab with a local
configuration file, so the analysis isn't trivial.)

-- 
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/8761dzf9qh@hope.eyrie.org

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

[Axel Wagner]

Hi,

Marc Haber  writes:
> Your way of communicating is hurting people as usual. Please stop.

I respectfully disagree. There was imho nothing in the quoted message
that would warrant a reaction like this.


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

Re: Bug#771099: ITP: cakephp2 -- MVC rapid application development framework for PHP (2.x series)

[Moritz Mühlenhoff]

Maxime Chatelle  schrieb:
> Package: wnpp
> Severity: wishlist
> Owner: Maxime Chatelle 
>
> * Package name: cakephp2
>   Version : 2.5.6
>   Upstream Author : http://cakefoundation.org/
> * URL : http://cakephp.org/
> * License : MIT
>   Programming Lang: PHP
>   Description : MVC rapid application development framework for PHP (2.x 
> series)
>  CakePHP is a flexible model-view-controller rapid application development
>  framework for PHP inspired by Ruby on Rails.

Why a separate source package? cakephp is orphaned, you should rather
adopt it and update it to the most recent upstream release.

Cheers,
Moritz


-- 
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/slrnm7hj5n.3ms@inutil.org

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

[Olav Vitters]

On Fri, Nov 28, 2014 at 07:03:14PM +0100, Marc Haber wrote:
> It's not that anybody needs to listen, but nobody is going to tell me
> to shut up just because I only know how the result of a job should
> look like without being able to do the job myself.

Having a detailed discussion about how systemd should be developed on
debian-devel could get a little bit tiring for some though.

-- 
Regards,
Olav


-- 
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/20141128192412.gc25...@bkor.dhs.org

Re: Summary:Re: Bug#762194: Proposal for upgrades to jessie

[Simon Richter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Am 28.11.2014 15:55, schrieb Marco d'Itri:
> > I have a system where the network connection is so important that the pppd 
> > is invoked via the
inittab, which is a published interface of the init system and has been
for decades. When an upgrade installs systemd, this machine will simply
drop off the network.
> I want to warn about non-standard inittab entries with a debconf notice,
> but I have not started working on it yet.
Excellent, thank you!

   Simon
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iJwEAQECAAYFAlR40l0ACgkQ0sfeulffv7tV1gP/SByNCzmUNh6N0i8C/3aW9Ziq
F2jq7uKuDfNjOa/VlIcj2TPNP4phDyPgEChu6yzstfIutwOOCYbfip72T829anQ2
cixkAKm8cOkbfXHcdPzZZ5g8t2p0+oo0lvA/ixXpj2HFgY6uoTQEXtzlf7gJzfjj
oZWVokDS5awd3zICa1Q=
=h93B
-END PGP SIGNATURE-


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

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

[Philipp Kern]

On Fri, Nov 28, 2014 at 04:40:50PM +0100, Thorsten Glaser wrote:
> Hey, there are *still* bugs found because of s390 (not s390x).

Uhm. s390x is 64bit BE; ppc64 and sparc64 never made it into the archive.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: successful upgrade to jessie - thanks!

[Philipp Kern]

On Fri, Nov 28, 2014 at 07:08:09PM +0100, Marc Haber wrote:
> And this facing a mostly hostile upstream and a Fedora-Centric
> community.

I have observed a mostly hostile Debian community in recent months. I'm not
sure if this jab at Fedora is particularly warranted.

Kind regards
Philipp Kern 


signature.asc
Description: Digital signature

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

[Nikolaus Rath]

Marc Haber  writes:
> On Thu, 27 Nov 2014 14:25:46 -0800, Nikolaus Rath 
> wrote:
>> Would you stop using (random example) apache if it started shipping with
>> some often-useful CGI scripts?
>
> I am pretty sure that the apache people would include them with a way
> to disable them just in case one does not want them.

So what? You can also use systemd without using the tools for NTP,
network configuration, or the journal.

Best,
-Nikolaus

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

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


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

Re: Bug#771099: ITP: cakephp2 -- MVC rapid application development framework for PHP (2.x series)

[Maxime Chatelle]

On Fri, Nov 28, 2014 at 08:27:51PM +0100, Moritz Mühlenhoff wrote:
> Maxime Chatelle  schrieb:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Maxime Chatelle 
> >
> > * Package name: cakephp2
> >   Version : 2.5.6
> >   Upstream Author : http://cakefoundation.org/
> > * URL : http://cakephp.org/
> > * License : MIT
> >   Programming Lang: PHP
> >   Description : MVC rapid application development framework for PHP 
> > (2.x series)
> >  CakePHP is a flexible model-view-controller rapid application development
> >  framework for PHP inspired by Ruby on Rails.
> 
> Why a separate source package? cakephp is orphaned, you should rather
> adopt it and update it to the most recent upstream release.

I'm already adopting cakephp, in fact I just need a sponsor, the last
1.x upstream release is waiting on mentors.d.n

cakephp (1.x series) is still used by peoples (120+ installs in popcon)
and still maintained by upstream. So instead of forcing users to migrate
their webapp I prefer to add alternative. And 2.x series is not
backward compatible with 1.x series.


Regards,
-- 
Maxime Chatelle
gpg: 5111 3F15 362E 13C6 CCDE  03BE BFBA B6E3 24AE 0C5B


--
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/20141128201710.ga4...@hermes.rxsoft.eu

Re: successful upgrade to jessie - thanks!

[Ansgar Burchardt]

Hi,

Marc Haber  writes:
> A few hours of reasearch later (which could have been a few minutes if
> just the community would have been a bit more helpful) it turned out
> they were right: We start kdm via an init script and sysvrc emulation,
> and this does actually break the distinction between multi-user.target
> and graphical.target.
>
> I have yet to find out why runlevel3.target doesn't work either.

runlevel{2,3,4}.target are by default aliases for multi-user.target:

$ /lib/systemd/system % ls -l runlevel*
lrwxrwxrwx 1 root root   15 Nov 18 13:15 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root   13 Nov 18 13:15 runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root   17 Nov 18 13:15 runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root   17 Nov 18 13:15 runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root   17 Nov 18 13:15 runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root   16 Nov 18 13:15 runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root   13 Nov 18 13:15 runlevel6.target -> reboot.target

Ansgar


-- 
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/8738932ep7@deep-thought.43-1.org

Re: successful upgrade to jessie - thanks!

[Marc Haber]

On Fri, 28 Nov 2014 20:55:42 +0100, Philipp Kern 
wrote:
>On Fri, Nov 28, 2014 at 07:08:09PM +0100, Marc Haber wrote:
>> And this facing a mostly hostile upstream and a Fedora-Centric
>> community.
>
>I have observed a mostly hostile Debian community in recent months. I'm not
>sure if this jab at Fedora is particularly warranted.

On #systemd yesterday, it took a mere twelve minutes until I got the
first "maybe your distribution is broken" when I just wanted to debug
a faulty X server.

A few hours of reasearch later (which could have been a few minutes if
just the community would have been a bit more helpful) it turned out
they were right: We start kdm via an init script and sysvrc emulation,
and this does actually break the distinction between multi-user.target
and graphical.target.

I have yet to find out why runlevel3.target doesn't work either.

Thankfully kdm does still have an init script which honored a
strategically placed exit 0.

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/e1xut2e-0004ll...@swivel.zugschlus.de

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

[Martin Steigerwald]

Am Freitag, 28. November 2014, 09:28:39 schrieb Matthias Urlichs:
> Hi,
> 
> Martin Steigerwald:
> > Am Donnerstag, 27. November 2014, 22:30:15 schrieb Vincent Bernat:
> > >  ❦ 27 novembre 2014 22:02 +0100, Martin Steigerwald 
 :
> > > > And well, I also wonder why systemd --user functionality is in the
> > > > *same*
> > > > binary than the PID 1 stuff… but well…
> > > 
> > > Wild guess: because it manages processes like PID 1?
> > 
> > That kind of exchange isn´t productive
> 
> You mean the "wild guess" part? Yes, it's not, but you have to admit that
> "I wonder why systemd --user is the same binary as systemd --system" kindof
> asks for that kind of response – after all, the answer should be obvious;
> it's not as if we started discussing what systemd does (and how) yesterday.

Well, it doesn´t get any more productive. And if you read and understand one 
of my previous posts it would be obvious *why*.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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

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

[Marc Haber]

On Fri, 28 Nov 2014 12:28:19 -0800, Nikolaus Rath 
wrote:
>Marc Haber  writes:
>> On Thu, 27 Nov 2014 14:25:46 -0800, Nikolaus Rath 
>> wrote:
>>> Would you stop using (random example) apache if it started shipping with
>>> some often-useful CGI scripts?
>>
>> I am pretty sure that the apache people would include them with a way
>> to disable them just in case one does not want them.
>
>So what? You can also use systemd without using the tools for NTP,
>network configuration, or the journal.

Is that as "easy" as running current GNOME without systemd, which is
surely possible?

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/e1xusz6-0004ls...@swivel.zugschlus.de

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

[Olav Vitters]

On Fri, Nov 28, 2014 at 10:21:48PM +0100, Marc Haber wrote:
> Is that as "easy" as running current GNOME without systemd, which is
> surely possible?

Much easier. Note that if you want GNOME without systemd, it required
actual effort instead of doing petty jabs on mailing lists. Actual
effort was done amongst others the developers of systemd-shim. Currently
not having systemd and use GNOME is quite easy on Debian.

-- 
Regards,
Olav (GNOME release 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/20141128213622.gd25...@bkor.dhs.org

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

[Adam Borowski]

On Fri, Nov 28, 2014 at 10:36:22PM +0100, Olav Vitters wrote:
> On Fri, Nov 28, 2014 at 10:21:48PM +0100, Marc Haber wrote:
> > Is that as "easy" as running current GNOME without systemd, which is
> > surely possible?
> 
> Much easier. Note that if you want GNOME without systemd, it required
> actual effort instead of doing petty jabs on mailing lists. Actual
> effort was done amongst others the developers of systemd-shim. Currently
> not having systemd and use GNOME is quite easy on Debian.

Uh?
gnome-settings-daemon → libpam-systemd → systemd

(There's more to systemd than just pid 1.)

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
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/20141128222911.ga10...@angband.pl

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

[Matthias Klumpp]

2014-11-28 23:29 GMT+01:00 Adam Borowski :
> On Fri, Nov 28, 2014 at 10:36:22PM +0100, Olav Vitters wrote:
>> On Fri, Nov 28, 2014 at 10:21:48PM +0100, Marc Haber wrote:
>> > Is that as "easy" as running current GNOME without systemd, which is
>> > surely possible?
>>
>> Much easier. Note that if you want GNOME without systemd, it required
>> actual effort instead of doing petty jabs on mailing lists. Actual
>> effort was done amongst others the developers of systemd-shim. Currently
>> not having systemd and use GNOME is quite easy on Debian.
>
> Uh?
> gnome-settings-daemon → libpam-systemd → systemd
>
> (There's more to systemd than just pid 1.)

I think he meant systemd, the PID 1 specifically here.
As for the other parts: You couldn't have GNOME without ConsoleKit or
GTK+ before either...


--
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/caknhny9qf1kuvn1o6jhafxrdrgbjsq344nrv37tdmauw7se...@mail.gmail.com

Re: Javascript trigger design

[Thomas Goirand]

On 11/28/2014 08:20 PM, Thorsten Glaser wrote:
> On Fri, 28 Nov 2014, Thomas Goirand wrote:
> 
>> It's been a long time I've been thinking about it, and I believe that
>> the only way to do this, would be to use triggers. Though I have never
> 
> Look at libjs-protoaculous which combines prototype and
> scriptaculous into one (possibly minified) js file. In
> (our inhouse version of) FusionForge, we just depend on
> it, and it contains all the trigger and dependency magic
> needed for that.

Hi!

Thanks for the pointer. I just had a look, let me make sure I understand
how it works now. So if I understand well (by reading your example
package), the only thing I have to do (for horizon) is:

1/ Create a debian/openstack-dashboard.triggers that would contain a
list of "interest /usr/share/javascript/", for example:

interest /usr/share/javascript/jsencrypt

then I'd get triggered in my postinst, and then I should do:

2/ in debian/openstack-dashboard.postinst, implement something like:

if [ "$1" = "triggered" ] ; then
/usr/share/openstack-dashboard/manage.py compress --force
fi

Is it *that* simple?

Cheers,

Thomas Goirand (zigo)


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

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

[Nikolaus Rath]

Marc Haber  writes:
> On Fri, 28 Nov 2014 12:28:19 -0800, Nikolaus Rath 
> wrote:
>>Marc Haber  writes:
>>> On Thu, 27 Nov 2014 14:25:46 -0800, Nikolaus Rath 
>>> wrote:
 Would you stop using (random example) apache if it started shipping with
 some often-useful CGI scripts?
>>>
>>> I am pretty sure that the apache people would include them with a way
>>> to disable them just in case one does not want them.
>>
>>So what? You can also use systemd without using the tools for NTP,
>>network configuration, or the journal.
>
> Is that as "easy" as running current GNOME without systemd, which is
> surely possible?

Much easier, the comparison does not really make sense. Running systemd
without the extra tools is about as easy as running systemd without
Gnome.

Best,
Nikolaus

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

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


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

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

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 27, 2014 at 10:02:06PM +0100, Martin Steigerwald wrote:
> And well, I also wonder why systemd --user functionality is in the *same* 
> binary than the PID 1 stuff… but well… I brought this upstream to no avail.
OK, since this is a different forum, let me go over the reasons once again.

The code paths in systemd which differ between --system and --user are
relatively small. One part that is the table of paths where to load
units from (/etc/systemd/system vs. /etc/systemd/user, /run/systemd/system
vs $XDG_RUNTIME_DIR/systemd/user, etc). Another part says (grossly simplyfying)
if ("--system" && !test_mode && !virtualized_in_container())
 setup_filesystems();
But those are just a few (important, but still) parts of the code. The
majority, like the unit dependency logic, starting of processes,
notifications from services, opening of sockets, watching of paths,
etc, etc, are all shared.  Actually systemd --user is probably closer
to systemd --system running in a container than to systemd --system
running on the host, because both run without full privileges and
simply skip mounting of various things and other low-level setup.

In this scenario it is natural to structure the code as a single binary
that conditionalized parts of it logic as necessary.

> At least the logind stuff appears to be separate:
Yes, logind does not share many high-level code paths with the systemd
binary, so it is natural to keep them separate.

OTOH, systemd and systemd-logind use the same primitives like string
handling, configuration file parsing (including the logic of drop-in
directories and /etc-overrides-/run-overrides-/usr/lib), and a bunch
of other utility functions, which are provided by the shared systemd
libraries, so it is much easier to develop them in a single repository.

I hope this explains things.

Zbyszek


-- 
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/20141129003222.gh12...@in.waw.pl

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

[Cameron Norman]

On Fri, Nov 28, 2014 at 4:32 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Nov 27, 2014 at 10:02:06PM +0100, Martin Steigerwald wrote:
>> And well, I also wonder why systemd --user functionality is in the *same*
>> binary than the PID 1 stuff… but well… I brought this upstream to no avail.
> OK, since this is a different forum, let me go over the reasons once again.
>
> The code paths in systemd which differ between --system and --user are
> relatively small.
>
> [snip]
>
> The
> majority, like the unit dependency logic, starting of processes,
> notifications from services, opening of sockets, watching of paths,
> etc, etc, are all shared.  Actually systemd --user is probably closer
> to systemd --system running in a container than to systemd --system
> running on the host, because both run without full privileges and
> simply skip mounting of various things and other low-level setup.
>
> In this scenario it is natural to structure the code as a single binary
> that conditionalized parts of it logic as necessary.

+1

>
>> At least the logind stuff appears to be separate:
> Yes, logind does not share many high-level code paths with the systemd
> binary, so it is natural to keep them separate.
>
> OTOH, systemd and systemd-logind use the same primitives like string
> handling, configuration file parsing (including the logic of drop-in
> directories and /etc-overrides-/run-overrides-/usr/lib), and a bunch
> of other utility functions, which are provided by the shared systemd
> libraries, so it is much easier to develop them in a single repository.

Do you really think logind and systemd are the only pieces of C
software that struggle with strings or config parsing? Those are
definitely a couple of things that could be split out into a separate
library so we all do not have to either (a) suffer through it,
tediously writing another solution or (b) throw our software in
systemd's git repo and use the same release cycle and license and all
the other implications of being in the same repo (including not having
commit access to your own software automatically).

The config aspects especially so. It would be very positive if
software knew they could just depend on a really simple library and
get config parsing for basically free, since then users would
eventually only have to know how to write one config format and
software would only have to know how to read (parse) that same one.

I do not know why I am discussing this here though, haha.

Cheers,
--
Cameron Norman


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

Re: Thank you for the remarkable work on Jessie

[lumin]

On Sat, 2014-11-29 at 00:08 +0800, Paul Wise wrote:
> Please file a bug (severity serious):

Yes, filed this bug at:
#771387: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771387

-- 
Regards,
  C.D.Luminate


-- 
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/1417227159.2059.3.ca...@gmail.com

Re: successful upgrade to jessie - thanks!

[Alexandre Detiste]

Le vendredi 28 novembre 2014, 22:25:28 Marc Haber a écrit :
> We start kdm via an init script and sysvrc emulation,
> and this does actually break the distinction between multi-user.target
> and graphical.target.

Hi,

Here is a native kdm service I'v copied from an other distro months ago;
and used daily since.

In theory it should go in /etc/systemd/system/ ,
but I guess that if you put it in /lib/systemd/system/ ;
it will then be overwriten by dpkg once the package
ship a native service.

What begs me is that it actually works fine,
without something matching the lengthlty setup_config() in init script;
that is not replicated here.

FYI: There is a more elaborate patch linked to this open bug report:
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=kdm-systemd.diff;att=1;bug=754314

Alexandre Detiste
[Unit]
Description=KDM Display Manager
Conflicts=getty@tty1.service
After=systemd-user-sessions.service getty@tty1.service plymouth-quit.service

[Service]
ExecStart=/usr/bin/kdm -nodaemon
Restart=always
IgnoreSIGPIPE=no

[Install]
Alias=display-manager.service
WantedBy=multi-user.target

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

[Marc Haber]

On Fri, 28 Nov 2014 23:49:58 +0100, Matthias Klumpp
 wrote:
>I think he meant systemd, the PID 1 specifically here.

No.

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/e1xuc3j-0005ub...@swivel.zugschlus.de

Re: successful upgrade to jessie - thanks!

[Marc Haber]

On Fri, 28 Nov 2014 22:33:08 +0100, Ansgar Burchardt
 wrote:
>Marc Haber  writes:
>> A few hours of reasearch later (which could have been a few minutes if
>> just the community would have been a bit more helpful) it turned out
>> they were right: We start kdm via an init script and sysvrc emulation,
>> and this does actually break the distinction between multi-user.target
>> and graphical.target.
>>
>> I have yet to find out why runlevel3.target doesn't work either.
>
>runlevel{2,3,4}.target are by default aliases for multi-user.target:
>
>$ /lib/systemd/system % ls -l runlevel*
>lrwxrwxrwx 1 root root   15 Nov 18 13:15 runlevel0.target -> poweroff.target
>lrwxrwxrwx 1 root root   13 Nov 18 13:15 runlevel1.target -> rescue.target
>lrwxrwxrwx 1 root root   17 Nov 18 13:15 runlevel2.target -> multi-user.target
>lrwxrwxrwx 1 root root   17 Nov 18 13:15 runlevel3.target -> multi-user.target
>lrwxrwxrwx 1 root root   17 Nov 18 13:15 runlevel4.target -> multi-user.target
>lrwxrwxrwx 1 root root   16 Nov 18 13:15 runlevel5.target -> graphical.target
>lrwxrwxrwx 1 root root   13 Nov 18 13:15 runlevel6.target -> reboot.target

Which significantly changes things in Jessie since the majory of
services is still started via the old rcX.d mechanism, and thus
starting to runlevels behaves completely different from what users
expect.

This is bad.

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/e1xuc8j-0005uv...@swivel.zugschlus.de

Embedded systems and systemd

[Josh Triplett]

Simon Richter wrote:
> On 28.11.2014 09:43, Svante Signell wrote:
> > The official name of the Debian fork is devuan: https://devuan.org 
> > It will be interesting to see how many Debian Maintainers and
> > Developers will jump the ship and join them (in addition to the
> > users). Future will tell...
> 
> Well, not me.
> 
> While the situation sucks for embedded systems, I doubt this project
> will gain sufficient traction to provide a better alternative, so the
> result is basically going back to square one and providing the
> necessary tools for embedded system development from emdebian.org.

Why, precisely, do you foresee future problems with embedded systems
development?  Personally, I'm looking forward to a much easier time
building future embedded systems using systemd, or the occasional
too-small-for-anything-else embedded system (that couldn't run standard
sysvinit or Debian for that matter) using a dedicated
init=/custom-program.

If you've actually evaluated systemd for embedded systems applications
and run into issues, please consider filing bug reports or raising
issues on the upstream mailing list; that's a use case I'm interested in
as well, and I'd be happy to help.

- Josh Triplett


-- 
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/20141129070620.GA8027@thin

Re: successful upgrade to jessie - thanks!

[Matthias Urlichs]

Hi,

Marc Haber:
> It's learning and understanding more than just a few bizarre new concepts.
> 
I learned. I (think I) understand. But I do not think these fancy new
concepts are bizarre at all. If anything, they make my life way easier.

If anything, IMHO using words like "bizarre" isn't exactly conductive
to rational dialogue …

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Re: Javascript trigger design

[Jonas Smedegaard]

Quoting Thorsten Glaser (2014-11-28 13:20:36)
> On Fri, 28 Nov 2014, Thomas Goirand wrote:
> 
>> It's been a long time I've been thinking about it, and I believe that 
>> the only way to do this, would be to use triggers. Though I have 
>> never

> Look at libjs-protoaculous which combines prototype and scriptaculous 
> into one (possibly minified) js file. In (our inhouse version of) 
> FusionForge, we just depend on it, and it contains all the trigger and 
> dependency magic needed for that.

Just looking at the package name that seems not an ideal aproach: Should 
we then make packages for each combination of libraries to be merged 
together, or am I missing a more clever logic?  Or do you perhaps point 
at that package not suggesting duplicating it but instead cherry-picking 
triggers for a system-wide structure?


> On Fri, 28 Nov 2014, Ben Finney wrote:
> 
>> My understanding is that the Debian JavaScript team is converging on 
>> a standard for compiling JavaScript (using uglify, I think) as a 
>> routine
>
> That’s not good. Various upstreams recommend/require various minifier 
> tools and say they have had issues with other tools, e.g. due to the 
> minifiers differing in what they require from the source code to work 
> without failure.

I agree that too strong standardization is not good - and I disagree 
with the interpretation that the Javascript team is moving towards such 
standardization.

That said, I do believe Uglifyjs is the best compressor we have, and 
recomend to treat it as a "default" similar to newest GCC for C - i.e. 
use Uglifyjs unless all of...

  * code is complex, and
  * upstream tests only only against an alternate compressor which is
available in Debian, and
  * no testsuite with decent coverage and usable for us on build 
daemons


 - 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

Bug#771398: ITP: ruby-redis-activesupport -- Redis store for ActiveSupport::Cache

[Balasankar C]

Package: wnpp
Severity: wishlist
Owner: Balasankar C 

* Package name: ruby-redis-activesupport
  Version : 4.0.0
  Upstream Author : Luca Guidi 
* URL : https://github.com/redis-store/redis-activesupport
* License : Expat
  Programming Lang: Ruby
  Description : Redis store for ActiveSupport::Cache


-- 
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/20141129074851.31910.66496.reportbug@sasalam

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

[Vincent Bernat]

 ❦ 28 novembre 2014 22:21 +0100, Marc Haber  :

>>So what? You can also use systemd without using the tools for NTP,
>>network configuration, or the journal.
>
> Is that as "easy" as running current GNOME without systemd, which is
> surely possible?

systemd-timesyncd and systemd-networkd are disabled by default, at least
in Debian. You can disable systemd-journald as well if you wish.
-- 
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Embedded systems and systemd

[Tollef Fog Heen]

]] Josh Triplett 

> Simon Richter wrote:
> > On 28.11.2014 09:43, Svante Signell wrote:
> > > The official name of the Debian fork is devuan: https://devuan.org 
> > > It will be interesting to see how many Debian Maintainers and
> > > Developers will jump the ship and join them (in addition to the
> > > users). Future will tell...
> > 
> > Well, not me.
> > 
> > While the situation sucks for embedded systems, I doubt this project
> > will gain sufficient traction to provide a better alternative, so the
> > result is basically going back to square one and providing the
> > necessary tools for embedded system development from emdebian.org.
> 
> Why, precisely, do you foresee future problems with embedded systems
> development?  Personally, I'm looking forward to a much easier time
> building future embedded systems using systemd, or the occasional
> too-small-for-anything-else embedded system (that couldn't run standard
> sysvinit or Debian for that matter) using a dedicated
> init=/custom-program.

I'm not Simon, but one valid argument I've heard is that embedded stuff
has a tendency to get stuck on old vendor kernels, something that
doesn't work so well when systemd uses newer kernel interfaces.

Apart from «don't use new kernel interfaces» (something that upstream
won't do, ditto for adding workarounds fro old kernels), I don't really
see this as easily fixable.

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


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