Hai SEO Friends.. ADD ME TO YOUR LIST
*Hai SEO,* Hope you doing well. I am SEO Prasad. I wanted to built a wide SEO network. Already added many SEO guys. So thought to add you in my friend list. Kindly accept the request and add me to your professional Network. My gTalk ID is : seo.onlined...@gmail.com. It would be helpful for us to share our links and skills and grow our professional network.And If your there in orkut. Kindly send me a friend request to the above Gmail ID. Hoping to have a strong SEO relationship With you. Thanks for your time and responds. *Thanks & Regards,* SEO Prasad
Re: ries, AKA ftp-master.debian.org back, status
> When this long uploadqueue process is done I will run a manual dinstall, > closely monitoring the steps taken and after this the ftpmaster service > will be back up normal. And we are all set, all cronjobs of the release and ftp teams are back on now, the dinstall in the night went all nice with only a minor problem. (The debtags information will be back with next run) -- bye, Joerg I want to share something with you: The three little sentences that will get you through life. Number 1: Cover for me. Number 2: Oh, good idea, Boss! Number 3: It was like that when I got here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ljd3hdw4@gkar.ganneff.de
Bug#576406: ITP: libfusioninventory-agent-task-snmpquery-perl -- SNMP devices scan support for FusionInventory Agent
Package: wnpp Severity: wishlist Owner: "Gonéri Le Bouder" Owner: "Gonéri Le Bouder" * Package name: libfusioninventory-agent-task-snmpquery-perl Version : 1.0 Upstream Author : David DURIEUX * URL : http://www.FusionInventory.org * License : GPLv2+ Programming Lang: Perl Description : SNMP devices scan support for FusionInventory Agent This module scans your networks to get informations from devices with SNMP protocol: -networking devices discovery within an IP range - network switche, printer and router analyse - relation between computer / printer / switch port - identify unknown MAC addresses - report printer cartridge and ounter status - support management of SNMP versions v1, v2, v3 . The plugin depends on FusionInventory for GLPI. OCS Inventory can't use this plugin. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100404094533.3988.41953.report...@aofr08093.si.fr.atosorigin.com
Re: Best practices for development workstations
[Robert Collins] > Wearing my squid upstream hat: please file bugs if squid is > misbehaving. Squid is used in many high volume high load web sites, > so if there are reliability bugs we really really want to know about > them. If you really plan to fix apt and squid related problems, it would be nice if #56 was fixed. Also, the default setup for Squid do not allow it to proxy all packages in the archive (the maximum_object_size is too small). In Debian Edu, we increased it from 20480 KB to 153600 KB, to allow the openartwork and fluid-soundfound packages to be proxied. In Debian Edu, PXE installation is set up out of the box, and to use it for several machines it is vital to proxy also the big packages. :) Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flmxxjy0ka@login2.uio.no
Re: Best practices for development workstations
On Sun, 2010-04-04 at 12:27 +0200, Petter Reinholdtsen wrote: > [Robert Collins] > > Wearing my squid upstream hat: please file bugs if squid is > > misbehaving. Squid is used in many high volume high load web sites, > > so if there are reliability bugs we really really want to know about > > them. > > If you really plan to fix apt and squid related problems, it would be > nice if #56 was fixed. HTTP pipelining is broken; don't use it. (Its now considered fundamentally insecure - see the HTTP Smuggling whitepaper for all the gory details). We're unlikely to ever invest a lot of time in it: browsers are now going for many parallel TCP connections, and the HTTP working group is blessing more connections as good practice. (This is vs deep pipelining). That said, squid handing back a truncated response is definitely a bug, if it is indeed squid causing that (the bug doesn't have enough data to tell - a tcpdump of a broken session would help, I suspect). > Also, the default setup for Squid do not allow it to proxy all > packages in the archive (the maximum_object_size is too small). In > Debian Edu, we increased it from 20480 KB to 153600 KB, to allow the > openartwork and fluid-soundfound packages to be proxied. In Debian > Edu, PXE installation is set up out of the box, and to use it for > several machines it is vital to proxy also the big packages. :) Michael has created a squid-deb-proxy in Ubuntu, which should be pretty trivial to include in Debian, that configures squid appropriately for apt; and advertises it over avahi; squid-deb-proxy-client teaches apt to use a zeroconf configured proxy. -Rob signature.asc Description: This is a digitally signed message part
Re: Proposal: Automatic selection of hardware specific packages
[Julian Andres Klode] > Ubuntu developed a tool called 'jockey' for installing hardware > drivers. There is an ITP for it in Bug #436722. Jockey is in my > opinion the best place to do something like this. I CCed Martin > Pitt, the developer of jockey (and quoted the remaining parts of the > email in case he did not read the original one). Yes, it was a nice tool. I tested it for the first time a few weeks ago. I noticed in #436722 that Martin Pitt was positive to shared maintenance. What is holding you from uploading the package to Debian? The ITP haven't seen any progress for a long time. :) Note that I GUI tool would be nice for the non-free stuff, but would be a bad idea for other hardware specific packages like RAID administration tools. For this, I would like to integrate something like discover-pkginstall into the hwsetup package in debian-installer, to make sure hardware specific packages are automatically installed when it make sense. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2flhbnrxxkm@login2.uio.no
Re: Proposal: Automatic selection of hardware specific packages
Hi, If you actually want a student to look at your proposal, please put it on the wiki :) http://wiki.debian.org/gsoc Cheers Arthur On Sun, Apr 4, 2010 at 1:32 PM, Petter Reinholdtsen wrote: > > [Julian Andres Klode] >> Ubuntu developed a tool called 'jockey' for installing hardware >> drivers. There is an ITP for it in Bug #436722. Jockey is in my >> opinion the best place to do something like this. I CCed Martin >> Pitt, the developer of jockey (and quoted the remaining parts of the >> email in case he did not read the original one). > > Yes, it was a nice tool. I tested it for the first time a few weeks > ago. > > I noticed in #436722 that Martin Pitt was positive to shared > maintenance. What is holding you from uploading the package to > Debian? The ITP haven't seen any progress for a long time. :) > > Note that I GUI tool would be nice for the non-free stuff, but would > be a bad idea for other hardware specific packages like RAID > administration tools. For this, I would like to integrate something > like discover-pkginstall into the hwsetup package in debian-installer, > to make sure hardware specific packages are automatically installed > when it make sense. > > Happy hacking, > -- > Petter Reinholdtsen > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: http://lists.debian.org/2flhbnrxxkm@login2.uio.no > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/u2vc09ddae71004040437g619dacddq65461829b49fb...@mail.gmail.com
Re: deb.li - the Debian ShortURL Service - beta test
On Sun, 2010-04-04 at 00:30 +0200, Bernd Zeimetz wrote: > On 04/03/2010 05:29 PM, Frank Lin PIAT wrote: > > How can we make sure that all URL don't become broken once Bernd's > > attention move away from Debian (this may happen)? > > If the service is used I'd like to give it into the hands of DSA and have it > runnign on DSA hardware, transfer the domain into the hands of SPI anf just > take > care of the software... I like the plan, Thank you, Franklin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270381519.3705.883.ca...@solid.paris.klabs.be
Keysigning near Rimouski, Quebec, Canada?
Hi all, My key is old and needs to be replaced. Is there anyone close to Rimouski (Québec) for key signing? I also regurlarly go to Québec City. Thanks, Peter -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4638.1270391...@mixed
Bug#576437: ITP: python-gevent -- a coroutine-based Python networking library
Package: wnpp Severity: wishlist Owner: "Örjan Persson" * Package name: python-gevent Version : 0.12.2 Upstream Author : Denis Bilenko * URL : http://www.gevent.org/ * License : MIT Programming Lang: C, Python Description : a coroutine-based Python networking library gevent is a coroutine-based Python networking library that uses greenlet to provide a high-level synchronous API on top of libevent event loop. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (600, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100404163836.18082.87556.report...@bender.fobie.net
Popcon disabled?
Hello, since some days I noticed that the 'Popularity contest statistics' of packages are not updated. For example for the package "xfe" the last value of 'popcon' comes from 2010-04-01. Does anyone know why? Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: Some mail changes
On Sun, 4 Apr 2010, Stephen Gran wrote: > Hello all, > > Currently, there is an implicit conflation between $u...@debian.org and > $u...@$machine.debian.org. This means that mail to, for instance, > sg...@gluck.debian.org is handled the same way as mail to > sg...@debian.org, whether or not I have an account on the gluck. I'd > quite like to change this. > > Unfortunately, this will break some people's mail setups if they rely on > this implicit behavior. The most common usage I have seen of this type > is a user whoes does not have a mail forward set and relies on, for > instance, procmail on master to do the work for them. If you are > currently relying on something like this, please set your mail forward > to $u...@master.debian.org. This will allow procmail/.forward/etc > handling to continue. There appear to currently be 27 active users who > do not have mail forwards set in ldap, so this mail is primarily to > them. A list can be provided, but the same list can be obtained with: > > ldapsearch -x > '(&(uid=*)(!(emailForward=*))(!(accountStatus=*))(!(objectClass=debianRoleAccount)))' > uid > > from any debian.org machine. I am one of those 27. Would not be easier and more straightforward if the mail setup is automatically changed for us? The net effect would be the same: receiving @debian.org mail on master. Am I missing anything? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.1.10.1004042209060.16...@kolmogorov.unex.es
Re: Some mail changes
This one time, at band camp, Santiago Vila said: > On Sun, 4 Apr 2010, Stephen Gran wrote: > > > Hello all, > > > > Currently, there is an implicit conflation between $u...@debian.org and > > $u...@$machine.debian.org. This means that mail to, for instance, > > sg...@gluck.debian.org is handled the same way as mail to > > sg...@debian.org, whether or not I have an account on the gluck. I'd > > quite like to change this. > > > > Unfortunately, this will break some people's mail setups if they rely on > > this implicit behavior. The most common usage I have seen of this type > > is a user who does not have a mail forward set and relies on, for > > instance, procmail on master to do the work for them. If you are > > currently relying on something like this, please set your mail forward > > to $u...@master.debian.org. This will allow procmail/.forward/etc > > handling to continue. There appear to currently be 27 active users who > > do not have mail forwards set in ldap, so this mail is primarily to > > them. A list can be provided, but the same list can be obtained with: > > > > ldapsearch -x > > '(&(uid=*)(!(emailForward=*))(!(accountStatus=*))(!(objectClass=debianRoleAccount)))' > > uid > > > > from any debian.org machine. > > I am one of those 27. > > Would not be easier and more straightforward if the mail setup is > automatically changed for us? Easier and more straightforward for who? > The net effect would be the same: receiving @debian.org mail on master. > > Am I missing anything? While I appreciate the vote of confidence in my omniscience, I do not share it. I would much prefer people to use the opportunity to decide what to do with their own mail. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Handling optimization flags in Debian packages
Hi all,
I've faced an issue (#557550) which is much probably caused by a CPU which
doesn't support SSE2 instructions. I'm not sure about the best way to address
this. Any suggestion will be very welcome. Actually I can see the following
workarounds:
1) consider that most of CPUs support this flag, so tell the reporter to
compile the package by him/herself.
2) remove this specific flag during package building, ending with a
non-optimized software available for all users.
3) create a specific -sse2 (or -non-sse2) package.
4) ask the upstream to code runtime checks before using SSE2 specific
instructions (is that possible?).
For now, my choice is #1.
Btw, there is an old proposal [0] related to this subject but I have no ideia
how it's going.
[0] http://lists.debian.org/debian-devel/2003/06/msg01714.html
--
.''`. Tiago Bortoletto Vaz GPG : 1024D/A504FECA
: :' : http://tiagovaz.org XMPP : tiago at jabber.org
`. `' tiago at {tiagovaz,debian}.org IRC : tiago at OFTC
`-Debian GNU/Linux - The Universal OS http://www.debian.org
signature.asc
Description: Digital signature
Re: Some mail changes
On Sun, 4 Apr 2010, Stephen Gran wrote: > > The net effect would be the same: receiving @debian.org mail on master. > > > > Am I missing anything? > > While I appreciate the vote of confidence in my omniscience, I do not > share it. I would much prefer people to use the opportunity to decide > what to do with their own mail. Those of us not having a mail forward have already decided (implicitly, if you like) to receive the email in master. Why would we have to do something for things to work as before? Juat announce "Effective [some day], people who do not have an email forward setup will have one pointing to master, so that they will continue to receive email in master" and be done with it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.1.10.1004042303220.20...@kolmogorov.unex.es
Re: Handling optimization flags in Debian packages
On 04.04.2010 22:29, Tiago Bortoletto Vaz wrote:
Hi all,
I've faced an issue (#557550) which is much probably caused by a CPU which
doesn't support SSE2 instructions. I'm not sure about the best way to address
this. Any suggestion will be very welcome. Actually I can see the following
workarounds:
1) consider that most of CPUs support this flag, so tell the reporter to
compile the package by him/herself.
Quite bad.
2) remove this specific flag during package building, ending with a
non-optimized software available for all users.
3) create a specific -sse2 (or -non-sse2) package.
Sounds like too much work.
4) ask the upstream to code runtime checks before using SSE2 specific
instructions (is that possible?).
AFAIK it is possible.
For now, my choice is #1.
This is a bad decision.
The only architecture where you can assume, that all CPUs support MMX
and SSE{2} is amd64. So you can enable the optimizing flags only on this
arch.
I am also handling it this way in my packages.
--
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bb90113.2080...@debian.org
Re: Handling optimization flags in Debian packages
Tiago Bortoletto Vaz writes: > 1) consider that most of CPUs support this flag, so tell the reporter to > compile the package by him/herself. This is not acceptable and would make your package rc-buggy. Even though it's called i386 and in fact only supports i486, we are not in a state where we want to ditch support for all pre-Pentium 3 CPUs. > 2) remove this specific flag during package building, ending with a > non-optimized software available for all users. > > 3) create a specific -sse2 (or -non-sse2) package. > > 4) ask the upstream to code runtime checks before using SSE2 specific > instructions (is that possible?). > > For now, my choice is #1. It's not an option, so you will need to do something else. Marc -- BOFH #441: Hash table has woodworm pgpNYlXKUHVbF.pgp Description: PGP signature
Re: Handling optimization flags in Debian packages
On 04/04/10 16:29, Tiago Bortoletto Vaz wrote: Hi all, I've faced an issue (#557550) which is much probably caused by a CPU which doesn't support SSE2 instructions. I'm not sure about the best way to address this. Any suggestion will be very welcome. Actually I can see the following workarounds: 1) consider that most of CPUs support this flag, so tell the reporter to compile the package by him/herself. 2) remove this specific flag during package building, ending with a non-optimized software available for all users. 3) create a specific -sse2 (or -non-sse2) package. 4) ask the upstream to code runtime checks before using SSE2 specific instructions (is that possible?). 5) Build twice, install both binaries in /usr/lib/package, and ship a wrapper script that calls the appropriate binary depending on the CPU flags. Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/hpb1i7$e9...@dough.gmane.org
Re: Handling optimization flags in Debian packages
On Sun, 2010-04-04 at 17:29 -0300, Tiago Bortoletto Vaz wrote: > Hi all, > > I've faced an issue (#557550) which is much probably caused by a CPU which > doesn't support SSE2 instructions. I'm not sure about the best way to address > this. Any suggestion will be very welcome. Actually I can see the following > workarounds: > > 1) consider that most of CPUs support this flag, so tell the reporter to > compile the package by him/herself. This is the wrong answer; we officially support CPUs dating back to 486. > 2) remove this specific flag during package building, ending with a > non-optimized software available for all users. > > 3) create a specific -sse2 (or -non-sse2) package. Both acceptable. > 4) ask the upstream to code runtime checks before using SSE2 specific > instructions (is that possible?). [...] This is the best. Also there are libraries like liboil that implement various common functions that can benefit from SIMD extensions and that automatically select the right version at run-time. Perhaps this package can use that? 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
New Kernel 2.6.32-4-amd -686
Dear Debian Team, Many thanks for releasing the 2.6.32-4-amd and -686 Debian kernel in sid. This is really a big step forward. I especially benefit from DRM/KMS in conjunction with the new radeon (also frame buffer) drivers. A great kernel! Thanks again, and best regards Han, Shi-Ming -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bb9053a.10...@hkicpdr.org
Re: Some mail changes
This one time, at band camp, Santiago Vila said: > On Sun, 4 Apr 2010, Stephen Gran wrote: > > > > The net effect would be the same: receiving @debian.org mail on > > > master. > > > > > > Am I missing anything? > > > > While I appreciate the vote of confidence in my omniscience, I do > > not share it. I would much prefer people to use the opportunity to > > decide what to do with their own mail. > > Those of us not having a mail forward have already decided > (implicitly, if you like) to receive the email in master. > > Why would we have to do something for things to work as before? > > Juat announce "Effective [some day], people who do not have an email > forward setup will have one pointing to master, so that they will > continue to receive email in master" and be done with it. I am going to politely assume that what you are saying is "would you please do this for me", rather than "I insist you do this because I can't be bothered to waste a precious 30 seconds on it and would rather write several mails instead". In response to your request, I am sorry, but I am unlikely to do a mass update of people's mail forwards for this. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Some mail changes
On Sun, 4 Apr 2010, Stephen Gran wrote: > This one time, at band camp, Santiago Vila said: > > Juat announce "Effective [some day], people who do not have an email > > forward setup will have one pointing to master, so that they will > > continue to receive email in master" and be done with it. > > I am going to politely assume that what you are saying is "would you > please do this for me", rather than "I insist you do this because I > can't be bothered to waste a precious 30 seconds on it and would rather > write several mails instead". In response to your request, I am sorry, > but I am unlikely to do a mass update of people's mail forwards for > this. I'm sorry too, but sending email to /dev/null as a punishment for not reading -devel-announce in 14 days (for whatever reason) is everything but "polite". It's true that it takes very little time to read the docs and find this: echo "emailforward: f...@bar.com" | gpg --clearsign | mail cha...@db.debian.org I'll do that. So, no, I didn't mean "please do this for me", but I will not insist that you have to do it either. Let people lose their email and see what happens. It will be fun. Thanks. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.1.10.1004050028120.31...@kolmogorov.unex.es
Re: Handling optimization flags in Debian packages
On Sun, Apr 04, 2010 at 10:53:09PM +0100, Ben Hutchings wrote:
> On Sun, 2010-04-04 at 17:29 -0300, Tiago Bortoletto Vaz wrote:
> > Hi all,
> >
> > I've faced an issue (#557550) which is much probably caused by a CPU which
> > doesn't support SSE2 instructions. I'm not sure about the best way to
> > address
> > this. Any suggestion will be very welcome. Actually I can see the following
> > workarounds:
> >
> > 1) consider that most of CPUs support this flag, so tell the reporter to
> > compile the package by him/herself.
>
> This is the wrong answer; we officially support CPUs dating back to 486.
>
> > 2) remove this specific flag during package building, ending with a
> > non-optimized software available for all users.
> >
> > 3) create a specific -sse2 (or -non-sse2) package.
>
> Both acceptable.
>
> > 4) ask the upstream to code runtime checks before using SSE2 specific
> > instructions (is that possible?).
> [...]
>
> This is the best. Also there are libraries like liboil that implement
> various common functions that can benefit from SIMD extensions and that
> automatically select the right version at run-time. Perhaps this
> package can use that?
Thanks Ben and all others who showed me I was choosing the wrong way here. I
liked the idea of building an extra non-sse2 binary until the upstream
(hopefully) starts using a liboil(-like) library. If things go well I'll
document somewhere for future reference.
Regards,
--
.''`. Tiago Bortoletto Vaz GPG : 1024D/A504FECA
: :' : http://tiagovaz.org XMPP : tiago at jabber.org
`. `' tiago at {tiagovaz,debian}.org IRC : tiago at OFTC
`-Debian GNU/Linux - The Universal OS http://www.debian.org
signature.asc
Description: Digital signature
Bug#576479: ITP: libhttp-server-simple-psgi-perl -- simple HTTP server with PSGI application support
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libhttp-server-simple-psgi-perl Version : 0.14 Upstream Author : Tatsuhiko Miyagawa * URL : http://search.cpan.org/dist/HTTP-Server-Simple-PSGI/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : simple HTTP server with PSGI application support HTTP::Server::Simple::PSGI is a simple standalone HTTP server, based on the HTTP::Server::Simple module (see libhttp-server-simple-perl). This module can be easily used as an embedded web server for development purposes. NOTE: this package is needed for packaging Dancer (libdancer-perl), and probably other stuff too. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/g2hd1b732a71004041920x5eabe4a3h32ba6bbe5e6e4...@mail.gmail.com
Re: Some mail changes
On 2010-04-04, Santiago Vila wrote: > Juat announce "Effective [some day], people who do not have an email > forward setup will have one pointing to master, so that they will continue > to receive email in master" and be done with it. You mean like [0]? Kind regards, Philipp Kern [0] <2009080914.ga24...@www.lobefin.net> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhrj2ct.gci.tr...@kelgar.0x539.de
