Re: New opinions wanted for bug #676485 ( squeeze→wheezy GNOME upgrade)

[Lisandro Damián Nicanor Pérez Meyer]

On Wed 19 Dec 2012 21:09:55 Josselin Mouette escribió:
> Hi all,
> 
> we’re facing a very subtle APT upgrade bug with #676485 and we’d like
> input from a larger number of developers before implementing an
> imperfect solution.
[snip]
> We found by testing a few ways to break this cycle and get the upgrade
> to work.

JFTR: this looks very similar to #687666. In this case, Sune found a way to 
break the circular dependency solving the problem. But IIRC another similar 
situation appeared in another package later (docbook?), although I can't 
confirm it's the same issue.

-- 
Cuando tenga duda, utilice la solución mas simple.
  Principio de William Occam, también llamado
  "la navaja de Occam"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

New opinions wanted for bug #676485 (squeeze→wheezy GNOME upgrade)

[Josselin Mouette]

Hi all,

we’re facing a very subtle APT upgrade bug with #676485 and we’d like
input from a larger number of developers before implementing an
imperfect solution.

Basically, a full GNOME upgrade from squeeze to wheezy is failing
because of a large number of lockstep upgrades using Depends/Breaks
pairs, for related packages.

The bug was triggered by fixing #677582 in gcc-4.7-base, adding a final
Breaks that makes APT lose itself in a loop involving glib, gdk-pixbuf,
libstdc++, gcc-4.*, gcj-4.*, and many others. This is clearly an APT bug
since it should just upgrade everything together, but so far we don’t
know the exact origin of this bug. (And as libstdc++ is involved,
upgrading APT first is not possible anyway.)

We found by testing a few ways to break this cycle and get the upgrade
to work.
1. Remove the gcj-4.7-jre → libgcj13-awt dependency
→ But applications depending on the JRE expect to have the GUI
parts, so I don’t think this can work.
2. Remove some of the Breaks in gcc-4.7-base
→ This means bringing back parts of #677582, meaning some
upgrades won’t be complete.
3. Remove most Breaks in libglib2.0-0 (all that depend directly or
 indirectly on libgdk-pixbuf2.0-0) 
  * The gvfs one can be kept as is. 
  * For gtk3, eog, gwaei and emacs23, the broken versions for which
the Breaks was added are not in squeeze, so we could remove the
Breaks safely. 
  * For gnome-session and gnome-control-center, it is mostly a
question of missing functionality when the upgrade is not done
together with glib, so the Breaks is less important. 
  * For gdm3, however, allowing partial upgrades leaves a
possibility of a login session from which you can invoke stuff
like a web browser, which is unacceptable from a security
standpoint.

So far, we’re going towards removing all Breaks from libglib2.0-0
(except for gvfs) and uploading a new gdm3 in squeeze to remove that
risk (provided this upload is approved by the SRMs):
- export XDG_DATA_DIRS in the greeter session
- add the mimeapps.list and mime-dummy-handler.desktop from the wheezy
   package

If anyone has an idea to make these upgrades better than doing a stable
upload, it would be appreciated.

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/1355962195.3401.29.camel@tomoyo

Re: Why are mailboxes in /var/mail owned by group mail?

[Russ Allbery]

"Jaldhar H. Vyas"  writes:

> What is the reason for mailboxes to be owned by group mail when in
> Debian we have per-user groups and AFAIK no daemons or other system
> processes belong to the mail group?

So that you can, if you choose, run mail delivery agents and POP/IMAP
servers as something other than root.

http://www.debian.org/doc/debian-policy/footnotes.html#f102

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


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

Re: Why are mailboxes in /var/mail owned by group mail?

[Asheesh Laroia]

On Wed, 19 Dec 2012, Jaldhar H. Vyas wrote:

The subject came up in the course of bug #693114 which in a nutshell is 
caused by dovecot by default copying the permissions of the users 
mailbox in /var/mail for indexes in the users home directory. 
Naturally, this fails when the user is not a member of group mail.


What is the reason for mailboxes to be owned by group mail when in 
Debian we have per-user groups and AFAIK no daemons or other system 
processes belong to the mail group?


As I understand things, it is so MUAs can lock the mailbox in mbox format.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414264 discusses it 
further.


-- Asheesh.


--
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/alpine.deb.2.02.1212191618330.7...@rose.makesad.us

Why are mailboxes in /var/mail owned by group mail?

[Jaldhar H. Vyas]

The subject came up in the course of bug #693114 which in a nutshell is 
caused by dovecot by default copying the permissions of the users mailbox 
in /var/mail for indexes in the users home directory.  Naturally, this 
fails when the user is not a member of group mail.


What is the reason for mailboxes to be owned by group mail when in Debian 
we have per-user groups and AFAIK no daemons or other system processes 
belong to the mail group?


--
Jaldhar H. Vyas 


--
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/alpine.DEB.2.02.1212191143260.25785@kubuntu

Re: RFA: jabberd2 -- Jabber instant messenger server

[Willem van den Akker]

On Wed, 2012-12-19 at 16:53 +0400, Michael Tokarev wrote:

> 18.12.2012 17:51, Andrei POPESCU wrote:
> > On Ma, 18 dec 12, 09:20:25, Willem van den Akker wrote:
> >> Hi,
> >> 
> >> I am willing to maintain the packages jabberd2 and udns. I have already 
> >> uploaded new versions of both packages to mentors.debian.org.
> >> 
> >> http://mentors.debian.net/package/udns 
> >> http://mentors.debian.net/package/jabberd2
> 
> > Regarding udns, the package doesn't appear to be orphaned (no O: bug 
> > against wnpp). In this case uploading a new package might be considered a 
> > hijack. If you want to help you should definitely contact the Maintainer 
> > first.
> 
> The package hasn't been orphaned, but I as the only upstream author
> asked for it to not enter.. lenny (!) because I thought I implement
> some different API for it.  But in recent years I haven't done a
> thing about it (except of accepting some patches which implements
> support for additional RR types, and fixing bugs in these patches).
> 
> #493599 - while most technical points are gone now, one point
> raised there is valid: maybe there's no need to have yet another
> resolver?  I dunno, I wrote it for a reason but I don't have time
> to support it, and while it does not have lots of bugs, it is
> missing some features, in particular it is DNSSEC support.
> 
> Besides, I'm now a debian developer, and it'd be quite a bit
> silly to ask another person to package my own software for
> debian... ;)
> 
> /mjt

Hi,

Yes I would be silly to ask an other person. But I just gave you a
little help.
Jabberd2 is orphaned. I would like to adopt it. However it depends on
udns and 
thats why I created a package. I could ask you first, however DD's are
often very
busy and I could take a little work out of their hands. 

#493599. Jabberd2 only depends on the library. Also Jabberd2 wont use
another
resolver in a short time [1]. So we are stuck with udns. I personally do
not find
ejabberd an alternatieve because it needs tons of elang files.

Greettngs,
Willem


[1] https://bugs.launchpad.net/jabberd2/+bug/496824)

Bug#696331: ITP: macs -- Model-based Analysis of ChIP-Seq on short reads sequencers

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: macs
  Version : 2.0.9.1
  Upstream Author : Tao Liu 
* URL : https://github.com/taoliu/MACS/
* License : Artistic
  Programming Lang: Python
  Description : Model-based Analysis of ChIP-Seq on short reads sequencers
 MACS empirically models the length of the sequenced ChIP fragments, which
 tends to be shorter than sonication or library construction size estimates,
 and uses it to improve the spatial resolution of predicted binding sites.
 MACS also uses a dynamic Poisson distribution to effectively capture local
 biases in the genome sequence, allowing for more sensitive and robust
 prediction. MACS compares favorably to existing ChIP-Seq peak-finding
 algorithms, is publicly available open source, and can be used for ChIP-Seq
 with or without control samples.

Remark: The package is maintained in Debian Med team and available in VCS at
  Vcs-Svn: svn://svn.debian.org/debian-med/trunk/packages/macs/trunk/


-- 
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/20121219171553.24379.32338.report...@mail.an3as.eu

Re: Multiple source package entries in Sources file

[Thorsten Glaser]

Ansgar Burchardt  debian.org> writes:

> On 12/18/2012 05:09 PM, Niels Thykier wrote:
[…]
> > also a talk about keeping old versions of the source package around for
> > license compliance.  This is mostly related to packages "embedding"
> > (parts of) other packages during builds (I believe they would use the
> > Built-Using header to declare this).
> 
> We already do this. But only a few packages need it, for example

mksh in experimental does that (since Built-Using did not get into
Policy before the wheezy freeze), as it provides a statically linked
binary. I believe bash-static must also start doing it soon.

Nice side-effect: the uploads from auto-builders whose libc or gcc
version is not up to date are REJECTed, as the corresponding sources
have already vanished from the archive before the first package B-Uing
them came in… looking at http://packages.debian.org/search?keywords=mksh
the only arch whose buildd admin did *not* upgrade their chroots yet
is amd64 out of all things…

bye,
//mirabilos via GMane


-- 
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/loom.20121219t150627-...@post.gmane.org

Re: RFA: jabberd2 -- Jabber instant messenger server

[Arno Töll]

Hi,

On 19.12.2012 13:53, Michael Tokarev wrote:
> Besides, I'm now a debian developer, and it'd be quite a bit
> silly to ask another person to package my own software for
> debian... ;)

while this is definitely a matter of personal preferences and you are of
course all allowed to do so, let me tell you that there is an opposing
position to yours as well.

Some people (hi Jakub!) do not package their own upstream software on
purpose for Debian because they believe that biases their work on either
side. Clearly there are situations where packaging and distribution
related tasks contradict with upstream's priorities and point of views.

The Debian principle of backporting important fixes instead of upgrading
for example is one of these things where upstream developers tend to say
"WTH? Why don't you just use my latest version".

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature

Re: RFA: jabberd2 -- Jabber instant messenger server

[Michael Tokarev]

18.12.2012 17:51, Andrei POPESCU wrote:
> On Ma, 18 dec 12, 09:20:25, Willem van den Akker wrote:
>> Hi,
>> 
>> I am willing to maintain the packages jabberd2 and udns. I have already 
>> uploaded new versions of both packages to mentors.debian.org.
>> 
>> http://mentors.debian.net/package/udns 
>> http://mentors.debian.net/package/jabberd2

> Regarding udns, the package doesn't appear to be orphaned (no O: bug against 
> wnpp). In this case uploading a new package might be considered a hijack. If 
> you want to help you should definitely contact the Maintainer first.

The package hasn't been orphaned, but I as the only upstream author
asked for it to not enter.. lenny (!) because I thought I implement
some different API for it.  But in recent years I haven't done a
thing about it (except of accepting some patches which implements
support for additional RR types, and fixing bugs in these patches).

#493599 - while most technical points are gone now, one point
raised there is valid: maybe there's no need to have yet another
resolver?  I dunno, I wrote it for a reason but I don't have time
to support it, and while it does not have lots of bugs, it is
missing some features, in particular it is DNSSEC support.

Besides, I'm now a debian developer, and it'd be quite a bit
silly to ask another person to package my own software for
debian... ;)

/mjt


-- 
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/50d1b8b2.2060...@msgid.tls.msk.ru

Re: Math Fonts for Iceweasel and MathJax

[Andrew Shadura]

Hello,

On Tue, 18 Dec 2012 14:50:05 +0100
Frédéric WANG  wrote:

> Basically, Iceweasel must not depend on ttf-lyx, ttf-mathematica4.1, 
> xfonts-mathml or any other font packages that would lead to the 
> installation of Computer Modern fonts or Mathematica fonts. These old 
> fonts were used a long time ago in Gecko's MathML engine but now they 
> may give weird rendering bugs if they are still installed. However,
> the dependency on otf-stix should be preserved and possibly a
> dependency on fonts-oflb-asana-math should be added: 
> http://packages.debian.org/sid/fonts-oflb-asana-math

> It would also be great to make Iceweasel depend on the MathJax fonts
> as they look more like the old Computer Modern fonts.

And what's wrong with Computer Modern Unicode fonts? Don't they render
properly?

-- 
WBR, Andrew


signature.asc
Description: PGP signature

Bug#696319: ITP: libapache2-mod-log-slow -- Apache module for logging of slow requests handling

[Cyril Bouthors]

Package: wnpp
Severity: wishlist

* Package name: libapache2-mod-log-slow
  Version : 1.0.6
  Upstream Author : Yoichi Kawasaki 
* URL or Web page : https://code.google.com/p/modlogslow/
* License : Apache License version 2.0
  Description : Apache module for logging of slow requests handling


mod_log_slow is Apache module to provide measures of the time period
used for handling each request by the current process. Logging is done
after processing a request if the request takes more than certain
period of time that you specifiy.
The idea of this module comes from MySQL's slow-query-log, and its
logging logic is partially based on mod_log_forensic.
-- 
 ,''`.
: :' :  Cyril Bouthors
`. `' Debian.org
  `-


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