Hello,
On Sat, May 28, 2011 at 05:41:52AM +0200, Guillem Jover wrote:
> > Note: Debian already contains pmake, also derived from NetBSD's make.
>
> There's also FreeBSD's pmake as freebsd-make in the freebsd-buildutils
> package.
Yes, but after 15+ years these two have diverged. There is softwar
This one time, at band camp, Roger Leigh said:
> On Sun, May 29, 2011 at 12:09:40PM -0500, Jonathan Nieder wrote:
> > (culled cc list of a few people I know read -devel)
> > Roger Leigh wrote:
> >
> > > Given the need to consider unlocking as well as locking, I'm not sure
> > > it's worth adding s
On Sun, May 29, 2011 at 01:57:29PM +0200, Sven Hoexter wrote:
> Hi,
> I currently see a wild mix of different format definitions used by people
> hitting debian-mentors. While I personally don't care as long as
> the copyright file is complete I don't think this fulfills the goal of
> this DEP.
>
On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> 2) Reinstallation.
>
>I'm currently using this logic (in postinst)
>
> # Create dedicated sbuild user
> if ! getent passwd sbuild > /dev/null; then
> adduser --system --quiet --home /var/lib/sbuild --no-create-h
On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.
Yes.
> However, most postinsts wrap the call to adduser with a check for
> whether the account already exists,
Which
On Mon, May 30, 2011 at 10:47:08AM +0200, Marc Haber wrote:
> On Sun, May 29, 2011 at 08:32:21PM +0100, Roger Leigh wrote:
> > Providing that we have consensus on a recommended strategy for
> > locking and unlocking accounts which can go into policy, I think all
> > we need are examples for h
On 2011-05-27 00:17:45 +0200, Michael Biebl wrote:
> Am 26.05.2011 23:26, schrieb Luk Claes:
>
> > There are some good reasons to keep some specific *.la files around,
>
> Just curious: what are these reasons / use case for keeping la files?
They are at least read by libtool. For instance, when
On Mon, 30 May 2011 12:23:35 +0200
Vincent Lefevre wrote:
> On 2011-05-27 00:17:45 +0200, Michael Biebl wrote:
> > Am 26.05.2011 23:26, schrieb Luk Claes:
> >
> > > There are some good reasons to keep some specific *.la files around,
> >
> > Just curious: what are these reasons / use case for k
On Mon, 30 May 2011 at 12:23:35 +0200, Vincent Lefevre wrote:
> They are at least read by libtool. For instance, when building MPFR
> (as a normal user):
[...]
> Either the information provided by /usr/lib/libgmp.la is important
> and this file should be kept, or libtool should not attempt to read
Roland Mas, 2011-05-30 13:49:23 +0200 :
[...]
> Then it was Saturday evening, [...] local Debian release manager
> Neil Williams.
Apparently my memory for names and faces is still playing tricks on
me, and it was Neil McGovern. My apologies.
Roland.
--
Roland Mas
Give a man a fire and he
Hi again,
I would like to repeat my question about UDD access from alioth (or one
/ both of its successors): Is there anybody working to reenable the UDD
access?
Kind regards and thanks for maintaining Alioth
Andreas.
On Wed, May 25, 2011 at 09:25:37AM +0200, Andreas Tille wrote:
> It also
On Sun, 29 May 2011, Benjamin Drung wrote:
> Am Sonntag, den 29.05.2011, 10:53 +0200 schrieb Raphael Hertzog:
> > Again to cope with the scenario explained at the start of this mail,
> > once a user has made modifications we must ensure that they end up in a
> > proper patch in debian/patches/. Rig
Hi,
On Sun, 29 May 2011, Bernhard R. Link wrote:
> That sounds a bit better, but it adds even more magic to dpkg-source.
> I really miss some way to express: "In this account, do not use magic.
> If things are not correct and need fixing, tell me what is wrong and
> abort so I'll never miss it." (
On Mon, May 30, 2011 at 12:16:13PM +0100, Simon McVittie wrote:
> On Mon, 30 May 2011 at 12:23:35 +0200, Vincent Lefevre wrote:
> > They are at least read by libtool. For instance, when building MPFR
> > (as a normal user):
> [...]
> > Either the information provided by /usr/lib/libgmp.la is import
Hi,
I am considering changing the default behaviour of dpkg triggers. [1]
Currently when a package activates a trigger (except if it uses
dpkg-trigger directly with the --no-await option, and that is a minority
of cases), the trigerring package ends up in "triggers-awaited" status
and it doesn't s
Raphael Hertzog wrote:
> My question is thus: are there triggers currently in use where this
> relaxed behaviour would be wrong? Or more simply are there packages which
> are really not working before the processing of their awaited triggers?
python-support seems to need that; python does not see
On 05/30/2011 06:17 PM, Joey Hess wrote:
> Raphael Hertzog wrote:
>> My question is thus: are there triggers currently in use where this
>> relaxed behaviour would be wrong? Or more simply are there packages which
>> are really not working before the processing of their awaited triggers?
>
> pytho
On Mon, 30 May 2011, Joey Hess wrote:
> Raphael Hertzog wrote:
> > My question is thus: are there triggers currently in use where this
> > relaxed behaviour would be wrong? Or more simply are there packages which
> > are really not working before the processing of their awaited triggers?
>
> pytho
[dropping d-dpkg@ as recipient]
On 11-05-30 at 12:17pm, Joey Hess wrote:
> ghc libraries could need [certain kind of dpkg triggers], if any
> package depends on such a library being available to be compiled
> against at installation time. I don't know if any packages use ghc
> libraries like th
On Sun, 29 May 2011 10:53:03 +0200, Raphael Hertzog wrote:
> Auto-application of patches
> ---
>
> I would like to improve this situation and not force the majority of
> people to add the unapply-patches option (if it turns out the majority
> of people use this option or a
Raphael Hertzog wrote:
> I don't know anything about Haskell. What does the trigger do? Is it some
> sort of non-optional byte-compilation?
It makes the cabal package manager aware of the package installed by the
dpkg package manager, iirc.
--
see shy jo
signature.asc
Description: Digital sign
Raphael Hertzog writes:
> On Sun, 29 May 2011, Benjamin Drung wrote:
>> The file should end with .patch
>> (debian/patches/debian-changes-.patch) so that your favorite text
>> editor uses the correct highlighting.
> At the time I wrote it, it was on purpose that I did not use any
> extension. It
* Raphael Hertzog [110530 16:42]:
> > That sounds a bit better, but it adds even more magic to dpkg-source.
> > I really miss some way to express: "In this account, do not use magic.
> > If things are not correct and need fixing, tell me what is wrong and
> > abort so I'll never miss it." (Actuall
Hi,
Am Montag, den 30.05.2011, 18:58 +0200 schrieb Jonas Smedegaard:
> [dropping d-dpkg@ as recipient]
>
> On 11-05-30 at 12:17pm, Joey Hess wrote:
> > ghc libraries could need [certain kind of dpkg triggers], if any
> > package depends on such a library being available to be compiled
> > again
On 11-05-30 at 10:47pm, Joachim Breitner wrote:
> Hi,
>
> Am Montag, den 30.05.2011, 18:58 +0200 schrieb Jonas Smedegaard:
> > [dropping d-dpkg@ as recipient]
> >
> > On 11-05-30 at 12:17pm, Joey Hess wrote:
> > > ghc libraries could need [certain kind of dpkg triggers], if any
> > > package dep
]] Andreas Tille
| I would like to repeat my question about UDD access from alioth (or
| one / both of its successors): Is there anybody working to reenable
| the UDD access?
It's on the list of known issues. Repeating questions means less time
to fix the issues that remain.
Regards,
--
Tolle
Hi,
Am Sonntag, den 29.05.2011, 11:26 +0200 schrieb Josselin Mouette:
> > But it still happens that those patches are generated[1] when the maintainer
> > did not expect any change at all. That's why we added the option
> > --abort-on-upstream-changes for maintainers who never wants dpkg-source
>
On May 30, Ben Hutchings wrote:
> There are likely to be many programs and build scripts that test for a
> kernel version prefix of '2.6' vs '2.4' and will behave incorrectly when
> they find '3.0'. Others require that there are at least 3 numeric
Expect module-init-tools and three udev scripts
On Mon, 2011-05-30 at 23:12 +0200, Marco d'Itri wrote:
> On May 30, Ben Hutchings wrote:
>
> > There are likely to be many programs and build scripts that test for a
> > kernel version prefix of '2.6' vs '2.4' and will behave incorrectly when
> > they find '3.0'. Others require that there are at
OoO Lors de la soirée naissante du lundi 30 mai 2011, vers 18:52, Ben
Hutchings disait :
> As you may have seen, the next version of the Linux kernel will be 3.0
> (or 3.0.0). There is no significant API change; this just shortens the
> version string and marks the start of the third decade o
Hello,
On Mon, 30 May 2011 23:30:03 +0200
Joachim Breitner wrote:
> BTW, for all who create patches this way and want to later split the
> patch into two logically independent patches, I am creating an
> interactive patch splitter based on the darcs UI (but only the UI,
> don’t worry):
> http://
]] Ian Jackson
| I think the answer is obviously the former. Someone who pushes to a
| repo already needs to know about it, set up keys, etc. A visitor who
| just wants to download may know nothing and just guess urls.
They're more likely to use their favourite search engine or click on a
link
Please reply to debian-kernel as originally requested.
On Tue, 2011-05-31 at 00:09 +0200, Vincent Bernat wrote:
> OoO Lors de la soirée naissante du lundi 30 mai 2011, vers 18:52, Ben
> Hutchings disait :
>
> > As you may have seen, the next version of the Linux kernel will be 3.0
> > (or 3.0
> We could delay uploading it to unstable for a while if this is necessary
> to allow time for fixes to userland.
Would this mean we wouldn't have it in Experimental either?
Adnan
On Mon, May 30, 2011 at 11:12 PM, Ben Hutchings wrote:
> Please reply to debian-kernel as originally requested.
>
Hello everybody,
in echo to Raphaël's question about the use of a VCS together with the 3.0
(quilt) format, I was just wondering, what is needed to have 3.0 (git)
acceptable in Debian, and how can we solve this ?
Have a nice day,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE,
On Mon, May 30, 2011 at 6:27 PM, Charles Plessy wrote:
> Hello everybody,
>
> in echo to Raphaël's question about the use of a VCS together with the 3.0
> (quilt) format, I was just wondering, what is needed to have 3.0 (git)
> acceptable in Debian, and how can we solve this ?
IIRC, there was a B
Russ Allbery writes:
> I have a very minor objection: I think it's aethetic clutter to add
> unnecessary file extensions (we're not DOS or Windows), and any decent
> editor should figure out that it's a patch from either the file format
> or the fact that it's in a debian/patches directory.
I am
Package: wnpp
Severity: wishlist
Owner: Daniele Tricoli
* Package name: sphinxcontrib-spelling
Version : 1.1
Upstream Author : Doug Hellmann
* URL : http://bitbucket.org/birkenfeld/sphinx-contrib
* License : BSD
Programming Lang: Python
Description : S
38 matches
Mail list logo
