Re: Lintian based autorejects

[Raphael Hertzog]

On Sun, 01 Nov 2009, Steve Langasek wrote:
> My only concern is that the ftp archive checks not be used to force changes
> in Policy.
> 
> If the set of tags being drawn from is limited to those that are recognized
> as violations of Policy "must" requirements, then I have no opinion on who
> should decide which tags are blockers and which ones are not.  If the
> candidate tags are *not* limited to that set, then I think we have a
> governance problem regardless of who's driving.

What about using those tags to achieve release goals?

For example, the support of 3.0 (quilt) by default would benefit from
getting rid of:
http://lintian.debian.org/tags/patch-modifying-debian-files.html
http://lintian.debian.org/tags/quilt-patch-with-non-standard-options.html

Otherwise, I generally agree with your point of view. I welcome this new
infrastructure but the set of tags used should be limited to clear
violations of must directives, really broken packages, and other
consensual tags that allow us to reach our current set of goals.

Cheers,
-- 
Raphaël Hertzog


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

Re: /var/www is depracated, which directory to use?

[Gabor Gombas]

On Sat, Oct 31, 2009 at 05:51:26PM +0200, Holger Levsen wrote:

> /var/lib/munin/www is wrong (FHS says: "Users must never need to modify files 
> in /var/lib to configure a package's operation." since users might want to 
> modify the css files)

IMHO that's not different from some user wanting to modify the sources
of any random package. If you really think that editing the css file is
an every-day operation, then it should be moved to /etc and marked as a
conffile. Ohterwise, don't bother.

Gabor

-- 
 -
 MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
 -


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

Re: Lintian based autorejects

[Stefano Zacchiroli]

On Sun, Nov 01, 2009 at 04:13:48PM -0800, Steve Langasek wrote:
> On Sun, Nov 01, 2009 at 03:31:12PM +0100, Stefano Zacchiroli wrote:
> > So, I revamp a proposal I made in a corner of this thread:
> >   Let the QA team decide upon the non overridable lintian errors.
> 
> My only concern is that the ftp archive checks not be used to force changes
> in Policy.
> 
> If the set of tags being drawn from is limited to those that are recognized
> as violations of Policy "must" requirements, then I have no opinion on who
> should decide which tags are blockers and which ones are not.  If the
> candidate tags are *not* limited to that set, then I think we have a
> governance problem regardless of who's driving.

Agreed.

I was splitting the issues in two sub-issues actually: (1) being sure
that lintian "E:" messages are only those coming from violated "must"
requirements, (2) deciding which among them are upload blockers.

I confess I was pretty much assuming that lintian maintainers ensure (1)
is always verified. Beside bugs in lintian that can always, I now
realize that (1) is probably not so strict. For instance, for OCaml
packages we do have custom lintian checks that do not appear in policy,
but rather in our own packaging policy, but which we do want to be
"E:". Surely we do not want those to be upload blockers.

All in all, your requirement can be probably be implemented by setting
the general rule that all upload blockers should match violated "must"
requirements, no matter who is in charge of defining the list.

That rule being clear, we can decide upon anyone team to be in charge of
defining the list, I just found QA a good balance of factors like: "not
too big" (to avoid consensus reaching problem), "not too small" (to
avoid bottlenecks), "on topic" (in charge of archive QA).

Cheers.

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


signature.asc
Description: Digital signature

Re: Lintian based autorejects

[Lucas Nussbaum]

On 01/11/09 at 15:31 +0100, Stefano Zacchiroli wrote:
> [ Adding -qa to Cc ]
> 
> On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote:
> > > For future handling: If we are adding tags to the list that will hit
> > > more than a few packages we will send a notice to the d-d-a list.
> > 
> > I don't think it's appropriate for the ftp team to add any other checks
> > without notifying the project, regardless of how many packages are currently
> > affected.  Please make sure you notify the project of /any/ additional rules
> > you apply at archive accept time.
> 
> ACK on this.
> 
> While I heartly welcome this addition, I see the centralization of the
> tag decision process as potentially dangerous; not for "power" reasons,
> but rather for the bad feelings (and related flamefests!) such changes
> can leave behind and for the potential bottleneck risks (nowadays FTP
> master is luckily and finally more stuffed than in the past, but
> tomorrow who knows?).
> 
> So, I revamp a proposal I made in a corner of this thread:
> 
>   Let the QA team decide upon the non overridable lintian errors.
> 
> Rationale: the QA mailing list is considered to be a rather good venue
> to discuss and reach consensus, also it is one of the places where
> lintian maintainers discuss various issues, and (trivially) QA is the
> supposed place where to enforce project-wide QA.
> (Full disclosure: yes, I'm currently an active QA member.)

I don't think that it's a good idea to give the reviewing power to the
QA team: QA team membership is loosely defined, and if we were to make
policy decisions, we would have to have a clear process to determine who
is empowered to take those decisions.

I'm fine with letting ftpmasters take that decision. However, they
should consult the project before adding new tags (mail to -devel: "We
are thinking of adding those new tags to our list, comments?" instead of
a mail to -devel saying "We just blocked the following tags"), and
listen to feedback. If someone feel that they made a mistake, it's
always possible to appeal to the TC.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: transitioning from a single to split package

[Neil McGovern]

On Sun, Nov 01, 2009 at 12:25:51PM +0100, Penny Leach wrote:
> The problem we've come across is how to handle migrations.  If we have a
> moodle package, that depends on moodle-mysql | moodle-pgsql, then package
> managers that just install the first dependency, could cause a situation,
> for example, where someone has configured their moodle installation to work
> on postgres, but the upgrade installs moodle-mysql, which is obviously a
> problem.   We could detect this case in preinst, and complain bitterly and
> refuse to install, but that's going to break upgrades, so is obviously a
> no-goer.
> 

Hi Penny,

I'm slightly confused about the need to depend. Are the
moodle-mysql/pgsql packages providing the support for the database
schemes in moodle, or utilising the dependency structure to pull in the
databases themselves (or both)?

I'm thinking specifically of the case when the database is on a remote
host, so the relevant db-connection libraries should be depended on, but
not the database itself.

Thanks,
Neil
-- 
 hermanr_: I never studied german
 I can just read some of it because it makes sense
 . o O ( There is stuff Ganneff writes, which makes sense? )


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

Re: Lintian based autorejects

[Brian May]

On Sun, Nov 01, 2009 at 02:22:28AM -0800, Steve Langasek wrote:
> I'd recommend that others do likewise, to get an appropriately large set of
> eyeballs on this change.

Question:

(apologies if this has already been addressed and I missed it)

I want to perform a NMU upload on a package, say to fix a security issue, or 
some
other major issue (as allowed by NMUs).

Unfortunately the package fails lintian checks required to perform an upload.

Since this is a NMU though, I am not suppose to make unrelated changes.

What do I do?

Can I fix these unrelated issues that prevent me uploading the package as well
as fixing the original issue?
-- 
Brian May 


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

Re: Bug#553760: replacing libreadline5-dev build dependency with libreadline-dev

[Vincent Danjean]

  Hi,

Manoj Srivastava wrote:
> There is not bug here. Perhaps the scripts or tests you use need
>  to be tightened?
> 
> The build dependency line reads (in part)
>  libreadline-dev | libreadline6-dev | libreadline5-dev,

  Just for record (I got the same 'bug' in one of my packages), I see that
libreadline5-dev in stable provides libreadline-dev.
  So, even with backport in mind, this build-depends can be reduced into
only libreadline-dev (but this would be a wishlist bug, not an important one)

> Closing the bug,  with no changes.

  I downgraded mine and it will be fixed in my next upload (but I'm not
doing one just for that)

  Regards,
Vincent

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial pacakges: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


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

Re: Lintian based autorejects

[Faidon Liambotis]

Lucas Nussbaum wrote:
> I'm fine with letting ftpmasters take that decision. However, they
> should consult the project before adding new tags (mail to -devel: "We
> are thinking of adding those new tags to our list, comments?" instead of
> a mail to -devel saying "We just blocked the following tags"), and
> listen to feedback. If someone feel that they made a mistake, it's
> always possible to appeal to the TC.
Is it?

By my interpretation, I don't think that the TC has any authority here
since the ftp-masters are DPL delegates and not individual maintainers.

Regards,
Faidon


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

Re: Lintian based autorejects

[Luk Claes]

Russ Allbery wrote:
> Luk Claes  writes:
> 
>> As before Manoj seems to interpret things and word things so they fit
>> the way he can use them at the moment he needs them. As long as that
>> continues I'm not going to even try to get the Debian Policy and RC bug
>> policy consistent and the Debian Policy will remain not useful for
>> anything release related as it will be incomplete and sometimes
>> conflicting with actual practice.
> 
> On behalf of the other four Policy maintainers who aren't Manoj and who so
> far as I know you don't have personal conflicts with, let me just say
> "gee, thanks."  This is how we can ensure that Policy continues not to be
> the document that it should be and people have to keep reading multiple
> documents to figure out what they're required to do.

Note that this predates me joining the Release Team, so I don't think
it's just a personal issue between Manoj and me...

> I have a limited amount of time to spend on Debian as a whole, which is
> divided between Lintian, Policy, and my own packages.  Reading things like
> the above is extremely demoralizing and both tends to reduce that overall
> time committment and the amount of time I'm willing to invest in Policy in
> particular.  If people are going to undercut or ignore that work, what's
> the point of me trying to fight upstream?

Exactly, I have only a limited amount of time and don't want to spend it
on demotivating discussions with Manoj about why he uses two standards.
Though just ignoring these is also of no help, so in general I just
point out when he does it (probably not in a very objective way due to
how hard it demotivates me to see people in such positions doing that).

For the actual matter at hand I think it's very wrong to do a MBF
without going through d-devel for several reasons:
- it gives developers a chance to fix bugs before they are filed to
decrease high bug traffic that is normal for MBFs
- it gives developers a chance to discuss the severity and tags that
should be used without the need to change them afterwards
- it gives developers a chance to change the preconditions for bugs
before they are filed
- it gives developers a chance to share ideas on how to fix the bugs and
include that information in the bug reports
- it gives developers a chance to update any relevant documentation
before the bugs are filed

Cheers

Luk

Cheers

Luk


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

Re: Cross compiler ITP (armel)

[Bernd Zeimetz]

Ben Hutchings wrote:

> You can disagree all you like, but I believe that the FTP team will
> currently reject any new packages that use source code from their build-
> dependencies.  It would likely be a waste of Hector's time to continue
> with this approach.

So if that is a problem - why not enhance the gcc packaging to build the
cross-compiler packages?

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


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

Re: Cross compiler ITP (armel)

[Matthias Klose]

On 02.11.2009 03:19, Ben Hutchings wrote:

On Mon, 2009-11-02 at 02:34 +0100, Matthias Klose wrote:

On 02.11.2009 00:00, Ben Hutchings wrote:

On Sun, 2009-11-01 at 23:14 +0100, Hector Oron wrote:

Hello,

I would like to do a little explanation on the ITP I have filled for
{linux,binutils,eglibc,gcc-4.3,gcc-4.4,gdb}-armel.

These set of packages provide a cross toolchain for armel targets to
be built on i386 and amd64 platforms (maybe ppc could be added)

In order to avoid code duplication in the archive, this packages
build depend on -source packages.

[...]

At present, there is nothing that will ensure that the binary packages
you build are released along with the packages containing their actual
source.  It would therefore require manual attention to ensure that we
meet the source distribution requirements of the GPL, which the FTP team
really hates having to do.

Until the FTP team implements a means of automatically recording some
build-dependencies and the versions actually used as additional source
dependencies, and ensuring that these source dependencies are satisfied
within each release, you should not use this approach.


I disagree. It's not worse than the current scheme splitting up GCC uploads into
three different source packages, forced by the release team.


You can disagree all you like, but I believe that the FTP team will
currently reject any new packages that use source code from their build-
dependencies.  It would likely be a waste of Hector's time to continue
with this approach.


You can believe all you like, but this is the approach which was communicated to 
the FTP team at Debconf, and didn't find resistance.



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

Bug#553942: ITP: libsexp-processor-ruby -- brings all the generic sexp processing tools to ruby

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 


* Package name: libsexp-processor-ruby
  Version : 3.0.3
  Upstream Author : Ryan Davis (Copyright (c) 2001-2007 Ryan Davis, Zen Spider 
Software)
* URL : http://rubyforge.org/projects/parsetree
* License : MIT
  Programming Lang: Ruby
  Description : brings all the generic sexp processing tools to ruby

sexp_processor branches from ParseTree bringing all the generic sexp
processing tools with it. Sexp, SexpProcessor, Environment, etc.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (999, 'stable'), (500, 'proposed-updates'), (100, 'testing'), (1, 
'unstable')
Architecture: i386 (i686)



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

Re: Bug#553936: FTBFS with binutils-gold

[Lucas Nussbaum]

Hi,

I thought people were supposed to discuss it on -devel@ before starting
a MBF?

Anyway, ways you could have made it better:
- provide a step by step guide to reproduce the problem
- use a usertag to follow all the bugs
- provide a link to a wiki page where you would have put more info about
  solving the common problems.

> Tried to build your package and it fails to build with GNU binutils-gold. The
> important difference is that --no-add-needed is the default behavior of of GNU
> binutils-gold. Please provide all needed libraries to the linker when building
> your executables.

Since this obviously breaks lots of packages, what about changing the
default in binutils-gold instead?
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: Bug#553936: FTBFS with binutils-gold

[Sune Vuorela]

On 2009-11-02, Lucas Nussbaum  wrote:
>
>> Tried to build your package and it fails to build with GNU binutils-gold. The
>> important difference is that --no-add-needed is the default behavior of of 
>> GNU
>> binutils-gold. Please provide all needed libraries to the linker when 
>> building
>> your executables.
>
> Since this obviously breaks lots of packages, what about changing the
> default in binutils-gold instead?

Binutils-gold is not the default. It is a bit 'stricter' in how it
works, but it is notably faster.

/Sune


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

Re: Cross compiler ITP (armel)

[Mike Hommey]

On Mon, Nov 02, 2009 at 12:25:16PM +0100, Bernd Zeimetz wrote:
> Ben Hutchings wrote:
> 
> > You can disagree all you like, but I believe that the FTP team will
> > currently reject any new packages that use source code from their build-
> > dependencies.  It would likely be a waste of Hector's time to continue
> > with this approach.
> 
> So if that is a problem - why not enhance the gcc packaging to build the
> cross-compiler packages?

Combinatorial explosion ?

Mike


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

Re: Bug#553936: FTBFS with binutils-gold

[Lucas Nussbaum]

On 02/11/09 at 12:12 +, Sune Vuorela wrote:
> On 2009-11-02, Lucas Nussbaum  wrote:
> >
> >> Tried to build your package and it fails to build with GNU binutils-gold. 
> >> The
> >> important difference is that --no-add-needed is the default behavior of of 
> >> GNU
> >> binutils-gold. Please provide all needed libraries to the linker when 
> >> building
> >> your executables.
> >
> > Since this obviously breaks lots of packages, what about changing the
> > default in binutils-gold instead?
> 
> Binutils-gold is not the default. It is a bit 'stricter' in how it
> works, but it is notably faster.

I was talking about not making --no-add-needed the default in
binutils-gold.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: Lintian based autorejects

[Matthew Johnson]

On Mon Nov 02 11:40, Luk Claes wrote:
> For the actual matter at hand I think it's very wrong to do a MBF
> without going through d-devel for several reasons:

> 

Otoh, this is a slightly special case, since they are things which are
causing the package to become non-uploadable. In this case the correct
place to have the discussion about the scope et al of the bugs is with
ftp-master about what constitutes rejection criteria; the bug filing is
purely a reflection of that.

I certainly don't think that having packages with an upload-critical bug
with no bug filed against them is a good idea

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Cross compiler ITP (armel)

[Hector Oron]

Hi,

2009/11/2 Mike Hommey :
> On Mon, Nov 02, 2009 at 12:25:16PM +0100, Bernd Zeimetz wrote:
>> So if that is a problem - why not enhance the gcc packaging to build the
>> cross-compiler packages?
>
> Combinatorial explosion ?

We took this approach, and we have been building this way.
Binutils, GCC, GDB, EGLIBC have cross built in capability, but some
tricks (relaying on dpkg-cross) must be done in order to build the
cross toolchain and Debian autobuilders do not know how to keep with
this. This is the reason we have been keeping the cross tools at
emdebian.org site.

Then relaying on -source packages approach was suggested by Matthias
and not entirely rejected by Ganeff when I talked to him about it. A
visualization of the build dependencies can be found at:
http://www.emdebian.org/~zumbi/docs/deps.pdf

There already packages in the archive build depending on -source, like
binutils-z80, which is not much different from binutils-armel
approach.

-- 
 Héctor Orón


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

Re: Cross compiler ITP (armel)

[Philipp Kern]

On 2009-11-02, Hector Oron  wrote:
> 2009/11/2 Mike Hommey :
>> On Mon, Nov 02, 2009 at 12:25:16PM +0100, Bernd Zeimetz wrote:
>>> So if that is a problem - why not enhance the gcc packaging to build the
>>> cross-compiler packages?
>> Combinatorial explosion ?
> We took this approach, and we have been building this way.
> Binutils, GCC, GDB, EGLIBC have cross built in capability, but some
> tricks (relaying on dpkg-cross) must be done in order to build the
> cross toolchain and Debian autobuilders do not know how to keep with
> this. This is the reason we have been keeping the cross tools at
> emdebian.org site.
>
> Then relaying on -source packages approach was suggested by Matthias
> and not entirely rejected by Ganeff when I talked to him about it. A
> visualization of the build dependencies can be found at:
> http://www.emdebian.org/~zumbi/docs/deps.pdf
>
> There already packages in the archive build depending on -source, like
> binutils-z80, which is not much different from binutils-armel
> approach.

Of course it is a sane approach but very special care needs to be taken when
releasing to ensure GPL compliance.  So what we should get is support in the
toolchain to declare against what source package the upload was built to
keep that around.

Kind regards,
Philipp Kern


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

Bug#553975: ITP: pgtune -- Optimize parameters in postgresql.conf file

[Rodolphe Quiédeville]

Package: wnpp
Severity: wishlist
Owner: "Rodolphe Quiédeville" 


* Package name: pgtune
  Version : 0.9.3
  Upstream Author : Greg Smith 
* URL : http://pgfoundry.org/projects/pgtune/
* License : BSD
  Programming Lang: Python
  Description : Optimize parameters in postgresql.conf file

pgtune takes the wimpy default postgresql.conf and expands the database server 
to be as powerful as the hardware it's being deployed on



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

Re: Bug#553936: FTBFS with binutils-gold

[Sune Vuorela]

On 2009-11-02, Lucas Nussbaum  wrote:
> On 02/11/09 at 12:12 +, Sune Vuorela wrote:
>> 
>> Binutils-gold is not the default. It is a bit 'stricter' in how it
>> works, but it is notably faster.

> I was talking about not making --no-add-needed the default in
> binutils-gold.

then you are effectively neutering gold.
thes is what I consider one of the features of gold, and it is also one
ef the ways it is faster (by not traversing the depndencies of the
libraries to see if they are needed)

the major difference is:
your app uses both libfoo and libbar. libbar uses libfoo.  with ld, it
is sufficient to do -lbar, and with gold you need -lfoo -lbar.
in both cases, your app will have NEEDED entries for both libfoo and
libbar.

/Sune


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

Re: Lintian based autorejects

[Luk Claes]

Matthew Johnson wrote:
> On Mon Nov 02 11:40, Luk Claes wrote:
>> For the actual matter at hand I think it's very wrong to do a MBF
>> without going through d-devel for several reasons:
> 
>> 
> 
> Otoh, this is a slightly special case, since they are things which are
> causing the package to become non-uploadable. In this case the correct
> place to have the discussion about the scope et al of the bugs is with
> ftp-master about what constitutes rejection criteria; the bug filing is
> purely a reflection of that.

Right, though filing bugs already is ignoring that step completely.

> I certainly don't think that having packages with an upload-critical bug
> with no bug filed against them is a good idea

I'm not saying that bugs should not be filed, though the content and
meta information of bugs can be very much improved by discussing before
filing them.

Cheers

Luk


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

Re: Bug#553936: FTBFS with binutils-gold

[Peter Fritzsche]

Lucas Nussbaum wrote:
> I thought people were supposed to discuss it on -devel@ before starting
> a MBF?
What is a MBF?

> Anyway, ways you could have made it better:
> - provide a step by step guide to reproduce the problem
> - use a usertag to follow all the bugs
> - provide a link to a wiki page where you would have put more info about
>   solving the common problems.
> 
> > Tried to build your package and it fails to build with GNU binutils-gold.
> > The important difference is that --no-add-needed is the default behavior
> > of of GNU binutils-gold. Please provide all needed libraries to the
> > linker when building your executables.
> 
> Since this obviously breaks lots of packages, what about changing the
> default in binutils-gold instead?
I am not sure but do you think that it is a good way to link against a library 
without specify that you link against it?

What I am currently testing is if there are crashes/segfaults possible when 
linking with binutils-gold. But it seems that many packages doesn't create 
problems for binutils-gold, but fail to build because they rely on the fact 
that other libraries link against the libraries. So when they stop to link 
against them the build of the "unrelated" executable would break (as it  
breaks right now with --no-add-needed or binutils-gold).

So things I could do is: ignore the fact that they don't specify the libraries 
which must be linked to work and wait until binutils-gold replaces old ld/old 
ld switches to more sane default/third party library stops to link against the 
needed library - or report the problem and let the maintainer decide what to 
do.

I choose the latter one because I think that most maintainers don't know about 
the problems.

Best regards,
Peter


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

Re: /var/www is depracated, which directory to use?

[Stig Sandbeck Mathisen]

Manoj Srivastava  writes:

> As I mentioned on IRC, look at trac. The trick is put configuration
> files in /etc/munin/, and symlink it back into /var/lib/munin if munin
> needs that.

All munin needs is a place to write static html and png files.

* /var/lib/munin is already used as top level for munin's data files.
  If we add a web root there, it may cause collisions.

* /var/cache may not be the best place, since FHS says that data here
  can be deleted with little consequence, and the generated web pages
  will be gone until the next time munin-graph and munin-html runs.

One could ask via debconf, and suggest /var/www/munin as a default,
would that be acceptable?

-- 
Stig Sandbeck Mathisen


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

Re: /var/www is depracated, which directory to use?

[Mike Hommey]

On Mon, Nov 02, 2009 at 01:30:37PM +0100, Stig Sandbeck Mathisen wrote:
> Manoj Srivastava  writes:
> 
> > As I mentioned on IRC, look at trac. The trick is put configuration
> > files in /etc/munin/, and symlink it back into /var/lib/munin if munin
> > needs that.
> 
> All munin needs is a place to write static html and png files.
> 
> * /var/lib/munin is already used as top level for munin's data files.
>   If we add a web root there, it may cause collisions.
> 
> * /var/cache may not be the best place, since FHS says that data here
>   can be deleted with little consequence, and the generated web pages
>   will be gone until the next time munin-graph and munin-html runs.

* /usr/share/munin.


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

Unidentified subject!

[anthony berger]

Re: /var/www is depracated, which directory to use?

[Tom Feiner]

On Mon, Nov 2, 2009 at 2:30 PM, Stig Sandbeck Mathisen 
wrote:
> All munin needs is a place to write static html and png files.
>
> * /var/lib/munin is already used as top level for munin's data files.
>  If we add a web root there, it may cause collisions.
>

Right.

> * /var/cache may not be the best place, since FHS says that data here
>  can be deleted with little consequence, and the generated web pages
>  will be gone until the next time munin-graph and munin-html runs.

Is /var/cache really such a bad option? I mean, the entire web content
is re-generated from templates & graphs are re-generated from the rrd
databases every 5 minutes. So even if someone did delete the directory,
it'll just be recreated up to 5 minutes later.

>
> One could ask via debconf, and suggest /var/www/munin as a default,
> would that be acceptable?

Users might not know a good answer such a question and will probably
just stick with the defaults, so suggesting /var/www/munin will just
keep the current non FHS complaint status quo.

Regards,
   Tom Feiner




signature.asc
Description: OpenPGP digital signature

Re: /var/www is depracated, which directory to use?

[Mike Hommey]

On Mon, Nov 02, 2009 at 02:27:16PM +0100, Mike Hommey wrote:
> On Mon, Nov 02, 2009 at 01:30:37PM +0100, Stig Sandbeck Mathisen wrote:
> > Manoj Srivastava  writes:
> > 
> > > As I mentioned on IRC, look at trac. The trick is put configuration
> > > files in /etc/munin/, and symlink it back into /var/lib/munin if munin
> > > needs that.
> > 
> > All munin needs is a place to write static html and png files.
> > 
> > * /var/lib/munin is already used as top level for munin's data files.
> >   If we add a web root there, it may cause collisions.
> > 
> > * /var/cache may not be the best place, since FHS says that data here
> >   can be deleted with little consequence, and the generated web pages
> >   will be gone until the next time munin-graph and munin-html runs.
> 
> * /usr/share/munin.

Forget it, i though it was for really static data, i.e. within the
package.

Mike


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

sync installer-i386

[anthony berger]

Re: Bug#553936: FTBFS with binutils-gold

[Lucas Nussbaum]

On 02/11/09 at 13:50 +0100, Peter Fritzsche wrote:
> Lucas Nussbaum wrote:
> > I thought people were supposed to discuss it on -devel@ before starting
> > a MBF?
> What is a MBF?

mass bug filing.

> > Anyway, ways you could have made it better:
> > - provide a step by step guide to reproduce the problem
> > - use a usertag to follow all the bugs
> > - provide a link to a wiki page where you would have put more info about
> >   solving the common problems.
> > 
> > > Tried to build your package and it fails to build with GNU binutils-gold.
> > > The important difference is that --no-add-needed is the default behavior
> > > of of GNU binutils-gold. Please provide all needed libraries to the
> > > linker when building your executables.
> > 
> > Since this obviously breaks lots of packages, what about changing the
> > default in binutils-gold instead?
> I am not sure but do you think that it is a good way to link against a 
> library 
> without specify that you link against it?

The question is not about what I think. The question is whether it's
reasonable to expect A LOT of packages to be modified to accomodate
this.

> What I am currently testing is if there are crashes/segfaults possible when 
> linking with binutils-gold. But it seems that many packages doesn't create 
> problems for binutils-gold, but fail to build because they rely on the fact 
> that other libraries link against the libraries. So when they stop to link 
> against them the build of the "unrelated" executable would break (as it  
> breaks right now with --no-add-needed or binutils-gold).
> 
> So things I could do is: ignore the fact that they don't specify the 
> libraries 
> which must be linked to work and wait until binutils-gold replaces old ld/old 
> ld switches to more sane default/third party library stops to link against 
> the 
> needed library - or report the problem and let the maintainer decide what to 
> do.
> 
> I choose the latter one because I think that most maintainers don't know 
> about 
> the problems.

Could you provide some numbers on the:
- packages that FTBFS with binutils-gold
- packages that FTBFS with binutils-gold because of --no-add-needed by
  default
  ?
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: /var/www is depracated, which directory to use?

[Stig Sandbeck Mathisen]

Tom Feiner  writes:

> Is /var/cache really such a bad option? I mean, the entire web content
> is re-generated from templates & graphs are re-generated from the rrd
> databases every 5 minutes. So even if someone did delete the
> directory, it'll just be recreated up to 5 minutes later.

Apart from "it feels wrong", no.

>> One could ask via debconf, and suggest /var/www/munin as a default,
>> would that be acceptable?
>
> Users might not know a good answer such a question and will probably
> just stick with the defaults, so suggesting /var/www/munin will just
> keep the current non FHS complaint status quo.

Ok, debconf question with /var/cache/munin/html as default, then.  The
admin then have the option to use /srv/foo/whatever or /var/www/munin.

By debconf, we have a path which we'll add to /etc/munin/munin.conf, and
to the web server configuration snippets.

Should the web configuration be enabled by default?  Assume apache2, and
add configuration to /etc/apache2/conf.d/munin.conf?

-- 
Stig Sandbeck Mathisen


pgpSv2ogmer7z.pgp
Description: PGP signature

Re: /var/www is depracated, which directory to use?

[Stig Sandbeck Mathisen]

Mike Hommey  writes:

> * /usr/share/munin.

Would not work well for variable data, I think.  The graphs and HTML is
updated every 5 minutes.

-- 
Stig Sandbeck Mathisen


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

Re: /var/www is depracated, which directory to use?

[Neil McGovern]

On Mon, Nov 02, 2009 at 02:48:56PM +0100, Stig Sandbeck Mathisen wrote:
> Should the web configuration be enabled by default?  Assume apache2, and
> add configuration to /etc/apache2/conf.d/munin.conf?
> 

Have a read of
http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html

Neil
-- 
automake: the emo of Debian software. "You just don't understand me."


signature.asc
Description: Digital signature

Re: /var/www is depracated, which directory to use?

[Tom Feiner]

On Mon, Nov 2, 2009 at 3:48 PM, Stig Sandbeck Mathisen 
wrote:
> Tom Feiner  writes:
>
>> Is /var/cache really such a bad option? I mean, the entire web content
>> is re-generated from templates & graphs are re-generated from the rrd
>> databases every 5 minutes. So even if someone did delete the
>> directory, it'll just be recreated up to 5 minutes later.
>
> Apart from "it feels wrong", no.

Hm... it does feel a bit wrong, but do we have any other sensible
choice? Adding /var/lib/munin-www/ is also an option, but it feels just
as bad as /var/cache :)

>
>>> One could ask via debconf, and suggest /var/www/munin as a default,
>>> would that be acceptable?
>>
>> Users might not know a good answer such a question and will probably
>> just stick with the defaults, so suggesting /var/www/munin will just
>> keep the current non FHS complaint status quo.
>
> Ok, debconf question with /var/cache/munin/html as default, then.  The
> admin then have the option to use /srv/foo/whatever or /var/www/munin.
>
> By debconf, we have a path which we'll add to /etc/munin/munin.conf, and
> to the web server configuration snippets.

Sorry for the newbie question (I'm not that familiar with debconf). Will
debconf be able to manage upgrade from current munin version? Changing
the current 'htmldir /var/www/munin' to the new user specified one?

>
> Should the web configuration be enabled by default?  Assume apache2, and
> add configuration to /etc/apache2/conf.d/munin.conf?
>

In phpmyadmin package they raise a debconf question, asking which web
server the user wants to configure phpmyadmin to run under (and they
give apache2,lighttpd options), maybe we can do the same in munin?

Can you help me implement this for the munin 1.4~svn release for debian
experimental?

Thanks,
Tom Feiner



signature.asc
Description: OpenPGP digital signature

Re: Bug#553936: FTBFS with binutils-gold

[Lucas Nussbaum]

On 02/11/09 at 15:04 +0100, Peter Fritzsche wrote:
> About the usertags? Is there a special format in which they should be? And a 
> maintainer asked for a wiki entry at 
> http://wiki.debian.org/qa.debian.org/FTBFS but I am not allowed to change 
> that 
> patch - and I am sure that I shouldn't be allowed to edit it.

You probably just need a wiki account.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: Bug#553936: FTBFS with binutils-gold

[Peter Samuelson]

[Sune Vuorela]
> the major difference is:
> your app uses both libfoo and libbar. libbar uses libfoo.  with ld, it
> is sufficient to do -lbar, and with gold you need -lfoo -lbar.
> in both cases, your app will have NEEDED entries for both libfoo and
> libbar.

If you want symbol versioning to work properly (assuming libfoo has
versioned symbols), you need to specify -lfoo -lbar regardless.  Been
there, didn't do that, got the segfaults.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

Re: Bug#553936: FTBFS with binutils-gold

[Peter Fritzsche]

Lucas Nussbaum wrote:
> > What is a MBF?
> 
> mass bug filing.
thanks

> > I am not sure but do you think that it is a good way to link against a
> > library without specify that you link against it?
> 
> The question is not about what I think. The question is whether it's
> reasonable to expect A LOT of packages to be modified to accomodate
> this.

This is way it is currently not marked as serious. It doesn't affect the 
release of the next debian version, but all these things could break in the 
future. I am willing to gather more informations in the wiki but currently 
don't know how.


> Could you provide some numbers on the:
> - packages that FTBFS with binutils-gold
> - packages that FTBFS with binutils-gold because of --no-add-needed by
>   default
>   ?

I have only build some packages. I have currently following numbers:

50 Packages break
555 Packages work (without arch all)

As you can see I have only data for about 7% of all packages so I cannot make 
a real forecast how many packages are real affected. If you want to 
extrapolate the data (real bad extrapolation) about 700 packages of around 
14000 source packages in Debian would break. I am currently hoping that they 
are less than that. Some packages in the statistics seems to be also broken 
with the current ld - avifile seems to be one of them. The author is currently 
waiting for a sponsor to fix that problem.

To illustrate the problem:
 exe -> liba -> libb

exe gets linked against liba, but actual need symbols from libb. It works in 
the case of the old GNU ld because it loads all libraries in that dependency 
graph until it finds the symbols. This seems to be ok unless liba gets 
modified and doesn't link anymore against libb. In this case the compilation 
stops during the linker run.

Keep in mind that these bugs aren't release critical, but the maintainer and 
upstream should know about these problems. Maybe I could reduce the problem of 
all bugs to minor.

About the usertags? Is there a special format in which they should be? And a 
maintainer asked for a wiki entry at 
http://wiki.debian.org/qa.debian.org/FTBFS but I am not allowed to change that 
patch - and I am sure that I shouldn't be allowed to edit it.

Best regards,
Peter


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

Re: Bug#553936: FTBFS with binutils-gold

[Peter Fritzsche]

Lucas Nussbaum wrote:
> On 02/11/09 at 15:04 +0100, Peter Fritzsche wrote:
> > About the usertags? Is there a special format in which they should be?
> > And a maintainer asked for a wiki entry at
> > http://wiki.debian.org/qa.debian.org/FTBFS but I am not allowed to change
> > that patch - and I am sure that I shouldn't be allowed to edit it.
> 
> You probably just need a wiki account.
Thanks for the info. A draft entry can be found at 
http://wiki.debian.org/qa.debian.org/FTBFS#A2009-11-02Packagesfailingbecausebinutils-gold.2BAC8-indirectlinking


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

Re: /var/www is depracated, which directory to use?

[Stig Sandbeck Mathisen]

Neil McGovern  writes:

> Have a read of
> http://webapps-common.alioth.debian.org/draft/html/ch-httpd.html

Useful, thanks. :)

-- 
Stig Sandbeck Mathisen


pgph88QZYVl0o.pgp
Description: PGP signature

Re: /var/www is depracated, which directory to use?

[Stig Sandbeck Mathisen]

Tom Feiner  writes:

> Sorry for the newbie question (I'm not that familiar with debconf).
> Will debconf be able to manage upgrade from current munin version?
> Changing the current 'htmldir /var/www/munin' to the new user
> specified one?

Debconf asks questions and stores them.  However, with the power of sed,
you can do anything. :)

> In phpmyadmin package they raise a debconf question, asking which web
> server the user wants to configure phpmyadmin to run under (and they
> give apache2,lighttpd options), maybe we can do the same in munin?
>
> Can you help me implement this for the munin 1.4~svn release for
> debian experimental?

Yes, I'll start looking at it tomorrow.

-- 
Stig Sandbeck Mathisen


pgprJ1xxt1YEf.pgp
Description: PGP signature

Re: Should I close and old RC bug?

[Rafal Czlonka]

Steve Langasek wrote:
> Where did you see this bug appearing as "RC"?  It's closed now, but it
> should not have shown up on any list of bugs that are release-critical for
> squeeze, since the package is not in squeeze.

Sorry, that's my fault. I've been searching for Release Critical bugs
using the website.
Naturally I've searched for bugs with severity "critical".
That old bug appeared in the results since it hasn't been closed.
I've used a mental shortcut and used Release Critical (RC) instead
of critical hence the mix-up.

Cheers,
-- 
Raf


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

Re: Lintian based autorejects

[Manoj Srivastava]

On Mon, Nov 02 2009, Luk Claes wrote:


> Exactly, I have only a limited amount of time and don't want to spend it
> on demotivating discussions with Manoj about why he uses two standards.
> Though just ignoring these is also of no help, so in general I just
> point out when he does it (probably not in a very objective way due to
> how hard it demotivates me to see people in such positions doing that).

If you could actually point out which two standards I am using,
 it could be somewhat useful. But in this case you were factually
 incorrect, in others you jump to conclusions and ascribe motivations to
 me that you make out of whole cloth,  and none of that is even remotely
 helpful. 

> For the actual matter at hand I think it's very wrong to do a MBF
> without going through d-devel for several reasons:
> - it gives developers a chance to fix bugs before they are filed to
> decrease high bug traffic that is normal for MBFs

The same developers who have been ignoring lintian telling them
 that their packages are buggy for ages? 

> - it gives developers a chance to discuss the severity and tags that
> should be used without the need to change them afterwards

There are standard definitions for tags for bugs that are
 violations of must directives in policy (look at policy and bugs.d.o),
 as well as packages determined too buggy to be in the archive by folks
 to are in charge of what goes in the archive.

Any opinion contrary to that would not likely have changed my
 set of bug filings at all.

> - it gives developers a chance to change the preconditions for bugs
>   before they are filed

Why was this not done long ago, when lintian has been screaming
 its little head off?

> - it gives developers a chance to share ideas on how to fix the bugs and
>   include that information in the bug reports

They can do so now. It is not as if these bugs did not have a
 user tag.

> - it gives developers a chance to update any relevant documentation
>   before the bugs are filed

Why had this not been done when lintian was warning them about
 these errors, then?

   manoj
-- 
Trespassers will be violated!
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: /lib32 -> emul/ia32-linux/lib ?

[Goswin von Brederlow]

Philipp Matthias Hahn  writes:

> Hello,
>
> I'm running "Debian sid" on "x86_64" and tried to build a "google-earth"
> package today, which failed with
>   dpkg-shlibdeps: error: no dependency information found for 
> /emul/ia32-linux/lib/libm.so.6 (used by ../usr/lib/googleearth/liblayer.so).
>
> After some investigation into bi-arch and multi-arch I discovered that I
> have the following directory structure:
>   /emul/ia32-linux/lib
>   /emul/ia32-linux/usr/lib
>   /lib
>   /lib32 -> emul/ia32-linux/lib
>   /lib64 -> lib
>   /usr/lib
>   /usr/lib32
>   /usr/lib64 -> lib
>
> Looking at "/var/lib/dpkg/info/libc6-i386.preinst" I found the following
> fishy line:
>   if [ "$(readlink /lib32)" = "/emul/ia32-linux/lib" ]; then
>^ notice that my symlink does not
>have the leading slash!
>   rm /lib32
>
> Since I don't remeber ever creating that symlink myself and also found
> no definite answer to my question on how a "right" directory layout
> should look like, I'd like to ask first before filing a possible bug on
> "libc6-i386" because of that to restrictive test.
>
> Sincerely
> Philipp Hahn

The expected layout in squeeze/sid is (at least it is here)

/lib
/lib32
/lib64 -> /lib
/usr/lib
/usr/lib32
/usr/lib64 -> lib

I don't understand why your links are different but libc6-i386 should
really cope with that. So go ahead and file a bug.

As for fixing it you need to remove the link and reinstall every
package that has files in /lib32. Then check if any package has files
left in /emul/ia32-linux/ and update/remove them before removing what
remains of /emul/ia32-linux/.

MfG
Goswin


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

Re: /var/www is depracated, which directory to use?

[sean finney]

hi stig,

On Mon, Nov 02, 2009 at 02:48:56PM +0100, Stig Sandbeck Mathisen wrote:
> Tom Feiner  writes:
> 
> > Is /var/cache really such a bad option? I mean, the entire web content
> > is re-generated from templates & graphs are re-generated from the rrd
> > databases every 5 minutes. So even if someone did delete the
> > directory, it'll just be recreated up to 5 minutes later.
> 
> Apart from "it feels wrong", no.

if it can be regenerated, then /var/cache/munin/html is exactly where it
should be.  only if there are actual things that can't be regenerated (i.e.
rrd files with historical data not put elsewhere) should it go under /var/lib.

with regards to the use of the top-level munin directory in /var/lib/munin,
you could fix that with some migration support in maintainer scripts (or just
chose another similarly named subdirectory under /var/lib), but it seems
like it's a non issue if /var/cache is the right place anyway.


mvh,
sean


signature.asc
Description: Digital signature

Re: Cross compiler ITP (armel)

[Goswin von Brederlow]

Ben Hutchings  writes:

> On Sun, 2009-11-01 at 23:14 +0100, Hector Oron wrote:
>> Hello,
>> 
>>   I would like to do a little explanation on the ITP I have filled for
>> {linux,binutils,eglibc,gcc-4.3,gcc-4.4,gdb}-armel.
>> 
>>   These set of packages provide a cross toolchain for armel targets to
>> be built on i386 and amd64 platforms (maybe ppc could be added)
>> 
>>   In order to avoid code duplication in the archive, this packages
>> build depend on -source packages.
> [...]
>
> At present, there is nothing that will ensure that the binary packages
> you build are released along with the packages containing their actual
> source.  It would therefore require manual attention to ensure that we
> meet the source distribution requirements of the GPL, which the FTP team
> really hates having to do.
>
> Until the FTP team implements a means of automatically recording some
> build-dependencies and the versions actually used as additional source
> dependencies, and ensuring that these source dependencies are satisfied
> within each release, you should not use this approach.
>
> Ben.
>
> -- 
> Ben Hutchings
> The generation of random numbers is too important to be left to chance.
> - Robert Coveyou

If gcc maintainers agree include a dummy gcc-source-armel package with
Depends: gcc-source (= 1.2-3). That way the cross build package will
require the right source. It ensures they always enter/leave testing
as a pair.

MfG
Goswin



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

Re: Cross compiler ITP (armel)

[Goswin von Brederlow]

Hector Oron  writes:

> Hello,
>
>   I would like to do a little explanation on the ITP I have filled for
> {linux,binutils,eglibc,gcc-4.3,gcc-4.4,gdb}-armel.
>
>   These set of packages provide a cross toolchain for armel targets to
> be built on i386 and amd64 platforms (maybe ppc could be added)
>
>   In order to avoid code duplication in the archive, this packages
> build depend on -source packages.
>
>   As major technical issues,  I would try to build cross compilers
> with --sysroot support, but that means dpkg-cross need to be updated
> for sysroot paths. For now, we might take the road we have been doing
> at emdebian.org (for many years) and start changing bits towards a
> nice sysrooted solution.
>
>   Please, let me know if you need farther explanations on some topics
> or if you have any comment.
>
> Kind regards,

Why do you need --sysroot support? Or what prevents a --sysroot of /
when using the multiarch directories?

It seems like wasted work with multiarch being a release goal for
squeeze. Hop on the wagon and make it work for you too.

MfG
Goswin


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

Re: /lib32 -> emul/ia32-linux/lib ?

[Neil Williams]

On Mon, 02 Nov 2009 16:33:07 +0100
Goswin von Brederlow  wrote:

> The expected layout in squeeze/sid is (at least it is here)
> 
> /lib
> /lib32
> /lib64 -> /lib

That should be:
/lib64 -> lib

(or to be clearer: ./lib64 -> ./lib )

Having a link to /lib causes problems with debootstrap, cdebootstrap
and others. See #553599

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgp28LpP1SR65.pgp
Description: PGP signature

Re: Lintian based autorejects

[Russ Allbery]

Stefano Zacchiroli  writes:

> I was splitting the issues in two sub-issues actually: (1) being sure
> that lintian "E:" messages are only those coming from violated "must"
> requirements, (2) deciding which among them are upload blockers.

> I confess I was pretty much assuming that lintian maintainers ensure (1)
> is always verified.  Beside bugs in lintian that can always, I now
> realize that (1) is probably not so strict. For instance, for OCaml
> packages we do have custom lintian checks that do not appear in policy,
> but rather in our own packaging policy, but which we do want to be
> "E:". Surely we do not want those to be upload blockers.

Right.  Lintian E: tags are not now and never have been only Policy must
directives.  They correspond to tags that, were one to file a bug about
them, would be either severity serious or higher or severity important
with a certainty of possible or higher.  This includes things that aren't
in Policy at all but that denote broken packages, Policy should directives
that are easy to fix, misuses of tools according to the documentation of
that tool that aren't mentioned in Policy at all, and a few other things.

> All in all, your requirement can be probably be implemented by setting
> the general rule that all upload blockers should match violated "must"
> requirements, no matter who is in charge of defining the list.

I do think it's reasonable to not allow people to upload packages with
obvious and easily-correctable errors even if they're not must directives,
although I suppose we could implement that by upgrading all such errors
to must in Policy.

-- 
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

Re: Lintian based autorejects

[Russ Allbery]

Luk Claes  writes:

> Exactly, I have only a limited amount of time and don't want to spend it
> on demotivating discussions with Manoj about why he uses two standards.

I really think the best solution to this is to stop having demotivating
discussions with Manoj, particularly in this case where I'm not seeing
where he's doing any significant harm even if you completely disagree with
the bugs he's filing and the severity at which he's filing them.  It's not
that hard to downgrade severity if the project doesn't agree with the
initial bug severity.

We're all human, which means that some of us are just not going to get
along with others of us.  There will be clashes in communication style, in
opinions about how to approach a problem, and in aggressiveness about
things like filing bugs.  There is usually some better way to deal with it
than get into a long, demotivating argument.

A lot of things I get upset about initially I sit on for a day or two and
usually they look like less of a big deal after that.  For things that
don't feel that way, this is one of the reasons why teams like Policy have
multiple members.  Please always feel free to approach me if you don't
want to approach another team member, and likewise feel free to approach
Manoj if I'm making you upset for some reason.  We all work together
fairly well and can generally serve as go-betweens and help with the
discussion in those cases.

-- 
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

Re: Cross compiler ITP (armel)

[Mark Hymers]

On Mon, 02, Nov, 2009 at 12:43:42PM +, Philipp Kern spoke thus..
> Of course it is a sane approach but very special care needs to be taken when
> releasing to ensure GPL compliance.  So what we should get is support in the
> toolchain to declare against what source package the upload was built to
> keep that around.

We haven't implemented that yet for the archive software but it's on the
TODO list (and not that difficult).  None of us have had time to do the
d-d-a post from the ftpteam meeting yet, but I'll make sure information
is in there about it.

I'm hoping to the archive-side support done in the next week or so.

Cheers,

Mark

-- 
Mark Hymers 

"Oh, this is John Reid who is 'Cabinet Bruiser' which just means that he's
 a bit squat, ugly and unpleasant and therefore gets to be called a 'Bruiser'."
 Jeremy Hardy, The News Quiz


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

Re: /lib32 -> emul/ia32-linux/lib ?

[Vincent Danjean]

Neil Williams wrote:
> On Mon, 02 Nov 2009 16:33:07 +0100
> Goswin von Brederlow  wrote:
> 
>> The expected layout in squeeze/sid is (at least it is here)
>>
>> /lib
>> /lib32
>> /lib64 -> /lib
> 
> That should be:
> /lib64 -> lib

On my system (amd64), this is currently /lib64 -> /lib
Which package manages this symlink ?

> Having a link to /lib causes problems with debootstrap, cdebootstrap
> and others. See #553599

-- 
Vincent Danjean   GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A  8A94 0BF7 7867 9D02 5E87
Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://perso.debian.org/~vdanjean/debian unstable main


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

Re: usplash-theme-debian uploaded to sid

[The Fungi]

On Sun, Oct 25, 2009 at 06:31:43AM +0100, Andreas Rottmann wrote:
> FWIW, my 24" LCD has 1920x1080 (16:9 HD).

In fact, more and more computers these days are being connected to
digital inputs on HDTVs which only grok a limited number of ATSC
video modes. For example, my Sony HDTV's HDMI inputs support only
1920x1080, 1280x720 and 640x480 (though it claims 720x480 as well
via EDID, it trims the sides and pillarboxes the resulting image,
apparently assuming 480 scanlines always means 4:3 aspect ratio).

So in addition to 1920x1080 I would also suggest 1280x720, since
that's closest to my TV's LCD panel's native resolution and what I
will be booting at via KMS (using manual resolution selection in the
kernel as of 2.6.32).
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }


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

Re: /lib32 -> emul/ia32-linux/lib ?

[Neil Williams]

On Mon, 02 Nov 2009 18:11:42 +0100
Vincent Danjean  wrote:

> Neil Williams wrote:
> >> /lib64 -> /lib
> > 
> > That should be:
> > /lib64 -> lib
> 
> On my system (amd64), this is currently /lib64 -> /lib
> Which package manages this symlink ?

libc6

> > Having a link to /lib causes problems with debootstrap, cdebootstrap
> > and others. See #553599

See also the other bugs from which 553599 was cloned.

#514015 and #514016 - both RC.

"Packages with absolute symlinks to dirs like libc6 on amd64, ppc64 and
s390x can lead to overwrites of files outside of the new root."

Any process that uses tar against /PATH/TO/CHROOT/lib64 will end up
putting files into /lib:

"If one package (lib6) contains the symlink /lib64 -> /lib, another
package (in this case libattr1) which includes files in /lib64, will
be extracted into the host system and overwrite files there, as tar
follows the symlinks."
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553599#12


-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpVCvws1b0Fc.pgp
Description: PGP signature

Bug#554033: ITP: luajit -- Just in time compiler for Lua 5.1

[Enrico Tassi]

Package: wnpp
Severity: wishlist
Owner: Enrico Tassi 


* Package name: luajit
  Version : 2.0.0beta1
  Upstream Author : Mike Pall 
* URL : http://luajit.org
* License : MIT/X
  Programming Lang: C, ASM, Lua
  Description : Just in time compiler for Lua 5.1



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

Re: /var/www is depracated, which directory to use?

[Stephen Gran]

This one time, at band camp, Tom Feiner said:
> On Mon, Nov 2, 2009 at 3:48 PM, Stig Sandbeck Mathisen 
> wrote:
> > Tom Feiner  writes:
> >
> >> Is /var/cache really such a bad option? I mean, the entire web content
> >> is re-generated from templates & graphs are re-generated from the rrd
> >> databases every 5 minutes. So even if someone did delete the
> >> directory, it'll just be recreated up to 5 minutes later.
> >
> > Apart from "it feels wrong", no.
> 
> Hm... it does feel a bit wrong, but do we have any other sensible
> choice? Adding /var/lib/munin-www/ is also an option, but it feels just
> as bad as /var/cache :)

/var/lib is much worse than /var/cache for this.  I don't really see an
objection to /var/cache, even aesthetically.  It's not like the admin
can't change it later if they don't like it.

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


signature.asc
Description: Digital signature

Re: transitioning from a single to split package

[gregor herrmann]

On Mon, 02 Nov 2009 07:15:35 +0100, Penny Leach wrote:

> Well, that's logically equivalent to installing multiple versions of the
> same package.  At the moment,  there's one moodle installation, which has
> code that lives in /usr/share/moodle, and connects to one database.   This
> is determined by its one config file.  You can do tricks in the config file
> to fool Moodle into connecting to different databases, based on some rule
> (like virtualhost), but I don't see the use case here, 

Having several separate moodle instances on one machine seems like a
normal use case to me.

> and I don't think
> any other web applications support being installed multiple times, do they?

wordpress for example allows "multiple blog" setups.

mediawiki can at least be tricked into it, and I remember a host with
one mediawiki instance using postgres and two or three others mysql.


Cheers,
gregor
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-NP: Funny van Dannen: Eurythmieschuhe


signature.asc
Description: Digital signature

ITP: ofono-phonesim -- Modem emulator used by the oFono mobile telephony stack

[Andres Salomon]

Package: wnpp
Owner: Andres Salomon 
Severity: wishlist

* Package name: ofono-phonesim
  Version : 1.0
  Upstream Author : various
* URL : http://www.ofono.org/
* License : GPL 2
  Programming Lang: C, C++
  Description : Modem emulator used by the oFono mobile telephony stack

oFono is a stack for mobile telephony devices on Linux.  oFono supports
speaking to telephony devices through specific drivers, or with generic
AT commands.
.
Phonesim is a modem emulator that oFono uses for development and testing.
This allows oFono to be used by any host without requiring special GSM
(or other) hardware.


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

CTTE deciding technical policy [Re: Lintian based autorejects]

[Don Armstrong]

On Mon, 02 Nov 2009, Faidon Liambotis wrote:
> By my interpretation, I don't think that the TC has any authority
> here since the ftp-masters are DPL delegates and not individual
> maintainers.

The intersection of §5.1.1 (DPL delegation) and §6.1.1 (CTTE decides
technical policy) is kind of uncharted, but assuming that this
decision is a matter of technical policy, §6.1.1 seems to apply
directly, even if the decision has been delegated. [Though the CTTE
probably needs 3:1 if §6.1.4 (overriding DD needs 3:1) applies.]

That said, see Kurt Roeckx's response[1] to me[2] when this was last
raised.


Don Armstrong

1: http://lists.debian.org/debian-ctte/2009/09/msg00012.html
2: http://lists.debian.org/debian-ctte/2009/09/msg00010.html
-- 
It is easier to build strong children than to repair broken men.
 -- Frederick Douglass

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

Re: /lib32 -> emul/ia32-linux/lib ?

[Goswin von Brederlow]

Neil Williams  writes:

> On Mon, 02 Nov 2009 18:11:42 +0100
> Vincent Danjean  wrote:
>
>> Neil Williams wrote:
>> >> /lib64 -> /lib
>> > 
>> > That should be:
>> > /lib64 -> lib
>> 
>> On my system (amd64), this is currently /lib64 -> /lib
>> Which package manages this symlink ?
>
> libc6
>
>> > Having a link to /lib causes problems with debootstrap, cdebootstrap
>> > and others. See #553599
>
> See also the other bugs from which 553599 was cloned.
>
> #514015 and #514016 - both RC.
>
> "Packages with absolute symlinks to dirs like libc6 on amd64, ppc64 and
> s390x can lead to overwrites of files outside of the new root."
>
> Any process that uses tar against /PATH/TO/CHROOT/lib64 will end up
> putting files into /lib:
>
> "If one package (lib6) contains the symlink /lib64 -> /lib, another
> package (in this case libattr1) which includes files in /lib64, will
> be extracted into the host system and overwrite files there, as tar
> follows the symlinks."
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553599#12

Maybe policy should be changed to allow only relative symlinks.

I've been bitten by this many many times. Not as bad as tar extracting
to / instead /chroot but try "file /chroot/lib64/libfoo.so" and
similar.

MfG
Goswin


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

Bug#554048: ITP: python-mhash -- Python bindings for libmhash

[Soren Hansen]

Package: wnpp
Severity: wishlist
Owner: Soren Hansen 


* Package name: python-mhash
  Version : 1.4
  Upstream Author : Gustavo Niemeyer 
* URL : http://labix.org/python-mhash
* License : LGPL 2.1+
  Programming Lang: C, Python
  Description : Python bindings for libmhash

python-mhash is a comprehensive Python interface to the mhash library,
which provides a uniform interface to access several hashing algorithms
such as MD4, MD5, SHA1, SHA160, and many others.



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

Bug#554045: ITP: libctapimkt -- Read German Krankenversichertenkarte and eGK

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: libctapimkt
  Version : 1.0.1
  Upstream Author : Claudia Neumann 
* URL : http://sourceforge.net/projects/ctapi-mkt
* License : GPL
  Programming Lang: C
  Description : Read German Krankenversichertenkarte and eGK
 Library and program to read the German health insurance card (KVK) and
 the German electronic health card (eGK) from a certified card reading
 device on the serial port in Linux with kernel 2.6.x.

I would like to maintain this package in the Debian Med team.



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

Re: Lintian based autorejects

[Lucas Nussbaum]

On 02/11/09 at 12:10 +0200, Faidon Liambotis wrote:
> Lucas Nussbaum wrote:
> > I'm fine with letting ftpmasters take that decision. However, they
> > should consult the project before adding new tags (mail to -devel: "We
> > are thinking of adding those new tags to our list, comments?" instead of
> > a mail to -devel saying "We just blocked the following tags"), and
> > listen to feedback. If someone feel that they made a mistake, it's
> > always possible to appeal to the TC.
> Is it?
> 
> By my interpretation, I don't think that the TC has any authority here
> since the ftp-masters are DPL delegates and not individual maintainers.

I don't think that this was raised as a blocker when the TC was asked to
overrule ftpmasters about the ia32-lib-tools removal. (but please
correct me, I'm clearly not a constitution expert)
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


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

Re: Lintian based autorejects

[Charles Plessy]

Le Mon, Nov 02, 2009 at 08:49:40AM -0800, Russ Allbery a écrit :
> 
> I'm not seeing where he's doing any significant harm

By killing the discusssion with a flood of emails. Here are the top posters for
this month in this thread:

  3 Charles Plessy (+1 with this one)
  3 Michael Banck
  3 Stefano Zacchiroli
  5 Luk Claes
  8 Russ Allbery
 10 Steve Langasek
 12 Manoj Srivastava

People left the discussion, in particular our archive administrators, which
makes the whole thread pointless. In addition, some important questions are
left unanswered. I reproduce here the one from Brian May, which I think is very
relevant and was asked in many different ways, and always ignored:


http://lists.debian.org/msgid-search/20091102084201.ga15...@microcomaustralia.com.au

I want to perform a NMU upload on a package, say to fix a security issue, 
or some
other major issue (as allowed by NMUs).

Unfortunately the package fails lintian checks required to perform an 
upload.

Since this is a NMU though, I am not suppose to make unrelated changes.

What do I do?


As for all difficult discussions on this high-traffic mailing list, I think
that we would collectively achieve much more by self-limiting our contributions
to one or two message per day.

Have a nice day,

-- 
Charles


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

Re: Lintian based autorejects

[Russ Allbery]

Charles Plessy  writes:

> In addition, some important questions are left unanswered. I reproduce
> here the one from Brian May, which I think is very relevant and was
> asked in many different ways, and always ignored:

> 
> http://lists.debian.org/msgid-search/20091102084201.ga15...@microcomaustralia.com.au

> I want to perform a NMU upload on a package, say to fix a security
> issue, or some other major issue (as allowed by NMUs).
> 
> Unfortunately the package fails lintian checks required to perform
> an upload.
> 
> Since this is a NMU though, I am not suppose to make unrelated changes.
> 
> What do I do?

Surely the answer to that question is obvious: fix the bugs Lintian is
finding that prevent upload.  They're the equivalent of RC bugs (not
precisely the same, but similar), which if you're already doing an NMU are
certainly fair game.

This answer is independent of what we decide should go into that set of
checks.

-- 
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

segmentation fault with libcrypto.so (but not libcrypto.a)

[N N]

Apologies if this is the wrong list.  If so, please direct me to the
appropriate one.

Consider the following C code:

include 
#include 

int main(int argc, char** argv) {
  unsigned char foo[10] = "boo";
  printf("%s\n", SHA1(foo, 3, 0));
}

in file test-hmac.c.

gcc -static test-hmac.c -lcrypto; ./a.out
This works correctly, spewing garbage to the terminal.

gcc test-hmac.c -lcrypto; ./a.out
This segmentation faults.

Why?  What is wrong here?  So far, my best guess is that it has to do with
how SHA1 allocates the return value when passed the null pointer (the third
argument, 0).  The SHA1 function creates a static pointer large enough to
hold the result which it then returns.  Does the fact that this operation
occurs in a shared library change the allocation to the static pointer so
that accessing after it returns is outside the allowed memory for the
calling program?  Any help is appreciated.

Thanks.

P.S. libcrypto version 0.9.8k, Debian version squeeze/sid.

Re: Lintian based autorejects

[John H. Robinson, IV]

Russ Allbery wrote:
> Charles Plessy  writes:
> 
> > In addition, some important questions are left unanswered. I reproduce
> > here the one from Brian May, which I think is very relevant and was
> > asked in many different ways, and always ignored:
> 
> > 
> > http://lists.debian.org/msgid-search/20091102084201.ga15...@microcomaustralia.com.au
> 
> > I want to perform a NMU upload on a package, say to fix a security
> > issue, or some other major issue (as allowed by NMUs).
> > 
> > Unfortunately the package fails lintian checks required to perform
> > an upload.
> > 
> > Since this is a NMU though, I am not suppose to make unrelated changes.
> > 
> > What do I do?
> 
> Surely the answer to that question is obvious: fix the bugs Lintian is
> finding that prevent upload.  They're the equivalent of RC bugs (not
> precisely the same, but similar), which if you're already doing an NMU are
> certainly fair game.

So there are two NMUs for each package? One for the lintian blocker, and
then finally for the security upload?

What about those packages that have multiple lintian blockers? One NMU
for each, as they are unrelated, and have the problem that they are all
blocked due to other outstanding lintian blockers, or have one giant NMU
that touches various pieces parts?

-- 
John H. Robinson, IV  jaq...@debian.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


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

Re: Lintian based autorejects

[Russ Allbery]

"John H. Robinson, IV"  writes:
> Russ Allbery wrote:

>> Surely the answer to that question is obvious: fix the bugs Lintian is
>> finding that prevent upload.  They're the equivalent of RC bugs (not
>> precisely the same, but similar), which if you're already doing an NMU
>> are certainly fair game.

> So there are two NMUs for each package? One for the lintian blocker, and
> then finally for the security upload?

Generally you make all RC-level changes to a package at the same time with
one NMU.  This case isn't any different than the case of a package with
multiple RC bugs that you're uploading an NMU for.

In the specific case of security fixes for stable and stable updates, I
believe the ftp team has already said that Lintian won't be used to test
such uploads for obvious reasons.

> What about those packages that have multiple lintian blockers? One NMU
> for each, as they are unrelated, and have the problem that they are all
> blocked due to other outstanding lintian blockers, or have one giant NMU
> that touches various pieces parts?

Looking at the Lintian tags that are being checked, I'm having a hard time
seeing what sort of package would need a "giant" NMU to deal with them,
except maybe for packages with FHS problems.  Most of these tags are one
or two line fixes.  I'm sure you can always ask the ftp team for an
exception in exceptional circumstances.

-- 
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

Re: transitioning from a single to split package

[Paul Wise]

On Tue, Nov 3, 2009 at 3:56 AM, gregor herrmann  wrote:
> On Mon, 02 Nov 2009 07:15:35 +0100, Penny Leach wrote:
>
>> Well, that's logically equivalent to installing multiple versions of the
>> same package.  At the moment,  there's one moodle installation, which has
>> code that lives in /usr/share/moodle, and connects to one database.   This
>> is determined by its one config file.  You can do tricks in the config file
>> to fool Moodle into connecting to different databases, based on some rule
>> (like virtualhost), but I don't see the use case here,
>
> Having several separate moodle instances on one machine seems like a
> normal use case to me.
>
>> and I don't think
>> any other web applications support being installed multiple times, do they?
>
> wordpress for example allows "multiple blog" setups.
>
> mediawiki can at least be tricked into it, and I remember a host with
> one mediawiki instance using postgres and two or three others mysql.

Python/Django/etc based web applications support multiple sites quite
well, usually you have to setup a directory where all the data is kept
before actually using the app. This is usually part of an admin tool
installed in $PATH. It seems that mainly PHP apps have an issue with
this.

-- 
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

Re: segmentation fault with libcrypto.so (but not libcrypto.a)

[Peter Samuelson]

[N N]
> #include 
> #include 
> 
> int main(int argc, char** argv) {
>   unsigned char foo[10] = "boo";
>   printf("%s\n", SHA1(foo, 3, 0));
> }

Don't use printf("%s") on binary data that is not null-terminated.
What you probably want is to convert each byte to 2 hex digits and
print it that way.  See below.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


#include 
#include 
#include 

int main(int argc, char** argv) {
int i;
char hex[] = "0123456789abcdef";
unsigned char foo[10] = "boo";
unsigned char *out = SHA1(foo, 3, 0);

for (i = 0; i < 20; i++)
printf("%c%c",
   hex[out[i] >> 4],
   hex[out[i] & 0x0f]);
putc('\n', stdout);
exit(0);
}


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

Re: Cross compiler ITP (armel)

[Florian Weimer]

* Ben Hutchings:

> You can disagree all you like, but I believe that the FTP team will
> currently reject any new packages that use source code from their build-
> dependencies.

Surely this is not true because that would rule out many programs
written in C++.


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