gmane.linux.debian.devel.general

Bug#709539: ITP: deltarpm -- Tools to create and apply deltarpms

Mike Miller — 2013-05-23T21:47:35

Package: wnpp
Severity: wishlist
Owner: Mike Miller <mtmiller< at >ieee.org>

* Package name    : deltarpm
  Version         : 3.5
  Upstream Author : Michael Schroeder <mls< at >suse.de>
* URL             : http://gitorious.org/deltarpm/deltarpm
* License         : BSD
  Programming Lang: C, Python
  Description     : Tools to create and apply deltarpms

 A deltarpm contains the differences between an old and a new version of
 an RPM. This makes it possible to recreate the new RPM from the
 deltarpm and the old RPM.
 .
 On Debian and derived systems these tools may be useful for creating
 and maintaining repositories of RPM packages.


This package is a dependency of the latest version of createrepo (#673958) and
will be a dependency of the next version of yum.

Re: Bwaaaaah I will tell my daddy^W^Wthe CTTE^W^Wa GR

Benjamin Drung — 2013-05-23T21:38:52

Am Donnerstag, den 23.05.2013, 08:51 +0200 schrieb Bjoern Meier:

Ondřej Surý is not spamming. He raises an important issue. Insults and
disrespectful behavior on debian-devel are not welcome. There is no
excuse for such behavior. You might have a thick skin and disagree, but
not everyone is happy to deal with bad manners. So I ask for
considerateness.

Re: Debian systemd survey

Josselin Mouette — 2013-05-23T21:18:04

Le jeudi 23 mai 2013 à 22:06 +0200, Marc Haber a écrit : 

I’d bother answering to that, but Lennart already did. Myth #1:
http://0pointer.de/blog/projects/the-biggest-myths.html

Systemd is just as much monolithic as, say, coreutils.

Re: Debian systemd survey

Miroslaw Baran — 2013-05-23T20:40:45

…and politics.

– Jubal

Re: Debian systemd survey

Thomas Goirand — 2013-05-23T20:21:59

I don't think that taking any random bug (which is a "can", not
"always") is fair.


I believe that is a very strong thing in *favor* of OpenRC.

Why on earth do you need to reimplement the PID 1 for booting your
system? It works very well, and doesn't need to be changed and
over-engineered. All the logic is done away from it, in its child PIDs,
because PID 1 is a very dangerous place to hack (if it crashes, your
whole system is dead).


Actually, I believe that OpenRC transition should be one of the most
smooth of all the init systems, once the port to Debian is done, and
when the support for existing LSB header is tackled (we already have
some script in both python and perl to handle automatic conversion of
the LSB header).

Meaning that we could simply replace sysvrc with OpenRC, have all the
nice added features (cgroups, nicer headers than LSB headers, tiny small
init scripts), and still continue to have the possibility to keep large,
bulky init scripts, if that is your thing. They all coexist together,
you just decide what you wish to implement.

What I like the most with it is that it is very, very simple, and easy
to hack.

I think I wrote too much already. I would prefer to be able "it does"
rather than "it could".

Thomas

Re: Debian systemd survey

Thomas Goirand — 2013-05-23T20:07:06

Sorry, that is probably badly translated from French. I meant as
argumentation, or "discussion point". I'm not sure if you got it now.
There was nothing about insults or anything like this.


It's not this way. Last time I checked, there was another upstream doing
about 30% of the work. The rest of is probably small patches contributed
here and there. Run

The facts are that there's no "big community" working on Systemd.
There's 2 main authors, and a crowd sending smaller (tiny?) contributions.


I'm still not convinced. Don't trust the lies from Lennart, the git
clone tells the truth:

4528 Lennart Poettering <lennart< at >poettering.net>
3291 Kay Sievers <kay< at >vrfy.org>
676 Greg KH <greg< at >kroah.com>
541 Zbigniew Jędrzejewski-Szmek <zbyszek< at >in.waw.pl>
274 Michal Schmidt <mschmidt< at >redhat.com>
190 Martin Pitt <martinpitt< at >gnome.org>
171 Harald Hoyer <harald< at >redhat.com>

There is no other contributor that has done more than 100 patches. If
you count people who contributed even a single patch, there's in total
421 "contributors" (but that is not the point, is it?).

(just did a "git pull" before running the stats...)

BTW, why did you make me repeat myself? Couldn't you search in the list
archive? And in what way is this a technical argumentation to choose a
init system? What are you trying to prove here?

Thomas

Re: Debian systemd survey

Marc Haber — 2013-05-23T20:06:19

On Thu, 23 May 2013 19:34:09 +0200, Matthias Klumpp
<matthias< at >tenstral.net> wrote:

Yes, systemd trying to replace so much of traditional UNIX tools at
once and so blatantly breaking the "One job one tool" principle that
has made our platform so successful is one major part of the
acceptance issues that systemd has in Debian.

Greetings
Marc

Re: Debian systemd survey

Steve Langasek — 2013-05-23T19:50:00





The problem isn't that your statements are false, it's that they're twisted
propaganda.  A large number of contributors to an *init system* is not
something that should be a goal in and of itself.  There's a certain level
of sustainability that we should be concerned about meeting; but that
doesn't require a community of hundreds of committers.  Feel free to check
how many committers sysvinit has had over the past decade - we're pushing to
move away from sysvinit not because it didn't have enough committers, but
because we believe a new architecture is needed.

Furthermore, the statistics for systemd are themselves a distortion.  The
only reason Lennart shows up as being responsible for a minority of the code
in systemd is because systemd gobbled up udev whole.  If we look at line
count rather than number of commits (which I would argue is a better
measure), and exclude the udev code, we get:

$ find . -name '*.c'|grep -v udev | xargs -n1 git blame --line-porcelain \
  | sed -n 's/^author //p' | sort | uniq -c | sort -rn | head -n1
 120124 Lennart Poettering
$ find . -name '*.c'|grep -v udev | xargs wc -l | tail -n1
 153404 total
$

And even then, that includes dbus services and other things not related to
the init daemon.

78% is not a minority.  But this isn't the statistic that gets trotted out
by people advocating for systemd; instead, they always cherry-pick the
statistics that paint it in the most favorable light.  Because systemd
advocates are not trying to win on technology, they're trying to win on
marketing.


Also worth noting:

~/systemd$ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' \
           | xargs wc -l | tail -n1
 149081 total
$ find . -name '*.c' | grep -vE 'tests|test/|intl/|udev/' | xargs wc -l \
  | tail -n1
 31282 total
$

Yep, systemd has a larger community of contributors... and weighs in at
nearly 5 times the code base.  Which of these is the more important
attribute for an init, I wonder?

Disclaimer: this comparison will catch files that are not part of init.
Feel free to slice and dice this differently to make the case that systemd
init is not bloated... and publish your methodology so we can be sure to
check how many committers that section of the code actually has.



Ohloh statistics are of dubious value.  Counting contributors to upstart
using a more direct method shows me 17 committers - small but not miniscule,
and not a mark of an unsustainable project.  I'm not going to bother
generating stats showing who's contributed how many lines to this, because I
don't think that's actually the useful metric - I just object to people
claiming this high ground for systemd when it's not materially true.  Feel
free to run these stats yourself if you wish.

Re: Algorithm for selecting between packages providing the same phpapi-20100525, change between squeeze -> wheezy

David Kalnischkies — 2013-05-23T18:57:45

(funny, talk without end about init systems, but not a single response
 for a Debian native tool for a few days… and with funny, I meant sad)

On Mon, May 20, 2013 at 3:16 PM, Ondřej Surý <ondrej< at >sury.org> wrote:

apt and aptitude are not the same program and have very different
behavior even through they share a 3 letter prefix and a library in
various areas, so don't assume that what I am saying about the
resolver in libapt which apt-get is using has anything to do with aptitude
which has its own or the various other libapt front-ends which might or
might not use the solver, or use it differently.
(Ignoring that most of them could use an external solver)

[…]

Actually, its not ignoring the Priority, in fact it sorts by Priority, just
that the order changed "recently" (Nov 2011). A certain individual –  who
I am not going to call out in public to protect him from the lynch-mob –
made the mistake of changing the code to sort lowest priority first …
(fixed in his branch now & added to the wheezy-maybe list)



This is indeed the recommend solution if you have a default as nowhere is
defined which provider of a priority is chosen. While priority might be an
obvious and easy choice for solvers working with a heuristic, I wouldn't be
surprised if more deterministic solvers would go for the least 'changes'
instead which might not be an optimal "default" choice.
Maybe you want to try it with: apt-get install $whatever --solver $solver
[where $solver is likely "aspcud" as we haven't that much more so far]

Also: build-dependencies, but that is probably not an issue for PHP.



Best regards

David Kalnischkies

Bug#709514: ITP: php5-stomp -- stomp module for PHP 5

Jonas Genannt — 2013-05-23T18:01:41

Package: wnpp
Severity: wishlist
Owner: Jonas Genannt <jonas.genannt< at >capi2name.de>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

* Package name    : php5-stomp
  Version         : 1.0.5
  Upstream Author : Pierrick Charron <pierrick< at >php.net>
* URL             : http://pecl.php.net/package/stomp
* License         : PHP License 3.01
  Programming Lang: C
  Description     : stomp module for PHP 5

 This extension allows php applications to communicate with any
 Stomp compliant Message Brokers through easy object oriented and
 procedural interfaces.


The package will be maintained wihtin the pkg-php group.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRnlmBAAoJEPBM7/YBbP/QuWYP/3SYbCnGgJzhSyMMliMUzdaY
BYW9hGXm1krlGVelModqfthvRyCfnyrJSgwcySCWxKzi3Jmd9DpaeK6ptu8Llw8n
6Dzr45Nzuada+2sOx/5aH8MRsvrBVAj1VXPORaB1n9V5nxbw/xAwXU0G0A5Ddleo
VxJHRsa/THyZMvgdc1BiU6uPtGQNFiXf0A0YpL6iqABk0MJhv4sQkf4Da1z/3kAr
FZdt+tQwxEBqqviZ361NmMXrJ29TAPlOVeOppdfbXfh6xyEbKDMAHzBYwPzDU3nw
c93cpiStm5HT08UmQ9XYSS19mZO95DAwL/hrWNuyKzevKjTmoIvXYC9V1VspdTGX
bSnFrgLAVWFTkugNybEboaeCNX/7e0gApU30gI5XT6TqSFOb+gyCJaZePxLFWqQD
wo4aZca9LKIWBZtzG3VYsrVphI/U+p0b7GAvcSyN+nbRyvuYbkZH02vsnsjvr74d
b4Nyvj15K9XZhvDU8vw9I+J7ZcQgO+Xfkvmb0QeahJMZ/Fx2YARXBKlBGSLB8AWA
d6ipD8txxIib88boCPOikY0iw56kfioBo9INjFValG8kOaQg9Bl3pZSpBQ87px8u
56qmJZVUhcd16y3NvAIjKblrnHujrwDJ1fT8OSHvI1voAGGhiCnlOA2DBO59pinJ
c4SdvVO8/10lrnZb5f67
=Hhsi
-----END PGP SIGNATURE-----

Re: Debian systemd survey

Matthias Klumpp — 2013-05-23T17:34:09

2013/5/23 Marc Haber <mh+debian-devel< at >zugschlus.de>:
One of the great goals of systemd is to unify init-"scripts" on all
Linux systems. The systemd unit files are entirely declarative and
work the same way on all Linux distributions (I recently spoke with
Mageia, Fedora and OpenSUSE people about how well this works - very
well so far :) )
And that is the reason why they can be shipped upstream. If some
tweaking is needed, the changes can even be upstreamed again, so
everyone benefits from the changes.
Cheers,
    Matthias

P.S: < at >all: Please keep in mind that systemd is not just an init
system, but contains many other buiĺding blocks to create an operating
system, e.g. journald to create better syslogs (it forwards messages
to traditional syslog, so no worries about binary stuff), logind as
replacement for ConsoleKit and to finally get multiseat support
working again, hostnamectl, udev and many other tools & daemons which
make it much nicer to administer a system and to abstract differences
between distributions (which makes writing applications (for Linux) so
much better...).

Re: Debian systemd survey

Andrey Rahmatullin — 2013-05-23T17:29:34

That's one of the most important problems with sysvinit.

Re: Debian systemd survey

Marc Haber — 2013-05-23T17:07:16

On Wed, 22 May 2013 19:40:57 +0200, Matthias Klumpp
<matthias< at >tenstral.net> wrote:

Are those any better than init scripts shipped by upstream? How many
Debian packages use upstream init scripts verbatim?

Greetings
Marc

Re: Debian systemd survey

Martin Wuertele — 2013-05-23T16:29:13

* Philipp Kern <pkern< at >debian.org> [2013-05-23 15:39]:


True, I should have followed George Carlins advice and not argued.

Bug#709507: ITP: ruby-html2haml -- Convert HTML into HAML

Gunnar Wolf — 2013-05-23T16:28:29

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf <gwolf< at >gwolf.org>

* Package name    : ruby-html2haml
  Version         : 1.0.1
  Upstream Author : Norman Clarke <norman< at >njclarke.com>
* URL             : https://github.com/haml/html2haml
* License         : MIT
  Programming Lang: Ruby
  Description     : Convert HTML into HAML

This package was split by its upstream author from the 'Haml' gem
(package ruby-haml). It allows converting between HTML and HAML
markups, and while mainly aimed at being used within Ruby code,
includes an executable wrapper that allows it to be called from the
command line.

Re: Debian systemd survey

Barry Warsaw — 2013-05-23T16:22:42


I don't think it's necessarily a bad thing for Debian and Ubuntu to have this
kind of symbiotic relationship.  Maybe from a Debian point of view, it
shouldn't be necessary, but given the current realities of differing release
schedules, goals, focus, and resources, where such an arrangement exists, I
think it can - and should - be used for mutual benefit.

This of course requires good coordination between the parties involved in both
distributions, and motivated people in both camps that want to strengthen
collaboration.  Of course, some folks will only have feet in one or the other,
and that's fine too.

Some recent examples include transitions we've seen in the Python world.  The
push for dh_python2, the push for Python 3 support, and the transition to
newer versions of the interpreter are all great examples (IMHO) where Debian
and Ubuntu worked together to come to some semblance of consensus, and where
Ubuntu, by benefit of its timed release schedule was able to be more
aggressive in adopting some of those transitions.  It was also able to
experience and alleviate some of the pain first too.  But this was *always*
done with the goal of ensuring those changes would get pushed back into Debian
when the time was right.  In such cases, the assistance, insight, expertise,
resources, and feedback of experienced Debian developers was crucial.

It's usually (but not always) easier to get changes that appear in Debian
first, migrated into Ubuntu.  IME, it's often harder to get changes from
Ubuntu into Debian.  I think there's ample opportunity to help make this
barrier lower on both sides of the pond.  Some of the hurdles include:

- Team based vs. individual maintainership.  In Ubuntu, no one person (or
  group of people) maintains any package.  There's a strong sense of team for
  maintaining packages.  This has an advantage in that important updates need
  not block on availability, workload, vacations, etc. of individual
  maintainers (not that it can't block on other reasons).  In Debian, teams
  like PAPT and DPMT do help with this.

- Membership differences.  I am currently sitting on the Ubuntu Developer
  Membership Board, and I am in the final stages of my DD application.
  Applying for DD was way more thorough than achieving core-dev in Ubuntu.
  Now, this may or may not be a good thing, but one of the key things that the
  DMB is addressing is how to streamline approval for DDs.  It should be
  fairly clear that a DD has the requisite technical expertise to package
  things for Ubuntu, so the initial interaction with the DMB can (mostly)
  accept that as a given, and thus explore other requirements of Ubuntu
  membership.  Hopefully (and I'd like to hear if otherwise) this means that a
  DD who wants to also contribute to Ubuntu, should be able to get the needed
  permissions fairly quickly and easily.  In Debian, it would be nice if the
  process were made easier, or more inviting for Ubuntu developers[1].

- Tool mismatches.  I just wish it were easier to build packages for both
  Debian and Ubuntu, but the tools chains are sufficiently different that it's
  difficult to switch your (well, *my* ;) brain into Debian mode from Ubuntu
  mode and vice versa.  Part of it is dealing with Ubuntu Distribute
  Development (UDD), which I'm very comfortable with, and which gives me a
  source-full checkout of a package (debian/ + unpacked upstream) all managed
  in a DVCS branch.  I can grab the source for any version of any package on
  any release of Ubuntu (and actually, Debian too!) through Launchpad[2], so
  it's easy to make a change, do merges from Debian or upstream, build it
  locally, test it, and upload it.  I personally find the Debian tools (svn
  instead of a dvcs, debian/ only directory) harder to deal with, but maybe
  that's just me.  I've said before that as much as I dislike git, if Debian
  had something like UDD+bzr but git based and more interoperable with quilt
  packages, I'd use it.  Also, I do think that Ubuntu's source-only uploads
  are a win.  PPAs are nice too, as are the new -proposed pocket for the
  in-development release.

- All is not roses in Ubuntu-land though.  When uploads to Debian are delayed
  (e.g. because of release freezes), then Ubuntu can get ahead of Debian in
  ways that are more difficult to untangle.  Ubuntu's auto-import from Debian
  gets blocked whenever a package has an -NubuntuM version number.  These take
  manual effort to resync, but of course even that's not always possible since
  some Ubuntu-specific deltas won't or can't be adopted into Debian (e.g. a
  build-dependency crossing main and universe).  I wonder if there's isn't a
  way to make this smoother so packages can more easily cross the chasm.

Anyway, I've rambled enough.  My intent wasn't to offend either community, but
just to say that Debian and Ubuntu work best when they appeal to their
strengths, but always strive for collaboration.  And maybe there's opportunity
to ease some of the rough spots.

Cheers,
-Barry

[1] Please note that I am not complaining about my own personal DD journey.
My experience, although it took a long time, was a great learning experience,
and quite pleasant.  I have nothing but respect and gratitude for my AM and
the Front Desk.

[2] Well, assuming the importer hasn't barfed on the package.

Re: Debian systemd survey

Steve Langasek — 2013-05-23T15:18:49


What's available in Ubuntu are the systemd dbus services, the libraries, and
a little-known daemon called 'udev'.  The systemd init is *not* in Ubuntu
and there are no plans to change that.

Bug#709480: ITP: libuv -- asynchronous event notification library

Luca BRUNO — 2013-05-23T14:43:34

Package: wnpp
Severity: wishlist
Owner: Luca BRUNO <lucab< at >debian.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

* Package name    : libuv
  Version         : 0.11.3
  Upstream Author : Ben Noordhuis <info< at >bnoordhuis.nl>
* URL             : https://github.com/joyent/libuv
* License         : MIT
  Programming Lang: C
  Description     : asynchronous event notification library

 Libuv is the asynchronous library behind Node.js. Very similar to libevent or
libev,
 it provides the main elements for event driven systems: watching and waiting
 for availability in a set of sockets, and some other events like timers or
 asynchronous messages. However, libuv also comes with some other extras like:
 * files watchers and asynchronous operations
 * a portable TCP and UDP API, as well as asynchronous DNS resolution
 * processes and threads management, and a portable inter-process
   communications mechanism, with pipes and work queues
 * a plugins mechanism for loading libraries dynamically
 * interface with external libraries that also need to access the I/O

This is going to be maintained within the javascript team.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlGeKxYACgkQRqobajv7n7MfMACfXnoqQUJYDb4BWdvoIU+kV+zf
lK0An3oMSsSOrFFvrW1bzl7Sfrex4lkh
=pAqX
-----END PGP SIGNATURE-----

Re: Debian systemd survey

Philipp Kern — 2013-05-23T13:10:46

I don't find yours to be much better.


There are more projects than kernel patches, though. And they argued
that they contribute to upstream, which is true, although the backport
situation is nothing to be proud of, I agree. There are a bunch of
projects started by RedHat (not in private as systemd) that are
useful to the community. See http://et.redhat.com/ for instance.


And we still need to cope with the problems Ubuntu didn't have by design. ;-)


As with RedHat, I guess.

Kind regards
Philipp Kern

Re: Debian systemd survey

Neil Williams — 2013-05-23T13:08:36

On Thu, 23 May 2013 14:17:43 +0200
Josselin Mouette <joss< at >debian.org> wrote:


Multi-Arch in Debian could have moved faster but Debian has a more
complex use-case for Multi-Arch than Ubuntu and was in freeze longer.

Innovation involves making mistakes and fixing things quickly - some of
that comes from having repositories to which uploads can be made
quickly and independently of processes not directly involved with that
particular development path, e.g. transitions in unrelated packages,
release freeze when the development path is not yet stable etc.

Debian is moving in a direction which can fix these problems by making
archives accessible in a way which does not have to affect everyone
else.

Making (or allowing for) mistakes in a large project is too disruptive
to allow in the main flow of the project. We need sandboxes which are
more than just a few local chroots and I'm very glad to see that this is
being implemented.

Debian has a reputation for stability and reliable releases.
Innovations like this should be able to ease the release process, keep
Debian releases just as stable as before and make things easier for
those who do want to drive innovative ideas within Debian itself.

There's no need to think that all future innovation will be constrained
by previous Debian workflows.

Re: Debian systemd survey

Ian Jackson — 2013-05-23T13:03:22

Josselin Mouette writes ("Re: Debian systemd survey"):

I see this quite differently.  The problem was that you didn't want to
do the work required to transition properly, and instead decided to
try to bounce everyone into dropping the old machinery entirely.

Indeed that's why you were overruled by the Technical Committee, who
clearly don't agree with your interpretation of the situation.

Ian.