Re: What happened to Agnula.org (DeMuDi)?

[Free Ekanayaka]

Hi Andreas,

|--==> Andreas Tille writes:

  AT> On Fri, 16 Mar 2007, Tomas Nykung wrote:
  >>The reason I didn't recommend the OP to install Etch is that Etch is not
  >>ready for multimedia out of the box, most importantly there is no real
  >>time enabled kernel in stock Etch, and that is a _must_ when working
  >>with real time audio (latency).

  AT> Well, if this is the case why did the people behind 64studio not
  AT> maintain a kernel package that fits their needs.  I would be really
  AT> astonished if there would be no possibility to maintain a package
  AT> linux-image-rt (or whatever name).

I've contacted the debian-kernel team about one year ago, on behalf of
the Debian Multimedia Team [0] , and asked them about the possibility
of having such a linux-image-rt subarch.

They basically welcomed the idea but said very clearly that, before
actually doing that, we (as Debian Multimedia Team) should somehow
"guarantee" that we have enough forces to provide security updates for
such a kernel flavour after Etch gets released.

As I wasn't really sure that the team was able to provide security
support, I've temporary dropped the idea.

Note that this is not only a question of tweaking the kernel .config,
but also of applying a very big patch (the rt patch [1]), which can't
get included in the stock debian kernel right away, as too many
modifications are involved.

  >>It's of course possible to patch and compile the kernel oneself, and
  >>tweak the installation until it works for an audio studio or whatever,
  >>but it's a lot of fiddling around and Free has already done this with 64
  >>Studio, so why not use it? :)

  AT> I'm a little bit confused that Free did so because we had several
  AT> discussions in the CDD field and my impression was that his goal
  AT> would be to go the integration path.  May be he changed his mind
  AT> but it would be interesting if he would share his reasons to do so.

Well, A/DeMuDi stopped after our former sponsor decided to cut the
funding of the project, and not really because it was a fork of
Debian, not anymore maintainable. On the contrary almost every
improvement done within the scope of the DeMuDi project (packages, bug
fixes, tweaks, etc) has been merged back to Debian. And of course the
same is happening with 64 Studio, which is contributing in packaging
and maintaining several important audio packages, and it's fully
compatible with Debian etch.

  >>I haven't tried 64 Studio myself, but based on my experience with
  >>DeMuDi, and knowing that it's basically the same guys behind 64 Studio
  >>(Free) I think it must be good enough for me to dare recommend people to
  >>at least try it.

  AT> It is fine to recommend this and everybody (especially Free ;-)) is free
  AT> to use it.

Oh, if had to time do that I would be delighted! :)

Ciao,

Free


[0] http://wiki.debian.org/DebianMultimedia?highlight=%28multimedia%29
[1] http://people.redhat.com/mingo/realtime-preempt/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

DM vs DD and security

[Kevin Mark]

Hi,
I was mulling over a 3-tiered Debian contributer system:
Debian contributer(non-software contributer)
Debian maintainer(software contributer with limited upload rights)
Debian developer(software contributer with full upload rights)
where a a DC and DM would not have access to debian.org machines.

I think the idea of limiting access to debian.org machines to DDs would
be more secure than having all DC's and DM's have access. At least that
is what I surmise. 

Then I wondered what percentage of DDs require access to debian.org
machines? 

Could anyone find out this or if not, a guestimate would be ok.

And if its large, then could this be reduced in some way by having the
more common tasks be replaced by a web frontend with password access and
leave fewer tasks that require ssh access.

-- 
|  .''`.  == Debian GNU/Linux == |   my web site:   |
| : :' :  The  Universal |mysite.verizon.net/kevin.mark/|
| `. `'  Operating System| go to counter.li.org and |
|   `-http://www.debian.org/ |be counted! #238656   |
|  my keyserver: subkeys.pgp.net | my NPO: cfsg.org |
|join the new debian-community.org to help Debian!  |


signature.asc
Description: Digital signature

future keys

[Adam Borowski]

Whee?!

While testing Etch upgrades on some old boxes, I noticed that key management
issues get worse and worse, especially if some time happens between upgrades.
Even when ignoring all users of "testing", upgrades between stable releases
kind of _have_ to work well.  So, here's my idea:

Could you please generate the Lenny and perhaps even Alien keys, both
testing and stable, and stick them into debian-archive-keyring before Etch
is released?  The private keys could be, let's say, buried under a tree
in the Secretary's garden. [1]

While keeping a key that is in use safe can be a tricky issue, having a
future key stored away is something easy to do in a secure manner.  And,
when the need arises, the public keys are already distributed.

[1]. Most of less melodramatic solutions would work at least as good.
-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problems packaging a kernel using cdbs

[Goswin von Brederlow]

"Luis R. Rodriguez" <[EMAIL PROTECTED]> writes:

> On 3/16/07, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
>> On Fri, Mar 16, 2007 at 01:50:14PM -0400, Luis R. Rodriguez wrote:
>> > I've seen some posts on debian-devel from a while back which indicates
>> > some of you (Robert Millan) you've build a kernel using cdbs. I'm
>>
>> Perhaps I misunderstand, but can't you use kernel-package?
>
> My goal is to actually generate a debian package which will have a
> very small x86 kernel and a very very custom initramfs (bundles of
> software) for a PXE boot environment. Kernel-package lets me build a
> debian package out of the kernel source tree, but I want to do
> something a bit different. I just looked into kernel-package's support
> for generating custom initramfs cpio archives but it really lacks
> documentation even on the source. I then checked out initramfs-tools
> but just installing this package makes it spin an generate an
> initramfs for me on /boot/ without even consulting...; then I read the
> man page for mkinitramfs and I see this:
>
> ---
>   At  boot  time, the kernel unpacks that archive into RAM disk,
> mounts and uses it as initial root file system. All finding of the
> root device hap-
>   pens in this early userspace.
> --
>
> initramfs is not an archive that gets put into a RAM disk, the ramdisk
> is only used by initrd... the new design of initramfs replaces that
> whole mess and takes advantage of the new tmpfs filesystem. The fact
> that the man page has it wrong doesn't make me want to touch that in
> any way.

Actualyl I think the manpage is right. The archive gets put into the
"ramdisk" as that is how the bootloader passes the data along.

The initramfs code then checks for the achive signature in the
"ramdisk", unpacks it to tmpfs and frees the ramdisk.

That is similar to the initrd code looking at the "ramdisk", finding the
gzip signature and uncompressing it into the actual rmadisk.

> Anyway -- I just tried to use "make-kpkg build" as the build commands
> for my "kernel" target and still run into the same problem. Running
> "make-kpkg build" manually works though. So there is something about
> using cdbs that is not letting me build the kernel right. The include
> path gets (./include) is getting ignored completely for some reason.
>
>  Luis

Please do use make-kpkg. If you need something in kernel-package to
change for your use case (like building the initrd during compile)
then please talk to the maintainer to support this. It is a bad Idea
to duplicate the kernel building and packaging. It is bad enough
linux-2.6 source has started to do that.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for testers: reportbug-ng

[Bastian Venthur]

Am 19.03.2007 01:34 schrieb Bastian Venthur:
> Problems I'm currently aware of:
>  * Getting the version of installed packages a package depends on is
>slow

Which is already fixed.

>  * Searching for a bugs of a package does not yet check the
>source-package's bugs as well

Which is not reasonable, so I'll stick to the current behavior for now.

Example: the source package of kate is kdebase. Kate has like ~40 bugs
(including: outstanding, forwarded and resolved) kdebase has like ~1000
bugs. Obviously the user should not see all those totally unrelated bugs.

Reportbug's behavior is BTW the exact opposite it shows the bugs of the
source package, I wonder why this is?


-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for testers: reportbug-ng

[Frans Pop]

On Monday 19 March 2007 12:27, Bastian Venthur wrote:
> >  * Searching for a bugs of a package does not yet check the
> >source-package's bugs as well
>
> Which is not reasonable, so I'll stick to the current behavior for now.

You could make it an option: button or option "Show all bugs for source 
package".


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: future keys

[Javier Fernández-Sanguino Peña]

On Mon, Mar 19, 2007 at 10:49:47AM +0100, Adam Borowski wrote:
> Whee?!
> 
> While testing Etch upgrades on some old boxes, I noticed that key management
> issues get worse and worse, especially if some time happens between upgrades.
> Even when ignoring all users of "testing", upgrades between stable releases
> kind of _have_ to work well.  So, here's my idea:

Could you please fill an 'upgrade-report' bug describing those issues? That
way we could document them in the Release Notes (if we want to support the
upgrade paths you are using).

Regards

Javier


signature.asc
Description: Digital signature

Re: Call for votes for the Debian Project Leader Elections 2007

[Lionel Elie Mamane]

e0acebd2-71f1-4df8-ae4d-50355ad7aa81
[ 1 ] Choice 1: Wouter Verhelst
[ 9 ] Choice 2: Aigars Mahinovs
[ 5 ] Choice 3: Gustavo Franco
[ 3 ] Choice 4: Sam Hocevar
[ 4 ] Choice 5: Steve McIntyre
[ 2 ] Choice 6: Raphaël Hertzog
[ 8 ] Choice 7: Anthony Towns
[ 6 ] Choice 8: Simon Richter
[ 7 ] Choice 9: None Of The Above


signature.asc
Description: Digital signature

Re: Changelog not signed by "human"

[Lionel Elie Mamane]

On Fri, Mar 16, 2007 at 07:56:31PM +0100, Wouter Verhelst wrote:
> On Fri, Mar 16, 2007 at 09:27:04AM -0700, Kapil Hari Paranjape wrote:

>>  screen (4.0.3-0.3+b1) unstable; urgency=low

>>* Binary-only non-maintainer upload for i386; no source changes.
>>* Rebuild to fix a bug of indeterminate origin that causes screen to 
>> switch

>>   -- Debian/i386 Build Daemon   Tue,  6 Mar 2007 
>> 17:06:12 -0600

> When a binNMU is necessary, someone with appropriate access to the right
> machine will run this:

> wanna-build -b /build-db -d unstable -m "Rebuild for the GCC10 
> transition" --binNMU=1 foobar_1.2-3

> which will result in the buildd host downloading the source, adding a
> changelog entry, compiling it, and the human behind the curtains signing
> the log.

> Since the buildd host generates the changelog entry, it's only natural
> that it's also the buildd host which is listed in the changelog
> entry.

Since it is acting on behalf of the "someone with appropriate access
to the right machine", and that is the person providing the "rebuild
for the GCCC10 transition" message, it would seem natural to me that
that's the name the changelog is signed with. After all, my changelog
entries are not signed by my Emacs or my debchange.

-- 
Lionel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for testers: reportbug-ng

[Magnus Holmgren]

On Monday 19 March 2007 12:27, Bastian Venthur wrote:
> Am 19.03.2007 01:34 schrieb Bastian Venthur:
> >  * Searching for a bugs of a package does not yet check the
> >source-package's bugs as well
>
> Which is not reasonable, so I'll stick to the current behavior for now.

It's not reasonable to list all bugs for the source package (including all 
bugs in all binary packages built from the same source), but it is reasonable 
to list bugs associated *only* with the source package, because those can 
affect all binary packages and are typically much fewer (but is it feasible 
to extract them?).

-- 
Magnus Holmgren[EMAIL PROTECTED]
   (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is better for 
   Scrabble (50 point bonus for clearing your rack)" -- Dave Evans


pgpgEYnWGQuLZ.pgp
Description: PGP signature

Re: Call for testers: reportbug-ng

[Bastian Venthur]

[Looks like my previous response is lost, so I'm writing it again]

Am 19.03.2007 02:39 schrieb Don Armstrong:
> On Mon, 19 Mar 2007, Bastian Venthur wrote:
>>  * Grepping information from HTML-code is unreliable and ugly. The BTS
>>should support answers in machine readable format
> 
> We do, using the SOAP interface. If you want more features than it has
> currently, you need only file wishlist bugs.

Is the SOAP interface already up and running on bugs.debian.org? If yes,
is some documentation available?


Cheers,

Bastian


-- 
Bastian Venthur  http://venthur.de
Debian Developer venthur at debian org


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DM vs DD and security

[Margarita Manterola]

On 3/19/07, Kevin Mark <[EMAIL PROTECTED]> wrote:

Then I wondered what percentage of DDs require access to debian.org
machines?


I, for myself, have used debian machines mainly for doing NMUs of bugs
in architectures which I normally wouldn't have access to.

This kind of use is difficult to anticipate, you don't know you'll
need it until you find a bug that you want to fix in that arch.

Also, the delayed queue is currently implemented as an scp to gluck,
so access to gluck is needed for that.


And if its large, then could this be reduced in some way by having the
more common tasks be replaced by a web frontend with password access and
leave fewer tasks that require ssh access.


The only other service I've used from Debian machines is madison,
which could be replaced by a front-end, yes.

--
Besos,
Marga


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DM vs DD and security

[Loïc Minier]

On Mon, Mar 19, 2007, Margarita Manterola wrote:
> The only other service I've used from Debian machines is madison,
> which could be replaced by a front-end, yes.

 I think rmadison is a public alternative.

-- 
Loïc Minier


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problems packaging a kernel using cdbs

[Luis R. Rodriguez]

On 3/19/07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:

"Luis R. Rodriguez" <[EMAIL PROTECTED]> writes:

> On 3/16/07, Roberto C. Sanchez <[EMAIL PROTECTED]> wrote:
>> On Fri, Mar 16, 2007 at 01:50:14PM -0400, Luis R. Rodriguez wrote:
>> > I've seen some posts on debian-devel from a while back which indicates
>> > some of you (Robert Millan) you've build a kernel using cdbs. I'm
>>
>> Perhaps I misunderstand, but can't you use kernel-package?
>
> My goal is to actually generate a debian package which will have a
> very small x86 kernel and a very very custom initramfs (bundles of
> software) for a PXE boot environment. Kernel-package lets me build a
> debian package out of the kernel source tree, but I want to do
> something a bit different. I just looked into kernel-package's support
> for generating custom initramfs cpio archives but it really lacks
> documentation even on the source. I then checked out initramfs-tools
> but just installing this package makes it spin an generate an
> initramfs for me on /boot/ without even consulting...; then I read the
> man page for mkinitramfs and I see this:
>
> ---
>   At  boot  time, the kernel unpacks that archive into RAM disk,
> mounts and uses it as initial root file system. All finding of the
> root device hap-
>   pens in this early userspace.
> --
>
> initramfs is not an archive that gets put into a RAM disk, the ramdisk
> is only used by initrd... the new design of initramfs replaces that
> whole mess and takes advantage of the new tmpfs filesystem. The fact
> that the man page has it wrong doesn't make me want to touch that in
> any way.

Actualyl I think the manpage is right. The archive gets put into the
"ramdisk" as that is how the bootloader passes the data along.

The initramfs code then checks for the achive signature in the
"ramdisk", unpacks it to tmpfs and frees the ramdisk.

That is similar to the initrd code looking at the "ramdisk", finding the
gzip signature and uncompressing it into the actual rmadisk.


Nope, its very wrong. You do not need ramdisk support to support
initramfs at all, we don't use ramdisk in any way. By default, meaning
its supported without regard to your .config, the cpio archive gets
packed into the kernel and later always extracted into rootfs. In fact
the entire block layer can be removed, which is required by ramdisk
support, and you will still get initramfs support, even if you want
external initramfs support (ie, grub initrd line). I have a patch
that'll allow you to get external initramfs support even if you do not
want the block layer, currently it doesn't because of the layout of
Kconfig, but its supposed to though, it works and I have tested it.


> Anyway -- I just tried to use "make-kpkg build" as the build commands
> for my "kernel" target and still run into the same problem. Running
> "make-kpkg build" manually works though. So there is something about
> using cdbs that is not letting me build the kernel right. The include
> path gets (./include) is getting ignored completely for some reason.
>
>  Luis

Please do use make-kpkg. If you need something in kernel-package to
change for your use case (like building the initrd during compile)
then please talk to the maintainer to support this. It is a bad Idea
to duplicate the kernel building and packaging. It is bad enough
linux-2.6 source has started to do that.


It does not do what I want it to right now and I need to move on
quick. I've adopted my own debian/rules instead of cdbs as well.
Perhaps if I have time I'll hack on make-kpkg.

Thanks,

 Luis


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

DBus IDL

[jacky . guillou]

Hi,

I'm not sure this is the right forum for this question but...

I'm currently doing some investigation on DBus.
I have been playing with the glib and java bindings but I feel like
something is missing.
I would like to be able to create my own complex type (giving it a
name), and define some methods which use this complex type as a
parameter.




















Is there a way to do something similar to that ?

Another question :
Why doesn't the dbus-binding-tool (glib) generate anything concerning
the signals that may be defined in the XML service description,
whereas the java stub generator does create some class for the
signals ?

Thanks

Jacky


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for testers: reportbug-ng

[Don Armstrong]

On Mon, 19 Mar 2007, Bastian Venthur wrote:
> [Looks like my previous response is lost, so I'm writing it again]
> 
> Am 19.03.2007 02:39 schrieb Don Armstrong:
> > On Mon, 19 Mar 2007, Bastian Venthur wrote:
> >>  * Grepping information from HTML-code is unreliable and ugly. The BTS
> >>should support answers in machine readable format
> > 
> > We do, using the SOAP interface. If you want more features than it has
> > currently, you need only file wishlist bugs.
> 
> Is the SOAP interface already up and running on bugs.debian.org?

Yes. [Well, effectively; it'll behave as if it was running there, and
it will be running there eventually.]

> If yes, is some documentation available?

See #377520; if you need more features, let me know.


Don Armstrong

-- 
"There's no problem so large it can't be solved by killing the user
off, deleting their files, closing their account and reporting their
REAL earnings to the IRS."
 -- The B.O.F.H..

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DM vs DD and security

[Mark Brown]

On Mon, Mar 19, 2007 at 05:41:32AM -0400, Kevin Mark wrote:

> I was mulling over a 3-tiered Debian contributer system:
> Debian contributer(non-software contributer)
> Debian maintainer(software contributer with limited upload rights)
> Debian developer(software contributer with full upload rights)

You might want to have a look at the thread "Developers vs Uploaders" on
debian-project.  Discussions about project organisation such as this are
more appropriate for that list.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: DM vs DD and security

[Gunnar Wolf]

Kevin Mark dijo [Mon, Mar 19, 2007 at 05:41:32AM -0400]:
> Hi,
> I was mulling over a 3-tiered Debian contributer system:
> Debian contributer(non-software contributer)
> Debian maintainer(software contributer with limited upload rights)
> Debian developer(software contributer with full upload rights)
> where a a DC and DM would not have access to debian.org machines.

Umh... I don't like that much viewing this as three tiers, three
consecutive stages you progress on as if you were progressing towards
nirvana :) And, besides, you left out the "voting rights" part, which
is quite important as well.

> I think the idea of limiting access to debian.org machines to DDs would
> be more secure than having all DC's and DM's have access. At least that
> is what I surmise. 
> 
> Then I wondered what percentage of DDs require access to debian.org
> machines? 

Umh... Looking at Marga's answer, and thinking a bit on this, maybe
the answer leads somewhere else... As she points out, we all might
need access to a @debian.org machine every now and then, to get to
some information, to update our people.debian.org information, or
whatever - Now, what about this probably over-simplified workflow?

1- Nobody has access to @d.o machines by default
2- There is a subset of @d.o machines which accept DD login
   2.1- There might even be a sub-subset which accept DM or DC
 login. Worth considering :)
3- If a DD needs access to a specific machine, (he|she|it) sends a
   GPG-signed machine-readable message requesting access to the
   specific needed machine
4- After a given time, access will be automatically revoked
   4.1- If somebody often requires access to a machine or set of
machines, (he|she|it) can request for permanently enabled
access

I think this would fit most of us quite nicely, and strongly help
prevent breakins like the ones we have suffered. What do you say?

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


signature.asc
Description: Digital signature

Re: Problems packaging a kernel using cdbs

[Ben Hutchings]

On Mon, 2007-03-19 at 11:26 -0400, Luis R. Rodriguez wrote:
> On 3/19/07, Goswin von Brederlow <[EMAIL PROTECTED]> wrote:
> > "Luis R. Rodriguez" <[EMAIL PROTECTED]> writes:

> > > initramfs is not an archive that gets put into a RAM disk, the ramdisk
> > > is only used by initrd... the new design of initramfs replaces that
> > > whole mess and takes advantage of the new tmpfs filesystem. The fact
> > > that the man page has it wrong doesn't make me want to touch that in
> > > any way.
> >
> > Actualyl I think the manpage is right. The archive gets put into the
> > "ramdisk" as that is how the bootloader passes the data along.
> >
> > The initramfs code then checks for the achive signature in the
> > "ramdisk", unpacks it to tmpfs and frees the ramdisk.
> >
> > That is similar to the initrd code looking at the "ramdisk", finding the
> > gzip signature and uncompressing it into the actual rmadisk.
> 
> Nope, its very wrong. You do not need ramdisk support to support
> initramfs at all, we don't use ramdisk in any way. By default, meaning
> its supported without regard to your .config, the cpio archive gets
> packed into the kernel and later always extracted into rootfs.

It's passed to the kernel at boot time just like an initrd image would
be, and while tmpfs is rather different from a Linux RAM disk, it's a
lot like the RAM disk provided by the AmigaOS and maybe some other
operating systems.  I can see that it would be more correct and perhaps
less confusing for the manual page to say "tmpfs" though.

Ben.

-- 
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: DM vs DD and security

[Robert Collins]

On Mon, 2007-03-19 at 05:41 -0400, Kevin Mark wrote:
> And if its large, then could this be reduced in some way by having the
> more common tasks be replaced by a web frontend with password access
> and leave fewer tasks that require ssh access.


Because ssh is /less/ secure than ssl?

-Rob
-- 
GPG key available at: .


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

Messages delayed on packages.debian.org?

[Christian Perrier]

Dear Debian admins,

I again suspect some delays in mail delivery for messages sent to
@packages.debian.org

I use such addresses quite extensively during my own various jihads
such as l10n updates or the newly founded debconf rewrite project
aaimed at proofreading all debconf templates.

As of last Sunday, I sent a test mail to
"[EMAIL PROTECTED]". geneweb being a package of mine, I'd
expect the mail to be delivered to me a few minutes/hours after.

Indeed, nearly two days after, I still didn't get this mail.

May someone check the mail queue on ?

Several weeks ago (back in January, IIRC), Joerg Jaspert did flush the
mail queue on some host a few times after I reported the same issue.

In case something is discovered, I suggest this issue to get some
attention by the Debian admins, as it may affect severely the way to
communicate with package maintainers on a reliable way.

-- 





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: DM vs DD and security

[Peter Makholm]

Robert Collins <[EMAIL PROTECTED]> writes:

> On Mon, 2007-03-19 at 05:41 -0400, Kevin Mark wrote:
>> And if its large, then could this be reduced in some way by having the
>> more common tasks be replaced by a web frontend with password access
>> and leave fewer tasks that require ssh access.
>
> 
> Because ssh is /less/ secure than ssl?

Yes, because a well written web frontend for a specific task is more
secure than a general purpose shell account.

//Makholm


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]