Re: Developer repositories for Debian

[Raphael Hertzog]

Hi Jörg,

we definitely needs something like this and your suggested set of rules
seems sane.

On Sun, 05 May 2013, Joerg Jaspert wrote:
>  - any member of the uploading keyrings can create a PPAMAIN using a
>defined interface[1].
>
> [1] Most probably it will either be a signed mail or a signed .commands
> style file.

While I won't question the need to support signed mails or commands files,
I would like to argue for the support of a web interface as well. The
sheer number of operations that are possible on such repositories will
make it difficult to remember the precise syntax of the various
operations. A web interface is much more discoverable. Furthermore
it's obvious that we will have web interfaces such as those used
to track transitions and it would be nice if we could unify them at
a single place (think: checking the tracker, then clicking a button to
trigger/request a bin-nmu of foo, another button to import the correct version
of bar, etc).

I'm not asking you to create that web interface but at least to keep in
mind the fact that someone might want to write it and as such to clearly
separate what needs to be handled separately (mainly authentication I
guess).

Cheers,
- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20130506070543.ge25...@x230-buxy.home.ouaza.com

Re: Proposal: a team maintaining packages managing media types (MIME).

[Josselin Mouette]

Hi,

Le lundi 06 mai 2013 à 09:24 +0900, Charles Plessy a écrit : 
> How about taking the opportunity of this new release cycle to start a 
> packaging
> team to organise the work on packages providing media type (MIME) support ?
> 
> The mime-support package (which I maintain) is on Alioth on collab-maint 
> (Git),
> already writable to all DDs (but please ask first).  We could bring
> mime-support, file, desktop-file-validate and shared-mime-info under a common
> umbrella if you are interested.

shared-mime-info and desktop-file-utils are already maintained under the
pkg-freedesktop umbrella.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1367828980.3585.979.camel@pi0307572

Re: Proposal: a team maintaining packages managing media types (MIME).

[Dmitry Smirnov]

Dear Josselin,

On Mon, 6 May 2013 18:29:40 Josselin Mouette wrote:
> shared-mime-info and desktop-file-utils are already maintained under the
> pkg-freedesktop umbrella.

I see no evidence that "desktop-file-utils" is associated with
pkg-freedesktop.  There is no corresponding repository under
"pkg-freedesktop" and Maintainer field contains "Ross Burton
". I've made new (first?) "desktop-file-utils"
package repository in collab-maint. Is that OK with you for now?

Best wishes,
 Dmitry Smirnov.


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

Re: Proposal: a team maintaining packages managing media types (MIME).

[Josselin Mouette]

Le lundi 06 mai 2013 à 20:19 +1000, Dmitry Smirnov a écrit : 
> Dear Josselin,
> 
> On Mon, 6 May 2013 18:29:40 Josselin Mouette wrote:
> > shared-mime-info and desktop-file-utils are already maintained under the
> > pkg-freedesktop umbrella.
> 
> I see no evidence that "desktop-file-utils" is associated with
> pkg-freedesktop.  There is no corresponding repository under
> "pkg-freedesktop" and Maintainer field contains "Ross Burton
> ". I've made new (first?) "desktop-file-utils"
> package repository in collab-maint. Is that OK with you for now?

http://anonscm.debian.org/viewvc/pkg-freedesktop/trunk/desktop-file-utils/

I see the two previous uploads have not been committed to the
repository, which is wrong.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


-- 
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/1367835869.3585.992.camel@pi0307572

Question about multiarch

[Walter Valenti]

Scenario:

a Intel x64 (T5500) with "Wheezy i386" installed.
It's possible use the multiarch support of dpkg
to migrate to "Wheezy amd64" ?

(after installation of linux-image-amd64, libc6-amd64)

Thanks

Walter



--
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/1367838195.92406.yahoomail...@web171405.mail.ir2.yahoo.com

Re: Question about multiarch

[Andrey Rahmatullin]

On Mon, May 06, 2013 at 12:03:15PM +0100, Walter Valenti wrote:
> a Intel x64 (T5500) with "Wheezy i386" installed.
> It's possible use the multiarch support of dpkg
> to migrate to "Wheezy amd64" ?
> 
> (after installation of linux-image-amd64, libc6-amd64)
Migrating a live system between architectures is not officially supported
and may be possible only with some manual actions which are usually very
dangerous.

-- 
WBR, wRAR


--
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/20130506111245.ga6...@belkar.wrar.name

Re: Proposal: a team maintaining packages managing media types (MIME).

[Dmitry Smirnov]

On Mon, 6 May 2013 20:24:29 Josselin Mouette wrote:
> > I see no evidence that "desktop-file-utils" is associated with
> > pkg-freedesktop.  There is no corresponding repository under
> > "pkg-freedesktop" and Maintainer field contains "Ross Burton
> > ". I've made new (first?) "desktop-file-utils"
> > package repository in collab-maint. Is that OK with you for now?
> 
> http://anonscm.debian.org/viewvc/pkg-freedesktop/trunk/desktop-file-utils/
> 
> I see the two previous uploads have not been committed to the
> repository, which is wrong.

I see, thanks. The repository layout is a bit unusual as it combines
several packages together...

And "desktop-file-utils" was last time updated in this repository 3
years ago...

Perhaps it's a good time to separate it to its own repository?
repository that I've made at collab-maint contains all previous
versions imported...

Cheers,
 Dmitry Smirnov.




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

Re: Proposal: a team maintaining packages managing media types (MIME).

[Sune Vuorela]

On 2013-05-06, Dmitry Smirnov  wrote:
> I see, thanks. The repository layout is a bit unusual as it combines
> several packages together...

No it is not. It is very normal with svn.

> Perhaps it's a good time to separate it to its own repository?

I think it is great to have desktop-file-utils and shared-mime-info
staying within pkg-freedesktop. They know how upstream work, and they
also do a great job in debian. 

/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/slrnkofaaq.j8.nos...@sshway.ssh.pusling.com

jessie release goals

[Andreas Beckmann]

Hi,

now might be the right time to start a discussion about release goals
for jessie. Here are some points that come into my mind right now (and
some were already discussed very recently):

* multiarch compatible binNMUs
* discarding maintainer uploaded binary packages [!arch:all]
* discarding maintainer uploaded binary packages [incl. arch:all]
* extending binNMUs to allow rebuilding arch:all packages (so it's no
longer a "binary only" but a sourceful no-change rebuild - the classic
binNMU should stay of course)


Andreas

... looking forward to have PPAs in the future :-)


-- 
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/5187a6f5.2080...@debian.org

Re: jessie release goals

[Christoph Anton Mitterer]

Hey.

I would like to see the following with respect to PHP and all packages
using PHP:
1) We should try to educate users not to use mod_php. From a security
POV it's rather problematic, as it runs in server context. And for
people really needing the performance, FPM should be an equally good
solution.
There are other issues with mod_php, like not being able to use all
MPMs.


2) Because of (1) other packages should no longer assume mod_php is in
place... they should provide support for all the SAPIs (as far as this
is possible).


3) Especially packages should no longer automatically set things up for
mod_php.
IMHO it's (security wise) generally a bad idea to have such stuff
enabled out of the box by just installing a package.
A solution could be, that packages use debconf, and allow the user to
either set up nothing automagically,... or let the user choose between a
SAPI / webserver combination.
This would also allow packages, to provide out of the box support for
privilege separation, which could then in turn be used to do e.g. clean
and secure authentication against local databases (wich are often used
in that context).


4) One might further try to harden the default php.ini much more... and
debian packages using PHP could ship their additions, which then allow
things that are required.

Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: jessie release goals

[Niels Thykier]

On 2013-05-06 14:49, Andreas Beckmann wrote:
> Hi,
> 
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
> 


While the ideas themselves are worthwhile, they do not seem to be
"release goal" material at first glance[1].  (Or possibly I am
misunderstanding the "Affect more than just one set of packages" clause
in [1]).

> * multiarch compatible binNMUs

dpkg (and maybe APT) is probably the only tools needing to be changed.

That said, from a RT PoV, "multiarch compatible binNMUs" would be
appreciated so we don't break m-a with each and every transition.

> * discarding maintainer uploaded binary packages [!arch:all]
> * discarding maintainer uploaded binary packages [incl. arch:all]
> * extending binNMUs to allow rebuilding arch:all packages (so it's no
> longer a "binary only" but a sourceful no-change rebuild - the classic
> binNMU should stay of course)
> 

I am guessing this is (mostly) a dak/buildd.d.o side change or so.

> 
> Andreas
> 
> ... looking forward to have PPAs in the future :-)
> 
> 


~Niels

[1] https://wiki.debian.org/ReleaseGoals

"""
Please note: a release goal should be:

SMART (Specific, measurable, attainable, realistic, timely)
Affect more than just one set of packages (eg: not just a package
transition)
Have an 'advocate', who can track and keep status of progress.
"""



-- 
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/5187af8e.4070...@thykier.net

Re: Proposal: a team maintaining packages managing media types (MIME).

[Dmitry Smirnov]

On Mon, 6 May 2013 23:00:05 Sune Vuorela wrote:
> On 2013-05-06, Dmitry Smirnov  wrote:
> > Perhaps it's a good time to separate it to its own repository?
> 
> I think it is great to have desktop-file-utils and shared-mime-info
> staying within pkg-freedesktop. They know how upstream work, and they
> also do a great job in debian. 
 
I do not suggest to take desktop-file-utils out of pkg-freedesktop but
would like to see desktop-file-utils in its own repository...

Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


-- 
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/201305062329.06281.only...@member.fsf.org

Re: jessie release goals

[Mathieu Parent]

Hello,

2013/5/6 Christoph Anton Mitterer :
> Hey.
>
> I would like to see the following with respect to PHP and all packages
> using PHP:
[...]

Related to PHP, but more on the PEAR side, I would like to see all
PEAR packages migrated to build with pkg-php-tools (the dh way of PEAR
packages).

Migrating PECL packages would also be great (but pieces are missing on
the pkg-php-tools side, I've started to work on this).

Jessie might also be a good release to rename all php5-* packages to
php-*, as the distinction between PEAR and PECL packages is not seen
when declaring dependencies (but this might be too ambitious).

Regards

--
Mathieu Parent


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

Re: jessie release goals

[The Wanderer]

On 05/06/2013 08:49 AM, Andreas Beckmann wrote:


Hi,

now might be the right time to start a discussion about release goals
for jessie. Here are some points that come into my mind right now (and
some were already discussed very recently):

* multiarch compatible binNMUs
* discarding maintainer uploaded binary packages [!arch:all]
* discarding maintainer uploaded binary packages [incl. arch:all]
* extending binNMUs to allow rebuilding arch:all packages (so it's no
longer a "binary only" but a sourceful no-change rebuild - the classic
binNMU should stay of course)


I don't know whether it would be practical, but one thing I would like
to see included as an explicit goal is the completion of multi-arch -dev
support.

There is functionality provided by the old ia32-libs-dev package which
is not apparently possible - short of installing the necessary headers
and so forth by hand, and maybe not even then - with multi-arch library
packages, unless multi-arch -dev packages are also supported. Since they
aren't, this means the transition from ia32-libs to multiarch introduces
a regression.

Since I use some of the functionality which appears to be lost in that
regression, I would hope for fixing that regression to be one of the
goals for the next release.


I understand that the necessary specification for letting this be
possible has not been completed, and that work on that is ongoing. I am
certainly not attempting to bash anyone for the regression; delaying the
release of wheezy until the work could be completed, such as would have
been necessary to avoid the regression without delaying multiarch, would
plainly not have been a reasonable option.

That said, I'd obviously prefer this not to continue to be delayed any
longer than necessary, and including it on the list of release goals
seems like an appropriate way of raising its profile (and/or its
priority) in pursuit of that.

--
   The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
  - LiveJournal user antonia_tiger


--
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/5187b1ee.1030...@fastmail.fm

Re: jessie release goals

[Christoph Anton Mitterer]

Two more things I remember:

1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
default on the network (unless loopback only) shouldn't be started per
default, after being installed.
The usually come only with a default config which may not be hardened
enough for the local system, and that short time may already be enough
for an attacker to attack.

Or default config may be simply pointless for the environment, and
starting the service per default is just annoying.
It shouldn't be to hard for an admin to configure the appropriate
runlevels when he thinks he's finished with configuration.

One could handle this different for local only services/daemons. E.g.
when I install haveged, I usually want it... and there shouldn't be a
security impact when it immediately runs after being installed.


2) No more packages that bypass the package management system and secure
apt:
a) There are still several (typically non-free) packages which download
stuff from the web, install or at least un-tar it somwhere without
checking any integrity information that would be hardcoded in that
package.

b) Another problem are IMHO plugins like Firefox extensions, kinda
bypassing APT. I think at least those that are installed via a package,
shouldn't be upgradable/overwritable anymore with online versions.


Cheers,
Chris.



smime.p7s
Description: S/MIME cryptographic signature

Re: jessie release goals

[Andrey Rahmatullin]

On Mon, May 06, 2013 at 04:08:07PM +0200, Christoph Anton Mitterer wrote:
> 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> default on the network (unless loopback only) shouldn't be started per
> default, after being installed.
> The usually come only with a default config which may not be hardened
> enough for the local system, and that short time may already be enough
> for an attacker to attack.
> 
> Or default config may be simply pointless for the environment, and
> starting the service per default is just annoying.
> It shouldn't be to hard for an admin to configure the appropriate
> runlevels when he thinks he's finished with configuration.
> 
> One could handle this different for local only services/daemons. E.g.
> when I install haveged, I usually want it... and there shouldn't be a
> security impact when it immediately runs after being installed.
There is also a related thing that was discussed in the past: stop
disabling services via /etc/default.


-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: jessie release goals

[Игорь Пашев]

2013/5/6 Andrey Rahmatullin :
> There is also a related thing that was discussed in the past: stop
> disabling services via /etc/default.


Modern service management systems might be better choice.
E. g. systemd or SMF :-P


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

Re: git as a source package format?

[Goswin von Brederlow]

On Sat, May 04, 2013 at 12:11:23PM +0800, Paul Wise wrote:
> On Sat, May 4, 2013 at 10:41 AM, Charles Plessy wrote:
> 
> > The fact is that Debian does not make much effort to ensure that we do not
> > distribute unredistributable files in our mirrors and installation media, 
> > once
> > a package has passed its first copyright and license review.
> 
> That is simply not true, every developer is responsible for checking
> this before every upload, to NEW or directly to unstable. I don't know
> about you or the rest of Debian but I certainly take this
> responsibility seriously and perform this very necessary action.

And even if it were true then how should that first copyright and
license review work with git format? Do you expect ftp-master to audit
every single commit?

After the initial upload subsequent uploads are easier to check since
only the "diff" to the previous one needs to be considered. Still with
git format that could be a lot of commits.

MfG
Goswin

PS: For me a debian source package is the compact snapshot of the VCS
repository that was used to build a binary. If I want history I
checkout the VCS.


-- 
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/20130506144644.GA21910@frosties

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Goswin von Brederlow]

On Sat, May 04, 2013 at 09:33:14PM +0200, Helmut Grohne wrote:
> On Fri, May 03, 2013 at 04:53:59PM +0800, Thomas Goirand wrote:
> > I think there's a consensus, the problem is who's going
> > to do the work for automating dropping of binaries and
> > rebuild.
> 
> Not implying that I am the one doing this work, I would like to learn
> more about what needs to be touched to achieve aspects of the following
> features: (Again not implying that they are all desired.)
>  * Throwing away binaries and rebuilding everything.
>  * Permitting source-only uploads.
>  * arch:all binNMUs.
> 
> Pointers to relevant documentation appreciated. Specific questions:
>  * Which tools/infrastructure needs changes?
>  * What are the general changes needed?
>  * How can those changes be split in independent pieces and applied
>without interfering badly?
> 
> Helmut

Maybe as an intermediate and imediate step we could switch to
uploading only arch:all debs for mixed packages. That is already
supported by DAK and the buildds and would drop a lot of locally build
debs.

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/20130506145729.GB21910@frosties

Re: Proposal: a team maintaining packages managing media types (MIME).

[Charles Plessy]

Le Mon, May 06, 2013 at 12:24:29PM +0200, Josselin Mouette a écrit :
> Le lundi 06 mai 2013 à 20:19 +1000, Dmitry Smirnov a écrit : 
> > 
> > On Mon, 6 May 2013 18:29:40 Josselin Mouette wrote:
> > > shared-mime-info and desktop-file-utils are already maintained under the
> > > pkg-freedesktop umbrella.
> > 
> > I see no evidence that "desktop-file-utils" is associated with
> > pkg-freedesktop.  There is no corresponding repository under
> > "pkg-freedesktop" and Maintainer field contains "Ross Burton
> > ". I've made new (first?) "desktop-file-utils"
> > package repository in collab-maint. Is that OK with you for now?
> 
> http://anonscm.debian.org/viewvc/pkg-freedesktop/trunk/desktop-file-utils/

Hi Josselin,

with no mention of a team or of the VCSes in debian/control, is is impossible
to guess that the packages are team-maintained...  Please consider making it
more proeminent.

For the mime-support package, I am tempted to generate /etc/mime.types from the
freedesktop.org.xml in shared-mime-info, if it is maintained in close
adequation with the IANA's definitions.  If I would like to contact the
pkg-freedesktop team in the future, what is its address ?  The Alioth project
has no mailing list...  Or would it be better to discuss this upstream ?

Cheers,

-- 
Charles


-- 
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/20130506152227.ga22...@falafel.plessy.net

Re: jessie release goals

[Thomas Goirand]

On 05/06/2013 09:15 PM, Christoph Anton Mitterer wrote:
> Hey.
>
> I would like to see the following with respect to PHP and all packages
> using PHP:
> 1) We should try to educate users not to use mod_php. From a security
> POV it's rather problematic, as it runs in server context. And for
> people really needing the performance, FPM should be an equally good
> solution.
There's not only FPM as a solution. I maintain SBOX to do chroot, and
I use it together with aufs to maintain chroot templates. I also currently
maintain my own version of Apache with a patch to backport the
AllowOverrideList feature of Apache 2.4 in the (old)stable Debian, so
that a hacker can't write in a .htaccess to hook the Options / AddHandler
thing and by-pass my cgi-wrapper.

So yeah, maintainers shouldn't assume mod_php. But please do not
assume FPM either!

By the way, using FPM + SBOX should be a quite nice thing, which I need
to investigate.

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/5187cd5f.2010...@debian.org

Re: Bug:#700917: desktop-file-utils: call for (co-)maintainership [ITA]

[Dmitry Smirnov]

Dear pkg-freedesktop team,

Thank you for letting me join "pkg-freedesktop" team.

I migrated old "desktop-file-utils" repository to new location:

http://anonscm.debian.org/gitweb/?p=pkg-freedesktop/desktop-file-utils.git

where I imported all history including missing versions and also added
tags. My changes are committed as well. I intend to upload updated
package somewhat next week. Please use the opportunity to add your
changes as well if you have something to add. Thanks.

Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

Platitude: an idea (a) that is admitted to be true by everyone, and (b)
that is not true.
-- H. L. Mencken



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

Re: jessie release goals

[Marco d'Itri]

On May 06, Christoph Anton Mitterer  wrote:

> 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> default on the network (unless loopback only) shouldn't be started per
> default, after being installed.
This has been discussed over and over, I think with a clear consensus: 
installed software should work. If you do not want a service to act like 
a service then do not install it.

> The usually come only with a default config which may not be hardened
> enough for the local system, and that short time may already be enough
> for an attacker to attack.
[citation needed]

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: jessie release goals

[Thomas Goirand]

On 05/06/2013 09:29 PM, Mathieu Parent wrote:
> Related to PHP, but more on the PEAR side, I would like to see all
> PEAR packages migrated to build with pkg-php-tools (the dh way of PEAR
> packages).

Yes ! I do 100% agree with the above. This could be a release goal, IMO.

> Migrating PECL packages would also be great (but pieces are missing on
> the pkg-php-tools side, I've started to work on this).

Oh, cool!!! :)
Thanks!

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/5187cdda.5020...@debian.org

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Thomas Goirand]

On 05/05/2013 03:33 AM, Helmut Grohne wrote:
> what needs to be touched to achieve aspects of the following
> features: (Again not implying that they are all desired.)
>  * Permitting source-only uploads.
While there is a consensus about dropping binaries, there is
none about permitting source-only uploads (and I'm not in
the favor of it myself, not because I don't trust others, but
because I think it should be possible to add some more QA
tests comparing what the uploaded built and what the buildd
produces, and I don't want to remove that possibility).

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/5187cf02.6030...@debian.org

Bug#706974: ITP: assword -- Simple and secure password management and retrieval system.

[Jameson Graef Rollins]

Package: wnpp
Severity: wishlist
Owner: Jameson Graef Rollins 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: assword
  Version : 0.7
  Upstream Author : Jameson Graef Rollins 
* URL : http://finestructure.net/assword/
* License : GPL
  Programming Lang: Python
  Description : Simple and secure password management and retrieval system.

Passwords and context strings are stored in a single OpenPGP encrypted
and signed file.  The contexts can be searched.  Passwords are
securely retrieved without displaying on the screen.  Multiple
retrieval methods are available, including inserting retrieved
password into the X clipboard, or typing them directly into an X
window.

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

iQIcBAEBCAAGBQJRh81mAAoJEO00zqvie6q8o7oQALsCWM++BMC/6K203TfM/mN+
C7QbnfnRg74TzISdQs/cBlf3KEW3rN6rg72LITPTXOvxDh3fgk/7mHSJRbVP5qcL
bMNucb38uhCN5jBG+1O9C5v952jwIiqd0EX2g7AOMLVQRr+0R+jPTSCg8VvfX2gY
xdE+VOeV1YO1V3w4DeQGFphCshXlDZBdT63ydFhxPXGfG4G6UzkrD3HTIAbNUjrn
4KZF6Us2YpMcmEk8ROlY/LNM8ZXZYgvx7M08N865ifVH9mXEmTcYe2v/2W8D6cPm
LSpcL2b8mybF804r8qvXutacXVtO5+VsXd9ZtnfvGAv9Z6dFdw/v8Ai33hVs0Ppc
CZBoNPebTiyMzATWhrdcEmiKHBSufTVVNIJ06Q2kOO05tbwk8D589walrl+nWJaw
l93BW89i/TKBeHgJaTYhJddixPtD5xgox5frHLBs9Aju8r+05+cqSDeq3KOxCLj8
j8GwylxXhCewFkDV7gXJJZcdNaewTuleE/f2ztB3aykI10e/nev8JMe7XE8AZgXg
BlmYlha880bpYP1VrnBJB/uq4ZDM0PQeBrihXTrJPzEKzwlq+3WMR2QBYHeHl6Up
4hyZZTo+ME+9beqTrEVm4dZmAjJRCaR7fjjqm0JDTCr/Dss0sYNK24pMOf8gVLSL
St50QLuAsof88KIGDTRq
=rj9J
-END PGP SIGNATURE-


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

Bug#706975: ITP: xapers -- Personal journal article management and indexing system.

[Jameson Graef Rollins]

Package: wnpp
Severity: wishlist
Owner: Jameson Graef Rollins 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: xapers
  Version : 0.5.1
  Upstream Author : Jameson Graef Rollins 
* URL : http://finestructure.net/xapers/
* License : GPL
  Programming Lang: Python
  Description : Personal journal article management and indexing system.

Xapers is a personal document indexing system, geared towards
academic journal articles.  Think of it as your own personal document
search engine, or a local cache of online libraries.  It provides
fast search of document text and bibliographic data and simple
document and bibtex retrieval.
.
Document files (in PDF format) and source identifiers (e.g. DOI) are
parsed and indexed into a Xapian search engine.  Document text is
extracted from the PDF and fully indexed.  Bibliographic information
downloaded from online libraries is indexed as prefixed search terms.
Existing bibtex databases can be easily imported as well, including
import of pdf files specified in Jabref/Mendeley format.  Documents
can be arbitrarily tagged.  Original document files are easily
retrievable from a simple curses search UI.  The command line
interface allows for exporting bibtex from arbitrary searches,
allowing seemless integration into LaTeX work flows.

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

iQIcBAEBCAAGBQJRh83sAAoJEO00zqvie6q8sIIP/3altO7iOrL5zndnnLaRE68K
bJv7yTTHe1goSNab5CFZRSCsqavGOeyNkkNcLHoz1AvuQ2fPpkONe9QByk+vWBqS
/uar8LbMXcAJBufkX9PtAuPm1cXDNuY0b9lAOY8YBkHQHyKK4cO/S5CxT8mt2/5O
iq+StPxv0S+gglp0Uqts+Y0/9cDGrmJ/ARi5IH2K86sSuDkkJ9Nu07uQ59qbr3mc
ndsWwJlLGpLo1VlnNpshISZ212DAU2MM6QcrQS3uhQmMw9AMHPOrfEAT6oI22eMM
4mgX/FwQE1xQih7Y8l6jhbA6OWjQgZLqbksPsK+7vrvcaLx33A9fYh2xNu6i66Yk
zIk3fGY88pSqoO6nO+2Y3ghlfh+HhqRrzByVpYNBnXw7Vo6pzXgixCM22mlOo0k2
g1tZUZkLO8KrEGAhhykrig+5eE1PuvZ48gHMPs+e8Fo28HrJgZ/0ngtQOyaWbt/G
8H2b+NxjlXT19H3c6l7Ja1MnLqNMemMBtpGh1byL+CRDrjofrawgAozsDJdKgWa+
FwFTHORwuvGIcxn8KLoGvbncl706qCOuUiLgJnVMyXGgj5VuSbPmHLM0tfTyJSPy
dPm3lwFp7qMFaYk+vn/ZscBW++vaU+CT1pEaHe2sieYoHoytrX4i9UpRSrw5ivO9
ma39QDPqmragD5u7diLl
=1DCE
-END PGP SIGNATURE-


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

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Andrey Rahmatullin]

On Mon, May 06, 2013 at 11:40:50PM +0800, Thomas Goirand wrote:
> > what needs to be touched to achieve aspects of the following
> > features: (Again not implying that they are all desired.)
> >  * Permitting source-only uploads.
> While there is a consensus about dropping binaries, there is
> none about permitting source-only uploads (and I'm not in
> the favor of it myself, not because I don't trust others, but
> because I think it should be possible to add some more QA
> tests comparing what the uploaded built and what the buildd
> produces, and I don't want to remove that possibility).
And the usual argument for source-only uploads is "I'm not going to upload
this 500Mb package via my slow link just to prove I've built it".

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Thomas Goirand]

On 05/04/2013 05:10 PM, Wookey wrote:
> This is a result of maintainer's workflows never
> doing this, I presume.
Yeah! Probably git-buidpackage getting more adoption
has something to do with it too.

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/5187d2be.5040...@debian.org

Re: jessie release goals

[Jakub Wilk]

* Niels Thykier , 2013-05-06, 15:26:
now might be the right time to start a discussion about release goals 
for jessie. Here are some points that come into my mind right now (and 
some were already discussed very recently):
While the ideas themselves are worthwhile, they do not seem to be 
"release goal" material at first glance[1].


Meh. RGs are overrated anyway. RT's blessing is neither sufficient nor 
necessary for doing awesome stuff.


--
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/20130506161122.ga6...@jwilk.net

Bug#706985: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Daniel Walrond]

Package: wnpp
Severity: wishlist
Owner: Daniel Walrond 


* Package name: opensmtpd
  Version : 5.3.1p1
  Upstream Author : OpenBSD
* URL : http://www.opensmtpd.org/
* License : ISC, BSD
  Programming Lang: C
  Description : Simple Mail Transfer Protocol daemon

OpenSMTPD is a FREE implementation of the server-side SMTP protocol as
defined by RFC 5321, with some additional standard extensions. It allows
ordinary machines to exchange e-mails with other systems speaking the
SMTP protocol.


-- 
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/20130506161017.28566.62066.report...@brekka.sumodave.com

Re: Bug#706985: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Lars Wirzenius]

On Mon, May 06, 2013 at 05:10:17PM +0100, Daniel Walrond wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Walrond 
> 
> 
> * Package name: opensmtpd
>   Version : 5.3.1p1
>   Upstream Author : OpenBSD
> * URL : http://www.opensmtpd.org/
> * License : ISC, BSD
>   Programming Lang: C
>   Description : Simple Mail Transfer Protocol daemon
> 
> OpenSMTPD is a FREE implementation of the server-side SMTP protocol as
> defined by RFC 5321, with some additional standard extensions. It allows
> ordinary machines to exchange e-mails with other systems speaking the
> SMTP protocol.

Is this better than exim4 or postfix, or one of the other SMTP servers
we already have in Debian?

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for 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/20130506164234.ge2...@havelock.liw.fi

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Adam Borowski]

On Mon, May 06, 2013 at 09:49:33PM +0600, Andrey Rahmatullin wrote:
> On Mon, May 06, 2013 at 11:40:50PM +0800, Thomas Goirand wrote:
> > > what needs to be touched to achieve aspects of the following
> > > features: (Again not implying that they are all desired.)
> > >  * Permitting source-only uploads.
> > While there is a consensus about dropping binaries, there is
> > none about permitting source-only uploads (and I'm not in
> > the favor of it myself, not because I don't trust others, but
> > because I think it should be possible to add some more QA
> > tests comparing what the uploaded built and what the buildd
> > produces, and I don't want to remove that possibility).
> And the usual argument for source-only uploads is "I'm not going to upload
> this 500Mb package via my slow link just to prove I've built it".

Stripping them on the client side and providing a list of file names, sizes
and maybe md5s would work almost as well.

-- 
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ


-- 
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/20130506164554.ga23...@angband.pl

Re: jessie release goals

[Thomas Goirand]

On 05/06/2013 10:08 PM, Christoph Anton Mitterer wrote:
> The usually come only with a default config which may not be hardened
> enough for the local system, and that short time may already be enough
> for an attacker to attack.
If the default config isn't hardened enough, fix the default config.
Adding a supplementary step to start the service doesn't fix the
problem anyway.

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/5187dfb3.6000...@debian.org

Re: jessie release goals

[Holger Levsen]

severity 601455 normal
thanks

Hi,

On Montag, 6. Mai 2013, Andrey Rahmatullin wrote:
> There is also a related thing that was discussed in the past: stop
> disabling services via /etc/default.

#601455 "can't stop daemon using /etc/init.d/foo stop when disabled via 
/etc/default/foo" is related to this, though msg#19 gives a good example when 
this is useful.


cheers,
Holger 



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

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Holger Levsen]

Hi,

On Montag, 6. Mai 2013, Thomas Goirand wrote:
> While there is a consensus about dropping binaries, there is
> none about permitting source-only uploads (and I'm not in
> the favor of it myself, not because I don't trust others, but
> because I think it should be possible to add some more QA
> tests comparing what the uploaded built and what the buildd
> produces, and I don't want to remove that possibility).

there is nothing blocking you from doing this if all you can upload are 
sources. Nothing.


cheers,
Holger




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

Re: Developer repositories for Debian

[Holger Levsen]

Hi,

On Montag, 6. Mai 2013, Raphael Hertzog wrote:
> While I won't question the need to support signed mails or commands files,
> I would like to argue for the support of a web interface as well.

how about a web interface which creates such mails/commands, which then only 
need to be copied into the MUA, signed there and send?!

That way there would be *no* attack vector from this webapp whatsoever.


cheers,
Holger



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

Re: Bug:#700917: desktop-file-utils: call for (co-)maintainership [ITA]

[Jakub Wilk]

* Dmitry Smirnov , 2013-05-05, 12:30:
I'm quite concerned that `desktop-file-validate` utility (provided by 
"desktop-file-utils" package) is checking .desktop files against 
outdated specification. On some occasions such "validation" recommend 
changes conflicting with the current specification (see more in 
#690279).


Wrong bug number?

--
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/20130506170202.ga8...@jwilk.net

Will we see MariaDB in Jessie?

[Thomas Goirand]

I wonder what the plans of the MySQL maintainers are concerning MySQL vs
MariaDB. Famously, Fedora made the switch. What will happen in Debian?
What kind of transition would this mean? Would it be a drop-in
replacement like Monty is pretending, or would it be harder?

Cheers,

Thomas Goirand (zigo)


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

Processed: Re: jessie release goals

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 601455 normal
Bug #601455 [general] can't stop daemon using /etc/init.d/foo stop when 
disabled via /etc/default/foo
Bug #661496 [general] multiple, annoyingly different ways to disable an init 
script
Severity set to 'normal' from 'minor'
Severity set to 'normal' from 'minor'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
601455: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601455
661496: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661496
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


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

Re: Bug#706985: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Daniel Walrond]

On Mon, May 06, 2013 at 05:42:35PM +0100, Lars Wirzenius wrote:
> On Mon, May 06, 2013 at 05:10:17PM +0100, Daniel Walrond wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: Daniel Walrond 
> > 
> > 
> > * Package name: opensmtpd
> >   Version : 5.3.1p1
> >   Upstream Author : OpenBSD
> > * URL : http://www.opensmtpd.org/
> > * License : ISC, BSD
> >   Programming Lang: C
> >   Description : Simple Mail Transfer Protocol daemon
> > 
> > OpenSMTPD is a FREE implementation of the server-side SMTP protocol
> > as defined by RFC 5321, with some additional standard extensions. It
> > allows ordinary machines to exchange e-mails with other systems
> > speaking the SMTP protocol.
> 
> Is this better than exim4 or postfix, or one of the other SMTP servers
> we already have in Debian?

Depends how you define better. I don't see it as a replacement to exim4
or postfix, since it is not as powerful as them. It does have a much
simpler configuration syntax. Personally I prefer to use it over ssmtp,
but it's more capable than that package.


Dan


-- 
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/20130506170637.gi29...@sumdoave.com

Re: Bug#706985: ITP: opensmtpd -- Simple Mail Transfer Protocol daemon

[Carlos Alberto Lopez Perez]

On 06/05/13 18:42, Lars Wirzenius wrote:
> On Mon, May 06, 2013 at 05:10:17PM +0100, Daniel Walrond wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Daniel Walrond 
>>
>>
>> * Package name: opensmtpd
>>   Version : 5.3.1p1
>>   Upstream Author : OpenBSD
>> * URL : http://www.opensmtpd.org/
>> * License : ISC, BSD
>>   Programming Lang: C
>>   Description : Simple Mail Transfer Protocol daemon
>>
>> OpenSMTPD is a FREE implementation of the server-side SMTP protocol as
>> defined by RFC 5321, with some additional standard extensions. It allows
>> ordinary machines to exchange e-mails with other systems speaking the
>> SMTP protocol.
> 
> Is this better than exim4 or postfix, or one of the other SMTP servers
> we already have in Debian?
> 

It has a special focus on security:

https://en.wikipedia.org/wiki/OpenSMTPD#Goals
http://www.opensmtpd.org/goals.html

I'm eager to try it.

Thanks for packaging it!



signature.asc
Description: OpenPGP digital signature

Bug#706987: general: Gnome freezes after some minutes of starting session

[Javier Juan Albarracín]

Package: general
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Gnome desktop freezes after some minutes of starting the session. The solution
is to change to another tty and restart the gdm3 server. I've noticed that it
only happens at the begining of the session but once the gdm3 is restarted it
doesn't reproduce. Also, it occurs in the stable version (wheezy) and the
testing one. I also checked it occur with the default debian drivers and the
nvidia drivers. My machine is an Intel Core i5 2500 8GB RAM Nvidia GTX 550 Ti.

Hope it helps



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

Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_ES.utf8, LC_CTYPE=es_ES.utf8 (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/20130506171015.4601.47373.reportbug@raizti

Re: Developer repositories for Debian

[Paul Tagliamonte]

On Mon, May 06, 2013 at 09:05:43AM +0200, Raphael Hertzog wrote:
> 
> While I won't question the need to support signed mails or commands files,
> I would like to argue for the support of a web interface as well. The
> sheer number of operations that are possible on such repositories will
> make it difficult to remember the precise syntax of the various
> operations. A web interface is much more discoverable. Furthermore

Hi there, Raphaël, pleasure to speak with you,

So, anyone creating such PPAs will understand how to use such tools as
dput or dcut. Since dcut actually stands for debian command upload tool
(and not some sort of "cutting" from the queue tool), we've added
support for DM permissions in dcut from dput-ng.

Stuff like

  $ dcut dm --uid "Paul Tagliamonte" --allow "glibc"

Isn't so hard to use! (for those who are wondering, it looks up the name
in the maintainer keyring and asks you to confirm the fingerprint )

I plan to add support for PPAs as well.

Since DDs/DMs (unclear as to who can create these) know how to use such
tools, I think it'll be much more secure if we require a GPG signature,
like everywhere else :)

Fondly,
  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: Will we see MariaDB in Jessie?

[Patrick Matthäi]

Am 06.05.2013 19:02, schrieb Thomas Goirand:
> I wonder what the plans of the MySQL maintainers are concerning MySQL vs
> MariaDB. Famously, Fedora made the switch. What will happen in Debian?
> What kind of transition would this mean? Would it be a drop-in
> replacement like Monty is pretending, or would it be harder?

An ITP exists: #565308

But why should it _replace_ MySQL, why not providing it as an
alternative MySQL'ish server?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Re: Will we see MariaDB in Jessie?

[Julien Cristau]

On Mon, May  6, 2013 at 19:17:47 +0200, Patrick Matthäi wrote:

> But why should it _replace_ MySQL, why not providing it as an
> alternative MySQL'ish server?
> 
Because Oracle.

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Will we see MariaDB in Jessie?

[Patrick Matthäi]

Am 06.05.2013 19:33, schrieb Julien Cristau:
> On Mon, May  6, 2013 at 19:17:47 +0200, Patrick Matthäi wrote:
> 
>> But why should it _replace_ MySQL, why not providing it as an
>> alternative MySQL'ish server?
>>
> Because Oracle.

That alone does not count, since it is still OSS.

As long as _MySQL_ maintainers are able (and want) to continue MySQL (or
some other person) there is no reason to not keep it in Debian.

I also can not get used to the thought that we only provide one
alternative like some other more or less popular distributions, where
you need e.g. a HTTP daemon and then you just can install Apache from
their repositories.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Re: Will we see MariaDB in Jessie?

[Paul Tagliamonte]

On Mon, May 06, 2013 at 07:39:50PM +0200, Patrick Matthäi wrote:
> 
> As long as _MySQL_ maintainers are able (and want) to continue MySQL (or

It's my understanding a lot of them jumped ship.

Meh. +1 to kill MySQL for MariaDB. It's got a much better future. I see
it more like a libc changeover. Who cares, it's got the same interface.
We only have things to gain (better upstream, upstream commited to real
f/oss, new features, etc.)

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

Re: Will we see MariaDB in Jessie?

[Clint Byrum]

On 2013-05-06 10:02, Thomas Goirand wrote:
I wonder what the plans of the MySQL maintainers are concerning MySQL 
vs

MariaDB. Famously, Fedora made the switch. What will happen in Debian?
What kind of transition would this mean? Would it be a drop-in
replacement like Monty is pretending, or would it be harder?



Funny you should ask, we are planning to discuss that very topic this 
Thursday at 2000 UTC via Google Hangout.


I see no reason to "switch". We need to make sure that MariaDB 
packaging plays nice with MySQL packaging, and then users can decide. If 
we can have common elements between the packaging, that will certainly 
make our lives easier. As others have already stated, MariaDB packages 
are prepared and we'll be discussing how to get them well integrated 
into Jessie.


I'd invite anybody interested in talking about the subject to join 
#debian-mysql of OFTC and join the pkg-mysql-maint mailing list. We 
would also welcome any time people can bring to the problem, as we all 
seem to be pretty limited, so please do join the pkg-mysql team on 
Alioth if you want to assist with MySQL or MariaDB.


In addition to MariaDB, we most definitely need to ship MySQL 5.6. I'd 
also like to get MySQL back in sync with Ubuntu to reduce waste between 
the two distros.



--
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/ad49036e53f552c9f4ae4f42261bc...@secure.spamaps.org

Re: Will we see MariaDB in Jessie?

[Carlos Alberto Lopez Perez]

On 06/05/13 19:02, Thomas Goirand wrote:
>  Famously, Fedora made the switch

Seems that also OpenSUSE and Arch (among others) did the switch

https://kb.askmonty.org/en/distributions-which-include-mariadb/



signature.asc
Description: OpenPGP digital signature

Re: Will we see MariaDB in Jessie?

[Bjoern Meier]

hi,


Just my two 2 cent: I would like to have an virtual package
"Database", to resolve some deps. So there hasn't be a question of
what database someone have to use.
Okay, the mainproblem here is not all packages have interface for
every database, but it could solve these questions

Greetings,
Björn


--
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/CAGMPS54koWSWc0iVtcprY=PSGgPBCNdt=3v02idbfq+uswd...@mail.gmail.com

Re: [debian-mysql] Will we see MariaDB in Jessie?

[Steven Ayre]

On 6 May 2013 18:54, Paul Tagliamonte  wrote:
> Meh. +1 to kill MySQL for MariaDB. It's got a much better future. I see
> it more like a libc changeover. Who cares, it's got the same interface.
> We only have things to gain (better upstream, upstream commited to real
> f/oss, new features, etc.)

Personally I think the users should have the flexibility to choose.

Having a policy on how such packages can coexist could then allow
other options to also be added cleanly (MySQL Cluster, Percona, Galera
etc).

That's not to say the recommended one can't switch to MariaDB, if the
community decides that's the way to go.


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

Re: [debian-mysql] Will we see MariaDB in Jessie?

[Otto Kekäläinen]

Hello,

2013/5/6 Thomas Goirand :
> I wonder what the plans of the MySQL maintainers are concerning MySQL vs
> MariaDB. Famously, Fedora made the switch. What will happen in Debian?
> What kind of transition would this mean? Would it be a drop-in
> replacement like Monty is pretending, or would it be harder?

Others already replied, but let me make it clear that we are not going
to make any "switch". We are merely adding MariaDB to Debian so that
users can choose to either apt-get install mariadb or apt-get install
mysql.

Both will install smoothly. They both will have conflict-rules, so you
cannot install and run them at the same time, but users will be able
to easily switch between them, at least for now as they are still
binary/configuration/database file format compatible.

It is the up to the users to choose which flavor they like the most.
Although personally I believe most Debian users will prefer MariaDB
over the Oracle version.


-- 
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/CAHj_TLAgj8gae4FP1atrvdVTssY+CHZv782nD=kamydv0uy...@mail.gmail.com

Re: [debian-mysql] Will we see MariaDB in Jessie?

[Andrey Rahmatullin]

On Mon, May 06, 2013 at 07:18:35PM +0100, Steven Ayre wrote:
> On 6 May 2013 18:54, Paul Tagliamonte  wrote:
> > Meh. +1 to kill MySQL for MariaDB. It's got a much better future. I see
> > it more like a libc changeover. Who cares, it's got the same interface.
> > We only have things to gain (better upstream, upstream commited to real
> > f/oss, new features, etc.)
> 
> Personally I think the users should have the flexibility to choose.
> 
> Having a policy on how such packages can coexist could then allow
> other options to also be added cleanly (MySQL Cluster, Percona, Galera
> etc).
http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: [debian-mysql] Will we see MariaDB in Jessie?

[Otto Kekäläinen]

2013/5/6 Steven Ayre :
> Having a policy on how such packages can coexist could then allow
> other options to also be added cleanly (MySQL Cluster, Percona, Galera
> etc).

I've done my best to package MariaDB following best practices on
Debian control files and conflict/replace rules. So I am confident to
say we actually already have a way how to get MySQL flavors to
coexist. What we seem to lack is _resources_. I guess we could package
all of Percona, Galera etc is we had 15 team members to take care of
all testing, security patching etc.

Would you like to join?

Volunteer by attending our next online meeting!

Next online meeting is Thu 2013-05-09 at 20:00 GMT. Anybody can
attend, just join the Google Hangout at
https://plus.google.com/hangouts/_/calendar/b3R0b0BzZXJhdm8uZmk.29m1jpsppitqqvv76s609dbuf8
(fallback to #debian-mysql if Hangout does not work for somebody).


-- 
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/CAHj_TLD2h7c_qrcOn7UMaVyRNT1Vo=y=rok+ersek2wj3tq...@mail.gmail.com

Re: Will we see MariaDB in Jessie?

[Michael Banck]

On Mon, May 06, 2013 at 01:54:41PM -0400, Paul Tagliamonte wrote:
> Meh. +1 to kill MySQL for MariaDB. It's got a much better future. I see
> it more like a libc changeover. Who cares, it's got the same interface.
> We only have things to gain (better upstream, upstream commited to real
> f/oss, new features, etc.)

AIUI, recent MySQL releases (and the latest beta release) have seen tons
of new[1] and quite advanced features which I am not sure are being
merged into MariaDB.  So the codebases have been quickly diverging, very
much unlike glibc vs. eglibc, the latter of which being basically a
friendly patch-set on top of it.

Sure, the security advisories are awful and Oracle is generally bad, but
from a technical point of view, I am not sure dropping MySQL right now
is that best approach, provided some fellow DDs would like to continue
maintaining it.  Having both MySQL and MariaDB in the archive at least
until freeze would make it easier later on to evaluate what we really
want to ship with jessie.


Michael

[1] My favourite being: "Previously, Control+C in mysql interrupted the
current statement if there was one, or exited mysql if not. Now
Control+C interrupts the current statement if there was one, or cancels
any partial input line otherwise, but does not exit."


-- 
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/20130506183807.ga31...@nighthawk.chemicalconnection.dyndns.org

Re: jessie release goals

[Jakub Wilk]

* Christoph Anton Mitterer , 2013-05-06, 16:08:
2) No more packages that bypass the package management system and 
secure apt:
a) There are still several (typically non-free) packages which download 
stuff from the web, install or at least un-tar it somwhere without 
checking any integrity information that would be hardcoded in that 
package.


Do you have any concrete examples (besides flashplugin-nonfree, which is 
indeed abominable)?


b) Another problem are IMHO plugins like Firefox extensions, kinda 
bypassing APT. I think at least those that are installed via a package, 
shouldn't be upgradable/overwritable anymore with online versions.


What exactly do you mean? The only way I can upgrade my Iceweasel 
add-ons is via apt/dpkg.


--
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/20130506184725.ga3...@jwilk.net

Re: [debian-mysql] Will we see MariaDB in Jessie?

[Clint Byrum]

On 2013-05-06 10:54, Paul Tagliamonte wrote:

On Mon, May 06, 2013 at 07:39:50PM +0200, Patrick Matthäi wrote:


As long as _MySQL_ maintainers are able (and want) to continue MySQL 
(or


It's my understanding a lot of them jumped ship.



At the time Oracle purchased Sun, there was really only one active 
MySQL maintainer, Norbert Tretkowski. He got busy and was unable to keep 
up. While I was employed by Canonical and charged with MySQL maintenance 
for Ubuntu, it became clear to me that Debian needed help, so I took up 
the charge and started working on updating to MySQL 5.5. Around the same 
time Nicholas Bamber also stepped up and did a ton of amazing work to 
get things in order and clean them up for the switch to MySQL 5.5. Since 
leaving Canonical I have kept up what little maintenance I can with what 
little free time I have for Debian.


So, the jumping ship has little to do with Oracle. MySQL maintenance in 
Debian has long been in need of help.



Meh. +1 to kill MySQL for MariaDB. It's got a much better future. I 
see
it more like a libc changeover. Who cares, it's got the same 
interface.
We only have things to gain (better upstream, upstream commited to 
real

f/oss, new features, etc.)



Otto has stepped up and done most of the hard work of getting MariaDB 
in a state where it can at least be in the archive along side MySQL. I 
have been trying to keep up with Oracle's insidious non-disclosure 
policies (basically shipping every minor release as a security release), 
but it is getting harder and harder to justify the effort and thus far 
nobody else has stepped up to help.


Once MariaDB is in Debian, I may consider stopping my maintenance of 
MySQL. For now though, it is important that we keep it healthy for the 
current users. We should also carefully consider what MySQL users would 
be faced with if we ever "dropped" MySQL.



--
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/4f0874ca61d7fe7ff3badcad69793...@secure.spamaps.org

Re: [debian-mysql] Will we see MariaDB in Jessie?

[Thomas Goirand]

On 05/07/2013 03:05 AM, Clint Byrum wrote:
> We should also carefully consider what MySQL users would be faced with
> if we ever "dropped" MySQL. 
This was part of my original question.

How much difference do we have for our users?
Can MariaDB be a drop-in replacement as advertized?
I'd be happy to have your point of view on this.

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/518804cb.6040...@debian.org

Re: Will we see MariaDB in Jessie?

[Thomas Goirand]

On 05/07/2013 01:31 AM, Clint Byrum wrote:
> I'd also like to get MySQL back in sync with Ubuntu to reduce waste
> between the two distros. 
It seems there's more and more a trend of seeing these
differences increasing. :(

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/5188053d.8060...@debian.org

Re: Developer repositories for Debian

[Joerg Jaspert]

On 13203 March 1977, Raphael Hertzog wrote:

>>  - any member of the uploading keyrings can create a PPAMAIN using a
>>defined interface[1].
>> [1] Most probably it will either be a signed mail or a signed .commands
>> style file.
> While I won't question the need to support signed mails or commands files,
> I would like to argue for the support of a web interface as well.

Anyone is free to create one.

> The sheer number of operations that are possible on such repositories will
> make it difficult to remember the precise syntax of the various
> operations. A web interface is much more discoverable. Furthermore
> it's obvious that we will have web interfaces such as those used
> to track transitions and it would be nice if we could unify them at
> a single place (think: checking the tracker, then clicking a button to
> trigger/request a bin-nmu of foo, another button to import the correct version
> of bar, etc).

> I'm not asking you to create that web interface but at least to keep in
> mind the fact that someone might want to write it and as such to clearly
> separate what needs to be handled separately (mainly authentication I
> guess).

Nah, the webinterface just should end up like the DAM webinterface: You
do whatever you need, then click a button - and voila, there is
everything ready to copy/paste into a MUA. Send with sig, done.

Or it ends up giving you a commandline for $whatevertoolisTHEsuck on
that day.

-- 
bye, Joerg
 Alfie: warum heist du jetzt eigentlich Rhonda?
 das ist heuer so mode...
 17:07  Nein, ich erklärs nicht schon wieder nicht
 17:08  10mal nicht erklären muss genügen.
 Rhonda ist die Frühjahrskollektion von Alfie :)


-- 
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/87haif7vkv@gkar.ganneff.de

Re: jessie release goals

[Vincent Lefevre]

On 2013-05-07 00:52:03 +0800, Thomas Goirand wrote:
> On 05/06/2013 10:08 PM, Christoph Anton Mitterer wrote:
> > The usually come only with a default config which may not be hardened
> > enough for the local system, and that short time may already be enough
> > for an attacker to attack.
> If the default config isn't hardened enough, fix the default config.

This can be fine for some daemons/servers. For instance, for a web
server, displaying a default web page is harmless. But what about a
mail server? Any default config would probably lead to loss of mail
if things like virtual alias domains are used.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130506200036.ga16...@xvii.vinc17.org

Re: jessie release goals

[Vincent Lefevre]

On 2013-05-06 17:22:57 +0200, Marco d'Itri wrote:
> On May 06, Christoph Anton Mitterer  wrote:
> > 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> > default on the network (unless loopback only) shouldn't be started per
> > default, after being installed.
> This has been discussed over and over, I think with a clear consensus: 
> installed software should work. If you do not want a service to act like 
> a service then do not install it.

This doesn't make any sense. What is installed is a package, not
a service. There are packages, like rsync, that provide more than
a service, e.g. a client and a daemon. What if the user wants the
client but not the corresponding service (at any time, including
a short time after the installation)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130506201110.gb16...@xvii.vinc17.org

Re: Question about multiarch

[Andrei POPESCU]

On Lu, 06 mai 13, 12:03:15, Walter Valenti wrote:
> Scenario:
> 
> a Intel x64 (T5500) with "Wheezy i386" installed.
> It's possible use the multiarch support of dpkg
> to migrate to "Wheezy amd64" ?
> 
> (after installation of linux-image-amd64, libc6-amd64)

This belongs on debian-user, see
http://wiki.debian.org/FAQsFromDebianUser#Are_cross-grades_possible.3F

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


signature.asc
Description: Digital signature

Re: jessie release goals

[Serafeim Zanikolas]

As the sole driver and implementor of DEP9, I would like to see all reverse
depends of update-inetd migrate to reconf-inetd. That is, assuming inetd is
not entirely deprecated by systemd/upstart/whathaveyou by the time jessie is
released.

On a less boring note, I would like to see apt-listbugs become usable without
a terminal (#628996), and have at least one GUI package manager integrate with
apt-listbugs, so that Debian-testing users can be warned about RC-buggy
packages.

-- 
Every great idea is worthless without someone to do the work. --Neil Williams


-- 
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/20130506202406.GB14246@mobee

Re: Will we see MariaDB in Jessie?

[Clint Byrum]

On 2013-05-06 12:32, Thomas Goirand wrote:

On 05/07/2013 01:31 AM, Clint Byrum wrote:

I'd also like to get MySQL back in sync with Ubuntu to reduce waste
between the two distros.

It seems there's more and more a trend of seeing these
differences increasing. :(



This is yet another dig at Ubuntu, something I think is both unfounded 
and unproductive.


In this particular case, the delta is purely due to lack of time on my 
part to pull changes that are necessary in Ubuntu into Debian. For 
instance, changes that allowed Debian to take .upstart files in the 
debian dir were not yet settled when we diverged. There are just a few 
minor items, but currently all of my Debian spare time is eaten up 
shipping security updates.



--
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/507fed94140a96262cdb209cad405...@secure.spamaps.org

Re: jessie release goals

[Don Armstrong]

On Mon, 06 May 2013, Vincent Lefevre wrote:
> On 2013-05-06 17:22:57 +0200, Marco d'Itri wrote:
> > On May 06, Christoph Anton Mitterer  wrote:
> > > 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that
> > > listen per default on the network (unless loopback only) shouldn't
> > > be started per default, after being installed.
> > This has been discussed over and over, I think with a clear
> > consensus: installed software should work. If you do not want a
> > service to act like a service then do not install it.
> 
> This doesn't make any sense. What is installed is a package, not a
> service. There are packages, like rsync, that provide more than a
> service, e.g. a client and a daemon. What if the user wants the client
> but not the corresponding service (at any time, including a short time
> after the installation)?

The trivial answer to this is to separate out the client from the
service when it's reasonable to have the client installed by not the
daemon running. In cases where that's not desired, a reasonable,
hardened default service should be enabled. In some cases, this
reasonable, hardened default will result in the service detecting that
it has nothing configured, and not starting the daemon at all. However,
stopping the daemon should still always work.

In the case of rsync, as rsync is already capable of detecting if it has
an rsync configuration file and not starting if that is the case, it
should default to RSYNC_ENABLE=true.


Don Armstrong

-- 
PowerPoint is symptomatic of a certain type of bureaucratic
environment: one typified by interminable presentations with lots of
fussy little bullet-points and flashy dissolves and soundtracks masked
into the background, to try to convince the audience that the goon
behind the computer has something significant to say.
 -- Charles Stross _The Jennifer Morgue_ p33

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20130506205640.ge26...@rzlab.ucr.edu

Re: jessie release goals

[Bob Proulx]

Christoph Anton Mitterer wrote:
> I would like to see the following with respect to PHP and all packages
> using PHP:
> 1) We should try to educate users not to use mod_php.

If "Best Practices" such as this were documented such as on the Debian
wiki then it would go a long way to making this easy for users to do.
They could then simple follow recipies to good practices.  Without
good clear documentation they will be left to their own and will do
what is easiest.

  http://wiki.debian.org/PHP

Bob


signature.asc
Description: Digital signature

Re: jessie release goals

[Helmut Grohne]

On Mon, May 06, 2013 at 04:08:07PM +0200, Christoph Anton Mitterer wrote:
> 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> default on the network (unless loopback only) shouldn't be started per
> default, after being installed.

May I point to /usr/sbin/policy-rc.d? As has been pointed out a number
of times now, there is no consensus on not starting daemons by default.
To enable you as a user to change the default this policy helper is
provided as a hook. You also might want to look at the
policyrcd-script-zg2 package.

This is not to say that the current mechanisms for achieving "do not
start daemons at installation" are ideal. Clearly there is room for
improvement, but the hooks are available.

Helmut


-- 
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/20130506210429.GA13397@localhost.localdomain

Uploading only arch:all (Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes)

[Joachim Breitner]

Hi,

Am Montag, den 06.05.2013, 16:57 +0200 schrieb Goswin von Brederlow:
> Maybe as an intermediate and imediate step we could switch to
> uploading only arch:all debs for mixed packages. That is already
> supported by DAK and the buildds and would drop a lot of locally build
> debs.

sounds interesting, I certainly would be happy to do so. I guess this
would need a patch to dpkg-genchanges, adding an option for that?
Anything else that needs to be modified?

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Bug#707015: ITP: taginfo -- convenience wrapper for taglib

[Dominique Lasserre]

Package: wnpp
Severity: wishlist
Owner: Dominique Lasserre 

* Package name: taginfo
  Version : 0.1.6
  Upstream Author : Jörn Magens
* URL : https://bitbucket.org/shuerhaaken/libtaginfo
* License : LGPL-2+
  Programming Lang: C++
  Description : convenience wrapper for taglib


Following paragraphs are copied from the project homepage:

Features are reading/writing fields like: Artist, Album, Title, Genre,
AlbumArtist, Comments, Disk number, Compilation flag, User labels,
Embedded Images, Lyrics, Audio properties (length, bitrate, samplerate,
channels ...), ...

TagInfo is fast. Very rough tests have shown that it is about 40 - 60
times faster in file reading than with GStreamer's GstDiscoverer (codec
based). There is not much overhead coming with this library, so it reads
at almost the same speed as taglib itself, which is the fastest way
around to read tag information.

Additionally, this library offers C and vala bindings that provide a lot
of features that are not available via TagLib's own C bindings (and the
according vala bindings).

The lacking possibility of accessing certain data fields via taglibs own
C bindings was the original motivation for the creation of this library.


This library is a requirement to get the xnoise media player included. See
also #632932.


-- 
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/20130506221433.32542.63635.reportbug@localhost

Re: [debian-mysql] Will we see MariaDB in Jessie?

[Steven Ayre]

> I've done my best to package MariaDB following best practices on
> Debian control files and conflict/replace rules. So I am confident to
> say we actually already have a way how to get MySQL flavors to
> coexist. What we seem to lack is _resources_. I guess we could package
> all of Percona, Galera etc is we had 15 team members to take care of
> all testing, security patching etc.
> 
> Would you like to join?

For my own part I packaged MySQL Cluster some time ago, but missed the wheezy 
freeze and besides no one came forward as a sponsor (I'm not a DD). It's 
largely based on the mysql-5.5 packaging.

https://github.com/SteveAyre/mysql-cluster

Now the freeze is over I'll take a look at updating it following the meeting 
and raise it on debian-mentors again.

Re: jessie release goals

[Michael Gilbert]

On Mon, May 6, 2013 at 8:49 AM, Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
> * multiarch compatible binNMUs
> * discarding maintainer uploaded binary packages [!arch:all]
> * discarding maintainer uploaded binary packages [incl. arch:all]
> * extending binNMUs to allow rebuilding arch:all packages (so it's no
> longer a "binary only" but a sourceful no-change rebuild - the classic
> binNMU should stay of course)

An "infrastructure" goal that I would like to see during this cycle is
automated piuparts passage before testing acceptance for all packages.

Let's reduce jessie's release-critical bug count by about 500 right
now [0] by preventing piuparts-broken future uploads from ever
reaching testing.

Best wishes,
Mike

[0] https://lists.debian.org/debian-release/2013/05/msg00116.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/CANTw=MO0wymAWJt7sY2=tb03ch_x0ejejswmqnx0fzm-uzf...@mail.gmail.com

Re: jessie release goals

[Christoph Anton Mitterer]

On Mon, 2013-05-06 at 14:59 -0600, Bob Proulx wrote:
> > 1) We should try to educate users not to use mod_php.
> If "Best Practices" such as this were documented such as on the Debian
> wiki then it would go a long way to making this easy for users to do.
> They could then simple follow recipies to good practices.
Well but right now many packages rather assume that one uses mod_php...

I run several PHP programs on our faculty (e.g. icinga-classic,
icinga-web, pnp)... all of them with CGI each of them running with it's
own user and thereby also doing the DB authentication...

Setting this up was really time consuming as it required lots of trying,
especially when also "hardening" php.ini per each of these programs (and
therefore most end users simply won't to it)... in an ideal world...
such things would be better supported.

This is definitely _not_ to blame any of the respective maintainers... I
just think that it's better to harden and separate as much as
possible :)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: jessie release goals

[Christoph Anton Mitterer]

On Mon, 2013-05-06 at 20:47 +0200, Jakub Wilk wrote:
> Do you have any concrete examples (besides flashplugin-nonfree, which is 
> indeed abominable)?
I know at least of susv2/3.

I once manually went through all the packages depending on wget/curl,...
but I don't have the list anymore and would likely be outdated, as I
opened several bugs back then and the maintainers did some good job.


> >b) Another problem are IMHO plugins like Firefox extensions, kinda 
> >bypassing APT. I think at least those that are installed via a package, 
> >shouldn't be upgradable/overwritable anymore with online versions.
> What exactly do you mean? The only way I can upgrade my Iceweasel 
> add-ons is via apt/dpkg.
Mhh seems you're right... has this changed recently? Anyway... me hiding
in shame ;)


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#705879: general: wheezy don't boot on ext4 with external-journal

[Dmitry Smirnov]

On Sun, 5 May 2013 10:50:09 Calvin Owens wrote:
> I encountered a similar problem in Gentoo - e2fsck 1.42.5 can't check
> read-only mounted FS with an external journal. Ted Ts'o just wrote a
> fix: http://www.spinics.net/lists/linux-ext4/msg38096.html

Thanks for your fantastic feedback Calvin.

So we have two unrelated issues that I reported against "e2fsprogs":

 * #707029 "UUID is not used to discouver ext4 external journal"
 * #707030 "Unable to check root file system on ext4 with external journal"

Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


-- 
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/201305071100.12767.only...@member.fsf.org

Re: jessie release goals

[Christoph Anton Mitterer]

On Tue, 2013-05-07 at 00:52 +0800, Thomas Goirand wrote:
> If the default config isn't hardened enough, fix the default config.
> Adding a supplementary step to start the service doesn't fix the
> problem anyway.

I don't think this is only a question of hardened enough of not...
simply supplying a service even if fully secure, may cause troubles if
it starts out with defaults.

So I agree with Vincent here...
In my opinion, most of these servers are always potentially dangerous
both, for the user himself as for the rest of the internet... of course
one can never prevent people from doing stupid things, but ideally
responsible admins should have the chance to first configure, then
start.


On Mon, 2013-05-06 at 17:22 +0200, Marco d'Itri wrote:
> > The usually come only with a default config which may not be
> > hardened enough for the local system, and that short time may
> > already be enough for an attacker to attack.
> [citation needed]
I think, security wise this ("show me a hole or nothing will happen") is
the wrong approach.
There are so many weird ideas to exploit things, and the policy should
rather be lock as much as possible, even if it seems to be safe, in
order to prevent those attacks one cannot think of.

Remember that issue with PHP/Apache and open server-status pages? That's
kind of an example for that. Why running something per default that may
be attackable? If the admin really needs or misses it, he will take care
to set it up. 


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Bug:#700917: desktop-file-utils: call for (co-)maintainership [ITA]

[Dmitry Smirnov]

On Tue, 7 May 2013 03:02:02 Jakub Wilk wrote:
> * Dmitry Smirnov , 2013-05-05, 12:30:
> >I'm quite concerned that `desktop-file-validate` utility (provided by 
> >"desktop-file-utils" package) is checking .desktop files against 
> >outdated specification. On some occasions such "validation" recommend 
> >changes conflicting with the current specification (see more in 
> >#690279).
> 
> Wrong bug number?
 
No but perhaps its description could be more clear to emphasise why
new upstream version is particularly important. The importance of new
upstream version is that it accommodate changes in specification. See
links to upstream commit and related upstream bug report that I
mentioned in #690279.

Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B


-- 
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/201305071120.02983.only...@member.fsf.org

Re: jessie release goals

[Wookey]

+++ The Wanderer [2013-05-06 09:36 -0400]:
> 
> I don't know whether it would be practical, but one thing I would like
> to see included as an explicit goal is the completion of multi-arch -dev
> support.

I think it's eminently practical.

> There is functionality provided by the old ia32-libs-dev package which
> is not apparently possible - short of installing the necessary headers
> and so forth by hand, and maybe not even then - with multi-arch library
> packages, unless multi-arch -dev packages are also supported. Since they
> aren't, this means the transition from ia32-libs to multiarch introduces
> a regression.
> 
> Since I use some of the functionality which appears to be lost in that
> regression, I would hope for fixing that regression to be one of the
> goals for the next release.
> 
> 
> I understand that the necessary specification for letting this be
> possible has not been completed, and that work on that is ongoing. 

In fact this work has been done, at least to a reasonable
approximation. A large number of multiarch -dev packages have been put
in Ubuntu and tested there for building and cross-building against. It
didn't actually need any significant changes to the multiarch spec
(just a decision to leave arch-independent headers in /usr/include and
move arch-dependent headers to /usr/include/triplet). So long as the
toolchain knows to look on both those paths by default nearly
everything 'jsut works'. There are a few wrinkles about finding
headers (python was a bit ugly IIRC), and we may find a few more but
this seems to work well in practice.

Updating the multiarch spec to record this info just needs doing.

Telling apt to assume that arch:all Build-dep: packages are
M-A:foreign also dramatically improves the effectiveness of multiarch
for -dev packages (without having to wait until everything has
actually been explicitly marked):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666772

Again this has worked nicely in Ubuntu and I see no reason not to do
it in Debian too (although we could decide to explictly mark every
package instead if we really wanted the makework). 

> I am
> certainly not attempting to bash anyone for the regression; delaying the
> release of wheezy until the work could be completed, such as would have
> been necessary to avoid the regression without delaying multiarch, would
> plainly not have been a reasonable option.

Indeed.

> That said, I'd obviously prefer this not to continue to be delayed any
> longer than necessary, and including it on the list of release goals
> seems like an appropriate way of raising its profile (and/or its
> priority) in pursuit of that.

I'm all for that. If anyone has any objections, speak up. 

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/20130507020450.gb2...@stoneboat.aleph1.co.uk

Re: Will we see MariaDB in Jessie?

[Steve Langasek]

On Tue, May 07, 2013 at 03:32:13AM +0800, Thomas Goirand wrote:
> On 05/07/2013 01:31 AM, Clint Byrum wrote:
> > I'd also like to get MySQL back in sync with Ubuntu to reduce waste
> > between the two distros. 
> It seems there's more and more a trend of seeing these
> differences increasing. :(

The Debian/Ubuntu delta is a Rorschach test; people see in it what they want
to.  The mysql server packages haven't been in sync between Debian and
Ubuntu for at *least* the past 5 years, and possibly ever[1].  Some might
look at this and think it's a good thing that someone is trying to eliminate
the delta on this package now.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[1] it's harder to look up "ever" thanks to the constantly-changing source
package name.


signature.asc
Description: Digital signature

Doubts about PPA in Debian

[Adrian Alves]

Why I vote NO for ppa in Debian,

Something that everybody loves about debian is you have everything in one
repo for stable testing or development, the use of PPA it couse things like
happens in ubuntu when u need something important you need to install it
from a PPA because is not in the repo thats not the case in debian, always
happens this kind of scenarios:

- in ubuntu I need this important app OH no is not in the main repo look
for a PPA and then add it but probably some day you will see it on the main
repos, how a user it will look or find this app in a PPA you need another
PPA for a tool that search in the PPA, but th
In other words when u need something importante in debian u can look at it
just one apt but in ubuntu u need to look or search for a PPA crossing the
fingers to find it
- and when that app gonna be pushed into the mains repos?, in ubuntu some
pkgs lives forever in PPA and never reach the main repo.
- all the efforts of the developer to push apps into the mains debian repo
like main contrib and non-free it will be affected because now all the new
things gonna need to be pushed from PPA into mains repos?
- something that everybody loves from debian is u have everything in one
like at source.list
-and debian is not ubuntu in other way ubuntu is debian

am not saying PPA is bad just worried about not to lose the magic of debian
who has everything in one place.

Regards, Adrian.-

Re: Doubts about PPA in Debian

[Brian May]

On 7 May 2013 14:23, Adrian Alves  wrote:

> am not saying PPA is bad just worried about not to lose the magic of
> debian who has everything in one place.
>

This is already the case. Not everything I package deserves to go into
Debian main. e.g. because it is specific to a problem I am solving and may
not be of general use. Or because of problems with licensing, Or because it
has changes that the Debian maintainer disagrees with. Or any number of
other reasons. However that does not mean I want to make the package
private. It is possible that others may be able to make use of it. Who
knows, maybe at a later date it might be ok to put in Debian main.

PPA support will allow keeping more things open. Instead of requiring
developers to create their own private repositories on random websites,
everything can be in one global set of repositories.

While it may be true that some deserving packages live in Ubuntu's PPA
forever, I am sure that there are deserving Debian packages that are stored
in random private repositories for ever. PPA support for Debian wont change
this - although it may make it easier to migrate from the PPA to Debian
main.
-- 
Brian May 

Re: Doubts about PPA in Debian

[Adrian Alves]

On Tue, May 7, 2013 at 1:42 AM, Brian May wrote:

> On 7 May 2013 14:23, Adrian Alves  wrote:
>
>> am not saying PPA is bad just worried about not to lose the magic of
>> debian who has everything in one place.
>>
>
> This is already the case. Not everything I package deserves to go into
> Debian main. e.g. because it is specific to a problem I am solving and may
> not be of general use. Or because of problems with licensing, Or because it
> has changes that the Debian maintainer disagrees with. Or any number of
> other reasons. However that does not mean I want to make the package
> private. It is possible that others may be able to make use of it. Who
> knows, maybe at a later date it might be ok to put in Debian main.
>
> PPA support will allow keeping more things open. Instead of requiring
> developers to create their own private repositories on random websites,
> everything can be in one global set of repositories.
>
> While it may be true that some deserving packages live in Ubuntu's PPA
> forever, I am sure that there are deserving Debian packages that are stored
> in random private repositories for ever. PPA support for Debian wont change
> this - although it may make it easier to migrate from the PPA to Debian
> main.
>
well as u explain it has logic but whats happens if that never happens on
that way? and packages that deserve to be in Debian repos never reach it
because it never be pushed into? or how you gonna look into all the PPA's
looking for something? YPPA in ubuntu has it own PPA u get my point?


> --
> Brian May 
>

Re: jessie release goals

[Paul Wise]

On Mon, May 6, 2013 at 8:49 PM, Andreas Beckmann wrote:

> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):

I have a long wishlist that contains some items which may be suitable
for turning into release goals:

http://wiki.debian.org/PaulWise#wishlist

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

Re: Doubts about PPA in Debian

[Paul Wise]

On Tue, May 7, 2013 at 1:10 PM, Adrian Alves wrote:

> well as u explain it has logic but whats happens if that never happens on
> that way? and packages that deserve to be in Debian repos never reach it
> because it never be pushed into? or how you gonna look into all the PPA's
> looking for something? YPPA in ubuntu has it own PPA u get my point?

I think you may have misunderstood the Debian PPA proposal. It will
not be like the Ubuntu PPA system where anyone can upload a package to
Launchpad and have it autobuilt for multiple releases. I suggest that
you re-read it:

http://lists.debian.org/87y5btehw3@gkar.ganneff.de

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

Re: Developer repositories for Debian

[Raphael Hertzog]

Hi,

On Mon, 06 May 2013, Joerg Jaspert wrote:
> Nah, the webinterface just should end up like the DAM webinterface: You
> do whatever you need, then click a button - and voila, there is
> everything ready to copy/paste into a MUA. Send with sig, done.

Why? This is just a band-aid and not what I would call a web interface.
And except lazyness I don't see a good reason for that. Web interfaces
can be secure (and with an audit trail in case of breach). After all we
can manage our Debian passwords over a web interface...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20130507062252.ga32...@x230-buxy.home.ouaza.com

Re: jessie release goals

[Raphael Hertzog]

On Mon, 06 May 2013, Helmut Grohne wrote:
> On Mon, May 06, 2013 at 04:08:07PM +0200, Christoph Anton Mitterer wrote:
> > 1) IMHO, services/daemons (e.g. apache, ejabberd, etc.) that listen per
> > default on the network (unless loopback only) shouldn't be started per
> > default, after being installed.
> 
> May I point to /usr/sbin/policy-rc.d? As has been pointed out a number
> of times now, there is no consensus on not starting daemons by default.
> To enable you as a user to change the default this policy helper is
> provided as a hook. You also might want to look at the
> policyrcd-script-zg2 package.
>
> This is not to say that the current mechanisms for achieving "do not
> start daemons at installation" are ideal. Clearly there is room for
> improvement, but the hooks are available.

Except for chroots that do not run the boot-time scripts, this mechanism
is mostly useless. /etc/init.d/rc doesn't know about policy-rc.d and thus
you can't use it to disable services that are installed on a real server.

(Or I missed something and someone need to enlighten me.)

While I believe that the "start by default" is a reasonable default,
I also believe that we should have a way for administrators to control
this more finely, and unfortunately policy-rc.d doesn't seem
to do that.

For Kali Linux, I opted to dpkg-divert update-rc.d to be able to disable
services as soon as they are installed.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
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/20130507063224.gb32...@x230-buxy.home.ouaza.com