Re: [Pkg-openldap-devel] [SRM] (PRSC) Security fixes and possible database corruption
On Mar 28, 2011, at 11:36 PM, Adam D. Barratt wrote: Hi, Thanks for working on fixing issues in stable. On Mon, 2011-03-28 at 22:41 +0200, Matthijs Möhlmann wrote: According to bug #617606 there are currently 2 CVE's open. CVE-2011-1024: [...] CVE-2011-1025: These look okay, although it doesn't appear that they've been resolved in unstable yet? If so, that really should be done first. Once the patches have been tested in unstable, we can then look again at applying them to stable. CVE-2011-1081: modrdn.c in slapd in OpenLDAP 2.4.x before 2.4.24 allows remote attackers to cause a denial of service (daemon crash) via a relative Distinguished Name (DN) modification request (aka MODRDN operation) that contains an empty value for the OldDN field. Fix: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/modrdn.c.diff?hideattic=1r1=texttr1=1.181r2=texttr2=1.182f=c Impact: High, possibility to remotely crash slapd. The security tracker indicates that this CVE hasn't yet been checked for its applicability to and impact on Debian. Have you confirmed with the security team that they don't wish to handle this? No I havent confirmed with the security team. I'll file a ticket in their bug tracking and then they can decide what to do. As suggested by Michael Gilbert. Then we have a possible database corruption (introduced by patch service-operational-before-detach (debian specific)) Fix: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=service-operational-before-detach;att=1;bug=616164 Above fix is the new patch for service-operational-before-detach. Looking at the upstream commits, should servers/slapd/main.c r1.279 be included here? As with the earlier patches, this should also be tested in unstable before being applied to stable. Regards, Adam You are right, I shouldn't blindly copy patches. Thanks for the notice. Regards, Matthijs Möhlmann -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0768c501-d485-46b5-8d34-ca8be419e...@cacholong.nl
Re: Bug#619990: developers-reference: Update of merkel.d.o URLs
Hi, On Tue, 29 Mar 2011, Charles Plessy wrote: - For Britney, I do not find the equivalent on ries.d.o for the following: merkel:/org/ftp-debian-org;/testing/update_out/ merkel:~aba/testing/update_out Was it moved somewhere else ? It's now part of release.debian.org and thus not mirrored on ries.debian.org. hertzog@ries:~$ ls -al /srv/ftp.debian.org/web/testing lrwxrwxrwx 1 dak ftpteam 35 3 juil. 2010 /srv/ftp.debian.org/web/testing - /srv/release.debian.org/www/britney hertzog@ries:~$ ls -al /srv/release.debian.org/www/britney ls: cannot access /srv/release.debian.org/www/britney: No such file or directory But I think it's not very important: - the former is web accessible at http://ftp-master.debian.org/testing/update_output/ - the latter is probably not really the reference implementation of britney anymore it can either be removed or replaced with http://git.debian.org/?p=debian-release/britney1.git;a=summary and http://git.debian.org/?p=debian-release/britney2.git;a=summary Index: pkgs.dbk === --- pkgs.dbk (révision 8598) +++ pkgs.dbk (copie de travail) @@ -2596,10 +2596,7 @@ before or after this main run, depending on the exact type. /para para -If you want to see more details, you can look it up on -filenamemerkel:/org/ftp-debian-org;/testing/update_out//filename (or -in filenamemerkel:~aba/testing/update_out/filename to see a setup with -a smaller packages file). Via web, it's at ulink +If you want to see more details, you can look it up on ulink url=http://ftp-master-host;/testing/update_out_code/;/ulink. /para para Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110329070955.ga14...@rivendell.home.ouaza.com
fakechroot bugginess on squeeze
debootstrap --variant=fakechroot does not currently work on squeeze.
It fails with error messages like:
W: Failure while unpacking required packages. This will be attempted up to
five times.
These errors appear to be due to two distinct bugs: #561991 and #588508
Maybe a targeted patch of these two bugs in fakechroot is a good
candidate for the next point release of squeeze?
I'm attaching a debdiff against what is currently in stable (2.9-1.1).
i tested this as a non-privileged user on an i386 squeeze environment with:
mkdir root
PATH=/sbin:/usr/sbin:$PATH fakeroot \
-i $(pwd)/fakeroot.state \
-s $(pwd)/fakeroot.state \
fakechroot \
debootstrap --variant=fakechroot squeeze root
Without these patches applied, the base fakechroot does not succeed.
With these patches applied, it completes successfully.
I also tried fixing only one bug or the other, but debootstrap failed to
complete without both fixes together, so i think they are both necessary.
I ran into these bugs while building debirf images. It would be nice
for users of debian stable to not have to use a backported fakechroot
for debirf.
I do not believe these fixes have any adverse affect on other uses of
fakechroot.
Is there anything else you need from me in order to consider this
request for a future point release?
Regards,
--dkg
PS i am not subscribed to debian-release -- please CC me on replies.
thanks!
diff -u fakechroot-2.9/configure.ac fakechroot-2.9/configure.ac
--- fakechroot-2.9/configure.ac
+++ fakechroot-2.9/configure.ac
@@ -172,6 +172,7 @@
unlinkat \
ulckpwdf \
utime \
+utimensat \
utimes \
])
diff -u fakechroot-2.9/config.h.in fakechroot-2.9/config.h.in
--- fakechroot-2.9/config.h.in
+++ fakechroot-2.9/config.h.in
@@ -368,6 +368,9 @@
/* Define to 1 if you have the `utimes' function. */
#undef HAVE_UTIMES
+/* Define to 1 if you have the `utimensat' function. */
+#undef HAVE_UTIMENSAT
+
/* Define to 1 if you have the utime.h header file. */
#undef HAVE_UTIME_H
diff -u fakechroot-2.9/configure fakechroot-2.9/configure
--- fakechroot-2.9/configure
+++ fakechroot-2.9/configure
@@ -12458,6 +12458,7 @@
unlinkat \
ulckpwdf \
utime \
+utimensat \
utimes \
do :
diff -u fakechroot-2.9/src/libfakechroot.c fakechroot-2.9/src/libfakechroot.c
--- fakechroot-2.9/src/libfakechroot.c
+++ fakechroot-2.9/src/libfakechroot.c
@@ -543,6 +543,9 @@
/* static int (*next_ulckpwdf) (void) = NULL; */
#endif
static int (*next_utime) (const char *filename, const struct utimbuf *buf)
= NULL;
+#ifdef HAVE_UTIMENSAT
+static int (*next_utimensat) (int dirfd, const char *pathname, const
struct timespec times[2], int flags) = NULL;
+#endif
static int (*next_utimes) (const char *filename, const struct timeval
tv[2]) = NULL;
@@ -821,6 +824,9 @@
/*nextsym(ulckpwdf, ulckpwdf); */
#endif
nextsym(utime, utime);
+#ifdef HAVE_UTIMENSAT
+nextsym(utimensat, utimensat);
+#endif
nextsym(utimes, utimes);
}
@@ -896,10 +902,19 @@
/* #include unistd.h */
int __lxstat (int ver, const char *filename, struct stat *buf)
{
-char *fakechroot_path, *fakechroot_ptr, fakechroot_buf[FAKECHROOT_MAXPATH];
+char *fakechroot_path, *fakechroot_ptr,
fakechroot_buf[FAKECHROOT_MAXPATH], tmp[FAKECHROOT_MAXPATH];
+int retval;
+READLINK_TYPE_RETURN status;
+const char* orig;
+orig = filename;
expand_chroot_path(filename, fakechroot_path, fakechroot_ptr,
fakechroot_buf);
if (next___lxstat == NULL) fakechroot_init();
-return next___lxstat(ver, filename, buf);
+retval = next___lxstat(ver, filename, buf);
+/* deal with http://bugs.debian.org/561991 */
+if ((buf-st_mode S_IFMT) == S_IFLNK)
+ if ((status = readlink(orig, tmp, sizeof(tmp)-1)) != -1)
+buf-st_size = status;
+return retval;
}
#endif
@@ -909,10 +924,19 @@
/* #include unistd.h */
int __lxstat64 (int ver, const char *filename, struct stat64 *buf)
{
-char *fakechroot_path, *fakechroot_ptr, fakechroot_buf[FAKECHROOT_MAXPATH];
+char *fakechroot_path, *fakechroot_ptr,
fakechroot_buf[FAKECHROOT_MAXPATH], tmp[FAKECHROOT_MAXPATH];
+int retval;
+READLINK_TYPE_RETURN status;
+const char* orig;
+orig = filename;
expand_chroot_path(filename, fakechroot_path, fakechroot_ptr,
fakechroot_buf);
if (next___lxstat64 == NULL) fakechroot_init();
-return next___lxstat64(ver, filename, buf);
+retval = next___lxstat64(ver, filename, buf);
+/* deal with http://bugs.debian.org/561991 */
+if ((buf-st_mode S_IFMT) == S_IFLNK)
+ if ((status = readlink(orig, tmp, sizeof(tmp)-1)) != -1)
+buf-st_size = status;
+return retval;
}
#endif
@@ -2158,10 +2182,19 @@
/* #include unistd.h */
int lstat (const char *file_name, struct stat *buf)
{
-char *fakechroot_path, *fakechroot_ptr, fakechroot_buf[FAKECHROOT_MAXPATH];
+char *fakechroot_path, *fakechroot_ptr,
fakechroot_buf[FAKECHROOT_MAXPATH], tmp[FAKECHROOT_MAXPATH];
+
Bug#618871: transition: ocaml
Le 19/03/2011 08:40, Stéphane Glondu a écrit : The Debian OCaml team is ready for a transition to OCaml 3.12.0. All packages depending on ocaml-base-nox-3.11.2 and ocaml-base-3.11.2 will be affected. I am waiting for the approval from the release team to proceed. Any news on that? Cheers, -- Stéphane -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d91df17.6060...@debian.org
Bug#618871: transition: ocaml
On Tue, Mar 29, 2011 at 15:31:03 +0200, Stéphane Glondu wrote: Le 19/03/2011 08:40, Stéphane Glondu a écrit : The Debian OCaml team is ready for a transition to OCaml 3.12.0. All packages depending on ocaml-base-nox-3.11.2 and ocaml-base-3.11.2 will be affected. I am waiting for the approval from the release team to proceed. Any news on that? Clearly not. Cheers, Julien -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110329175227.gk3...@radis.liafa.jussieu.fr
Tracking ghc transition on http://release.debian.org/transitions/
Hi release team, the transitions monitors on http://release.debian.org/transitions/ look useful, and I guess it makes more sense to use an existing instance instead of setting up the software ourself on alioth. Would that be possible? For the ghc transition, these settings should do, if I guess the syntax correctly: Affected: .build-depends ~ /ghc6?/ Good: .depends ~ /libghc-base-dev.*/ Bad: .depends ~ /libghc6-base-dev.*/ or even Affected: .build-depends ~ /ghc6?/ Good: .build-depends ~ /ghc/ Bad: .build-depends ~ /ghc6/ Thanks, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Suggestion to include old firewire stack
Hi Is it able to include old firewire stack into next kernel release within Squeeze distro? I have some troubles about my WD My Book and new firewire stack. Troubles resolved in newer kernel (2.6.38). Old firewire implementation is more stable, but was exluded from kernel. It would be more better to include old and new firewire modules in squeeze kernel, but old modules would be black -- Евгений Кабиольский инженер ОГСТ Южно-Уральский Государственный Университет тел.: (351) 267-93-60 (доб. 104) e-mail: evg...@urc.ac.ru -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301426826.9370.17.camel@darkstar
Suggestion to include old firewire stack
Hi Is it able to include old firewire stack into next kernel release within Squeeze distro? I have some troubles about my WD My Book and new firewire stack. Troubles resolved in newer kernel (2.6.38). Old firewire implementation is more stable, but was exluded from kernel. It would be more better to include old and new firewire modules in squeeze kernel, but, for example, old modules would be blacklisted by default. -- Евгений Кабиольский инженер ОГСТ Южно-Уральский Государственный Университет тел.: (351) 267-93-60 (доб. 104) e-mail: evg...@urc.ac.ru -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301426815.9370.15.camel@darkstar
Re: Bug#619990: developers-reference: Update of merkel.d.o URLs
On Tue, Mar 29, 2011 at 09:09:55AM +0200, Raphael Hertzog wrote: But I think it's not very important: - the former is web accessible at http://ftp-master.debian.org/testing/update_output/ - the latter is probably not really the reference implementation of britney anymore it can either be removed or replaced with http://git.debian.org/?p=debian-release/britney1.git;a=summary and http://git.debian.org/?p=debian-release/britney2.git;a=summary True. I've still set up a sync between franck and ries now. It should be synced every two hours and after britney. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Stable update of linux-2.6
On Sun, 2011-03-27 at 20:31 +0100, Ben Hutchings wrote: There were a couple of regressions in linux-2.6 version 2.6.32-31 (i.e. Debian 6.0.1) that should be fixed a.s.a.p: [...] Either Dann or I will upload an update to stable-proposed-updates, intended for early release through stable-updates. Unfortunately, the powerpc build reproducibly FTBFS: CC arch/powerpc/kernel/crash.o /build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/source_powerpc_none/arch/powerpc/kernel/crash.c: In function 'default_machine_crash_shutdown': /build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/source_powerpc_none/arch/powerpc/kernel/crash.c:448: error: implicit declaration of function 'crash_kexec_wait_realmode' make[6]: *** [arch/powerpc/kernel/crash.o] Error 1 make[5]: *** [arch/powerpc/kernel] Error 2 make[4]: *** [sub-make] Error 2 make[3]: *** [all] Error 2 make[3]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/build_powerpc_none_powerpc' make[2]: *** [debian/stamps/build_powerpc_none_powerpc_plain] Error 2 make[1]: *** [build_powerpc_none_powerpc_real] Error 2 make[2]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32' make: make[1]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32' *** [debian/stamps/build-base] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1301437578.12508.562.ca...@hathi.jungle.funky-badger.org
Re: [Pkg-openldap-devel] [SRM] (PRSC) Security fixes and possible database corruption
Matthijs Möhlmann matth...@cacholong.nl schrieb: On Mar 28, 2011, at 11:36 PM, Adam D. Barratt wrote: Hi, Thanks for working on fixing issues in stable. On Mon, 2011-03-28 at 22:41 +0200, Matthijs Möhlmann wrote: According to bug #617606 there are currently 2 CVE's open. CVE-2011-1024: [...] CVE-2011-1025: These look okay, although it doesn't appear that they've been resolved in unstable yet? If so, that really should be done first. Once the patches have been tested in unstable, we can then look again at applying them to stable. CVE-2011-1081: modrdn.c in slapd in OpenLDAP 2.4.x before 2.4.24 allows remote attackers to cause a denial of service (daemon crash) via a relative Distinguished Name (DN) modification request (aka MODRDN operation) that contains an empty value for the OldDN field. Fix: http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/modrdn.c.diff?hideattic=1r1=texttr1=1.181r2=texttr2=1.182f=c Impact: High, possibility to remotely crash slapd. The security tracker indicates that this CVE hasn't yet been checked for its applicability to and impact on Debian. Have you confirmed with the security team that they don't wish to handle this? No I havent confirmed with the security team. I'll file a ticket in their bug tracking and then they can decide what to do. As suggested by Michael Gilbert. Please proceed with a stable point update. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnip4mli.dpd@inutil.org
Re: Stable update of linux-2.6
On Tue, 2011-03-29 at 23:26 +0100, Adam D. Barratt wrote: On Sun, 2011-03-27 at 20:31 +0100, Ben Hutchings wrote: There were a couple of regressions in linux-2.6 version 2.6.32-31 (i.e. Debian 6.0.1) that should be fixed a.s.a.p: [...] Either Dann or I will upload an update to stable-proposed-updates, intended for early release through stable-updates. Unfortunately, the powerpc build reproducibly FTBFS: Introduced by: commit 4d4d502715479044f02ae7464474bbb615b2d158 Author: Michael Neuling mi...@neuling.org Date: Thu May 13 19:40:11 2010 + powerpc/kdump: Fix race in kdump shutdown commit 60adec6226bbcf061d4c2d10944fced209d1847d upstream. The new function crash_kexec_wait_realmode() is only defined if CONFIG_SMP is defined, but is used unconditionally. Of course, this was quickly fixed upstream: commit c2be05481f6125254c45b78f334d4dd09c701c82 Author: Paul E. McKenney paul...@linux.vnet.ibm.com Date: Tue Jun 15 14:48:39 2010 + powerpc: Fix default_machine_crash_shutdown #ifdef botch but that doesn't appear to have been sent to stable. Ben. CC arch/powerpc/kernel/crash.o /build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/source_powerpc_none/arch/powerpc/kernel/crash.c: In function 'default_machine_crash_shutdown': /build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/source_powerpc_none/arch/powerpc/kernel/crash.c:448: error: implicit declaration of function 'crash_kexec_wait_realmode' make[6]: *** [arch/powerpc/kernel/crash.o] Error 1 make[5]: *** [arch/powerpc/kernel] Error 2 make[4]: *** [sub-make] Error 2 make[3]: *** [all] Error 2 make[3]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32/debian/build/build_powerpc_none_powerpc' make[2]: *** [debian/stamps/build_powerpc_none_powerpc_plain] Error 2 make[1]: *** [build_powerpc_none_powerpc_real] Error 2 make[2]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32' make: make[1]: Leaving directory `/build/buildd-linux-2.6_2.6.32-32-powerpc-emhBwA/linux-2.6-2.6.32' *** [debian/stamps/build-base] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Regards, Adam -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: Bug#619990: developers-reference: Update of merkel.d.o URLs
tag 619990 + patch thanks Le Tue, Mar 29, 2011 at 09:09:55AM +0200, Raphael Hertzog a écrit : On Tue, 29 Mar 2011, Charles Plessy wrote: - For Britney, I do not find the equivalent on ries.d.o for the following: merkel:/org/ftp-debian-org;/testing/update_out/ merkel:~aba/testing/update_out Was it moved somewhere else ? hertzog@ries:~$ ls -al /srv/release.debian.org/www/britney ls: cannot access /srv/release.debian.org/www/britney: No such file or directory Hi Raphaël, it seems that things changed overnight: plessy@ries:~$ ls -ald /srv/release.debian.org/www/britney drwxr-sr-x 5 release debian-release 4096 29 mars 10:20 /srv/release.debian.org/www/britney So finally the mirror link can be replaced. I attached the patch, that focuses on correcting the links after the move from merkel to ries. The links to the Git repositories would be an interesting addition. But I even found a third one: http://git.debian.org/?p=tools-release/britney.git If there is interest, I can extend the patch to include references to Git repositories, but since I am not familiar with them, I would need guidance. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan Index: pkgs.dbk === --- pkgs.dbk (révision 8599) +++ pkgs.dbk (copie de travail) @@ -2597,9 +2597,8 @@ /para para If you want to see more details, you can look it up on -filenamemerkel:/org/ftp-debian-org;/testing/update_out//filename (or -in filenamemerkel:~aba/testing/update_out/filename to see a setup with -a smaller packages file). Via web, it's at ulink +filenameries:/srv/release.debian.org/www/britney/update_output//filename. +Via web, it's at ulink url=http://ftp-master-host;/testing/update_out_code/;/ulink. /para para Index: resources.dbk === --- resources.dbk (révision 8599) +++ resources.dbk (copie de travail) @@ -260,9 +260,6 @@ the Bug Tracking System (BTS). /para para -It is restricted; a mirror is available on literalmerkel/literal. -/para -para If you plan on doing some statistical analysis or processing of Debian bugs, this would be the place to do it. Please describe your plans on email-debian-devel; before implementing anything, however, to @@ -278,7 +275,7 @@ end up on this server, see xref linkend=upload/. /para para -It is restricted; a mirror is available on literalmerkel/literal. +It is restricted; a mirror is available on literalftp-master-mirror;/literal. /para para Problems with the Debian FTP archive generally need to be reported as bugs Index: common.ent === --- common.ent (révision 8599) +++ common.ent (copie de travail) @@ -37,7 +37,7 @@ !ENTITY ftp-upload-host ftp.upload.debian.org !ENTITY ftp-eu-upload-host ftp.eu.upload.debian.org !ENTITY ssh-upload-host ssh.upload.debian.org -!ENTITY ftp-master-mirror merkel.debian.org +!ENTITY ftp-master-mirror ries.debian.org !ENTITY upload-queue /pub/UploadQueue/ !ENTITY url-debian-policy http://www-debian-org;/doc/debian-policy/;
sh4 architecture into Wheezy
Dear release team.
We(sh4 porting team) are now trying to run Debian on Renesas SH(sh4) CPU.
http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4
We want to support sh4 by the next release (Wheezy).
- Buildd status
Currentry, we are finished with build with packages of about 90%.
http://buildd.debian-ports.org/stats/sh4.txt
http://buildd.debian-ports.org/status/architecture.php?suite=unstablea=sh4priority=
- ArchiveQualification of sh4
http://wiki.debian.org/ArchiveQualification/sh4
How do you think about including sh4 in the next release?
If I have say go ahead!, we will start work with DSA, buildd
team, security team and ftp-master team.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
signature.asc
Description: Digital signature
Re: Bug#619990: developers-reference: Update of merkel.d.o URLs
On Wed, 30 Mar 2011, Charles Plessy wrote: Hi Raphaël, it seems that things changed overnight: Yes, see 20110329215524.ga21...@thrall.0x539.de by Phil Kern. The links to the Git repositories would be an interesting addition. But I even found a third one: http://git.debian.org/?p=tools-release/britney.git If there is interest, I can extend the patch to include references to Git repositories, but since I am not familiar with them, I would need guidance. I don't think dev-ref is the place to document the Git repositories in use by the release team, http://wiki.debian.org/Teams/ReleaseTeam would be much more suited. If you want to see more details, you can look it up on -filenamemerkel:/org/ftp-debian-org;/testing/update_out//filename (or -in filenamemerkel:~aba/testing/update_out/filename to see a setup with -a smaller packages file). Via web, it's at ulink +filenameries:/srv/release.debian.org/www/britney/update_output//filename. Please use the web URL (http://ftp-master-host;/testing/update_out/), it's much more stable convenient than this path on a Debian machine. +Via web, it's at ulink url=http://ftp-master-host;/testing/update_out_code/;/ulink. Please drop this link. It's really of no use to point people to britney's code (note it's not the web version of the above link...). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330055539.gb20...@rivendell.home.ouaza.com
