On Sat, Mar 30, 2013 at 10:49:18PM +0100, Benjamin Drung wrote:
> devscripts ships a bunch of scripts to make the life of a Debian Package
> maintainer easier. Not every script in there is Debian packaging
> specific. Some of them are used on other non-Debian-based distributions.
> I was contacted
On Sat, Mar 30, 2013 at 10:49:18PM +0100, Benjamin Drung wrote:
> I like to keep only Debian packaging specific scripts in devscripts (see
> the list below). Where should we put the non Debian packaging specific
> scripts? Should we create a neutral project or are there other projects
> in which th
Kurt Roeckx writes:
>> - md5_hex("$name $alias obfuscate\n"), "\n";
>> + hmac_sha256_hex($name, "obfuscate"), "\n";
>>
>> part probably needs some further work. Should it be
>>
>> + hmac_sha256_hex($name, $alias + "obfuscate"), "\n";
>
> This is for the dummy sheet. I
On Sun, Mar 31, 2013 at 01:03:52PM +0300, Timo Juhani Lindfors wrote:
> Kurt Roeckx writes:
> >> - md5_hex("$name $alias obfuscate\n"), "\n";
> >> + hmac_sha256_hex($name, "obfuscate"), "\n";
> >>
> >> part probably needs some further work. Should it be
> >>
> >> + hma
+++ Benjamin Drung [2013-03-30 22:49 +0100]:
> Hi,
>
> devscripts ships a bunch of scripts to make the life of a Debian Package
> maintainer easier. Not every script in there is Debian packaging
> specific. Some of them are used on other non-Debian-based distributions.
Whilst considering what scr
On Sun, Mar 31, 2013 at 11:56 AM, Wookey wrote:
> +++ Benjamin Drung [2013-03-30 22:49 +0100]:
>> Hi,
>>
>> devscripts ships a bunch of scripts to make the life of a Debian Package
>> maintainer easier. Not every script in there is Debian packaging
>> specific. Some of them are used on other non-De
A new major release R 3.0.0 will come out on Wednesday April 3rd, as usual
according the the release plan and announcements [1].
It contains major internal changes [2] and requires rebuilds of all R
packages. As I usually do, I started packaging pre-releases and rc
candidates [3] based on March
On Sun, Mar 31, 2013 at 11:56 AM, Wookey wrote:
>
> +++ Benjamin Drung [2013-03-30 22:49 +0100]:
> > Hi,
> >
> > devscripts ships a bunch of scripts to make the life of a Debian Package
> > maintainer easier. Not every script in there is Debian packaging
> > specific. Some of them are used on othe
Dirk Eddelbuettel writes:
> A new major release R 3.0.0 will come out on Wednesday April 3rd, as usual
> according the the release plan and announcements [1].
>
> It contains major internal changes [2] and requires rebuilds of all R
> packages. As I usually do, I started packaging pre-releases a
CC list trimmed and -release added
On 31.03.2013 17:45, Dirk Eddelbuettel wrote:
A new major release R 3.0.0 will come out on Wednesday April 3rd, as
usual
according the the release plan and announcements [1].
It contains major internal changes [2] and requires rebuilds of all R
packages.
[..
On 31 March 2013 at 19:12, Ansgar Burchardt wrote:
| However the binaries seem to claim they would also work with the newer R
| versions? I looked at r-cran-rsymphony and it has
| Depends: [...], r-base-core (>= 2.14.1)
You looked at the code from before the update of that package:
Package:
On 31 March 2013 at 18:18, Adam D. Barratt wrote:
| Aside from the lack of pre-discussion, co-ordination etc., the last few
| weeks of a freeze _really_ isn't the right time to be starting a large
| (or indeed small) transition in unstable. We now have at least 87 (based
| on this morning's bri
Dirk Eddelbuettel writes:
> On 31 March 2013 at 19:12, Ansgar Burchardt wrote:
> | However the binaries seem to claim they would also work with the newer R
> | versions? I looked at r-cran-rsymphony and it has
> | Depends: [...], r-base-core (>= 2.14.1)
>
> You looked at the code from before the
On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
>
> On 31 March 2013 at 18:18, Adam D. Barratt wrote:
> | Aside from the lack of pre-discussion, co-ordination etc., the last few
> | weeks of a freeze _really_ isn't the right time to be starting a large
> | (or indeed small) tr
On 31 March 2013 at 19:41, Ansgar Burchardt wrote:
| Dirk Eddelbuettel writes:
| > On 31 March 2013 at 19:12, Ansgar Burchardt wrote:
| > | However the binaries seem to claim they would also work with the newer R
| > | versions? I looked at r-cran-rsymphony and it has
| > | Depends: [...], r-ba
Dirk Eddelbuettel writes:
> On 31 March 2013 at 19:41, Ansgar Burchardt wrote:
> | Dirk Eddelbuettel writes:
> | > On 31 March 2013 at 19:12, Ansgar Burchardt wrote:
> | > | However the binaries seem to claim they would also work with the newer R
> | > | versions? I looked at r-cran-rsymphony and
On 31 March 2013 at 20:25, Ansgar Burchardt wrote:
| Dirk Eddelbuettel writes:
| > On 31 March 2013 at 19:41, Ansgar Burchardt wrote:
| > | Dirk Eddelbuettel writes:
| > | > On 31 March 2013 at 19:12, Ansgar Burchardt wrote:
| > | > | However the binaries seem to claim they would also work with
On Sun, 2013-03-31 at 20:25:45 +0200, Ansgar Burchardt wrote:
> I assume this means that a non-working set of packages could also
> migrate to testing (if there was no freeze).
The freeze only prevents breakage for wheezy, but after wheezy one can
still get a "broken system" due to a partial upgra
On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
> In the grand scheme of things, R is a rather peripheral package.
Not sure where you get that idea, but given that you insist on that:
| pkern@franck ~ % dak rm -nR -s testing r-base
| Working... done.
[…]
| Checking reverse depe
Philipp Kern wrote:
> On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
> > I cannot influence the R release cycle which happens within our freeze. As
> > have a few previous R releases, and none of those created any trouble.
>
> Thanks for trading the R release cycle with Debian
Uoti Urpala, le Mon 01 Apr 2013 00:48:08 +0300, a écrit :
> Philipp Kern wrote:
> > On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
> > > I cannot influence the R release cycle which happens within our freeze. As
> > > have a few previous R releases, and none of those created any
On 31.03.2013 23:48, Uoti Urpala wrote:
> Philipp Kern wrote:
>> On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
>>> I cannot influence the R release cycle which happens within our freeze. As
>>> have a few previous R releases, and none of those created any trouble.
>>
>> Thanks
Le dimanche 31 mars 2013 à 13:35 -0500, Dirk Eddelbuettel a écrit :
> That is why we have a meta-variable
>
> ${R:Depends}
>
> in Depends: which gets filled by the R version that compiling the package,
> currently 3.0.0~20130330-1. And which prevents the migration.
>
> The same scheme worked
Dirk Eddelbuettel writes:
> | I assume this means that a non-working set of packages could also
> | migrate to testing (if there was no freeze). This should probably get
> | fixed, maybe with something similar to the perlapi-5.14.2 virtual
> | package provided by perl(-base)?
>
> That is why we h
On Mon, 01 Apr 2013 00:48:08 +0300
Uoti Urpala wrote:
> Philipp Kern wrote:
> > On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
> > > I cannot influence the R release cycle which happens within our freeze. As
> > > have a few previous R releases, and none of those created any t
Le lundi 01 avril 2013 à 00:48 +0300, Uoti Urpala a écrit :
> IMO it's important to remember that it's fundamentally the release team
> that is at fault for problems here, not the R maintainer.
There are certainly problems with the duration of the wheezy freeze, but
pointing fingers at the relea
On Mon, Apr 01, 2013 at 12:48:08AM +0300, Uoti Urpala wrote:
> Philipp Kern wrote:
> > On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
> > > I cannot influence the R release cycle which happens within our freeze. As
> > > have a few previous R releases, and none of those created
Le Mon, Apr 01, 2013 at 12:15:17AM +0200, Arno Töll a écrit :
>
> There are release-critical problems which need to be fixed first. Hint: You
> could help there as well which is a much better idea rather than ranting and
> trolling around.
Hi Arno,
Note that according to the dynamic list of bloc
On Mon, Apr 01, 2013 at 12:48:08AM +0300, Uoti Urpala wrote:
> Philipp Kern wrote:
> > On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
> > > I cannot influence the R release cycle which happens within our freeze. As
> > > have a few previous R releases, and none of those created
On 31 March 2013 at 22:14, Philipp Kern wrote:
| On Sun, Mar 31, 2013 at 12:33:46PM -0500, Dirk Eddelbuettel wrote:
| > In the grand scheme of things, R is a rather peripheral package.
|
| Not sure where you get that idea, but given that you insist on that:
|
| | pkern@franck ~ % dak rm -nR -s t
On 1 April 2013 at 00:16, Josselin Mouette wrote:
| Le dimanche 31 mars 2013 à 13:35 -0500, Dirk Eddelbuettel a écrit :
| > That is why we have a meta-variable
| >
| > ${R:Depends}
| >
| > in Depends: which gets filled by the R version that compiling the package,
| > currently 3.0.0~20130330-
On 1 April 2013 at 00:17, Ansgar Burchardt wrote:
| Dirk Eddelbuettel writes:
| > | I assume this means that a non-working set of packages could also
| > | migrate to testing (if there was no freeze). This should probably get
| > | fixed, maybe with something similar to the perlapi-5.14.2 virtua
On Sunday, March 31, 2013 05:49:31 PM Dirk Eddelbuettel wrote:
> On 1 April 2013 at 00:17, Ansgar Burchardt wrote:
> | Dirk Eddelbuettel writes:
> | > | I assume this means that a non-working set of packages could also
> | > | migrate to testing (if there was no freeze). This should probably get
On Mon, 01 Apr 2013 07:24:29 +0900, Charles Plessy wrote:
> > There are release-critical problems which need to be fixed first. Hint: You
> > could help there as well which is a much better idea rather than ranting and
> > trolling around.
> Note that according to the dynamic list of blockers for
On Mon, Apr 01, 2013 at 01:18:49AM +0200, gregor herrmann wrote:
> > > There are release-critical problems which need to be fixed first. Hint:
> > > You
> > > could help there as well which is a much better idea rather than ranting
> > > and
> > > trolling around.
> > Note that according to the d
The residents of #debian-uk are pleased to announce that, in conjunction with
our friendly FTP masters, dak-roulette has just been activated in cron on
ftp-master.debian.org targetting unstable and no particular maintainer.
I enclose the documentation for your reference.
_
Neil Williams wrote:
> On Mon, 01 Apr 2013 00:48:08 +0300
> Uoti Urpala wrote:
> > Philipp Kern wrote:
> > > Thanks for trading the R release cycle with Debian's and for delaying the
> > IMO it's important to remember that it's fundamentally the release team
> > that is at fault for problems here
Uoti Urpala, le Mon 01 Apr 2013 03:07:25 +0300, a écrit :
> Having latest upstream versions easily available to users is important
> for the development of many projects,
That's what experimental is for.
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of
On Monday, April 01, 2013 01:07:32 AM Jonathan Wiltshire wrote:
> The residents of #debian-uk are pleased to announce that, in conjunction
> with our friendly FTP masters, dak-roulette has just been activated in cron
> on ftp-master.debian.org targetting unstable and no particular maintainer.
>
>
On Monday, April 01, 2013 03:07:25 AM Uoti Urpala wrote:
> Neil Williams wrote:
> > On Mon, 01 Apr 2013 00:48:08 +0300
> >
> > Uoti Urpala wrote:
> > > Philipp Kern wrote:
> > > > Thanks for trading the R release cycle with Debian's and for delaying
> > > > the
> > >
> > > IMO it's important to
Scott Kitterman, le Sun 31 Mar 2013 20:37:38 -0400, a écrit :
> > dak-roulette(1)
>
> Excellent. What's the interval on the cron runs? If we get lucky, this
> could
> get us to a release really soon.
Which could even fit on just one CD!
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ
Samuel Thibault dijo [Mon, Apr 01, 2013 at 02:40:56AM +0200]:
> Scott Kitterman, le Sun 31 Mar 2013 20:37:38 -0400, a écrit :
> > > dak-roulette(1)
> >
> > Excellent. What's the interval on the cron runs? If we get lucky, this
> > could
> > get us to a release really soon.
>
> Which could eve
Scott Kitterman wrote:
> If I'm reading you correctly, you seem to believe that creating the release
> is
> somehow the release team's job. It's not. The job belongs to all of us.
No, that's not what I'm saying. But I think the release team is
primarily responsible for the policies that harm t
Uoti Urpala dijo [Mon, Apr 01, 2013 at 05:12:46AM +0300]:
> No, that's not what I'm saying. But I think the release team is
> primarily responsible for the policies that harm the work other
> maintainers do on unstable.
>
> A release must not be the only goal for package maintainers, and IMO it
>
On 04/01/13 05:48, Gunnar Wolf wrote:
Uoti Urpala dijo [Mon, Apr 01, 2013 at 05:12:46AM +0300]:
No, that's not what I'm saying. But I think the release team is
primarily responsible for the policies that harm the work other
maintainers do on unstable.
A release must not be the only goal for pac
Philipp Kern wrote:
> Thanks for trading the R release cycle with Debian's and for
> delaying the release. The harm has already been done, so somebody
> should probably go and create a transition tracker for it?
Rather than accept the harm, surely the release team could simply roll
back the uploa
46 matches
Mail list logo
