Re: jpeg8 vs jpeg-turbo

[Mathieu Malaterre]

On Thu, Apr 25, 2013 at 6:17 AM, Riku Voipio  wrote:
> On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
>> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more 
>> feature.
>
> Only the applications that actually want to experiment with libjpeg8/9 ABI 
> should be using it -
>
> The 100% of current applications that work just libjpeg-turbo should be
> using libjpeg-turbo for better performance and compatibility with rest
> of the linux distributions.
>
> Which feature in libjpeg9 does anyone want? The ability to make jpeg's
> images that nobody else can view?

Chicken & egg issue, until everyone follow debian and uses libjpeg9,
there may be surprise.

>> I do not see libjpeg-turbo as a suitable replacement. It has
>> 1) an different license
>
> Be specific, what do you not like about libjpeg-turbo license? As far as
> I see, it is under the exact same license?
>
>> 2) much more security issues in a much smaller timeframe.
>
> Which translates to.. a single CVE in libjpeg-turbo since it's
> inception!
>
>> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.
>
> This would be a relevant if some application actually used the
> "full libjpeg8 ABI" . In fact, 100% of debian works fine with
> libjpeg-turbo, or even the original libjpeg6b (if the would be
> recompiled against it again).
>
> I find the reason that IJG libjpeg8 fork is so triggerhappy to
> repeatedly break the API and ABI (and image format!) rather a reason
> to make libjpeg8 the non-default.
>
> You should not deprive debian users from high performance jpeg rendering
> for a few ABI features that nobody uses - or anyone is asking for.

I do not believe in debian life-span, a package manager ever switch an
implementation of a package. So libjpeg9 and libjpeg-turbo will have
to co-live.

I understand your point that libjpeg9 offers experimental feature not
needed for everyone, but at least from my point of view libjpeg-turbo
by only implementing portion of ITU-T T.81, ISO/IEC IS 10918-1 (namely
lossy 8bits progressive & sequential) is a no-go for my applications.
Have a look at ITK, DCMTK and/or GDCM which provide a patched libjpeg
to provide support for lossy 8 & 12 bits and lossless 16bits. This is
a burden to maintain those side implementations.

This goes without saying that JPEG commitee is now working on a full
implementation of ITU 81:

https://github.com/thorfdbg/libjpeg

Which also has a different license, may be slower, but *at last*
provide a complete implementation of JPEG. It is said to provide an
ABI compatible with the original IJG implementation in the near
future. So debian may have to provide three JPEG implementations

This bug will be really messy to read, but I wished the team from
libjpeg-turbo and whoever is running IJG found a compromise to either
integrate optimization from -turbo into jpeg9, or the other way
around, -turbo provides empty body function for the new API. oh
well...

-M


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/ca+7wuszqjfo+ma94e2s_mkzbjduvmvcg+wsbgzhrfghjb5+...@mail.gmail.com

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Andreas Tille]

On Wed, Apr 24, 2013 at 09:43:48PM +0200, Guillem Jover wrote:
> ...
> A distribution (any, most) is the gel that binds and gives an unified
> and coherent shape to the software ecosystem.

+1 (to everything even the cutted part)

> An app store is just like
> a scrapyard, you might find magnificent and isolated gems there, but most
> of it will probably be junk, or not combine with the other scrap parts.

I honestly wonder if there is some more general definition for the term
"app store" besides what according to[1] certain companies have made out
of it.  Following the logic that "app store" is crap because some
companies provide it as such we are terribly lucky that they did not
choose the term "distribution" for their crap.  I personally can not
find something wrong in a *generic* term "application store" and I would
not seriously object if someone would call Debian an app store done the
right way.

> > Where Debian's efforts should be focused is on things like license
> > verification and helping bug reports and fixes get to upstream.
> 
> So basically, getting rid of most of the fun stuff and turning it into
> a lawyerish play-ground and support center... I'd venture to say, not
> the most attractive work for most people here if it was the only
> thing to be done, which we do because we think it's important non the
> less.

+1

Kind regards

   Andreas.

[1] http://en.wikipedia.org/wiki/App_Store 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425072059.gd23...@an3as.eu

Re: jpeg8 vs jpeg-turbo

[Sune Vuorela]

On 2013-04-25, Mathieu Malaterre  wrote:
> Chicken & egg issue, until everyone follow debian and uses libjpeg9,
> there may be surprise.

Everyone seems to head towards libjpeg-turbo.

>> I find the reason that IJG libjpeg8 fork is so triggerhappy to
>> repeatedly break the API and ABI (and image format!) rather a reason
>> to make libjpeg8 the non-default.

And because of the image format changes, some of my upstreams are going
to force using libjpeg-turbo because they do not want or need jpeg files
that are incompatible with the world.

/Sune


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnknhns9.fhs.nos...@sshway.ssh.pusling.com

mis-identification of quotations due to lazy bike-shedding

[Neil Williams]

On Thu, 25 Apr 2013 07:08:48 +0800
Thomas Goirand  wrote:

> On 04/25/2013 01:52 AM, Neil McGovern wrote:
> > Perhaps you should go read the bug report first. As you seem to be
> > unwilling to actually do research, I'll include the relevant section for
> > your benefit:
> 
> When you write:

This will be my only reply to this particular bike-shed.

Thomas: Read the bug report. I filed it. Neil McGovern quoted it. I
wrote the comments as part of a wider critique of the package. You are
replying to Neil McGovern as if he wrote it. 

Yes, I know, maybe it's too difficult for some of the contributors to
this petulant thread to understand but we're both called Neil, we're
both currently based in the UK, still most people can actually tell us
apart, even after several beers. The different @d.o email address is
probably a clue. The different family name is a big fat clue.

Maybe attributing something to you originally written by the Reverend
Awdry would make the point...

Thomas said:
"Little Engines can do big things, especially when they have nice blue
paint like me."

Now which Thomas might that be again?



> > That cannot be guaranteed - at some point, someone else is going to
> > need to work on pax. The build system is non-standard and not well
> > tested because it's restricted to only two packages.
> > 
> > If that turns out to be me, I will RM. I'm not going to spend time on
> > the current insanity.
> 
> then I don't agree, and I don't support such decision.

The decision didn't need your support and I stand by it.

As with the rest of this ridiculous thread, all the discussion is about
one element of a much larger problem and it was the entirety of the
previous packaging which convinced me that there were only two sane
options for the package: Fix all of the problems or remove the package
entirely.

I was not seeking removal merely due to this one quoted part of the bug
report. There were other, more serious, issues than this one but nobody
seems to have noticed any of that.

I think it is entirely appropriate to remove insane packages from
Debian - it raises the quality of Debian as a whole.

The bug is now fixed, the package wasn't removed, I will not reply to
any messages relating to it or this bike-shedding thread either on or
off list. Anyone who perpetuates this sub-thread invites the moniker of
"troll" - unless posting entirely in fun.

Move on now, get some real work done, it's more fun. PLEASE?

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpdc4A_fHEoM.pgp
Description: PGP signature

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Clint Byrum]

On 2013-04-24 12:43, Guillem Jover wrote:

Hi!

On Sat, 2013-04-20 at 11:05:29 -0700, Clint Byrum wrote:

[...]. IMO this is why upstream packaging should be
embraced and enhanced rather than focusing on dpkg.


I'm not sure if you refer to the tool here, or to the packaging work,
doesn't change much anyway.



I'm referring to delivering software in general, most of which falls 
into a few categories which are not "a programming language", 
"plumbing", and "system development tools".



I once worked on the 'pkgme' project for Ubuntu and there have been
others, but never followed through. The idea was just to build
debian source packages from upstream sources. Upstreams should be
able to release a package which serves their needs, and Debian
should be able to consume these almost directly.


Respectfully, I think you've entirely missed the point of a 
distribution

(and sadly I'm seeing this trend more often than before now, with all
the hype around app stores and similar...). Packaging and maintaining 
a

consistent and unified distribution cannot be delegated to upstreams
(and I'm talking as an upstream developer here too), because that 
entails
a bit more than slapping some files somewhere, tarring the thing up 
and

calling it a day.



Indeed, there is a great deal of hard work in putting together an 
operating system. But for the bulk of software, things like MongoDB 
included, I see very little point in distributions spending a lot of 
time tweaking and poking and prodding the software to work into a grand 
policy.


For the most part, developers ship and test a good tarball that builds 
with some pretty standard and easy to detect options. The bits where 
that doesn't work ought be fixed upstream, and I know sometimes they 
are, but in the mean time, the distribution maintainers (myself 
included) spend their precious time conforming to the broken upstream, 
instead of the other way around.



Building a nice distribution requires a high-level view and QA of the
entire system; requires curating sane namespaces, be them on the
package/project names, on the version strings, on the filesystem (by
avoiding file collisions, using alternatives or diversions), on 
exposed

programming interfaces, etc; requires making sure a diverse set of
programs interact correctly with each other; performing security
updates; ideally keeping single runtime versions; doing global
transitions to use other or newer runtimes, programs, libraries or
packages; an unified way to build from sources to cope with the 
endless

and interesting different upstream build systems; porting and building
for different binary architectures, not just what upstream might have
around; documentation; translation; tagging stuff with metadata to
allow for easy searches; excision of the embedded code copies cancer;
even stuff like how the Delete and Backspace keys should behave;
sets a qualify bar for upstream projects, stuff of low quality will
not be accepted most of the time; license checks; etc, etc...



All of the things you mention are huge accomplishments, but the scope 
is what I am suggesting has gotten out of hand. Do we really need "a 
high level view" and "QA of the entire system" for MongoDB? It is a 
daemon and some client tools. If I install it from tarball, I know this 
is shocking, but it actually works fine and doesn't interfere with 
anything else. If it does, I will complain to upstream. My suggestion is 
not to stop packaging, but to shift focus from "make an awesome package" 
to "make an awesome upstream" that results in an automatically generated 
awesome package. Debhelper and many of the other tools definitely help 
with this, but we can do more.



And all this, upstream will never be able to provide (at least not as
defaults), because each distribution has its own policies, some are
better, some are worse, and some are just different. In general I'd
never trust the packaging produced by an upstream for a distribution
they are not involved in. But most of the time there will be no such
packages for the desired distribution anyway.



Debian wants to provide end-to-end generalized tight integration. Thus 
packages lagging behind upstream. I'm suggesting that this tight 
integration ideal actually *limits* the scope of Debian.



Although there's been work on creating distribution-neutral specs that
some upstreams have picked up, there's always going to be something 
new,

the specs will just not cover all needed things, the specs might not
be liked by some/many people, or might not have been fully adopted by
all upstreams.



Right, and Debian maintainers can, and will keep bending over backward 
to get all the upstreams into Debian. That doesn't mean its a good use 
of someone's time.



A distribution (any, most) is the gel that binds and gives an unified
and coherent shape to the software ecosystem. An app store is just 
like
a scrapyard, you might find magnificent and isolated gems there, but 
most
of it will prob

Bug#706133: ITP: ompl -- Set of sampling-based motion planning algorithms.

[Leopold Palomo-Avellaneda]

Package: wnpp
Severity: wishlist
Owner: "Leopold Palomo-Avellaneda" 

* Package name: ompl
  Version : 0.12.2
  Upstream Author : Ioan A. Șucan, Mark Moll, Lydia E. Kavraki 
* URL : http://ompl.kavrakilab.org
* License : The 3-clause BSD License
  Programming Lang: (C++, Python)
  Description : Consists of a set of sampling-based motion planning 
 algorithms. The content of the library is limited to these algorithms,
 which means there is no environment specification, no collision 
 detection or visualization. The library is designed so it can be easily 
 integrated into systems that provide the additional needed components.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425091452.6013.39653.report...@soho.upc.es

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Charles Plessy]

Le Thu, Apr 25, 2013 at 01:50:58AM -0700, Clint Byrum a écrit :
> 
> My suggestion is not to stop packaging, but to shift focus
> from "make an awesome package" to "make an awesome upstream" that
> results in an automatically generated awesome package. Debhelper and
> many of the other tools definitely help with this, but we can do
> more.

Hi Clint,

indeed, we do more:

http://wiki.debian.org/UpstreamGuide

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425094629.gf21...@falafel.plessy.net

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Jonas Smedegaard]

Quoting Andreas Tille (2013-04-25 09:20:59)
> On Wed, Apr 24, 2013 at 09:43:48PM +0200, Guillem Jover wrote:
> > ...
> > A distribution (any, most) is the gel that binds and gives an unified
> > and coherent shape to the software ecosystem.
> 
> +1 (to everything even the cutted part)
> 
> > An app store is just like a scrapyard, you might find magnificent 
> > and isolated gems there, but most of it will probably be junk, or 
> > not combine with the other scrap parts.
> 
> I honestly wonder if there is some more general definition for the 
> term "app store" besides what according to[1] certain companies have 
> made out of it.  Following the logic that "app store" is crap because 
> some companies provide it as such we are terribly lucky that they did 
> not choose the term "distribution" for their crap.  I personally can 
> not find something wrong in a *generic* term "application store" and I 
> would not seriously object if someone would call Debian an app store 
> done the right way.

If by "not seriously object" you mean that you would object but with a 
smile and continue your great meal together, rather than leave the 
party and file a lawsuit, then I agree with you...

To me, calling Debian an "app store" would be only misleading. To me an 
"app store" is for "topping op" a system, not the system itself.

Debian is no app store: content is not only apps nor app-centric, and 
aim is not to archive nor to sell, but to streamline and distribute.

When I need an alternative term to describe what "distribution" means, I 
use "library": Like librarians we care not only about the individual 
"books" of software, and not only about the "novels", but about 
long-term cohesive structure of the library as a whole.

Libraries also has the connotation of "collecting dust" which arguably 
is descriptive for (stable) Debian as well ;-)


 - Jonas

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

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425100011.12767.1...@bastian.jones.dk

Re: mis-identification of quotations due to lazy bike-shedding

[Jakub Wilk]

* Neil Williams , 2013-04-25, 08:51:
Perhaps you should go read the bug report first. As you seem to be 
unwilling to actually do research, I'll include the relevant section 
for your benefit:

When you write:


This will be my only reply to this particular bike-shed.

Thomas: Read the bug report. I filed it. Neil McGovern quoted it.

[snip - pointless scoffing]

Shit happens. It's not the first time somebody confuses you two[0], 
probably not the last. Making song and dance about it was uncalled-for.


I was not seeking removal merely due to this one quoted part of the bug 
report. There were other, more serious, issues than this one but nobody 
seems to have noticed any of that.


Sorry, it's hard to tell which issues are more serious when they are all 
wishlist.


Anyone who perpetuates this sub-thread invites the moniker of "troll" - 
unless posting entirely in fun.


[The things I wrote above were not for fun, but these below are. Do I 
still qualify as a troll?]


Don't dare to reply if you disagree with me!


[0] http://lists.debian.org/87lixoz9c6@mirexpress.internal.placard.fr.eu.org

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425104636.ga6...@jwilk.net

GSoC project: fedmsg for the Debian infrastructure

[Simon Chopin]

Hi,

Nicolas Dandrimont and I are currently working on a project proposal for
the Google Summer of Code to use the messaging system written by Fedora,
fedmsg[0][1], within the Debian infrastructure (some of you might have seen
the various ITPs related to that on -devel).

Tollef kindly pointed out to us that Debian service administrators would
probably have something to say about all this, so here we are.

As a premise, please note that we obviously plan to make fedmsg
distro-agnostic before anything else (than packaging). The original
upstream author seems very enthousiastic about the project, which makes
it probable that we won't have to carry those patches on our own.

The thing itself is based on the ZeroMQ protocol.

To quote Nicolas: 
> One of the key outcomes of getting such a system in place, is that everyone,
> everywhere, can start listening to the messages and using them, opening up 
> lots
> of doors for people to make amazing services based on Debian.
> 
> A few ideas:
>  - getting a signal from the archive on an accepted package (I'm confusing
>binaries and sources for the sake of brevity):
>→ Trigger a piuparts run
>→ Trigger lintian checks
>→ Let any derivative intent a rebuild
>→ Signal ports to rebuild
>→ Trigger a jenkins job on specific package uploads
>→ Post to pump.io/identi.ca/twitter
>→ get a notification on your desktop
>→ ...
>  - one of your pet packages gets a git commit
>→ try a rebuild
>→ run QA checks
>→ ...
> 
> (boy, that escalated quickly)
> 
> I think the possibilities are quite nice, and, as the fedmsg webpage says, 
> that
> "gives new meaning to open infrastructure".

Two features I'd like to implement during this GSoC that are not AFAICT
already present in fedmsg are GPG support and some kind of playback
mechanism for the systems where it is important that all messages are
sent and received (there are some others where the information would
have value only at the time of emitting, I suppose).

Questions, comments?

Cheers,
Simon

[0] http://wiki.debian.org/SummerOfCode2013/StudentApplications/SimonChopin
[1] http://fedmsg.com/

PS: debian-admin, debian-services-admin and soc-coordination Cc-ed for
reference, but further discussion should be on -devel. Upstream author
Ralph Bean  also Cc-ed, it would probably be useful to
keep him in the loop.


signature.asc
Description: signature

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Wouter Verhelst]

On 25-04-13 10:50, Clint Byrum wrote:
> On 2013-04-24 12:43, Guillem Jover wrote:
> All of the things you mention are huge accomplishments, but the scope is
> what I am suggesting has gotten out of hand. Do we really need "a high
> level view" and "QA of the entire system" for MongoDB?

We don't need it for MongoDB, but we do need it for Debian.

The difference might seem to be minor, but it isn't.

> It is a daemon
> and some client tools. If I install it from tarball, I know this is
> shocking, but it actually works fine and doesn't interfere with anything
> else.

That's fine, great, and dandy. But it's besides the point.

I would hope that all upstream software "works fine" and "doesn't
interfere with anything else" if installed from tarball. If it doesn't,
they seriously need to check what they're doing.

But Debian packages go beyond "work fine". They are integrated. If there
are other packages out there that do similar functionality to whatever
it is that "MongoDB" does (I don't have a clue, but it doesn't matter
for this discussion; I guess it's some sort of database), then it's
reasonable to expect that a MongoDB package would need to behave
similarly to those other packages.

For a database server, this could include things like:
- making sure the data is stored in the right location in the file
system; e.g., postgresql upstream assumes all its stuff (binaries,
configuration, data files) are stored in a single directory. Given their
background (they support way more systems than we do; e.g., they also
support Windows) this makes sense, but that doesn't mean we should, too.
- If it's an SQL database, integrating everything with dbconfig-common.
This is a Debian-specific thing to make installing database-using
packages easier; it makes no sense whatsoever to push this upstream.
- ... probably others, but I'm not very fluent in packaging of database
systems.

> If it does, I will complain to upstream. My suggestion is not to
> stop packaging, but to shift focus from "make an awesome package" to
> "make an awesome upstream" that results in an automatically generated
> awesome package. Debhelper and many of the other tools definitely help
> with this, but we can do more.

Yes, we do have a guideline that says you should push improvements
upstream if and when they make sense there, and that is more often the
case than you'd think if you were just looking at the number of patches
that flow upstream.

But making a distribution is so much more than just checking licenses
and converting source into installable packages.

Take, for instance, the apache packages. If you were to just take the
upstream source, compile, and install it, then it would also Just Work.
But it wouldn't have the same flexibility that the Debian packages have.
On Debian, you can just install some libapache-mod-foo package, and due
to how the configuration files are arranged, it will simply work. This
kind of integration isn't something that can (or should!) be done
upstream; it's squarely inside the realm of what a distribution does.

The amount of such integration is part of what makes a distribution
unique; some distributions tend to do this more than others, and at one
extreme of this are Arch and Slackware, who make it a policy to ship
upstream source as pristine as possible. Debian is clearly not at that
extreme, and it should not be, IMO; the high level of integration, the
expectation that I can have from the behaviour of a package that's part
of Debian is what attracted me to Debian in the first place, and if we
ever lose that I'll probably start looking for a different distribution.

>> And all this, upstream will never be able to provide (at least not as
>> defaults), because each distribution has its own policies, some are
>> better, some are worse, and some are just different. In general I'd
>> never trust the packaging produced by an upstream for a distribution
>> they are not involved in. But most of the time there will be no such
>> packages for the desired distribution anyway.
>>
> 
> Debian wants to provide end-to-end generalized tight integration. Thus
> packages lagging behind upstream. I'm suggesting that this tight
> integration ideal actually *limits* the scope of Debian.

Sometimes packages are lagging behind, yes, and that's a problem; but I
don't agree that the tight integration lies at the root of that problem.
When done right, this kind of integration consists of just a few files
inside a debian/ directory; they should not interfere with packaging a
new upstream version.

Yes, there are exceptions, and we should strive to eliminate such cases.
Sometimes this is because upstream is no longer active; sometimes this
happens because the maintainer isn't doing a good (enough?) job.
Whatever the reason, it's something we should try to fix. But just
throwing our hands up in the air and saying that we should therefore
give up on trying to integrate isn't the right way forward, I'd say.

[...]
>> Although there's been

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Andreas Tille]

Hi,

On Thu, Apr 25, 2013 at 12:00:11PM +0200, Jonas Smedegaard wrote:
> Quoting Andreas Tille (2013-04-25 09:20:59)
> > I honestly wonder if there is some more general definition for the 
> > term "app store" besides what according to[1] certain companies have 
> > made out of it.  Following the logic that "app store" is crap because 
> > some companies provide it as such we are terribly lucky that they did 
> > not choose the term "distribution" for their crap.  I personally can 
> > not find something wrong in a *generic* term "application store" and I 
> > would not seriously object if someone would call Debian an app store 
> > done the right way.
> 
> If by "not seriously object" you mean that you would object but with a 
> smile and continue your great meal together, rather than leave the 
> party and file a lawsuit, then I agree with you...

It depends with whom I share that great meal.  If it is my father I
would simply say "yes".  If it is my son I would mind explaining the
difference.  Rationale:  I have installed Debian on my fathers box and
told him how he can install additional applications.  Once you have a
basic system running the Debian mirror serves as an app store and it
makes actually the point for this kind of user (and a lot of other users
as well).

> To me, calling Debian an "app store" would be only misleading.

Yes.  That's why I would not call Debian an "app store" to *you*.

> To me an 
> "app store" is for "topping op" a system, not the system itself.

There are actually users who do not "see" the system but just the
topping.  I would never try to blame the user about this.  For my father
it is even easier to understand what I'm doing in Debian because I spend
most of my time with leaf packages (if I do not care for Blends
infrastructure stuff).  So telling him "Debian is an app store and my
work on it is adding apps to the store" this is an very easy to
understand explanation which leaves out the part that is not
understandable to him: What is an operating system.  (Hey, also Windows
is no operating system - it is just a kick-starter for Windows, Excel, a
browser and a mail client, right?)

> Debian is no app store: content is not only apps nor app-centric, and 
> aim is not to archive nor to sell, but to streamline and distribute.

If you do not like the selling part:  Store in the sense of some
"storage of goods" is not necessarily about bying (at least of my
understanding).  Or tweak it like this:  We are selling our stuff but
the price tag says 0€/$.  Feel free to blame me about oversimplification

> When I need an alternative term to describe what "distribution" means, I 
> use "library": Like librarians we care not only about the individual 
> "books" of software, and not only about the "novels", but about 
> long-term cohesive structure of the library as a whole.
> 
> Libraries also has the connotation of "collecting dust" which arguably 
> is descriptive for (stable) Debian as well ;-)

Nice alternative explanation.

Kind regards

 Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425124038.ga7...@an3as.eu

Re: Upstream packaging

[Gergely Nagy]

Clint Byrum  writes:

>> Also if people thought that distributions are unneeded, then the
>> amount
>> of them would reflect that, or start decreasing, which I'm not seeing.
>> Distributions will exist as long as there's FLOSS, because by its
>> decentralized nature, there's no single coordination point; people
>> who are distraught by the amount of distributions or by their mere
>> existence might probably only be able to find peace in closed-systems
>> instead, with their centralized control points.
>>
>
> Nobody is distraught. The problem statement was something like
> "distributions lag upstreams, how can we solve this?" and I'm
> suggesting that its kind of already solved with upstreams who use
> their native packaging format (i.e., autotools, pypi for python, or
> maven for java). Its just that Debian has such strong policies that we
> are unable to consume said packaging, because the upstream packaging
> is less expressive. So, we have to lag while we QA all of our
> specialness.

There's so much more to packaging and *maintaining* a debian package
than wrapping whatever upstream has in a .deb, even if we apply very
few (or none at all) changes during the process.

Just because something uses autotools, it will not mean you can
trivially package it, or upgrade from one version to the other. There
are a million things that can - and sooner or later, will - break even
if upstream only uses standard tools. A new dependency, a new configure
option, changing defaults, and all kinds of incompatible changes make
maintainance neccessary and far more effort than you seem to imply.

Most of these are things upstream do not have to care about: they'll
document it in an UPGRADING file or similar, and delegate the task to
their users. A distribution will most likely wish to automate most of
that in a straightforward and safe manner.

>>> Where Debian's efforts should be focused is on things like license
>>> verification and helping bug reports and fixes get to upstream.
>>
>> So basically, getting rid of most of the fun stuff and turning it into
>> a lawyerish play-ground and support center... I'd venture to say, not
>> the most attractive work for most people here if it was the only
>> thing to be done, which we do because we think it's important non the
>> less.
>>
>
> I am suggesting that there are a lot of things that are much more fun
> than conforming software to Debian policy.

Wouter said it very well, that the Policy is not a goal, but a tool to
achieve a goal: that of an integrated system. Making packages conform to
policy is pointless, if it is not done to achieve the goal. Creating a
well integrated system on the other hand *is* fun, and something that
can't be delegated to upstream, or anywhere else but the distribution
itself.

> I'm also suggesting that these things don't need to happen in the
> context of Debian.

Where else? Upstreams should not be concerned about integrating their
software into distributions. That's what package maintainers are for:
they know the distribution better, they have the skills and resources to
do the neccessary integration work, they know how their distribution
handles upgrades, and so on and so forth.

Upstreams should provide the tools and documentation to make integration
possible and smooth, but that's where it should end.

As an upstream, I do not wish to care about any single distribution.
I'll provide ample documentation, scripts and whatever else they need,
but I do not wish to play the integrator role. If I start to do that for
one distribution (wit my upstream hat on), I'll have to do it for the
rest too. No, thank you, that is as far from fun as it can ever be.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwsm7pgx.fsf@algernon.balabit

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Andreas Tille]

On Thu, Apr 25, 2013 at 02:40:38PM +0200, Andreas Tille wrote:
> understandable to him: What is an operating system.  (Hey, also Windows
> is no operating system - it is just a kick-starter for Windows, Excel, a
> browser and a mail client, right?)

s/for Windows, Excel/for Word, Excel/ 

Kind regards

   Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425125614.gb7...@an3as.eu

Re: Upstream packaging (was Re: Derivatives, MongoDB and freezes)

[Ben Armstrong]

On 04/25/2013 09:40 AM, Andreas Tille wrote:
> There are actually users who do not "see" the system but just the
> topping.

Yes, but I don't think we should encourage any users in this skewed view
of the system.

> I would never try to blame the user about this.

Nor would I. However, I would not use this as an excuse not to educate them.

> For my father
> it is even easier to understand what I'm doing in Debian because I spend
> most of my time with leaf packages (if I do not care for Blends
> infrastructure stuff).  So telling him "Debian is an app store and my
> work on it is adding apps to the store" this is an very easy to
> understand explanation which leaves out the part that is not
> understandable to him: What is an operating system.  (Hey, also Windows
> is no operating system - it is just a kick-starter for Windows, Excel, a
> browser and a mail client, right?)

I understand using app store as an analogy, as long as it is explained
as such, and qualified as being an imperfect analogy. But the common
conception of an "app store" as involving you solely as consumer and not
as participant in the free software ecosystem encourages poor
relationship between users and producers (or distributors) of free
software. So long as users continue to see themselves as a tiny,
insignificant recipient at the end of the production of the software
with no input into the system, you've stripped them of the power to
change the software to meet their needs. So using the "app store"
analogy is walking the fine line and really needs to be qualified to
avoid doing damage to the user's relationship to the community.

> If you do not like the selling part:  Store in the sense of some
> "storage of goods" is not necessarily about bying (at least of my
> understanding).  Or tweak it like this:  We are selling our stuff but
> the price tag says 0€/$.  Feel free to blame me about oversimplification

Honestly, I don't think the selling part is the most offensive part of
the concept of an "app store". It's the one-way nature of the
transactions carried out with them.

Ben


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51792a53.7080...@sanctuary.nslug.ns.ca

Re: jpeg8 vs jpeg-turbo

[Steve McIntyre]

Riku Voipio wrote:
>On Wed, Apr 24, 2013 at 03:19:59PM +0200, Bill Allombert wrote:
>
>> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.
>
>This would be a relevant if some application actually used the
>"full libjpeg8 ABI" . In fact, 100% of debian works fine with
>libjpeg-turbo, or even the original libjpeg6b (if the would be
>recompiled against it again). 
>
>I find the reason that IJG libjpeg8 fork is so triggerhappy to
>repeatedly break the API and ABI (and image format!) rather a reason 
>to make libjpeg8 the non-default. 

That *alone* sounds like a good argument for switching, to be honest...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1uvnew-xi...@mail.einval.com

Re: jpeg8 vs jpeg-turbo

[Peter Samuelson]

[Mathieu Malaterre]
> I do not believe in debian life-span, a package manager ever switch
> an implementation of a package. So libjpeg9 and libjpeg-turbo will
> have to co-live.

It happens.  Look at the source for 'libc6'.  It used to be glibc,
these days it is a fork called eglibc.  Likewise the source for the
'ssh' package was once SSH by Tatu Ylonen, these days it is a fork
called OpenSSH maintained by some OpenBSD hackers.


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

Re: GSoC project: fedmsg for the Debian infrastructure

[Daniel Pocock]

On 25/04/13 13:50, Simon Chopin wrote:
> Hi,
>
> Nicolas Dandrimont and I are currently working on a project proposal for
> the Google Summer of Code to use the messaging system written by Fedora,
> fedmsg[0][1], within the Debian infrastructure (some of you might have seen
> the various ITPs related to that on -devel).
>
> Tollef kindly pointed out to us that Debian service administrators would
> probably have something to say about all this, so here we are.
>
> As a premise, please note that we obviously plan to make fedmsg
> distro-agnostic before anything else (than packaging). The original
> upstream author seems very enthousiastic about the project, which makes
> it probable that we won't have to carry those patches on our own.
>
> The thing itself is based on the ZeroMQ protocol.
>
> To quote Nicolas: 
>> One of the key outcomes of getting such a system in place, is that everyone,
>> everywhere, can start listening to the messages and using them, opening up 
>> lots
>> of doors for people to make amazing services based on Debian.
>>
>> A few ideas:
>>  - getting a signal from the archive on an accepted package (I'm confusing
>>binaries and sources for the sake of brevity):
>>→ Trigger a piuparts run
>>→ Trigger lintian checks
>>→ Let any derivative intent a rebuild
>>→ Signal ports to rebuild
>>→ Trigger a jenkins job on specific package uploads
>>→ Post to pump.io/identi.ca/twitter
>>→ get a notification on your desktop
>>→ ...
>>  - one of your pet packages gets a git commit
>>→ try a rebuild
>>→ run QA checks
>>→ ...
>>
>> (boy, that escalated quickly)
>>
>> I think the possibilities are quite nice, and, as the fedmsg webpage says, 
>> that
>> "gives new meaning to open infrastructure".
> Two features I'd like to implement during this GSoC that are not AFAICT
> already present in fedmsg are GPG support and some kind of playback
> mechanism for the systems where it is important that all messages are
> sent and received (there are some others where the information would
> have value only at the time of emitting, I suppose).
>
> Questions, comments?

ZeroMQ is a very lightweight solution - it is brokerless (like
multicast) so won't necessarily support the requirement for durable
subscriptions (keeping messages queued up for clients that are disconnected)
http://www.zeromq.org/topics:requirements-for-reliability

Some things that are worth looking at:

- do we want to use an AMQP broker? In theory, this is an open standard
like SMTP: the clients and brokers are interchangeable

- as an alternative, could we use something like SIP or XMPP as a
messaging platform? Then people can receive messages in their chat
client. In this case it doesn't appear to be the optimal solution, but
these protocols are quite good for systems that are very widely
distributed over public networks.

- then again, there are plenty of examples of systems like Apache Camel
that can take a message from a traditional broker and deliver it to just
about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
other possible destinations:
http://camel.apache.org/components.html
and it can use Java or XML to describe various filters and transforms



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51794ceb@pocock.com.au

Re: GSoC project: fedmsg for the Debian infrastructure

[Paul Tagliamonte]

On Thu, Apr 25, 2013 at 05:34:03PM +0200, Daniel Pocock wrote:
> On 25/04/13 13:50, Simon Chopin wrote:
> > Hi,
> >
> > Nicolas Dandrimont and I are currently working on a project proposal for
> > the Google Summer of Code to use the messaging system written by Fedora,
> > fedmsg[0][1], within the Debian infrastructure (some of you might have seen
> > the various ITPs related to that on -devel).
> >
> > Tollef kindly pointed out to us that Debian service administrators would
> > probably have something to say about all this, so here we are.
> >
> > As a premise, please note that we obviously plan to make fedmsg
> > distro-agnostic before anything else (than packaging). The original
> > upstream author seems very enthousiastic about the project, which makes
> > it probable that we won't have to carry those patches on our own.
> >
> > The thing itself is based on the ZeroMQ protocol.
> >
> > To quote Nicolas: 
> >> One of the key outcomes of getting such a system in place, is that 
> >> everyone,
> >> everywhere, can start listening to the messages and using them, opening up 
> >> lots
> >> of doors for people to make amazing services based on Debian.
> >>
> >> A few ideas:
> >>  - getting a signal from the archive on an accepted package (I'm confusing
> >>binaries and sources for the sake of brevity):
> >>→ Trigger a piuparts run
> >>→ Trigger lintian checks
> >>→ Let any derivative intent a rebuild
> >>→ Signal ports to rebuild
> >>→ Trigger a jenkins job on specific package uploads
> >>→ Post to pump.io/identi.ca/twitter
> >>→ get a notification on your desktop
> >>→ ...
> >>  - one of your pet packages gets a git commit
> >>→ try a rebuild
> >>→ run QA checks
> >>→ ...
> >>
> >> (boy, that escalated quickly)
> >>
> >> I think the possibilities are quite nice, and, as the fedmsg webpage says, 
> >> that
> >> "gives new meaning to open infrastructure".
> > Two features I'd like to implement during this GSoC that are not AFAICT
> > already present in fedmsg are GPG support and some kind of playback
> > mechanism for the systems where it is important that all messages are
> > sent and received (there are some others where the information would
> > have value only at the time of emitting, I suppose).
> >
> > Questions, comments?
> 
> ZeroMQ is a very lightweight solution - it is brokerless (like
> multicast) so won't necessarily support the requirement for durable
> subscriptions (keeping messages queued up for clients that are disconnected)
> http://www.zeromq.org/topics:requirements-for-reliability
> 
> Some things that are worth looking at:
> 
> - do we want to use an AMQP broker? In theory, this is an open standard
> like SMTP: the clients and brokers are interchangeable
> 
> - as an alternative, could we use something like SIP or XMPP as a
> messaging platform? Then people can receive messages in their chat
> client. In this case it doesn't appear to be the optimal solution, but
> these protocols are quite good for systems that are very widely
> distributed over public networks.
> 
> - then again, there are plenty of examples of systems like Apache Camel
> that can take a message from a traditional broker and deliver it to just
> about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
> other possible destinations:
> http://camel.apache.org/components.html
> and it can use Java or XML to describe various filters and transforms
> 
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: http://lists.debian.org/51794ceb@pocock.com.au
> 

Guys, we're *days* into student applications. We should have had this
nailed down weeks ago.

Pick something, go with it, or let's stop this early. Really; we should
be fielding students now, now bikesheading over this stuff.

Cheers,
 Paul

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


signature.asc
Description: Digital signature

Bug#706158: general: Probleme d'affichage

[oxygene]

Package: general
Severity: normal

Bonjour,

1°) barre de menu

- probleme d'affichage d'icone, application en cours (same icone)
- un changement de fenetre (ctrl-alt-1) permet au retour sur
L'Interface  X11
   d'afficher les icones,
- probleme de mise a jour, erreur a l'execution,

2 °) MercI

FREDERIC




-- System Information:
Debian Release: 7.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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: http://lists.debian.org/20130425174913.12504.62653.reportbug@oxygene

Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library

[Alessandro Ghedini]

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

* Package name: libzmq-libzmq2-perl
  Version : 1.07
  Upstream Author : Daisuke Maki 
* URL : https://metacpan.org/release/ZMQ-LibZMQ2/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl bindings to the libzmq 2.x library

ØMQ is a library which extends the standard socket interfaces with features
traditionally provided by specialised messaging middleware products.

ØMQ sockets provide an abstraction of asynchronous message queues, multiple
messaging patterns, message filtering (subscriptions), seamless access to
multiple transport protocols and more.

ZMQ::LibZMQ2 is a thin Perl wrapper around the libzmq 2.x C API.


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

Re: GSoC project: fedmsg for the Debian infrastructure

[Paul Tagliamonte]

On Thu, Apr 25, 2013 at 11:44:35AM -0400, Paul Tagliamonte wrote:
> On Thu, Apr 25, 2013 at 05:34:03PM +0200, Daniel Pocock wrote:
> > On 25/04/13 13:50, Simon Chopin wrote:
> > > Hi,
> > >
> > > Nicolas Dandrimont and I are currently working on a project proposal for
> > > the Google Summer of Code to use the messaging system written by Fedora,
> > > fedmsg[0][1], within the Debian infrastructure (some of you might have 
> > > seen
> > > the various ITPs related to that on -devel).
> > >
> > > Tollef kindly pointed out to us that Debian service administrators would
> > > probably have something to say about all this, so here we are.
> > >
> > > As a premise, please note that we obviously plan to make fedmsg
> > > distro-agnostic before anything else (than packaging). The original
> > > upstream author seems very enthousiastic about the project, which makes
> > > it probable that we won't have to carry those patches on our own.
> > >
> > > The thing itself is based on the ZeroMQ protocol.
> > >
> > > To quote Nicolas: 
> > >> One of the key outcomes of getting such a system in place, is that 
> > >> everyone,
> > >> everywhere, can start listening to the messages and using them, opening 
> > >> up lots
> > >> of doors for people to make amazing services based on Debian.
> > >>
> > >> A few ideas:
> > >>  - getting a signal from the archive on an accepted package (I'm 
> > >> confusing
> > >>binaries and sources for the sake of brevity):
> > >>→ Trigger a piuparts run
> > >>→ Trigger lintian checks
> > >>→ Let any derivative intent a rebuild
> > >>→ Signal ports to rebuild
> > >>→ Trigger a jenkins job on specific package uploads
> > >>→ Post to pump.io/identi.ca/twitter
> > >>→ get a notification on your desktop
> > >>→ ...
> > >>  - one of your pet packages gets a git commit
> > >>→ try a rebuild
> > >>→ run QA checks
> > >>→ ...
> > >>
> > >> (boy, that escalated quickly)
> > >>
> > >> I think the possibilities are quite nice, and, as the fedmsg webpage 
> > >> says, that
> > >> "gives new meaning to open infrastructure".
> > > Two features I'd like to implement during this GSoC that are not AFAICT
> > > already present in fedmsg are GPG support and some kind of playback
> > > mechanism for the systems where it is important that all messages are
> > > sent and received (there are some others where the information would
> > > have value only at the time of emitting, I suppose).
> > >
> > > Questions, comments?
> > 
> > ZeroMQ is a very lightweight solution - it is brokerless (like
> > multicast) so won't necessarily support the requirement for durable
> > subscriptions (keeping messages queued up for clients that are disconnected)
> > http://www.zeromq.org/topics:requirements-for-reliability
> > 
> > Some things that are worth looking at:
> > 
> > - do we want to use an AMQP broker? In theory, this is an open standard
> > like SMTP: the clients and brokers are interchangeable
> > 
> > - as an alternative, could we use something like SIP or XMPP as a
> > messaging platform? Then people can receive messages in their chat
> > client. In this case it doesn't appear to be the optimal solution, but
> > these protocols are quite good for systems that are very widely
> > distributed over public networks.
> > 
> > - then again, there are plenty of examples of systems like Apache Camel
> > that can take a message from a traditional broker and deliver it to just
> > about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
> > other possible destinations:
> > http://camel.apache.org/components.html
> > and it can use Java or XML to describe various filters and transforms
> > 
> > 
> > 
> > -- 
> > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact 
> > listmas...@lists.debian.org
> > Archive: http://lists.debian.org/51794ceb@pocock.com.au
> > 
> 
> Guys, we're *days* into student applications. We should have had this
> nailed down weeks ago.
> 
> Pick something, go with it, or let's stop this early. Really; we should
> be fielding students now, now bikesheading over this stuff.

OK. It's not Bikesheading, I read the rest of the thread. I'm a bit out
of order.

I'm still not pleased it's still up for discussion, this puts slot
allocation into a funny place where the GSoC team has to decide if we
can bet on a project with a huge payout but is ill defined.

I'll shut up and get out of this thread, but we should *really* nail
this down, like, in the next few days.

> 
> Cheers,
>  Paul
> 

Sorry!
  Paul

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


signature.asc
Description: Digital signature

Re: GSoC project: fedmsg for the Debian infrastructure

[Simon Chopin]

Quoting Daniel Pocock (2013-04-25 17:34:03)
> ZeroMQ is a very lightweight solution - it is brokerless (like
> multicast) so won't necessarily support the requirement for durable
> subscriptions (keeping messages queued up for clients that are disconnected)
> http://www.zeromq.org/topics:requirements-for-reliability
As I mentionned in my original email (granted, without expanding much on
it), I plan to implement a mechanism to solve this very problem by
keeping the messages sent on the emitter side and resending them on
demand.

> Some things that are worth looking at:
> 
> - do we want to use an AMQP broker? In theory, this is an open standard
> like SMTP: the clients and brokers are interchangeable

This solution has been already examined by the Fedora folks, and
rejected by lack of scalability WRT the broker. This sort of question is
actually why I think it is a good idea to use fedmsg because its authors
have needs that are quite similar to ours, and virtually the same use
cases.

> - as an alternative, could we use something like SIP or XMPP as a
> messaging platform? Then people can receive messages in their chat
> client. In this case it doesn't appear to be the optimal solution, but
> these protocols are quite good for systems that are very widely
> distributed over public networks.
Correct me if I'm wrong, but isn't SIP specific to VoIP?
I don't know much about XMPP outside of its application in chatting.

> - then again, there are plenty of examples of systems like Apache Camel
> that can take a message from a traditional broker and deliver it to just
> about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
> other possible destinations:
> http://camel.apache.org/components.html
> and it can use Java or XML to describe various filters and transforms
See above.

Cheers,
Simon


signature.asc
Description: signature

Re: GSoC project: fedmsg for the Debian infrastructure

[Simon Chopin]

Quoting Paul Tagliamonte (2013-04-25 18:04:26)
> OK. It's not Bikesheading, I read the rest of the thread. I'm a bit out
> of order.
> 
> I'm still not pleased it's still up for discussion, this puts slot
> allocation into a funny place where the GSoC team has to decide if we
> can bet on a project with a huge payout but is ill defined.
As far as I'm concerned, this would almost be an "all or nothing" deal,
I've already done quite a bit of work on fedmsg and I don't really have
the courage to throw it all away and begin again with another software
stack.

/me goes and ask ansgar about the dak test GSoC stuff :-)


signature.asc
Description: signature

Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

[Ben Longbons]

Package: general
Severity: wishlist

Introduction:
  This is my attempt at explaining exactly what frustrations prevent me from
  doing anything with Debian packages, and how another distro (Gentoo) does
  it better. The fact that Gentoo is a source-based distro is irrelevant.

  I hope you will seriously consider the issues here for jessie, rather than
  replying "we understand our system, if others don't that's their problem".

First some definitions:
  Ordinary Developer:
A debian user who is comfortable enough with command-line to install
programs in /usr/local. They want to perform Simple Tasks.
  Simple Tasks:
quick:
  Given a program that is not packaged for Debian and is not
  sufficiently useful to the general public to be worth the maintenance
  burden, install it such that the package manager knows about it.
distribute:
  Given a completed set of package information for such a package,
  distribute it in a way that is easy for others to install.
patch:
  Given a program with a buggy upstream release, apply a patch.
revert:
  Given a program with buggy Debian packaging, revert a patch.
upgrade:
  Given a program that is packaged in Debian, upgrade to an unpackaged
  version.

The problems with the way Debian does it are:
  - debian/ is a subdirectory of the extracted source tree.
  - Because of the above, debian/rules tries to know about backwards steps.
  - There are too many files that need to be modified.
  - There are too many arcane commands that have to be called.
  - It's not obvious how to build except from apt-get source.
  - It's not obvious how to modify the patch set directly.
  - There is no attempt at managing multiple source versions.

How Simple Tasks are approached:
  quick:
Debian:
  - checkinstall is buggy, quirky, and has no upgrade path.
  - I still haven't figured out how to do this easily. Based on the
'hello' package, which is the simplest possible package, this
requires writing a hundred lines of voodoo. A random sampling of
existing package I've looked at agrees with this as a lower bound.
Gentoo:
  - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo
  - That may look like oversimplification, but the contents of
foo-1.ebuild really are very simple.
  distribute:
Debian:
  - Still haven't figured out the right way.
  - I did find the 'dget' command that does some things. How was I
supposed to know about this obscure command for a common use case?
  - You probably have to ship the whole huge .orig.tar.gz file, even
though it's available on the internet under a different name, or
even if it's really a git snapshot.
Gentoo:
  - Put foo-1.ebuild somewhere online (typically in a git repo)
  - foo-1.ebuild contains the URL of the upstream tarball or git repo.
  patch:
Debian:
  - After trying to make local changes, it said: dpkg-source --commit
  - But it is tedious when you already have a full patch from upstream.
Gentoo:
  - Assume that you're competent enough to get ahold of a patch.
  - Add the patch to files/ (which is shared between all versions of
the package, though you can of course use a different name).
  - Add the filename to the PATCHES=() variable, remanifest.
  revert:
Debian:
  - no clue, it keeps trying to readd the changes and it's not obvious
how to wipe the working tree.
Gentoo:
  - Remove the filename from the PATCHES=() variable, remanifest.
  upgrade:
Debian:
  - Hope it's in experimental.
  - Hope its experimental package is not broken.
  - Hope adding an experimental package won't break dependencies in the
rest of your system.
Gentoo:
  - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest
  - Typically, the source URL will automatically change based on the
version number. If this is not the case, it is very obvious to fix.

In conclusion:
  The current Debian way is complicated. The Gentoo way is simple. This is
  not tied to the fact that Gentoo is a source-based distribution, although
  that does encourage the right mindset.

  For evidence, look at the simplicity of:
- 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-misc/hello/hello-2.8.ebuild?view=markup
- http://devmanual.gentoo.org/eclass-reference/ebuild/index.html

  Do NOT add yet another packaging tutorial or yet another set of helper
  scripts. There are too many as it is - they are just confusing and long.
  For the things that I'm talking about, Gentoo gets along just fine with a
  manpage - though they have a slightly longer guide for official packages.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130425162202.31360.43414.reportbug@ben-laptop.loc

Re: Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library

[Julian Taylor]

On 25.04.2013 18:01, Alessandro Ghedini wrote:
> Package: wnpp
> Owner: Alessandro Ghedini 
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org
> 
> * Package name: libzmq-libzmq2-perl
>   Version : 1.07
>   Upstream Author : Daisuke Maki 
> * URL : https://metacpan.org/release/ZMQ-LibZMQ2/
> * License : Artistic or GPL-1+
>   Programming Lang: Perl
>   Description : Perl bindings to the libzmq 2.x library
> 
> ØMQ is a library which extends the standard socket interfaces with features
> traditionally provided by specialised messaging middleware products.
> 
> ØMQ sockets provide an abstraction of asynchronous message queues, multiple
> messaging patterns, message filtering (subscriptions), seamless access to
> multiple transport protocols and more.
> 
> ZMQ::LibZMQ2 is a thin Perl wrapper around the libzmq 2.x C API.
> 
> 


what is the difference to libzeromq-perl that we already have in unstable?


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51795b97.7070...@googlemail.com

Re: jpeg8 vs jpeg-turbo

[Ondřej Surý]

On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
 wrote:
> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
>> Hi Bill and Debian Developers,
>>
>> My proposal is:
>> A. Add libjpeg-turbo to Debian archive (that's easy)
>> B. Add required provides/alternatives for libjpeg62-dev and
>> libjpeg8-dev (where API/ABI match)
>> C. Decide which package should provide default libjpeg-dev library
>>
>> 1. 
>> https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
>> 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
>> 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034
>
> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has more 
> feature.
>
> I do not see libjpeg-turbo as a suitable replacement. It has
> 1) an different license.
> 2) much more security issues in a much smaller timeframe.
> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.

Bill,

sorry to barge in, but as a maintainer of the most prominent rev-deps
of libjpeg (libgd2 & php5-gd), I would like to have some questions
answered, and I cannot find the answer neither on http://www.ijg.org/
nor http://www.infai.org/jpeg/.

1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
2. What's the legal status of IJG?
3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
4. Is there a (public) bug tracker?
5. Is there a source repository?
6. Is there a mailing list for libjpeg development/users?
7. How do I contribute code to IJG libjpeg?
8. There are new features incorporated to libjpeg? Is that a community
process? Or how are the changes driven? IJG (and the features they
implement in libjpeg) is independent from jpeg.org (the standards
committee).
9. Is there a documentation for new features of libjpeg (DCT,
SmartScale), so independent implementations can be done?
10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
comment rant under: http://blog.kaourantin.net/?p=116)

I haven't been able to find answers at IJG or any linked sites, so as
you are so far the only one taking stand for IJG jpeg implementation,
I would like to to help me to answer those questions.

I wouldn't bother to care about libjpeg in Debian, but it's one of the
core graphics libraries, and I think we should strive for good
compatibility with the rest of the distros, applications and our
users. And the 'new features' of libjpeg seems to contradict this.

Ondrej
--
Ondřej Surý 


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/caljhhg-6u1y0v50zxuzn-2zcgomxy0dg5qb7cqsyc2m1zlz...@mail.gmail.com

Re: Bug#706159: ITP: libzmq-libzmq2-perl -- Perl bindings to the libzmq 2.x library

[Alessandro Ghedini]

On gio, apr 25, 2013 at 06:36:39 +0200, Julian Taylor wrote:
> On 25.04.2013 18:01, Alessandro Ghedini wrote:
> > * Package name: libzmq-libzmq2-perl
> >   Version : 1.07
> >   Upstream Author : Daisuke Maki 
> > * URL : https://metacpan.org/release/ZMQ-LibZMQ2/
> > * License : Artistic or GPL-1+
> >   Programming Lang: Perl
> >   Description : Perl bindings to the libzmq 2.x library
> >
> > [...]
>
> what is the difference to libzeromq-perl that we already have in unstable?

The ZeroMQ module (libzeromq-perl) is deprecated in favour of ZMQ::LibZMQ2
(libzmq-libzmq2-perl), ZMQ::LibZMQ3 and ZMQ. My intention would be to have
libzeromq-perl removed at some point soon (this is why it's not in wheezy, also
see #690680) but it's been taking me a long time (mostly because of a lack of
free time from my part).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'


signature.asc
Description: Digital signature

Re: GSoC project: fedmsg for the Debian infrastructure

[Nicolas Dandrimont]

* Daniel Pocock  [2013-04-25 17:34:03 +0200]:

> On 25/04/13 13:50, Simon Chopin wrote:
> > [ description of the fedmsg project ]
> > Questions, comments?
> 
> ZeroMQ is a very lightweight solution - it is brokerless (like
> multicast) so won't necessarily support the requirement for durable
> subscriptions (keeping messages queued up for clients that are disconnected)
> http://www.zeromq.org/topics:requirements-for-reliability
> 
> Some things that are worth looking at:
> 
> - do we want to use an AMQP broker? In theory, this is an open standard
> like SMTP: the clients and brokers are interchangeable

As Simon already said, the Fedora people have tested this and rejected it
because it didn't scale.

> - as an alternative, could we use something like SIP or XMPP as a
> messaging platform? Then people can receive messages in their chat
> client. In this case it doesn't appear to be the optimal solution, but
> these protocols are quite good for systems that are very widely
> distributed over public networks.
> 
> - then again, there are plenty of examples of systems like Apache Camel
> that can take a message from a traditional broker and deliver it to just
> about anything: SIP, XMPP, email, IRC channel, syslog, Nagios + 200
> other possible destinations:
> http://camel.apache.org/components.html
> and it can use Java or XML to describe various filters and transforms

Those are interesting suggestions, I actually had a look at Camel when it was
suggested to us on another thread, but we will keep going on with fedmsg.

There are several reasons for doing so:
 - It is currently implemented in Fedora, on an infra that is different to ours
   but has similar components

 - This allows for tool interoperability between distros, and why not for
   inter-distro collaboration

 - It's python, which fits very well with most of our stack

 - Upstream has been super, super helpful so far, and I don't see this changing

I wanted Simon to start this thread to gather ideas: I know some people, mostly
in DSA, have thought about such a system for some time, so this was more of a
heads-up than wanting to reconsider the project from scratch. It landed on
-devel because, well, we couldn't find a more appropriate list :)

To get back to your remark, it would definitely be possible to build a
fedmsg-to-xmpp filtering bridge, if there is interest, but that's not really
the scope of this GSoC project.

Cheers,
-- 
Nicolas Dandrimont

BOFH excuse #124:
user to computer ration too low.


signature.asc
Description: Digital signature

Re: GSoC project: fedmsg for the Debian infrastructure

[Jonas Smedegaard]

Quoting Simon Chopin (2013-04-25 18:07:29)
> Quoting Daniel Pocock (2013-04-25 17:34:03)
> > ZeroMQ is a very lightweight solution - it is brokerless (like 
> > multicast) so won't necessarily support the requirement for durable 
> > subscriptions (keeping messages queued up for clients that are 
> > disconnected) 
> > http://www.zeromq.org/topics:requirements-for-reliability
> As I mentionned in my original email (granted, without expanding much 
> on it), I plan to implement a mechanism to solve this very problem by 
> keeping the messages sent on the emitter side and resending them on 
> demand.

Hmm - so essentially you will follow a standard for low-level transport 
of messages, but invent something custom for the slightly higher level 
QoS handling. Sounds odd to me.


> > Some things that are worth looking at:
> > 
> > - do we want to use an AMQP broker? In theory, this is an open 
> > standard like SMTP: the clients and brokers are interchangeable
> 
> This solution has been already examined by the Fedora folks, and 
> rejected by lack of scalability WRT the broker. This sort of question 
> is actually why I think it is a good idea to use fedmsg because its 
> authors have needs that are quite similar to ours, and virtually the 
> same use cases.

Fair enough.

Could you perhaps point to the relevant prior discussions - I am curious 
what they found bad about AMQP, and also curious if they had considered 
MQTT which seems the perfect fit for this (simpler than AMQP, yet 
includes simple QoS and simple authentication not in 0MQ).


Good luck with the project - it sounds quite exciting!

 - Jonas

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

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425172009.28196.54...@bastian.jones.dk

Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

[Wouter Verhelst]

Hi Ben,

On 25-04-13 18:22, Ben Longbons wrote:
> Package: general
> Severity: wishlist
[...long introduction snipped]
> How Simple Tasks are approached:
>   quick:
> Debian:
>   - checkinstall is buggy, quirky, and has no upgrade path.
>   - I still haven't figured out how to do this easily. Based on the
> 'hello' package, which is the simplest possible package,

That's a misconception. The "hello" package shows how to build a Debian
package *without using any helper programs*. Almost nobody ever does
that anymore; I'm not sure why that package still exists. If you want an
example for how to really do things in practice, you should look at
hello-debhelper. Its debian/rules and debian/rules-dh files are much
simpler.

> this
> requires writing a hundred lines of voodoo. A random sampling of
> existing package I've looked at agrees with this as a lower bound.
> Gentoo:
>   - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo
>   - That may look like oversimplification, but the contents of
> foo-1.ebuild really are very simple.

By that rationale, building a Debian package simply requires "mkdir
debian; vim debian/rules; vim debian/control; dch --create; touch
debian/copyright; dpkg-buildpackage". The contents of debian/rules and
debian/control is really simple, dch helps you when creating a
changelog, and an *empty* debian/copyright file is syntactically valid
(though not semantically, of course).

>   distribute:
> Debian:
>   - Still haven't figured out the right way.
>   - I did find the 'dget' command that does some things. How was I
> supposed to know about this obscure command for a common use case?

dget isn't something we expect people not involved in the development of
Debian to use, so it's not documented in user-level documentation.

For distributing source packages, you put them in a directory and call
dpkg-scansources; users can then use "apt-get source" on that repository.

Of course, for Debian you don't ship sources, you ship binaries. For
that, there is dpkg-scanpackages. If you need to do a lot more than just
one or two packages, there are other tools, such as reprepro, which
allow you to just put files in a directory somewhere, and it's magically
moved to the right place, with the right index files updated.

If you're not interested in all that, you don't need to ship the .dsc or
.deb files; if as an upstream you just want to ship debian packaging
files, all you need to do is ship the debian/ directory. This Just
Works(TM).

>   - You probably have to ship the whole huge .orig.tar.gz file, even
> though it's available on the internet under a different name, or
> even if it's really a git snapshot.

If you want to provide a Debian source package, then yes, that's what
you need to do. However, you don't need to provide a full Debian source
package if all you want to do is to allow people to easily build a .deb
file.

[...too bored to come up with a reply to these...]
>   upgrade:
> Debian:
>   - Hope it's in experimental.
>   - Hope its experimental package is not broken.
>   - Hope adding an experimental package won't break dependencies in the
> rest of your system.

- Run "apt-get -d source package", fetch the new upstream source, run
"uupdate" with the right arguments (read the manpage for the details).
Unless it's something very complex, that will almost certainly work.

If, OTOH, it *is* something very complex, then this...

> Gentoo:
>   - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest

... won't work either.

>   - Typically, the source URL will automatically change based on the
> version number. If this is not the case, it is very obvious to fix.

That's not an issue for Debian, as we ship upstream tarballs ourself,
rather than relying on upstream for that. It has some downsides (as you
correctly point out above), but also some upsides. This is one of them
(there are more)

> In conclusion:
>   The current Debian way is complicated. The Gentoo way is simple.

For you.

To this Debian developer who's never done any Gentoo work, the Gentoo
way is complicated and the Debian way is simple.

Put otherwise, going to one distribution and saying "you guys are doing
it all wrong, look at how $OTHER distribution is doing it, you should do
it their way!!1!" isn't very convincing.

-- 
Copyshops should do vouchers. So that next time some bureaucracy
requires you to mail a form in triplicate, you can mail it just once,
add a voucher, and save on postage.


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

Re: GSoC project: fedmsg for the Debian infrastructure

[Luca Filipozzi]

On Thu, Apr 25, 2013 at 07:20:09PM +0200, Jonas Smedegaard wrote:
> Quoting Simon Chopin (2013-04-25 18:07:29)
> > Quoting Daniel Pocock (2013-04-25 17:34:03)
> > > ZeroMQ is a very lightweight solution - it is brokerless (like 
> > > multicast) so won't necessarily support the requirement for durable 
> > > subscriptions (keeping messages queued up for clients that are 
> > > disconnected) 
> > > http://www.zeromq.org/topics:requirements-for-reliability
> >
> > As I mentionned in my original email (granted, without expanding much 
> > on it), I plan to implement a mechanism to solve this very problem by 
> > keeping the messages sent on the emitter side and resending them on 
> > demand.
> 
> Hmm - so essentially you will follow a standard for low-level transport 
> of messages, but invent something custom for the slightly higher level 
> QoS handling. Sounds odd to me.
> 
> > > Some things that are worth looking at:
> > > 
> > > - do we want to use an AMQP broker? In theory, this is an open 
> > > standard like SMTP: the clients and brokers are interchangeable
> > 
> > This solution has been already examined by the Fedora folks, and 
> > rejected by lack of scalability WRT the broker. This sort of question 
> > is actually why I think it is a good idea to use fedmsg because its 
> > authors have needs that are quite similar to ours, and virtually the 
> > same use cases.
> 
> Fair enough.
> 
> Could you perhaps point to the relevant prior discussions - I am curious 
> what they found bad about AMQP, and also curious if they had considered 
> MQTT which seems the perfect fit for this (simpler than AMQP, yet 
> includes simple QoS and simple authentication not in 0MQ).

Indeed.  Both MQTT [1] and PZQ [2] seem interesting, which is hard or me to say
given my unabashed bias towards WSO2.

If we are wed to fedmsg and fedmsg is wed to ZeroMQ, then I'd be interested in
leveragingone of MQTT or PZQ for QoS.

[1] http://mqtt.org/
[2] https://github.com/mkoppanen/pzq/wiki/An-Introduction-To-PZQ

-- 
Luca Filipozzi
http://www.crowdrise.com/SupportDebian


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425182408.ga24...@emyr.net

Bug#706162: ITP: luxio -- Posix bindings for Lua

[Lars Wirzenius]

Package: wnpp
Severity: wishlist
Owner: Lars Wirzenius 

* Package name: luxio
  Version : 1.0
  Upstream Author : Rob Kendrick 
* URL : http://www.rjek.com/software.html
* License : MIT (Same as Lua)
  Programming Lang: Lua
  Description : Posix bindings for Lua

Lightweight UNIX I/O and POSIX binding for Lua

1. Reasonably good coverage of POSIX and BSD Sockets, including IPv6,
   and some GNU extensions.
2. Meant to be buildable anywhere that is POSIX.1-1996.  If it's not,
   there's a bug.  These are likely, as I have nowhere other than
   Linux to test.
3. Low-level.  You get the return values and the errno for the bound
   functions where possible.  Others take a table to fill in, or
   may return tables.
4. High-level wrapper library providing nice IO access and to misc.
   utility functions.  Generates useful errors in assert()able form,
   and provides meaningful __tostring metamethods to aid debugging.
5. A high-level poll()-based event dispatch library.
6. Sub-process handling library (read/write io.popen with job control).
7. A prototype POSIX Message Queue-based IPC scheme that can serialise
   most simple Lua values.  (No closures, userdata, etc)

This package is needed as a dependency for Gitano, for which an ITP will
be filed later.

I will be co-maintaining this package with Daniel Silverstone.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130425182657.411.13242.report...@havelock.liw.fi

Re: Bug#602034: jpeg8 vs jpeg-turbo

[Mike Gabriel]

Hi all,

On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote:


On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
 wrote:

On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:

Hi Bill and Debian Developers,

My proposal is:
A. Add libjpeg-turbo to Debian archive (that's easy)
B. Add required provides/alternatives for libjpeg62-dev and
libjpeg8-dev (where API/ABI match)
C. Decide which package should provide default libjpeg-dev library

1.  
https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian

2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034


As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has  
more feature.


I do not see libjpeg-turbo as a suitable replacement. It has
1) an different license.
2) much more security issues in a much smaller timeframe.
3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.


Bill,

sorry to barge in, but as a maintainer of the most prominent rev-deps
of libjpeg (libgd2 & php5-gd), I would like to have some questions
answered, and I cannot find the answer neither on http://www.ijg.org/
nor http://www.infai.org/jpeg/.

1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
2. What's the legal status of IJG?
3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
4. Is there a (public) bug tracker?
5. Is there a source repository?
6. Is there a mailing list for libjpeg development/users?
7. How do I contribute code to IJG libjpeg?
8. There are new features incorporated to libjpeg? Is that a community
process? Or how are the changes driven? IJG (and the features they
implement in libjpeg) is independent from jpeg.org (the standards
committee).
9. Is there a documentation for new features of libjpeg (DCT,
SmartScale), so independent implementations can be done?
10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
comment rant under: http://blog.kaourantin.net/?p=116)


All questions are really good questions. Some of them have already  
been answered in the backlogs of #602034 [1] and the-merged-with bug  
#612341 [2].


Reading through both of them is probably a good idea for all who are  
interested in the complete story.


Esp. some statements from Guido Vollbeding [3] make me ask myself:  
hey, what kind of guy is that and what is the stand of the IJG in the  
free software ecosystem. His arguing tends to be somehow aggressive  
and inbalanced. One quote that shows what I mean (taken from [3]):


"""
It seems that Bill Allombert is still one of the few sane people out
there, many others have apparently gone mad.
I don't care for the ignorant people.
"""

@Bill: Unfortunately, I am not an expert with image processing, but  
most of what I have read in this thread speaks for re-thinking the  
current strategy of staying with libjpeg IJG.


Can this be a proposal? Package libjpeg and libjpeg-turbo using an  
alternatives setup and thus, making both libs installable in parallel.  
Packagers can then build-depend on one or the other libjpeg  
implementations.


Greets,
Mike

[1] http://bugs.debian.org/602034
[2] http://bugs.debian.org/612341
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612341#116


--

DAS-NETZWERKTEAM
mike gabriel, rothenstein 5, 24214 neudorf-bornstein
fon: +49 (1520) 1976 148

GnuPG Key ID 0x25771B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy:
https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb

pgpqfFSaGlVaK.pgp
Description: Digitale PGP-Unterschrift

Re: GSoC project: fedmsg for the Debian infrastructure

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 25/04/13 18:07, Simon Chopin wrote:
> Quoting Daniel Pocock (2013-04-25 17:34:03)
>> ZeroMQ is a very lightweight solution - it is brokerless (like 
>> multicast) so won't necessarily support the requirement for
>> durable subscriptions (keeping messages queued up for clients
>> that are disconnected) 
>> http://www.zeromq.org/topics:requirements-for-reliability
> As I mentionned in my original email (granted, without expanding
> much on it), I plan to implement a mechanism to solve this very
> problem by keeping the messages sent on the emitter side and
> resending them on demand.

That seems like extra work to do something that can already be done in
a standard way, and it also seems like it is just transferring the
scalability problems from the brokers to the message sources.

>> Some things that are worth looking at:
>> 
>> - do we want to use an AMQP broker? In theory, this is an open
>> standard like SMTP: the clients and brokers are interchangeable
> 
> This solution has been already examined by the Fedora folks, and 
> rejected by lack of scalability WRT the broker. This sort of
> question is actually why I think it is a good idea to use fedmsg
> because its authors have needs that are quite similar to ours, and
> virtually the same use cases.

Red Hat promotes a number of messaging solutions, I've used several of
these things commercially - they publish a very interesting roadmap[1]:
- - HornetQ "new ultra high performance enterprise grade messaging"
- - MRG Messaging (based on Qpid) "Exploits Linux-specific optimizations
for performance"
- - Fuse MQ (based on ActiveMQ)
- - JBoss XQ Messaging

and I'm surprised that they ruled them all out and went for ZeroMQ

OpenStack is working with RabbitMQ, it is based on a broker paradigm too

My own feeling is that brokers do scale to some extent: if reliable
delivery is a requirement, then you just have to buy the right
hardware to run the broker at scale.

>> - as an alternative, could we use something like SIP or XMPP as
>> a messaging platform? Then people can receive messages in their
>> chat client. In this case it doesn't appear to be the optimal
>> solution, but these protocols are quite good for systems that are
>> very widely distributed over public networks.
> Correct me if I'm wrong, but isn't SIP specific to VoIP? I don't
> know much about XMPP outside of its application in chatting.

In practice, that is how they are used, but they are interchangeable
for both purposes. (and please see [2], feedback needed!)

SIP supports methods such as MESSAGE, SUBSCRIBE and NOTIFY which could
provide some very interesting ways to distribute data to
intermittently connected developers in all the odd locations where we
choose to have our workstations.

These protocols may not be at the core of the solution, they could
just be an external interface.


On 25/04/13 19:13, Nicolas Dandrimont wrote:
> * Daniel Pocock  [2013-04-25 17:34:03
> +0200]:

>> - then again, there are plenty of examples of systems like Apache
>> Camel that can take a message from a traditional broker and
>> deliver it to
just
>> about anything: SIP, XMPP, email, IRC channel, syslog, Nagios +
>> 200 other possible destinations: 
>> http://camel.apache.org/components.html and it can use Java or
>> XML to describe various filters and transforms
> 
> Those are interesting suggestions, I actually had a look at Camel
when it was
> suggested to us on another thread, but we will keep going on with
fedmsg.


I didn't necessarily suggest that Camel would replace fedmsg.  I have
used it in much larger environments where it has been the core
component for mediating messaging workflows, running multiple
instances in parallel off a HA message broker.  As such, I'm confident
it could scale well enough to replace fedmsg, but that is not what I'm
arguing - I'm just suggesting that it is a useful tool.  fedmsg could
well be the core of the solution, and a couple of Camel instances
could be set up to implement custom workflows and deliver messages (or
derivatives of the messages) over transports that fedmsg doesn't
natively support.

> I wanted Simon to start this thread to gather ideas: I know some
people, mostly
> in DSA, have thought about such a system for some time, so this
> was
more of a
> heads-up than wanting to reconsider the project from scratch. It
landed on
> -devel because, well, we couldn't find a more appropriate list :)
> 
> To get back to your remark, it would definitely be possible to
> build a fedmsg-to-xmpp filtering bridge, if there is interest, but
> that's
not really
> the scope of this GSoC project.

I agree the GSoC scope needs to be contained, but it would also be
good to have a wider architecture in mind and understand how things
fit together, so please don't feel I'm hijacking that - I just saw the
request for comments and was keen to help.

fedmsg may well be the best way forward, but it would be interesting
to know if we can

Re: GSoC project: fedmsg for the Debian infrastructure

[Stephen Gran]

Hi,

This one time, at band camp, Simon Chopin said:
> Hi,
> 
> Nicolas Dandrimont and I are currently working on a project proposal for
> the Google Summer of Code to use the messaging system written by Fedora,
> fedmsg[0][1], within the Debian infrastructure (some of you might have seen
> the various ITPs related to that on -devel).
> 
> Tollef kindly pointed out to us that Debian service administrators would
> probably have something to say about all this, so here we are.
> 
> As a premise, please note that we obviously plan to make fedmsg
> distro-agnostic before anything else (than packaging). The original
> upstream author seems very enthousiastic about the project, which makes
> it probable that we won't have to carry those patches on our own.
> 
> The thing itself is based on the ZeroMQ protocol.

One of the principles, up to now, of system design for the debian.org
infrastructure has been that it can tolerate single nodes being off line
for periods of time.  My understanding of ZeroMQ is that it doesn't do
very well when the sender and the receiver aren't on line at the same
time.  I have not used ZeroMQ in any serious way, so I'm only repeating
what I've heard.  Please correct me if I'm wrong.

It may be time to revisit our assumptions, of course - our hosting is
dramatically better than it was when I joined the project, and even
since I started doing DSA work.

Thanks for looking into it - something like this would be very useful
for us.

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


signature.asc
Description: Digital signature

Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

[Philip Hands]

Wouter Verhelst  writes:
...
> Put otherwise, going to one distribution and saying "you guys are doing
> it all wrong, look at how $OTHER distribution is doing it, you should do
> it their way!!1!" isn't very convincing.

It's particularly unconvincing if one has witnessed the Gentoo BoF at
this year's FOSDEM[1], in which they discussed the deep joy of having
users who patch packages into a state of uselessness, and then report
bugs against the result without mentioning that they broke the package
themselves.

We have a packaging system that rewards people that read up on the tools
we provide for doing the simple tasks one might expect to be able to do
with it.  Conversely, it punishes those that don't.

If those that expect to be able to do this sort of thing without
consulting any documentation are encouraged to go elsewhere by this
fact, then I'd say that's a feature, not a bug.

Cheers, Phil.

[1] I filmed that session:

  http://mirror.be.gbxs.net/video.fosdem.org//2013/crossdistro/Gentoo_BoF.webm

The relevant bit starts at 11:10, with a very salient quote almost
immediately from Petteri Räty (betelgeuse):

  "I think user patching should be a _bit_ hard ... it's a support
  nightmare. Unless well thought out, all the bugs coming in to
  gentoo.org, debugging becomes ... complicated"

-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpSd9MDsYVYA.pgp
Description: PGP signature

Re: Bug#602034: jpeg8 vs jpeg-turbo

[Ben Hutchings]

On Thu, 2013-04-25 at 20:49 +0200, Mike Gabriel wrote:
> Hi all,
> 
> On Do 25 Apr 2013 18:41:40 CEST Ondřej Surý wrote:
> 
> > On Wed, Apr 24, 2013 at 3:19 PM, Bill Allombert
> >  wrote:
> >> On Wed, Apr 24, 2013 at 11:23:04AM +0200, Ondřej Surý wrote:
> >>> Hi Bill and Debian Developers,
> >>>
> >>> My proposal is:
> >>> A. Add libjpeg-turbo to Debian archive (that's easy)
> >>> B. Add required provides/alternatives for libjpeg62-dev and
> >>> libjpeg8-dev (where API/ABI match)
> >>> C. Decide which package should provide default libjpeg-dev library
> >>>
> >>> 1.  
> >>> https://bitbucket.org/libgd/gd-libgd/issue/50/tests-jpeg-jpeg_readc-fails-on-debian
> >>> 2. http://lists.fedoraproject.org/pipermail/devel/2013-January/176299.html
> >>> 3. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602034
> >>
> >> As IJG libjpeg maintainer, my plan is to move to libjpeg9 which has  
> >> more feature.
> >>
> >> I do not see libjpeg-turbo as a suitable replacement. It has
> >> 1) an different license.
> >> 2) much more security issues in a much smaller timeframe.
> >> 3) do not implement the full libjpeg8 ABI, nor the upcoming libjpeg9.
> >
> > Bill,
> >
> > sorry to barge in, but as a maintainer of the most prominent rev-deps
> > of libjpeg (libgd2 & php5-gd), I would like to have some questions
> > answered, and I cannot find the answer neither on http://www.ijg.org/
> > nor http://www.infai.org/jpeg/.
> >
> > 1. Who is behind IJG? Is it just Guido Vollbeding or there are more people?
> > 2. What's the legal status of IJG?
> > 3. What is the relation of IJG and InfAI (http://www.infai.org/jpeg/)?
> > 4. Is there a (public) bug tracker?
> > 5. Is there a source repository?
> > 6. Is there a mailing list for libjpeg development/users?
> > 7. How do I contribute code to IJG libjpeg?
> > 8. There are new features incorporated to libjpeg? Is that a community
> > process? Or how are the changes driven? IJG (and the features they
> > implement in libjpeg) is independent from jpeg.org (the standards
> > committee).
> > 9. Is there a documentation for new features of libjpeg (DCT,
> > SmartScale), so independent implementations can be done?
> > 10. And what is JPEGClub (http://jpegclub.org/)? (Just found it in the
> > comment rant under: http://blog.kaourantin.net/?p=116)
> 
> All questions are really good questions. Some of them have already  
> been answered in the backlogs of #602034 [1] and the-merged-with bug  
> #612341 [2].
> 
> Reading through both of them is probably a good idea for all who are  
> interested in the complete story.
> 
> Esp. some statements from Guido Vollbeding [3] make me ask myself:  
> hey, what kind of guy is that and what is the stand of the IJG in the  
> free software ecosystem. His arguing tends to be somehow aggressive  
> and inbalanced. One quote that shows what I mean (taken from [3]):
[...]

He also says that he is treating his libjpeg as 'reference code' for
JPEG, i.e. for demonstrating and testing extensions to the JPEG
standard.  This does not sound like production code or a suitable
substitute for the established libjpeg which supported JFIF and little
else (i.e. everything that's in common use) and had a very stable API
for that.  Maybe when the ink is dry on JPEG 201x then we will want a
new libjpeg (perhaps an entirely separate library) that supports it.
But we don't need it now.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy others.


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

Re: Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

[Wookey]

+++ Ben Longbons [2013-04-25 09:22 -0700]:
> Package: general
> Severity: wishlist
> 
> Introduction:
>   This is my attempt at explaining exactly what frustrations prevent me from
>   doing anything with Debian packages, and how another distro (Gentoo) does
>   it better. The fact that Gentoo is a source-based distro is irrelevant.

Not entirely irrelevant, as you admit yourself later. 

And I think you are rather more familiar with gentoo than debian so
stuff seems simpler because you already know what to do. The converse
applies too.

>   patch:
> Debian:
>   - After trying to make local changes, it said: dpkg-source --commit
>   - But it is tedious when you already have a full patch from upstream.

actually this is just the same in Debian as in Gentoo: put the patch in
debian/patches and add its name to debian/patches/series

Applying the patch to the sources first and doing dpkg-source --commit
(*as above) also works (more reliably as it forces you to check that
the patch actually applies here). Neither seems hard to me. 

> Gentoo:
>   - Assume that you're competent enough to get ahold of a patch.
>   - Add the patch to files/ (which is shared between all versions of
> the package, though you can of course use a different name).
>   - Add the filename to the PATCHES=() variable, remanifest.
>   revert:
> Debian:
>   - no clue, it keeps trying to readd the changes and it's not obvious
> how to wipe the working tree.

Remove the patchname from debian/patches/series. Seems equivalent to your
Gentoo example to me.

> Gentoo:
>   - Remove the filename from the PATCHES=() variable, remanifest.


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425190902.ga2...@stoneboat.aleph1.co.uk

Re: Bug#602034: jpeg8 vs jpeg-turbo

[Pau Garcia i Quiles]

Hello,

The KDE maintainer in Fedora started an interesting discussion some time
ago in Digikam's mailing list. There was input from the very IJG:

http://mail.kde.org/pipermail/digikam-devel/2013-January/066206.html

It boils down to "jpeg6-2 is the only important thing. Forget about jpeg8
and jpeg9, which bring incompatible changes".

http://mail.kde.org/pipermail/digikam-devel/2013-January/066256.html

FWIW, Arch and Gentoo also follow the policy that jpeg6-2 (and jpeg-turbo
with 6-2 API/ABI) is the real deal.



On Wed, Apr 24, 2013 at 1:48 PM, Mike Gabriel <
mike.gabr...@das-netzwerkteam.de> wrote:

> Hi Ondřej,
>
> I have just uploaded libjpeg-turbo to Debian and it still hovers in NEW
> [1].
>
> On Mi 24 Apr 2013 11:23:04 CEST Ondřej Surý wrote:
>
>  Debian has already open ITP[3] #602034 for libjpeg-turbo, which
>> support libjpeg62 API/ABI and also some important bits of libjpeg8. As
>> libjpeg is one of the base libraries of the system, I think it might
>> be a good idea to discuss this project wide. Also although I have an
>> opinion (as you might have guessed from this email) that we should try
>> to be aligned with other distributions and the reasoning for not going
>> for , I will be happy with whatever result will end-up.
>>
>
> In an IRC discussion in #debian-devel several weeks ago the consensus was:
> the RT team (represented Julien) will probably not want two libjpeg
> implementations in Debian. My first packaging approach aimed at having the
> compat mode libraries available [2] and allow the user to install them as a
> drop-in replacement for libjpeg8.
>
> The IRC discussion lead to the result that the compat packages are not
> wanted in Debian, only the native TURBOjpeg ABI. I was asked to ping Bill
> Allombert about his opinion to transition from libjpeg8 fully to
> libjpeg8-turbo. @Bill: can you repeat your disposition here again? I guess
> our earlier mailing was a private mail exchange.
>
>  A. Add libjpeg-turbo to Debian archive (that's easy)
>>
>
> Done. Waiting in NEW. Only containing libturbojpeg.so.1
>
>  B. Add required provides/alternatives for libjpeg62-dev and
>> libjpeg8-dev (where API/ABI match)
>>
>
> A packaging example can be seen in [1]. If the packages disappears from
> the NEW queue, you can also obtain a libjpeg-turbo version with compat
> packages provided here [3].
>
>  C. Decide which package should provide default libjpeg-dev library
>>
>
> Last statement from Bill: libjpeg by IJG
>
> Greets,
> Mike
>
>
> [1] 
> http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-2.**html
> [2] 
> http://ftp-master.debian.org/**new/libjpeg-turbo_1.2.90-1.**html
> [3] 
> http://packages.x2go.org/**debian/pool/main/libj/libjpeg-**turbo/
>
> --
>
> DAS-NETZWERKTEAM
> mike gabriel, rothenstein 5, 24214 neudorf-bornstein
> fon: +49 (1520) 1976 148
>
> GnuPG Key ID 0x25771B31
> mail: mike.gabriel@das-netzwerkteam.**de,
> http://das-netzwerkteam.de
>
> freeBusy:
> https://mail.das-netzwerkteam.**de/freebusy/m.gabriel%40das-**
> netzwerkteam.de.xfb




-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

not co-installable Multi-Arch:same packages (was: Re: Issues with Multi-Arch:same packages on purge)

[Andreas Beckmann]

On 2013-04-22 21:38, Andreas Beckmann wrote:
> On 2013-04-22 07:31, Guillem Jover wrote:
>> I guess a way to detect those could be piuparts runs that install
>> multiple instances of Multi-Arch:same packages, purge just one of
...
> Actually I already tried something similar some time ago, although I
> only focussed on co-installability problems. I didn't look into this
...

I just reran these tests (host: amd64, installing the foreign i386 packages) on 
current wheezy and will provide a short report here:

Many packages marked M-A:same are not co-installable due to unsatisfied 
dependencies (usually not all deps are properly multiarchified).
That's not a problem right now, apt will take care of this.

But there are some packages that qualify as "co-installable", but fail to do so:

Uninstallable due to binNMU:
   trying to overwrite shared '/usr/share/doc/libbogl0/changelog.Debian.gz', 
which is different from other instances of package libbogl0:i386
   trying to overwrite shared 
'/usr/share/doc/libclutter-gst-1.0-0/changelog.Debian.gz', which is different 
from other instances of package libclutter-gst-1.0-0:i386
   trying to overwrite shared 
'/usr/share/doc/libclutter-gst-1.0-dbg/changelog.Debian.gz', which is different 
from other instances of package libclutter-gst-1.0-dbg:i386
   trying to overwrite shared '/usr/share/doc/libdmtx0a/changelog.Debian.gz', 
which is different from other instances of package libdmtx0a:i386
   trying to overwrite shared 
'/usr/share/doc/libftdi1-dbg/changelog.Debian.gz', which is different from 
other instances of package libftdi1-dbg:i386
   trying to overwrite shared '/usr/share/doc/libftdi1/changelog.Debian.gz', 
which is different from other instances of package libftdi1:i386
   trying to overwrite shared 
'/usr/share/doc/libftdipp1-dbg/changelog.Debian.gz', which is different from 
other instances of package libftdipp1-dbg:i386
   trying to overwrite shared '/usr/share/doc/libftdipp1/changelog.Debian.gz', 
which is different from other instances of package libftdipp1:i386
   trying to overwrite shared '/usr/share/doc/libmyodbc/changelog.Debian.gz', 
which is different from other instances of package libmyodbc:i386
   trying to overwrite shared '/usr/share/doc/libopenraw1/changelog.Debian.gz', 
which is different from other instances of package libopenraw1:i386
   trying to overwrite shared 
'/usr/share/doc/libopenrawgnome1/changelog.Debian.gz', which is different from 
other instances of package libopenrawgnome1:i386
   trying to overwrite shared '/usr/share/doc/libpano13-2/changelog.Debian.gz', 
which is different from other instances of package libpano13-2:i386
   trying to overwrite shared 
'/usr/share/doc/lua-sql-mysql-dev/changelog.Debian.gz', which is different from 
other instances of package lua-sql-mysql-dev:i386
   trying to overwrite shared 
'/usr/share/doc/lua-sql-mysql/changelog.Debian.gz', which is different from 
other instances of package lua-sql-mysql:i386
   trying to overwrite shared 
'/usr/share/doc/lua-sql-sqlite3-dev/changelog.Debian.gz', which is different 
from other instances of package lua-sql-sqlite3-dev:i386
   trying to overwrite shared 
'/usr/share/doc/lua-sql-sqlite3/changelog.Debian.gz', which is different from 
other instances of package lua-sql-sqlite3:i386
but otherwise dependencies are satisfied, so these might be candidates for 
no-change rebuilds to make them co-installable in wheezy.
Looks like this is a manageable amount of source packages:
  bogl clutter-gst libdmtx libftdi libopenraw libpano13 lua-sql myodbc

Debug packages:
   trying to overwrite shared '/usr/lib/debug/usr/lib/libffi.so.5.0.10', which 
is different from other instances of package libffi5-dbg:i386
Maybe this shouldn't have been MA:same.

Marked as MA:same but ship arch-specific files at shared locations:
   trying to overwrite shared 
'/usr/share/doc/libdmtx-dev/examples/net/Libdmtx.Net.Test/DmtxTest.cs.gz', 
which is different from other instances of package libdmtx-dev:i386
   trying to overwrite shared '/usr/share/doc/libreadline5/examples/Makefile', 
which is different from other instances of package libreadline-gplv2-dev:i386
   trying to overwrite shared 
'/usr/share/doc/libsylph-dev/examples/Makefile.gz', which is different from 
other instances of package libsylph-dev:i386
   trying to overwrite shared '/usr/share/info/udunits2.info.gz', which is 
different from other instances of package libudunits2-0:i386
   trying to overwrite shared '/usr/share/xfce4/helpers/mutt.desktop', which is 
different from other instances of package libexo-helpers:i386
These need to be bugged - what would be the correct severity?


Andreas


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

Re: [Soc-coordination] GSoC project: fedmsg for the Debian infrastructure

[Simon Chopin]

Quoting Stephen Gran (2013-04-25 21:17:29)
> Hi,
> 
> This one time, at band camp, Simon Chopin said:
> > Hi,
> > 
> > Nicolas Dandrimont and I are currently working on a project proposal for
> > the Google Summer of Code to use the messaging system written by Fedora,
> > fedmsg[0][1], within the Debian infrastructure (some of you might have seen
> > the various ITPs related to that on -devel).
> > 
> > Tollef kindly pointed out to us that Debian service administrators would
> > probably have something to say about all this, so here we are.
> > 
> > As a premise, please note that we obviously plan to make fedmsg
> > distro-agnostic before anything else (than packaging). The original
> > upstream author seems very enthousiastic about the project, which makes
> > it probable that we won't have to carry those patches on our own.
> > 
> > The thing itself is based on the ZeroMQ protocol.
> 
> One of the principles, up to now, of system design for the debian.org
> infrastructure has been that it can tolerate single nodes being off line
> for periods of time.  My understanding of ZeroMQ is that it doesn't do
> very well when the sender and the receiver aren't on line at the same
> time.  I have not used ZeroMQ in any serious way, so I'm only repeating
> what I've heard.  Please correct me if I'm wrong.

Well, as I understand it, when sender or receiver are not online, there
is simply no message passing. If your concern is about what happens to
the backlog when the consumer comes back online, then I've already
written about that earlier today :-)

> It may be time to revisit our assumptions, of course - our hosting is
> dramatically better than it was when I joined the project, and even
> since I started doing DSA work.
> 
> Thanks for looking into it - something like this would be very useful
> for us.
Thanks for your input,

Cheers,
Simon



signature.asc
Description: signature

Re: not co-installable Multi-Arch:same packages (was: Re: Issues with Multi-Arch:same packages on purge)

[Jakub Wilk]

* Andreas Beckmann , 2013-04-25, 21:27:
trying to overwrite shared '/usr/lib/debug/usr/lib/libffi.so.5.0.10', 
which is different from other instances of package libffi5-dbg:i386


#650106


Maybe this shouldn't have been MA:same.


There's no problem with -dbg packages being MA:same. They just need to 
use build-id-based paths. dh_strip does it for you in compat >= 9.


trying to overwrite shared 
'/usr/share/doc/libdmtx-dev/examples/net/Libdmtx.Net.Test/DmtxTest.cs.gz', 
which is different from other instances of package libdmtx-dev:i386


I can't reproduce this in unstable.

trying to overwrite shared 
'/usr/share/doc/libreadline5/examples/Makefile', which is different 
from other instances of package libreadline-gplv2-dev:i386


#658850 (someone should reopen it...)

trying to overwrite shared 
'/usr/share/doc/libsylph-dev/examples/Makefile.gz', which is different 
from other instances of package libsylph-dev:i386


#675105

trying to overwrite shared '/usr/share/info/udunits2.info.gz', which is 
different from other instances of package libudunits2-0:i386


#706168

trying to overwrite shared '/usr/share/xfce4/helpers/mutt.desktop', 
which is different from other instances of package libexo-helpers:i386


#680009

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425200916.ga7...@jwilk.net

OpenMAMA?

[Daniel Pocock]

I'm just wondering if anybody else has looked at OpenMAMA or seen any
potential problems for packaging it?

http://www.openmama.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51798f5b.3010...@pocock.com.au

Re: not co-installable Multi-Arch:same packages (was: Re: Issues with Multi-Arch:same packages on purge)

[Jakub Wilk]

* Andreas Beckmann , 2013-04-25, 21:27:

what would be the correct severity?


I've been using important (or normal, if only toy^Wexotic architectures 
were affected) for such file conflicts, regardless of whether you were 
able to reproduce the bug in practice by co-installing the packages in 
question.


You might find this script useful:
http://anonscm.debian.org/viewvc/collab-qa/multi-arch/report-multiarch-bug?view=markup

--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425202429.ga...@jwilk.net

Re: Bug#602034: jpeg8 vs jpeg-turbo

[Michael Biebl]

Am 25.04.2013 20:49, schrieb Mike Gabriel:
> Can this be a proposal? Package libjpeg and libjpeg-turbo using an
> alternatives setup and thus, making both libs installable in parallel.
> Packagers can then build-depend on one or the other libjpeg
> implementations.

Please no. If libjpeg-turbo is the saner implementation, which reading
through the messages posted so far it seems like, let's switch to it fully.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: GSoC project: fedmsg for the Debian infrastructure

[Wookey]

+++ Nicolas Dandrimont [2013-04-25 19:13 +0200]:
> * Daniel Pocock  [2013-04-25 17:34:03 +0200]:
> 
> > - do we want to use an AMQP broker? In theory, this is an open standard
> > like SMTP: the clients and brokers are interchangeable
> 
> As Simon already said, the Fedora people have tested this and rejected it
> because it didn't scale.
> 
> we will keep going on with fedmsg.
> 
> There are several reasons for doing so:
>  - It is currently implemented in Fedora, on an infra that is different to 
> ours
>but has similar components
> 
>  - This allows for tool interoperability between distros, and why not for
>inter-distro collaboration
> 
>  - It's python, which fits very well with most of our stack
> 
>  - Upstream has been super, super helpful so far, and I don't see this 
> changing
> 
> I wanted Simon to start this thread to gather ideas: I know some people, 
> mostly
> in DSA, have thought about such a system for some time, so this was more of a
> heads-up than wanting to reconsider the project from scratch. It landed on
> -devel because, well, we couldn't find a more appropriate list :)

I'm not sure how much this helps, but it seems relevant so I'll add it
to the thoughts: Someone has already written a RabbitMQ (APMQ) based
distributed debian buildd system in python: 
https://github.com/nicholasdavidson/pybit

This seems to cover at least some of the same ground as the proposed
project, but I just thought it should be mentioned in case it helped
as example code or reducing the wheel-reinventing. This one supports
cross-building. I hope fedmsg can too, but they may not have thought
about that as they don't currently do any. But perhaps it's
sufficiently generic and low-level that this is not a relevant point. 


Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425203435.gb2...@stoneboat.aleph1.co.uk

Re: Bug#602034: jpeg8 vs jpeg-turbo

[Marco d'Itri]

On Apr 25, Michael Biebl  wrote:

> Please no. If libjpeg-turbo is the saner implementation, which reading
> through the messages posted so far it seems like, let's switch to it fully.
Agreed.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: mis-identification of quotations due to lazy bike-shedding

[Thomas Goirand]

On 04/25/2013 03:51 PM, Neil Williams wrote:
> On Thu, 25 Apr 2013 07:08:48 +0800
> Thomas Goirand  wrote:
>
>> On 04/25/2013 01:52 AM, Neil McGovern wrote:
>>> Perhaps you should go read the bug report first. As you seem to be
>>> unwilling to actually do research, I'll include the relevant section for
>>> your benefit:
>> When you write:
> This will be my only reply to this particular bike-shed.
>
> Thomas: Read the bug report. I filed it. Neil McGovern quoted it. I
> wrote the comments as part of a wider critique of the package. You are
> replying to Neil McGovern as if he wrote it. 
Sorry for the confusion.
You have my apologies, if you can accept them.

Thomas


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

Re: [Soc-coordination] GSoC project: fedmsg for the Debian infrastructure

[Simon Chopin]

Quoting Peter Palfrader (2013-04-25 22:49:36)
> On Thu, 25 Apr 2013, Simon Chopin wrote:
> 
> > > One of the principles, up to now, of system design for the debian.org
> > > infrastructure has been that it can tolerate single nodes being off line
> > > for periods of time.  My understanding of ZeroMQ is that it doesn't do
> > > very well when the sender and the receiver aren't on line at the same
> > > time.  I have not used ZeroMQ in any serious way, so I'm only repeating
> > > what I've heard.  Please correct me if I'm wrong.
> > 
> > Well, as I understand it, when sender or receiver are not online, there
> > is simply no message passing. If your concern is about what happens to
> > the backlog when the consumer comes back online, then I've already
> > written about that earlier today :-)
> 
> Does that imply you expect us to run services on core infrastructure
> machines that listen to the world?

I don't know where you have read this implication, but no that is
certainly not what I meant.

PS: Removing the extra MLs from the Cc list. Please keep Ralph in Cc
though.


signature.asc
Description: signature

Re: mis-identification of quotations due to lazy bike-shedding

[Thomas Goirand]

On 04/25/2013 03:51 PM, Neil Williams wrote:
> As with the rest of this ridiculous thread, all the discussion is about
> one element of a much larger problem and it was the entirety of the
> previous packaging which convinced me that there were only two sane
> options for the package: Fix all of the problems or remove the package
> entirely.
>
> I was not seeking removal merely due to this one quoted part of the bug
> report. There were other, more serious, issues than this one but nobody
> seems to have noticed any of that.

I'm quite tired that people tell me I should read the bug report,
and make sure I'm aware of things.

FYI, I have read the full bug report, and downloaded the package
from snapshot.d.o to see what we were talking about.

What I found was indeed a package that had lots of hacks in the
debian/rules, but at the same time, absolutely all hacks where
carefully commented with the dh_* equivalent. In fact, I found it
very interesting to read, quite fun, and probably a good thing to
show to newbies so that they understand what's behind the dh
automagic "deliberate obfuscation". :)

> The bug is now fixed, the package wasn't removed, I will not reply to
> any messages relating to it or this bike-shedding thread either on or
> off list. Anyone who perpetuates this sub-thread invites the moniker of
> "troll" - unless posting entirely in fun.

Sure, let's move on...

Thomas


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

Re: [Soc-coordination] GSoC project: fedmsg for the Debian infrastructure

[Peter Palfrader]

On Thu, 25 Apr 2013, Simon Chopin wrote:

> > One of the principles, up to now, of system design for the debian.org
> > infrastructure has been that it can tolerate single nodes being off line
> > for periods of time.  My understanding of ZeroMQ is that it doesn't do
> > very well when the sender and the receiver aren't on line at the same
> > time.  I have not used ZeroMQ in any serious way, so I'm only repeating
> > what I've heard.  Please correct me if I'm wrong.
> 
> Well, as I understand it, when sender or receiver are not online, there
> is simply no message passing. If your concern is about what happens to
> the backlog when the consumer comes back online, then I've already
> written about that earlier today :-)

Does that imply you expect us to run services on core infrastructure
machines that listen to the world?

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425204936.gs23...@anguilla.noreply.org

Bug#706179: ITP: r-cran-rsclient -- R client for the headless Rserve R server

[Dirk Eddelbuettel]

Package: wnpp
Owner: Dirk Eddelbuettel 
Severity: wishlist

* Package name: r-cran-rsclient
  Version : 0.7-2
  Upstream Author : Simon Urbanek
* URL or Web page : http://www.rforge.net/RSclient/index.html
* License : GPL-2 plus OpenSSL exception
  Description : R client for the headless Rserve R server

This package extend the 'rserve' package we have had in Debian since 2007.
'rserve' already includes several reference clients, but this package
provides a more extensive version.

The package uses OpenSSL, and at my urging, Simon added the following to his
top-level LICENSE file:

[Summary: GPL-2 with OpenSSL linking exception]

RSclient
Copyright (C) 2002-2013 Simon Urbanek

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.

In addition, as a special exception, the copyright holders give
permission to link the code of portions of this program with the
OpenSSL project's "OpenSSL" library (or with modified versions of
it that use the same license as the "OpenSSL" library - see
http://www.openssl.org/), and distribute linked combinations
including the two.

You must obey the GNU General Public License in all respects
for all of the code used other than OpenSSL.  If you modify
file(s) with this exception, you may extend this exception to your
version of the file(s), but you are not obligated to do so.  If you
do not wish to do so, delete this exception statement from your
version.  If you delete this exception statement from all source
files in the program, then also delete it here.


which is followed by a full copy of the GPL-2.  I believe that this meets our
standards. 

Dirk

-- 
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjwmxpkb@max.nulle.part

Bug#706180: ITP: node-once -- Run a function only once with this module for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-once
  Version : 1.1.1
  Upstream Author : Isaac Z. Schlueter 
* URL : https://github.com/isaacs/once
* License : BSD-2-clause
  Programming Lang: JavaScript
  Description : Run a function only once with this module for Node.js

node-once is useful to make sure a listener for multiple events is
only run once.
.
Node.js is an event-based server-side javascript engine.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130425215929.19037.25318.reportbug@imac.chaumes

Re: Bug#602034: jpeg8 vs jpeg-turbo

[Ondřej Surý]

I think this might be a good move, since the libjpeg-turbo maintainer
still wants to keep compatibility with libjpeg7/8, and he doesn't want
to implement incompatible changes, which might be introduced when
coding Jpeg2000 or JpegXR.

And if there's and consensus in the community that libjpeg-turbo is
way to go, he might be brave and implement the real standards codified
by the Joint Photographic Experts Group, which would be something I
consider good (adhere to standard for interoperability).

See:
http://sourceforge.net/p/libjpeg-turbo/discussion/1086868/thread/40a03431/
http://sourceforge.net/p/libjpeg-turbo/feature-requests/4/

O.

On Thu, Apr 25, 2013 at 10:43 PM, Marco d'Itri  wrote:
> On Apr 25, Michael Biebl  wrote:
>
>> Please no. If libjpeg-turbo is the saner implementation, which reading
>> through the messages posted so far it seems like, let's switch to it fully.
> Agreed.
>
> --
> ciao,
> Marco



-- 
Ondřej Surý 


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

Re: Bug#706078: ITP: base91 -- base91 encoder/decoder

[Andreas Bombe]

On Wed, Apr 24, 2013 at 03:40:57PM +0200, Franck wrote:
> basE91 is an advanced method for encoding binary data as ASCII characters. It
> is similar to UUencode or base64, but is more efficient. The overhead produced
> by basE91 depends on the input data. It amounts at most to 23% (versus 33% for
> base64) and can range down to 14%, which typically occurs on 0-byte blocks.
> This makes basE91 very useful for transferring larger files over binary
> insecure connections like e-mail or terminal lines.

That word should be safety, not security. Safety here means the message
does not get mangled, security on the other hand would mean things like
encryption.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130425214222.gb8...@amos.fritz.box

Work-needing packages report for Apr 26, 2013

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 523 (new: 8)
Total number of packages offered up for adoption: 145 (new: 1)
Total number of packages requested help for: 64 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   jython (#705825), orphaned 5 days ago
 Description: Python seamlessly integrated with Java
 Reverse Depends: libred5-java libsikuli-script-java
 Installations reported by Popcon: 812

   libconstantine-java (#705826), orphaned 5 days ago
 Description: platform constants for Java
 Reverse Depends: jython libjnr-posix-java
 Installations reported by Popcon: 894

   pppconfig (#705769), orphaned 6 days ago
 Description: A text menu based utility for configuring ppp
 Installations reported by Popcon: 3461

   premail (#705938), orphaned 3 days ago
 Description: An e-mail privacy package.
 Installations reported by Popcon: 38

   screenie-qt (#705914), orphaned 3 days ago
 Description: fancy screenshot composer
 Installations reported by Popcon: 105

   spamprobe (#705824), orphaned 5 days ago
 Description: Bayesian spam filter
 Installations reported by Popcon: 607

   svn-all-fast-export (#705916), orphaned 3 days ago
 Description: fast-import based converter to convert repos from svn
   to git
 Installations reported by Popcon: 111

   tpp (#706041), orphaned 2 days ago
 Description: text presentation program
 Installations reported by Popcon: 104

515 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   pycocuma (#705767), offered 6 days ago
 Description: Pythonic Contact and Customer Management
 Installations reported by Popcon: 74

144 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apt-file (#703366), requested 38 days ago
 Description: search for files within Debian packages (command-line
   interface)
 Reverse Depends: command-not-found
 Installations reported by Popcon: 13568

   apt-xapian-index (#567955), requested 1179 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: ept-cache fuss-launcher goplay packagesearch
 Installations reported by Popcon: 65660

   asymptote (#517342), requested 1518 days ago
 Description: script-based vector graphics language inspired by
   MetaPost
 Installations reported by Popcon: 4311

   athcool (#278442), requested 3103 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 61

   balsa (#642906), requested 578 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 808

   bastille (#592137), requested 992 days ago
 Description: Security hardening tool
 Installations reported by Popcon: 171

   cardstories (#624100), requested 731 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 8

   chromium-browser (#583826), requested 1061 days ago
 Description: Chromium browser
 Reverse Depends: chromium chromium-browser chromium-browser-dbg
   chromium-browser-inspector chromium-browser-l10n chromium-dbg
   chromium-l10n mozplugger
 Installations reported by Popcon: 13689

   cups (#532097), requested 1419 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups chromium cups cups-backend-bjnp cups-bsd
   cups-client cups-dbg cups-filters cups-pdf cups-pk-helper (65 more
   omitted)
 Installations reported by Popcon: 109569

   debtags (#567954), requested 1179 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2475

   doc-central (#566364), requested 1188 days ago
 Description: web-based documentation browser
 Installations reported by Popcon: 206

   fbcat (#565156), requested 1198 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 149

   flightgear (#487388), requested 1769 days ago
 Description: Flight Gear Flight Simulator
 Installations reported by Popcon: 785

   freeipmi (#628062), requested 700 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse De

Bug#706160: marked as done (general: it should be easier for ordinary developers to work with Debian packages)

[Debian Bug Tracking System]

Your message dated Fri, 26 Apr 2013 07:10:37 +0200
with message-id <20130426051037.gg5...@mykerinos.kheops.frmug.org>
and subject line Re: Bug#706160: general: it should be easier for ordinary 
developers to work with Debian packages
has caused the Debian Bug report #706160,
regarding general: it should be easier for ordinary developers to work with 
Debian packages
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
706160: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706160
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: wishlist

Introduction:
  This is my attempt at explaining exactly what frustrations prevent me from
  doing anything with Debian packages, and how another distro (Gentoo) does
  it better. The fact that Gentoo is a source-based distro is irrelevant.

  I hope you will seriously consider the issues here for jessie, rather than
  replying "we understand our system, if others don't that's their problem".

First some definitions:
  Ordinary Developer:
A debian user who is comfortable enough with command-line to install
programs in /usr/local. They want to perform Simple Tasks.
  Simple Tasks:
quick:
  Given a program that is not packaged for Debian and is not
  sufficiently useful to the general public to be worth the maintenance
  burden, install it such that the package manager knows about it.
distribute:
  Given a completed set of package information for such a package,
  distribute it in a way that is easy for others to install.
patch:
  Given a program with a buggy upstream release, apply a patch.
revert:
  Given a program with buggy Debian packaging, revert a patch.
upgrade:
  Given a program that is packaged in Debian, upgrade to an unpackaged
  version.

The problems with the way Debian does it are:
  - debian/ is a subdirectory of the extracted source tree.
  - Because of the above, debian/rules tries to know about backwards steps.
  - There are too many files that need to be modified.
  - There are too many arcane commands that have to be called.
  - It's not obvious how to build except from apt-get source.
  - It's not obvious how to modify the patch set directly.
  - There is no attempt at managing multiple source versions.

How Simple Tasks are approached:
  quick:
Debian:
  - checkinstall is buggy, quirky, and has no upgrade path.
  - I still haven't figured out how to do this easily. Based on the
'hello' package, which is the simplest possible package, this
requires writing a hundred lines of voodoo. A random sampling of
existing package I've looked at agrees with this as a lower bound.
Gentoo:
  - vim foo-1.ebuild; ebuild foo-1.ebuild manifest; emerge foo
  - That may look like oversimplification, but the contents of
foo-1.ebuild really are very simple.
  distribute:
Debian:
  - Still haven't figured out the right way.
  - I did find the 'dget' command that does some things. How was I
supposed to know about this obscure command for a common use case?
  - You probably have to ship the whole huge .orig.tar.gz file, even
though it's available on the internet under a different name, or
even if it's really a git snapshot.
Gentoo:
  - Put foo-1.ebuild somewhere online (typically in a git repo)
  - foo-1.ebuild contains the URL of the upstream tarball or git repo.
  patch:
Debian:
  - After trying to make local changes, it said: dpkg-source --commit
  - But it is tedious when you already have a full patch from upstream.
Gentoo:
  - Assume that you're competent enough to get ahold of a patch.
  - Add the patch to files/ (which is shared between all versions of
the package, though you can of course use a different name).
  - Add the filename to the PATCHES=() variable, remanifest.
  revert:
Debian:
  - no clue, it keeps trying to readd the changes and it's not obvious
how to wipe the working tree.
Gentoo:
  - Remove the filename from the PATCHES=() variable, remanifest.
  upgrade:
Debian:
  - Hope it's in experimental.
  - Hope its experimental package is not broken.
  - Hope adding an experimental package won't break dependencies in the
rest of your system.
Gentoo:
  - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest
  - Typically, the source URL will automatically change based on the
version number. If this is not the case, it is very obvious to fix.

In

Bug#706160: general: it should be easier for ordinary developers to work with Debian packages

[Bernhard R. Link]

* Ben Longbons  [130425 18:27]:
> The problems with the way Debian does it are:
>   - debian/ is a subdirectory of the extracted source tree.

Why do you think that is a problem?

>   - Because of the above, debian/rules tries to know about backwards steps.

What are "backwards steps"?

>   - There are too many arcane commands that have to be called.

./debian/rules build
fakeroot ./debian/rules binary

Everything else is mostly convenience wrappers.

>   - It's not obvious how to modify the patch set directly.

modify upstream files, call dpkg-source --commit

>   - There is no attempt at managing multiple source versions.

First you say things are too complicated, then you complain about
some obscure missing option I never found any use case for.

> How Simple Tasks are approached:
>   Given a program that is not packaged for Debian and is not
>   sufficiently useful to the general public to be worth the maintenance
>   burden, install it such that the package manager knows about it.
> Debian:
>   - checkinstall is buggy, quirky, and has no upgrade path.
>   - I still haven't figured out how to do this easily. Based on the
> 'hello' package, which is the simplest possible package, this
> requires writing a hundred lines of voodoo. A random sampling of
> existing package I've looked at agrees with this as a lower bound.

You can't have easy and high-quality at the same time. Most of the tools
used for official Debian package have the minimal complexity needed for
some quality. Apart from having someone write tools to simply create
private packages there is not much that can be done here.
(and from what you describe for Gentoo, I do not really see how a
dh_make ; vim debian/* ; dpkg-buildpackage is more complicated than the
Gentoo case).


>   Given a completed set of package information for such a package,
>   distribute it in a way that is easy for others to install.
> Debian:
>   - Still haven't figured out the right way.

There are many ways, because needs are different.

>   - I did find the 'dget' command that does some things. How was I
> supposed to know about this obscure command for a common use case?

dget is simply a convenience wrapper. Just have three files to download
for a source package. Anyone can click at three links easily.

>   - You probably have to ship the whole huge .orig.tar.gz file, even
> though it's available on the internet under a different name, or
> even if it's really a git snapshot.

Sorry, but this is bullshit. If you want to make it easy for users, put
the .orig.tar.gz there. References too external resources will always go
stale and are and endless source of user frustration.

>   Given a program with a buggy upstream release, apply a patch.
> Debian:
>   - After trying to make local changes, it said: dpkg-source --commit
>   - But it is tedious when you already have a full patch from upstream.

patch -i patchfile ; dpkg-source --commit

I thought it was about users knowing the basic command line utilities?

>   Given a program with buggy Debian packaging, revert a patch.
> Debian:
>   - no clue, it keeps trying to readd the changes and it's not obvious
> how to wipe the working tree.

The very easy way: just revert the change and add another dpkg-source --commit
The direct way: revert the change, remove the line from debian/patches/series
The complicated way: use quilt or some other high-level tool.

>Gentoo:
>  - Assume that you're competent enough to get ahold of a patch.
>  - Add the patch to files/ (which is shared between all versions of
>the package, though you can of course use a different name).
>  - Add the filename to the PATCHES=() variable, remanifest.
>
> Gentoo:
>   - Remove the filename from the PATCHES=() variable, remanifest.

Yeah, because every patch can simply be removed without any effects on
the other patches, you can just apply any patches you need to the
version you need. And if it doesn't you can just apply manually, fix it
and produce a new clean patch. NOT, seriously.

That you can just do stuff in your working directory, build and fix
again iteratively in your working directory and finally have some
working package is in my eyes one of the biggest strengths of Debian's
package format w.r.t. low entrance and making it easy for unexperienced
people to use Debian to meed their needs.

> Gentoo:
>   - cp foo-1.ebuild foo-2.ebuild; ebuild foo-2.ebuild manifest
>   - Typically, the source URL will automatically change based on the
> version number. If this is not the case, it is very obvious to fix.

your gentoo solution is the equivalent of copying the debian/ directory
around.

> In conclusion:
>   The current Debian way is complicated. The Gentoo way is simple. This is
>   not tied to the fact that Gentoo is a source-based distribution, although
>   that does enc