Re: chromium-browser from experimental has included h.264 by default?

[Giuseppe Iuculano]

On 08/10/2010 09:25 PM, Adam D. Barratt wrote:
>> > Chromium isn't meant to be released with Squeeze. We'll reevaluate for
>> > Squeeze+1.
> Is that still the case?

No, it isn't. Please see #581265 and in particular message #32, #37 and #44

Cheers,
Giuseppe.



signature.asc
Description: OpenPGP digital signature

Raw Idea: one more control field for sponsors

[Toni Mueller]

Hi,

while working on a package I'm going to sponsor, it occurred to me with
all the DD, DM and sponsoring going on, that I'd like to have a field
in debian/control, like eg.

Bugs-To: some...@debian.org, ...

to have some...@debian.org automatically subscribed to the bugs for
this package, much in the same vein as the 'Uploaders:' field works.

I have found out that there are other ways to get at the bug reports
for some random package, but this could probably simplify things from
the perspective of a sponsor.

I would also like to know whether you think it is a good idea that a
sponsor be automatically subscribed to the bugs for all packages he
sponsors.


Kind regards,
--Toni++


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

Re: Notes from the DebConf Source Format BoF

[Bernhard R. Link]

* Russ Allbery  [100811 05:27]:
> If you're implementing 3.0 format, please don't hard-code the extensions that
> you "know" will be found in source packages, because as we add additional
> files listed in *.dsc, we may add other types of files.

Please be carefull with adding new extensions. Those files end up in
.changes files and in the pool/. The extensions of those files are
already hardcoded in many places (partly because of oversight, partly
because of missing imagination, partly because it is really hard to
catch common errors if you have no idea what you are dealing with).

> One issue with 3.0 (quilt) is that when you check it out when it's
> maintained in a VCS, you have two choices: commit the .pc directory and
> files, or leave it out and then have to run some magic after you fetch the
> VCS in order to work on the quilt patches.  (Assuming you check in to your
> VCS the results of having all the patches applied.)

If you have a patches source and no .pc that means:

if you just change stuff and call dpkg-source (e.g. via
dpkg-buildpackage), a new patch on top will just be generated.

And you can always use the method the patches were generated from. The
only thing that does not work is working with quilt on the already
existing patches easily. (I personally think quilt is just missing an
option to be initialized on an already patched working directory. That
would also could have avoided the "create .pc as dpkg-source -x" madness).

> - Why don't you just check in with patches not applied?
> [...]
>   * You can do this with a rebased patch branch, but then you don't get
> history on modifications to the patch.

You can merge the the different states of the patched branch into your
main branch. That way you can rebase it and still have the old state
around. (That is what git-dpm does).

Bernhard R. Link


-- 
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/20100811104138.ga7...@pcpool00.mathematik.uni-freiburg.de

Re: doc-base is hugely unloved; bug mass-filing needed?

[Ben Hutchings]

On Tue, 2010-08-10 at 18:08 +, Ian Zimmerman wrote:
> Steve Langasek  debian.org> writes:
> 
> > But again, as Thomas points out, you can address this use case with much
> > less per-package effort.  A centralized ten-line shell script would be
> > enough to locate all the installed packages on the system that ship files
> > under /usr/share/doc not matching the pattern
> > {copyright,NEWS*,changelog*,README*} and grab the short description of the
> > responsible package.  If you want to be really clever, some introspection of
> > html documents could give you document titles.  Then you only need to worry
> > about the minority of cases where autodetection fails.
> > 
> 
> PDFs have titles too, and they can't be snarfed in any way I know of.
[...]

pdfinfo from poppler-utils can show the title.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Re: why are there /bin and /usr/bin...

[Goswin von Brederlow]

Steve Langasek  writes:

> On Tue, Aug 10, 2010 at 11:53:10PM +0200, Goswin von Brederlow wrote:
>> Bruce Sass  writes:
>
>> Note that there is /lib/libcrypt* (at least here). This is just the more
>> optimized flavour the ld.so picks when the cpu supports it.
>
> libcrypt != libcrypto.

Ups, sorry.

MfG
Goswin


-- 
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/87lj8dnxfl@frosties.localdomain

Re: Raw Idea: one more control field for sponsors

[Ben Finney]

Toni Mueller  writes:

> while working on a package I'm going to sponsor, it occurred to me
> with all the DD, DM and sponsoring going on, that I'd like to have a
> field in debian/control, like eg.
>
> Bugs-To: some...@debian.org, ...

In the source package stanza, or the binary package stanza?

> to have some...@debian.org automatically subscribed to the bugs for
> this package, much in the same vein as the 'Uploaders:' field works.

This appears to duplicate functionality of the Package Tracking System
http://www.debian.org/doc/manuals/developers-reference/resources.html#pkg-tracking-system>.
Why is the PTS insufficient for this purpose?

(I'm not weighing in either way, I just think that adding duplicate
behaviour needs justification one way or another.)

-- 
 \ “To save the world requires faith and courage: faith in reason, |
  `\and courage to proclaim what reason shows to be true.” |
_o__)—Bertrand Russell |
Ben Finney


-- 
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/87y6cdw8z3@benfinney.id.au

Re: Notes from the DebConf Source Format BoF

[Wouter Verhelst]

On Tue, Aug 10, 2010 at 08:27:24PM -0700, Russ Allbery wrote:
> source.debian.org is working on importing source packages into a Git
> repository and storing the history as one revision per new source package
> upload.

That gives a 404. source.debian.net doesn't, but gives you a page with
as full contents the eight characters 'hallo...'

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html


-- 
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/20100811143133.gh22...@celtic.nixsys.be

Re: Notes from the DebConf Source Format BoF

[James Vega]

On Wed, Aug 11, 2010 at 10:31 AM, Wouter Verhelst  wrote:
> On Tue, Aug 10, 2010 at 08:27:24PM -0700, Russ Allbery wrote:
>> source.debian.org is working on importing source packages into a Git
>> repository and storing the history as one revision per new source package
>> upload.
>
> That gives a 404. source.debian.net doesn't, but gives you a page with
> as full contents the eight characters 'hallo...'

According to  it's still in
the idea/planning phase.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


-- 
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/aanlktikqdey_dzg=lcog-68jnwgpazqzs6cdrba8q...@mail.gmail.com

Re: Raw Idea: one more control field for sponsors

[Eugene V. Lyubimkin]

Hi,

Toni Mueller wrote:
> in debian/control, like eg.
> 
> Bugs-To: some...@debian.org, ...
This is the info which IMHO belongs to PTS and should stay there.

> I have found out that there are other ways to get at the bug reports
> for some random package, but this could probably simplify things from
> the perspective of a sponsor.
I consider PTS's fill-a-field-and-click much easier than changing a package.

I don't think this info (bug sending and handling) belongs to package control
files.

> I would also like to know whether you think it is a good idea that a
> sponsor be automatically subscribed to the bugs for all packages he
> sponsors.
I think it's a good idea, but this probably belongs to another thread.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer



signature.asc
Description: OpenPGP digital signature

Re: Notes from the DebConf Source Format BoF

[Stefano Zacchiroli]

On Tue, Aug 10, 2010 at 08:27:24PM -0700, Russ Allbery wrote:
> After a discussion on IRC, I organized a BoF at DebConf10 to discuss new
> source formats, specifically 3.0 (git).  Below are the notes from that
> discussion.  I tried to take reasonably comprehensive notes, but I'm sure
> that I missed things.  Other participants, please add any additional bits
> that I forgot!

Thanks for this very detailed notes!
Can you please also upload them as attachment to the Penta event at
http://penta.debconf.org/dc10_schedule/events/691.en.html ?

I've tried to do that for the events I own (with both slides and
minutes) and I find that to be a very good way to keep future/historical
memory of discussions we have at DebConf. Unfortunately, AFAICT only the
owner can add attachments, so it should be you doing that.

Thanks again!

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Notes from the DebConf Source Format BoF

[Tollef Fog Heen]

]] Russ Allbery 

| After a discussion on IRC, I organized a BoF at DebConf10 to discuss new
| source formats, specifically 3.0 (git).  Below are the notes from that
| discussion.  I tried to take reasonably comprehensive notes, but I'm sure
| that I missed things.  Other participants, please add any additional bits
| that I forgot!

I assume this is also meant as a starting point for further discussion
on the topic.

[...]

| ftp-team is concerned about doing license checks across the entire git
| archive Colin points out that we're in the same situation with Alioth for
| redistributability.  However, it is easier to withdraw things from Alioth
| than from the archive.  And redistributability (the legal requirement) is
| a lot less of a bar than what we check for DFSG.

While I am sympathetic with the problem of reviewing a large source
repository, I find myself increasingly considering the git repository as
the preferred form for modification, meaning that even a shallow clone
can't really be considered source any more than preprocessed source
would be, or a configure script without the corresponding configure.ac.

To some extent, I guess this then comes down to whose preferred form
we're talking about, if it's upstream's, Debian's, popular opinions, the
strictest of those, the least strict or something else entirely?

I don't really have a good solution here, so if somebody has a way to
make both camps happy, that'd be wonderful.

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


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

Re: Notes from the DebConf Source Format BoF

[Ian Jackson]

Russ Allbery writes ("Notes from the DebConf Source Format BoF"):
> * Part of Joey's motivation is that if you look at GitHub, the
>   people using it a lot consider Git to be a source package format,

I've been doing that for some non-Debian work.  It turns out to be
incredibly convenient, if you're prepared to assume that your
recipients have git.  It becomes a software distribution format, a
download tool, and a patch update tool, and makes lots of tiresome
operations very easy.  

I've found it tenable even for naive users (of whom I know they're
using Linux): the download instructions say "install git-core, and
then say git-clone thingy".

We should remember that our source formats and archive, together,
_are_ a revision control system, and a pretty poor one at that.

Ian.


-- 
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/19554.54309.552798.76...@chiark.greenend.org.uk

Re: Notes from the DebConf Source Format BoF

[Russ Allbery]

Tollef Fog Heen  writes:
> ]] Russ Allbery 

> | After a discussion on IRC, I organized a BoF at DebConf10 to discuss new
> | source formats, specifically 3.0 (git).  Below are the notes from that
> | discussion.  I tried to take reasonably comprehensive notes, but I'm sure
> | that I missed things.  Other participants, please add any additional bits
> | that I forgot!

> I assume this is also meant as a starting point for further discussion
> on the topic.

Oh, yes, absolutely!  Nothing is ever decided at a DebConf, since not
everyone is there.  It all needs to come back to the project mailing
lists.  But it's useful occasionally to have a high-bandwidth discussion
with notes so that people end up on more of the same page.

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


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

Re: Notes from the DebConf Source Format BoF

[Giacomo A. Catenazzi]

On 08/11/2010 06:47 PM, Ian Jackson wrote:

Russ Allbery writes ("Notes from the DebConf Source Format BoF"):

* Part of Joey's motivation is that if you look at GitHub, the
   people using it a lot consider Git to be a source package format,


I've been doing that for some non-Debian work.  It turns out to be
incredibly convenient, if you're prepared to assume that your
recipients have git.  It becomes a software distribution format, a
download tool, and a patch update tool, and makes lots of tiresome
operations very easy.

I've found it tenable even for naive users (of whom I know they're
using Linux): the download instructions say "install git-core, and
then say git-clone thingy".

We should remember that our source formats and archive, together,
_are_ a revision control system, and a pretty poor one at that.


hmm.

I think there are three usual use of the sources:
- developers/bug trackers/...
- users: to check and to learn the sources
- admins: who need to recompile/backport/.. sources

Using git for the last two groups seems too much.
Your solution will works only for master branch, but
the other users will need the "stable" or testing branch.
[Note: a wrapper could solve this]

Should sysadmin, which recompile a package, create
a new branch and commit the changes?
dpkg-source will no more create a new source package?
Do we really require sysadmin to learn the basic use of git?

IMHO we should use both methods. One, the classical one,
for users/sysadmin, and distributed in the mirrors,
and the second one in a central git debian server
(either with native git when available, and with imported
from tar.gz+diff.gz or other CVS, in the other cases).

BTW I find convenient to put the original source in git,
and removing non DFSG file (but distributable, like RFC
and GFDL) in the debian branches.
This would cause some problem IMHO in 3.0 (git).

ciao
cate


--
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/4c62e0da.9080...@debian.org

Re: eXtplorer web file manager packaging work and SWFUpload packaging

[Paul Wise]

On Mon, Aug 9, 2010 at 4:58 PM, Thomas Goirand  wrote:

> 2/ Ask for help for packaging swfupload
...
> How to fix the SWFUpload issue:
> - ---
> The SWFUpload is a client side file upload tool that uses a combination
...

AFAICT the source code is ActionScript 3 so you are out of luck with
mtasc and will need to use the old swfupload version v1.0.2 or make
some changes.

http://swfupload.org/forum/generaldiscussion/74

That said, it seems Adobe's stuff is MPL licensed so maybe it could be
packaged and used.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Usage of /var/lib for databases not properly described in policy

[Christoph Anton Mitterer]

On Tue, 2010-08-10 at 22:29 +0200, Andreas Tille wrote:
> I just tried to give some advise about proper placement of database
> files in a Debian package and I was sure I could simply link to the
> relevant paragraph in policy but there is none.  Is the usage of
> /var/lib/ just a reasonable habit which is shared by
> postgresql, mysql and probably others and I could for instance invent
> a directory
> 
> /var/my_super_duper_database
> 
> and keep the data there?  I do not actually intend to do so, but
> shouldn't this be fixed somewhere in the policy.  FHS[1] is not
> giving any explicite advise here and so we can not relay on the
> predefinition there and thus should rather make our own.
What about using /srv/ for such stuff? Wouldn't that fit better?

Cheers,
Chris.


-- 
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/1281554149.3229.32.ca...@fermat.scientia.net

Re: why are there /bin and /usr/bin...

[Christoph Anton Mitterer]

On Tue, 2010-08-10 at 03:15 -0600, Bruce Sass wrote:
> I was curious so...
> $ for f in /bin/* /sbin/*; do if [ "`file $f | grep ELF`" != "" ] ; then 

> /lib/ld-linux.so.2 (0x46bad000)
> libpcre.so.3 => /lib/libpcre.so.3 (0xb7856000)
> 
> Are these bugs just waiting to bite, or frustrate troubleshooting 
> efforts because some program is broken just when it is needed most?
There are even many more (e.g. #589641 - closed with tag
"maintainer-wants-no-fix") which can't be found so automatically... ;)


Cheers,
Chris.


-- 
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/1281554439.3229.36.ca...@fermat.scientia.net

Re: Usage of /var/lib for databases not properly described in policy

[Andreas Tille]

On Wed, Aug 11, 2010 at 09:15:49PM +0200, Christoph Anton Mitterer wrote:
> > 
> > /var/my_super_duper_database
> > 
> > and keep the data there?  I do not actually intend to do so, but
> > shouldn't this be fixed somewhere in the policy.  FHS[1] is not
> > giving any explicite advise here and so we can not relay on the
> > predefinition there and thus should rather make our own.
> What about using /srv/ for such stuff? Wouldn't that fit better?

No, definitely not.  I *want* to use /var/lib/ but I wanted to
give a good reason to do so and was not able to find one immediately.
Now I know to what section of FHS to point to and everything is fine.

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/20100811201659.gb31...@an3as.eu

Bug#592668: ITP: autopack -- Message packing for MPI made easy

[Christophe Prud'homme]

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

--- Please fill out the fields below. ---

Package name: autopack
Version: 1.3.2
Upstream Author: Raymond Loy  
URL: http://www.mcs.anl.gov/research/projects/autopack/
License: Free software
Description:
Autopack is a message-passing library which transparently packs small
 messages into fewer larger ones for more efficient transport by MPI.
 It can be used by any MPI program.  The underlying message size is
 easily adjusted at runtime for best efficiency.  Other features of
 Autopack include:
   o collective commands that proceed asynchronously
   o automatic management of MPI send and receive requests
   o management of message buffer memory
   o determination of the number of anticipated incoming messages from
 a set of arbitrary sends
   o deterministic message delivery from multiple sources to aid in
 program testing or debugging
 Autopack is written in C using MPI and should compile on any
 platform with any implementation of MPI.

-- 
Debian Developer (Scientific applications)
Prof. at Univ. Grenoble in Applied Math.

Re: Raw Idea: one more control field for sponsors

[Toni Mueller]

Hi,

On Wed, 11.08.2010 at 17:48:09 +0300, Eugene V. Lyubimkin  
wrote:
> Toni Mueller wrote:
> > in debian/control, like eg.
> > Bugs-To: some...@debian.org, ...
> This is the info which IMHO belongs to PTS and should stay there.

after rethinking the issue, I agree that it's better to not add a field
to the debian/control file.

Originally, I thought it would simplify things, but I'm no longer
convinced.


-- 
Kind regards,
--Toni++


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

Bug#592689: ITP: turtleart -- a LOGO-like tool for teaching programming

[Luke Faraone]

Package: wnpp
Severity: wishlist
Owner: Matthew Gallagher 

* Package name: turtleart
  Version : 93+git20100803.9bee2c4 
  Upstream Author : Walter Bender 
* URL : http://wiki.sugarlabs.org/go/Activities/Turtle_Art
* License : Expat
  Programming Lang: Python
  Description : a LOGO-like tool for teaching programming

Turtle Art is an activity with a Logo-inspired graphical "turtle" that 
draws colorful art based on snap-together visual programming elements.

Turtle Art is intended to be a stepping stone to the Logo programming
language, but there are many restrictions compared to Logo. However, 
you can export your Turtle Art creations to Berkeley Logo.



-- 
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/20100812031446.16279.84844.report...@stone.home