Re: Bits from the FTPMaster meeting
Steve Langasek writes: > Hello, > > On Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert wrote: >> source-only uploads >> --- >> After some discussion about this, there are two opinions within the >> ftp-team about this matter. Given that other distros experience has >> shown that allowing source only uploads results in a huge loss of >> quality checks and an increased load on the buildds from packages >> FTBFSing everywhere, > > Is there any quantitative evidence of this, or is it purely anecdotal? I > guess this is mostly based on the Ubuntu experience, where it was a cause > for grumbling early in Ubuntu's history that people were uploading > completely untested packages and causing problems, but I'm not sure that > this is a significant problem in Ubuntu today; I think packages in Ubuntu > are at least as likely to FTBFS because of either skew between the archive > and the set of packages being tested with (which is a problem that will > affect Debian as well) or because the package has been imported from Debian > in an unbuildable state (which points to a latent FTBFS bug in Debian). > > I'm not asserting that this problem is *not* significant, I simply don't > know - and am interested in knowing if anyone has more data on this beyond > some four-year-old anecdotes. Certainly, Debian with its wider range of > ports is more likely to run into problems because of this than Ubuntu, and > so will need to be fairly cautious. I don't think the number of ports will have any meaning here. If the package is too broken to build/work on the maintainers architecture it will most likely be broken on all archs. On the other hand if it works on the maintainers architecture then testing or no testing makes no difference to the other ports. It seems to me the only port that MIGHT suffer quality issues is the one the maintainer uses. Meaning i386 or amd64 usualy and Ubuntu already has experience there. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Sun, 2009-11-15 at 19:29 -0600, Steve Langasek wrote: > I'm not asserting that this problem is *not* significant, I simply don't > know - and am interested in knowing if anyone has more data on this beyond > some four-year-old anecdotes. Certainly, Debian with its wider range of > ports is more likely to run into problems because of this than Ubuntu, and > so will need to be fairly cautious. I'd have assumed that ports will have no effect on this: Debian only uploads one binary arch (from the maintainer) anyway :- only builds on that arch will be directly affected except in the case of a build failure that the maintainer could have caught locally. -Rob signature.asc Description: This is a digitally signed message part
Re: Bits from the FTPMaster meeting
On Mon, Nov 16, 2009 at 12:48:53AM +0100, Joerg Jaspert wrote: > On 11936 March 1977, Charles Plessy wrote: > > >> source-only uploads > > I am curious on how the rebuild of the architecture-independant packages > > happens. > > That depends on what we get out with in the end. > Probably all buildds can build arch:all (so the buildd maintainer wants it), > and there will be a new control field "Build-Architecture" for the > arch:all ones, for the few cases where it is mandantory to build on one > specific architecture. Another obvious check would be for the Build-Depends-Indep packages to be available on the building architecture. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556440: ITP: tuxcmd-modules-unrar -- unrar VFS module for tuxcmd file manager
Package: wnpp Severity: wishlist Owner: Salvatore Bonaccorso * Package name: tuxcmd-modules-unrar Version : 0.6.70 Upstream Author : TomáB?atek * URL : http://tuxcmd.sourceforge.net/download.php * License : GPL and non-free RAR license Programming Lang: C/C++ Description : unrar VFS module for tuxcmd file manager This package contains additional unrar VFS module for tuxcmd. . * read-only support for RAR archives * full support for Unix file and directory permissions * password protected archives are supported * can handle self-extracting .exe archives (when renamed to .rar) Note: Upstream for tuxcmd splitted now up tuxcmd-modules into a tuxcmd-modules and tuxcmd-modules-unrar part. This will alow to keep tuxcmd-modules in main (previously I repackaged tuxcmd-modules to remove non-free parts) and have an additional tuxcmd-modules-unrar, which should be in non-free. This furthermore closes a whishlist bugreport (#533569). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
Hello, On Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert wrote: > source-only uploads > --- > After some discussion about this, there are two opinions within the > ftp-team about this matter. Given that other distros experience has > shown that allowing source only uploads results in a huge loss of > quality checks and an increased load on the buildds from packages > FTBFSing everywhere, Is there any quantitative evidence of this, or is it purely anecdotal? I guess this is mostly based on the Ubuntu experience, where it was a cause for grumbling early in Ubuntu's history that people were uploading completely untested packages and causing problems, but I'm not sure that this is a significant problem in Ubuntu today; I think packages in Ubuntu are at least as likely to FTBFS because of either skew between the archive and the set of packages being tested with (which is a problem that will affect Debian as well) or because the package has been imported from Debian in an unbuildable state (which points to a latent FTBFS bug in Debian). I'm not asserting that this problem is *not* significant, I simply don't know - and am interested in knowing if anyone has more data on this beyond some four-year-old anecdotes. Certainly, Debian with its wider range of ports is more likely to run into problems because of this than Ubuntu, and so will need to be fairly cautious. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: GDM, getty and VTs
On Sun, Nov 15, 2009 at 07:13:39AM +0100, Christian Perrier wrote: > Of course, if no *dm is used, then the system should logically default > to N consoles with the first one on tty1. I'd say that N should, in > such case, be greater than 2. This adds much more complexity to the getty configuration than is otherwise necessary, because we also want to make sure that if no DM is configured, the tty that's up by default at boot time has a login prompt on it. I don't think this complexity is warranted; I think it's much more straightforward to just make sure tty1 is always a getty, and always open X on tty7, in the default config. (I consider it a failure of the gdm upstream rewrite that the code no longer implements support for this; but really, that's just one of many regressions in functionality from the new upstream version of gdm...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Clarify rationale for 'debian/rules' shebang line
On Sun, Nov 15, 2009 at 11:20:17PM +0100, Kurt Roeckx wrote: > On Sat, Oct 31, 2009 at 12:12:33PM +1100, Ben Finney wrote: > > === modified file 'policy.sgml' > > --- policy.sgml 2009-10-21 20:49:37 + > > +++ policy.sgml 2009-10-31 01:10:42 + > > @@ -1725,7 +1725,10 @@ > > > > It must start with the line #!/usr/bin/make -f, > > so that it can be invoked by saying its name rather than > > - invoking make explicitly. > > + invoking make explicitly. That is, invoking > > + either of make -f debian/rules args... > > + or ./debian/rules args... must cause > > + identical behaviour in each case. > > > > > > > Seconded. I'm not convinced this is necessary, but I think it would be better worded as: That is, invoking either of [...] must result in identical behavior. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Debian means 'closer to Windows'?
Quoting Marek Artur Penther (marekpent...@aol.com): > When Debian started to mean 'closer to windows'? > I want to use Debian, because I love this OS, but developers cutting this > love > by abadoning i386 arch. Sorry, but Windows making bigger minimal requirments, > and not Debian. And now it's changed? There have been many answers to your concern, but most of them sent only in the mailing list, as you didn't explicitely requested to be CC'ed to answers (the policy in Debian mailing list is to not CC individuals to answers except when requested). These aswers were, in short: what makes you think this? There has been no intent to drop the i386 architecture. Have you had trouble with a recent installation and could you give us details about this? signature.asc Description: Digital signature
Re: Bits from the FTPMaster meeting
On Mon, 16 Nov 2009 02:04:28 pm Carlo Segre wrote: > On Sun, 15 Nov 2009, Joerg Jaspert wrote: > > The current "winning" opinion is to go with the source+throw away > > binaries route. We are close to being able to achieve this, it is > > simply that it has not yet been enabled. Before any version of this > > can be enabled, buildd autosigning needs to be implemented in order > > that dak can differentiate buildd uploads vs maintainer uploads. > > It may be necessary to also move the building of contrib packages to the > unofficial non-free buildd network. As it stands any contrib package > which has a non-free Build-Depends is not guaranteed to build on all > architectures since not all the buildd systems include the non-free > archives. Up to now it has been possible to do binary uploads to work > around this and get as many architectures in the archive as possible to > build manually. When this new option is enabled, it will no longer be > possible. As I understood it, it is still possible for DDs to do binary-only uploads (as allowed per GR). This throwing away of the binary package is only for the initial source+binary upload. (In an ideal world, there should be no need for DDs to do binary-only uploads by hand, but in reality it has to happen every now and then, at least for security). Cheers Steffen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Sun, 15 Nov 2009, Joerg Jaspert wrote: The current "winning" opinion is to go with the source+throw away binaries route. We are close to being able to achieve this, it is simply that it has not yet been enabled. Before any version of this can be enabled, buildd autosigning needs to be implemented in order that dak can differentiate buildd uploads vs maintainer uploads. It may be necessary to also move the building of contrib packages to the unofficial non-free buildd network. As it stands any contrib package which has a non-free Build-Depends is not guaranteed to build on all architectures since not all the buildd systems include the non-free archives. Up to now it has been possible to do binary uploads to work around this and get as many architectures in the archive as possible to build manually. When this new option is enabled, it will no longer be possible. Cheers, Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Graduate Admissions, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 se...@iit.edu http://www.iit.edu/~segre se...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#556386: ITP: libdigest-sha-pureperl-perl -- Digest::SHA::PurePerl - Perl implementation of SHA-1/224/256/384/512
On Nov 16, Andres Mejia wrote: > Well, really the only reason why I'm even bothering to package this is > because > I'm working on an assignment which I want to make sure builds and runs on > CentOS and OSX and making Digest::SHA::PurePerl work would be easier for me > than making Digest::SHA build and run on these other distros. Of course, I > know I didn't need to debianize this module for this particular purpose, but > I > thought I would take the time to package it anyway. Please don't. Pure perl packages are not needed in the archive except for specific corner cases, and this is obviously not one. -- ciao, Marco signature.asc Description: Digital signature
Re: Bug#556386: ITP: libdigest-sha-pureperl-perl -- Digest::SHA::PurePerl - Perl implementation of SHA-1/224/256/384/512
On Sunday 15 November 2009 13:38:01 Jonathan Yu wrote: > On Sun, Nov 15, 2009 at 1:28 PM, Peter Samuelson wrote: > > [Andres Mejia] > > > >> Digest::SHA::PurePerl is a complete implementation of the NIST Secure > >> Hash Standard written entirely in Perl. It gives Perl programmers a > >> convenient way to calculate SHA-1, SHA-224, SHA-256, SHA-384, and > >> SHA-512 message digests. It is functionally equivalent to the > >> Digest::SHA module. > > > > Is there any possible point? All Debian architectures can build and > > run XS Perl modules. > > (Note: I have no idea what this particular case is about) > > PurePerl programs are often useful because they have less risk of > crashing horribly via a segfault. I'm not sure how this applies to > something as well-tested as the Digest::SHA module or the C > implementation of the algorithm. > > It should be noted that while all arches can build and run XS modules, > it doesn't preclude a given arch from being unable to build a module > properly. In that case, it's convenient to be able to fall back to a > pure perl equivalent easily. > > Neither of these is really convincing (not to me, and probably not to > you), but it's the best I could come up with. Well, really the only reason why I'm even bothering to package this is because I'm working on an assignment which I want to make sure builds and runs on CentOS and OSX and making Digest::SHA::PurePerl work would be easier for me than making Digest::SHA build and run on these other distros. Of course, I know I didn't need to debianize this module for this particular purpose, but I thought I would take the time to package it anyway. For anyone willing to sponsor an upload of this module, I have packages ready for review and upload at: git://git.debian.org/git/pkg-perl/packages/libdigest-sha-pureperl-perl.git http://git.debian.org/?p=pkg-perl/packages/libdigest-sha-pureperl- perl.git;a=summary Thanks in advance. -- Regards, Andres -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 11936 March 1977, Charles Plessy wrote: >> source-only uploads > I am curious on how the rebuild of the architecture-independant packages > happens. That depends on what we get out with in the end. Probably all buildds can build arch:all (so the buildd maintainer wants it), and there will be a new control field "Build-Architecture" for the arch:all ones, for the few cases where it is mandantory to build on one specific architecture. > Could we have a bit more details on the buildd(s) and arch(es) > involved, the contact points in case of breakage, etc… No, if you reread the second paragraph of this section you will see why. When we go and activate it it we will list more details. (It is not yet) Though there is no change for contact points or the like, it stays like it is. (And is actually nothing we are involved in, its buildd folks). -- bye, Joerg dvdbackup (0.1.1-7) unstable; urgency=medium . * The wiki-wacky-oaxtepec release -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
Le Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert a écrit : > > source-only uploads Hi Jörg and all the FTP team, fist of all, I want to say a big thank you for all this work. I have given harsh comments for part of it, but I am really grateful for most. I am curious on how the rebuild of the architecture-independant packages happens. Could we have a bit more details on the buildd(s) and arch(es) involved, the contact points in case of breakage, etc… Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 11935 March 1977, Joerg Jaspert wrote: > NEW/Byhand > -- > Due to the massive changes in the archive, NEW (and also Byhand) had to > be disabled. Certain assumptions made by the processing tools no longer > applied. The last week was used to work on this issue and we think this > will be fixed today, so NEW processing will return to its normal speed > soon. And I just committed and pushed the last change for it, so it is actually back alive. We already accepted a few packages to test, but should you notice weird things happening please notice us. (Yes, we know, the detailed overview of a package isnt yet visible) -- bye, Joerg Free beer is something that I am never going to drink and free speech is something that people are never going to be allowed to. ;) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Sun, 15 Nov 2009 19:53:02 + Mark Hymers wrote: > On Sun, 15, Nov, 2009 at 02:37:56PM -0500, Joey Hess spoke thus.. > > Andreas Metzler wrote: > > > FWIW dpkg does the smart thing by default. It uses gzip (both > > > for the debian packages and and debian.tar) but searches for both > > > foo_42.orig.tar.bz2 and .gz. Explicitely passing an option is required > > > to get bz2 compression for binary packages and/or debian.tar. > > > > Note that debootstrap does not support data.tar.bz2. > > I think there's some confusion here between source and binary formats. > The announcement was referring to bzip2 when used as part of a source > upload. As far as I can tell from looking in the git logs, dak has > supported data.tar.bz2 since 2005, so I'm surprised that this has never > been an issue before if debootstrap can't handle it. debootstrap-1.0.20/functions: extract progress "$p" "$#" EXTRACTPKGS "Extracting packages" packagename="$(echo "$pkg" | sed 's,^.*/,,;s,_.*$,,')" info EXTRACTING "Extracting %s..." "$packagename" ar -p "./$pkg" data.tar.gz | zcat | tar -xf - So it appears to be a case of "debootstrap might not have come across any packages that use data.tar.bz2, yet" - the range of packages that debootstrap has to handle is quite limited. I don't suppose there's a list anywhere, so anyone know which packages are already using data.tar.bz2 ? deb-gview is also affected by this but I haven't had any bug reports. Fairly easy to fix that in deb-gview though due to the use of libarchive. multistrap will also be affected. In comparison, using foo_1.0.0.orig.tar.bz2 isn't much of a problem. I've been adding .tar.bz2 upstream to most of my projects but the .tar.gz still gets >95% of the downloads, despite being ~100k smaller. If someone using data.tar.bz2 in their packages can let me know which packages use it (and why), it would help. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpV0dC2PPzM0.pgp Description: PGP signature
Re: Bits from the FTPMaster meeting
On Sun, Nov 15, 2009 at 04:15:35PM +0100, Joerg Jaspert wrote:
> Tracking arch all packages
> --
> #246992 asked us to not delete arch all packages before the
> corresponding (if any) arch any packages are available for all
> architectures. Example: whenever a new source package for emacs23
> gets uploaded the installation of the metapackage emacs_*_all.deb
> breaks on most architectures until the needed Architecture: any
> packages like emacs23 get built by the buildds. That happens because
> dak removes all arch: all packages but the newest one.
>
> While this behaviour is easily documented and one can easily devise a
> fix ("just keep the arch all until the any is there, stupid"), the
> actual implementation of it contains several nasty corner cases
> which is why it took so long to fix.
>
> Thankfully Torsten Werner took on this task during the meeting [2] and
> we are now in a position where we can merge his work. We'll email
> before turning on this feature so that people can watch out of any
> strange cases which could cause problems.
Hurray !
Thanks, a lot.
Mike
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Clarify rationale for 'debian/rules' shebang line
On Sat, Oct 31, 2009 at 12:12:33PM +1100, Ben Finney wrote: > > === modified file 'policy.sgml' > --- policy.sgml 2009-10-21 20:49:37 + > +++ policy.sgml 2009-10-31 01:10:42 + > @@ -1725,7 +1725,10 @@ > > It must start with the line #!/usr/bin/make -f, > so that it can be invoked by saying its name rather than > - invoking make explicitly. > + invoking make explicitly. That is, invoking > + either of make -f debian/rules args... > + or ./debian/rules args... must cause > + identical behaviour in each case. > > > Seconded. Kurt signature.asc Description: Digital signature
Re: common, FHS-compliant, default document root for the various web servers
hi stefano, On Fri, Nov 13, 2009 at 10:09:20AM +0100, Stefano Zacchiroli wrote: > I understand this problem, but I think you're shooting at the wrong > target. The advanced proposal (beside the aesthetically displeasing > name) is about standardizing a default vendor document root on disk so > that packages can install content in it, as well as defining a base URL > that maps to it. > > Inherently, such a proposal applies to static content, not CGI > applications. I fail to see where lay problems about unconfigured static > content. read-only static content unpacked from packages is certainly not an issue wrt being "unconfigured", but i was given the impression by other folks in this thread that the scope was not this narrow. but at the same time, if we're only talking about static content at this filesystem location, i wonder about the overall utility/benefit of standardizing on a location in the first place. how many webapp packages in debian consist of only read-only static content, which would be helped by such a standardization? wrt the issue about namespacing and default URL's (i guess this is a seperate issue from fs location, really) i'm unconvinced about the benefits outweighing the costs. has anyone considered putting up the arguments for it in a DEP? sean signature.asc Description: Digital signature
Re: YHBT [Was: Re: Debian means 'closer to Windows'?]
On Sun, Nov 15, 2009 at 03:54:57PM -0300, Mauro Lizaur wrote: > 2009-11-15, Patrick Matthäi: > > Marek Artur Penther schrieb: > > > > > > P.S. I wanted to start donating Debian, but now I'll rather start > > > donating > > > thing which I hate from bottom of heart - Microsoft! > > > Why you doing this to me and others? > > > > > > If you are happy with Windows, use it, if not, use another system with > > that you are happy. > > > [subject: YHBT] > Come on! No, I don't see this as being possibly intentional. I bet this poor soul plopped an amd64 CD into his i386 box, got an error message, and, not knowing any better, threw an anger fit. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
> Then can you (or someone else) please explain what exactly is meant by the > reference to bzip2 for binary packages in the following quote from the > original mail: > ! You can use either gzip as usual or bzip2 for the compression within > ! the binary packages - and now also for the source files. That you now can not only compress the binary contents with bz2, but also the source. -- bye, Joerg kde und tastatur? passt doch nicht mit dem nutzerprofil "windepp" zusammen :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GDM, getty and VTs
Hello, I think the problem only happens for desktop startup. Say you _don't_ start X at boot, this is what happens: - 6 ttys are occupied - startx will use the next free tty7, which is what I expect if I don't specify vt to X. In this case dynamic allocation is good. Say instead you have *dm at startup: I think in this case dynamic allocation is not good, because it means X could be started on vt1, vt2, ... Actually on vt2. This is my proposal: I'd say to start X in a fixed tty _only_ when X is started at boot, in all other cases the tty will be chosen dynamically as next free or by whatelse policy. Of course, if the fixed tty is already in use, then it will use the next free; but that's not our case I think. The problem is: how to use a fixed-configurable tty "only at boot time"? I think this is the best compromise. I don't know if my English was clear enough. Best regards, -- http://www.debian.org - The Universal Operating System signature.asc Description: Digital signature
Re: Bits from the FTPMaster meeting
This one time, at band camp, Frans Pop said: > Mark Hymers wrote: > > I think there's some confusion here between source and binary formats. > > The announcement was referring to bzip2 when used as part of a source > > upload. As far as I can tell from looking in the git logs, dak has > > supported data.tar.bz2 since 2005, so I'm surprised that this has never > > been an issue before if debootstrap can't handle it. > > Then can you (or someone else) please explain what exactly is meant by the > reference to bzip2 for binary packages in the following quote from the > original mail: > > ! You can use either gzip as usual or bzip2 for the compression within > ! the binary packages - and now also for the source files. I suspect it might have been better worded as: In addition to being able to use gzip or bzip2 for compression within the binary packages, you can now also use them for source files. That was my reading of it, at any rate. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Bits from the FTPMaster meeting
Mark Hymers wrote: > I think there's some confusion here between source and binary formats. > The announcement was referring to bzip2 when used as part of a source > upload. As far as I can tell from looking in the git logs, dak has > supported data.tar.bz2 since 2005, so I'm surprised that this has never > been an issue before if debootstrap can't handle it. Then can you (or someone else) please explain what exactly is meant by the reference to bzip2 for binary packages in the following quote from the original mail: ! You can use either gzip as usual or bzip2 for the compression within ! the binary packages - and now also for the source files. TIA, FJP -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Sun, 15, Nov, 2009 at 02:37:56PM -0500, Joey Hess spoke thus.. > Andreas Metzler wrote: > > FWIW dpkg does the smart thing by default. It uses gzip (both > > for the debian packages and and debian.tar) but searches for both > > foo_42.orig.tar.bz2 and .gz. Explicitely passing an option is required > > to get bz2 compression for binary packages and/or debian.tar. > > Note that debootstrap does not support data.tar.bz2. > > > cu and- happliy using v3 for gnutls -reas > > Please avoid doing so for libtasn1-3. I think there's some confusion here between source and binary formats. The announcement was referring to bzip2 when used as part of a source upload. As far as I can tell from looking in the git logs, dak has supported data.tar.bz2 since 2005, so I'm surprised that this has never been an issue before if debootstrap can't handle it. Mark -- Mark Hymers "Everyone is entitled to be stupid but some abuse the privilege." Unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On 2009-11-15, Goswin von Brederlow wrote: > If Architecture: all is kept then maybe allow source+all uploads? Those are already possible. If they're allowed is another question, though. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
Joey Hess wrote: > > cu and- happliy using v3 for gnutls -reas > > Please avoid doing so for libtasn1-3. Please ignore above; misread. -- see shy jo signature.asc Description: Digital signature
Re: Bits from the FTPMaster meeting
Sandro Tosi writes: > Hello Joerg, > thanks for the updates. > > On Sun, Nov 15, 2009 at 16:15, Joerg Jaspert wrote: > ... >> source-only uploads >> --- >> After some discussion about this, there are two opinions within the >> ftp-team about this matter. Given that other distros experience has >> shown that allowing source only uploads results in a huge loss of >> quality checks and an increased load on the buildds from packages >> FTBFSing everywhere, some members of the team believe that source+binary >> uploads should happen as currently, but that the maintainer built >> binaries should be rebuilt by the buildds (i.e. be thrown away at accept >> time). Other members of the team think that we should allow source-only >> uploads and that if some people keep uploading packages which FTBFS >> everywhere (showing a lack of basic testing), this should be dealt with >> by the project in other ways which are out of the scope of the ftp-team. >> >> The current "winning" opinion is to go with the source+throw away >> binaries route. We are close to being able to achieve this, it is >> simply that it has not yet been enabled. Before any version of this >> can be enabled, buildd autosigning needs to be implemented in order >> that dak can differentiate buildd uploads vs maintainer uploads. >> >> Provisions have been made in dak for things such as bootstrapping a >> new architecture where binary uploads from porters may be necessary >> in order to get going. > > While I like the "source + trow away" solution, I'd also like to ask > you to please consider some methods to allow the "throw away" step on > the developer machine, for example having dput/dupload not upload the > .debs (so .changes still has them listed, but are not actually > uploaded) and still accepting the upload. > > There are (still) people with slow internet connections or with very > huge packages, with several binary packages, that would benefit a lot > with this option. > > Additionally, things like NMUs or QA uploads (so where the tarball is > not, generally, changed), would reduce to a ".dsc + .diff.gz + > .changes" file set, that's a lot faster to upload. > > Thanks for considering, What about Architecture: all? Will they be kept? Is one buildd special and builds them? If Architecture: all is kept then maybe allow source+all uploads? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
Andreas Metzler wrote: > FWIW dpkg does the smart thing by default. It uses gzip (both > for the debian packages and and debian.tar) but searches for both > foo_42.orig.tar.bz2 and .gz. Explicitely passing an option is required > to get bz2 compression for binary packages and/or debian.tar. Note that debootstrap does not support data.tar.bz2. > cu and- happliy using v3 for gnutls -reas Please avoid doing so for libtasn1-3. -- see shy jo signature.asc Description: Digital signature
Re: GDM, getty and VTs
On Sun,15.Nov.09, 07:13:39, Christian Perrier wrote: > > Not considering the technical backgorund (which is of course an easy > stance), it could be really interesting to have *by default* the > default X session on tty1, when a display manager is used, and > something like 2 other console sessions on tty2 and tty3. Please don't forget about the switch user functionality which creates a new X session (by default on tty8). I think it would make sense to keep the X sessions "adjacent". Regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
YHBT [Was: Re: Debian means 'closer to Windows'?]
2009-11-15, Patrick Matthäi: > Marek Artur Penther schrieb: > > > > P.S. I wanted to start donating Debian, but now I'll rather start donating > > thing which I hate from bottom of heart - Microsoft! > > Why you doing this to me and others? > > > If you are happy with Windows, use it, if not, use another system with > that you are happy. > Come on! Saludos, Mauro -- JID: lavaram...@jabber.org | http://lizaur.github.com/ 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
Hello Joerg, thanks for the updates. On Sun, Nov 15, 2009 at 16:15, Joerg Jaspert wrote: ... > source-only uploads > --- > After some discussion about this, there are two opinions within the > ftp-team about this matter. Given that other distros experience has > shown that allowing source only uploads results in a huge loss of > quality checks and an increased load on the buildds from packages > FTBFSing everywhere, some members of the team believe that source+binary > uploads should happen as currently, but that the maintainer built > binaries should be rebuilt by the buildds (i.e. be thrown away at accept > time). Other members of the team think that we should allow source-only > uploads and that if some people keep uploading packages which FTBFS > everywhere (showing a lack of basic testing), this should be dealt with > by the project in other ways which are out of the scope of the ftp-team. > > The current "winning" opinion is to go with the source+throw away > binaries route. We are close to being able to achieve this, it is > simply that it has not yet been enabled. Before any version of this > can be enabled, buildd autosigning needs to be implemented in order > that dak can differentiate buildd uploads vs maintainer uploads. > > Provisions have been made in dak for things such as bootstrapping a > new architecture where binary uploads from porters may be necessary > in order to get going. While I like the "source + trow away" solution, I'd also like to ask you to please consider some methods to allow the "throw away" step on the developer machine, for example having dput/dupload not upload the .debs (so .changes still has them listed, but are not actually uploaded) and still accepting the upload. There are (still) people with slow internet connections or with very huge packages, with several binary packages, that would benefit a lot with this option. Additionally, things like NMUs or QA uploads (so where the tarball is not, generally, changed), would reduce to a ".dsc + .diff.gz + .changes" file set, that's a lot faster to upload. Thanks for considering, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#556386: ITP: libdigest-sha-pureperl-perl -- Digest::SHA::PurePerl - Perl implementation of SHA-1/224/256/384/512
On Sun, Nov 15, 2009 at 1:28 PM, Peter Samuelson wrote: > > [Andres Mejia] >> Digest::SHA::PurePerl is a complete implementation of the NIST Secure Hash >> Standard written entirely in Perl. It gives Perl programmers a convenient way >> to calculate SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 message digests. >> It >> is functionally equivalent to the Digest::SHA module. > > Is there any possible point? All Debian architectures can build and > run XS Perl modules. (Note: I have no idea what this particular case is about) PurePerl programs are often useful because they have less risk of crashing horribly via a segfault. I'm not sure how this applies to something as well-tested as the Digest::SHA module or the C implementation of the algorithm. It should be noted that while all arches can build and run XS modules, it doesn't preclude a given arch from being unable to build a module properly. In that case, it's convenient to be able to fall back to a pure perl equivalent easily. Neither of these is really convincing (not to me, and probably not to you), but it's the best I could come up with. > > > -- > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#556386: ITP: libdigest-sha-pureperl-perl -- Digest::SHA::PurePerl - Perl implementation of SHA-1/224/256/384/512
[Andres Mejia] > Digest::SHA::PurePerl is a complete implementation of the NIST Secure Hash > Standard written entirely in Perl. It gives Perl programmers a convenient way > to calculate SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 message digests. It > is functionally equivalent to the Digest::SHA module. Is there any possible point? All Debian architectures can build and run XS Perl modules. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian means 'closer to Windows'?
Marek Artur Penther, le Sun 15 Nov 2009 16:53:45 +, a écrit : > I want to use Debian, because I love this OS, but developers cutting this > love > by abadoning i386 arch. Do you mean the i386 processor? It's been abandonned by most OSes since quite some time already. Do you really still use an i386? Does it have enough RAM to run nowadays' Debian tools anyway? If you mean the i386 series (i.e. also pentium etc.) I don't see where you see Debian abandoning its i386 arch. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian means 'closer to Windows'?
On Sunday 15 November 2009 17:53:45 Marek Artur Penther wrote: > When Debian started to mean 'closer to windows'? You might confused that with the old Linspire stuff or Ubuntu. Debian never had a reason to really need to be closer to windows. Now I know Ubuntu is basing on Debian but we are still 2 independent(?) projects. > I want to use Debian, because I love this OS, but developers cutting this > love by abadoning i386 arch. As said before i386 wont be abandoned and I cant see why it should be abandoned at all for a long time. > Sorry, but Windows making bigger minimal > requirments, and not Debian. And now it's changed? > And this new minimal requirments making my computer completly obsolete? > It's madness! Please recheck your sources of information you probably just misread there something. > Even Windows 7 don't making my computer completly obsolete, and Debian 6.0 > making it. I doubt that 7 wants less from your computer unless you want to leave it in idle all the time and dont want to move anything. > I can't understand. Do you want to better then Microsoft? > So why you cutting me from our community? As I said NO. We are the basis and buildig block upon which businesses and Distrobuilders create their Systems nad have great appliances. > P.S. I wanted to start donating Debian, but now I'll rather start donating > thing which I hate from bottom of heart - Microsoft! > Why you doing this to me and others? > I dont think Windows actually needs anyones Donation unless its a bit more than bills house in money... Kind regards , Andreas Marschke. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556386: ITP: libdigest-sha-pureperl-perl -- Digest::SHA::PurePerl - Perl implementation of SHA-1/224/256/384/512
Package: wnpp Severity: wishlist Owner: Andres Mejia * Package name: libdigest-sha-pureperl-perl Version : 5.47 Upstream Author : Mark Shelor * URL : http://search.cpan.org/dist/Digest-SHA-PurePerl/ * License : Perl, GPL+1 Programming Lang: Perl Description : Digest::SHA::PurePerl - Perl implementation of SHA-1/224/256/384/512 Digest::SHA::PurePerl is a complete implementation of the NIST Secure Hash Standard written entirely in Perl. It gives Perl programmers a convenient way to calculate SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 message digests. It is functionally equivalent to the Digest::SHA module. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian means 'closer to Windows'?
Dear Marek, On Sun, Nov 15, 2009 at 04:53:45PM +, Marek Artur Penther wrote: > When Debian started to mean 'closer to windows'? > I want to use Debian, because I love this OS, but developers cutting this > love > by abadoning i386 arch. Sorry, but Windows making bigger minimal requirments, > and not Debian. And now it's changed? > And this new minimal requirments making my computer completly obsolete? > It's madness! > Even Windows 7 don't making my computer completly obsolete, and Debian 6.0 > making it. You seem to be having some trouble with your Debian installation, which is making it slow (to the best of my understanding). It would make it easier for us to help you if you could focus on the problems you are facing, and mail about it to the debian-user list, where people can offer suggestions and workarounds. I have been using Debian GNU/Linux for years, and have had the opposite experience. On most machines I have installed Debian on, it has performed much faster than Microsoft Windows, and all of these were i386 machines. The minimum requirements are fairly low as well. > I can't understand. Do you want to better then Microsoft? > So why you cutting me from our community? We are not cutting you from our community. Please bring your problems to the Debian users' list, and you will most likely get sound advice on how to resolve your problems with Debian GNU/Linux. HTH, and thanks. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: Debian means 'closer to Windows'?
On Sun, Nov 15, 2009 at 04:53:45PM +, Marek Artur Penther wrote: > I want to use Debian, because I love this OS, but developers cutting this > love > by abadoning i386 arch. Sorry, but Windows making bigger minimal requirments, > and not Debian. And now it's changed? > So why you cutting me from our community? There is no talk of dropping i386 from squeeze: http://release.debian.org/squeeze/arch_qualify.html -- Jonathan Wiltshire 1024D: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian means 'closer to Windows'?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marek Artur Penther schrieb: > When Debian started to mean 'closer to windows'? > I want to use Debian, because I love this OS, but developers cutting this > love > by abadoning i386 arch. Sorry, but Windows making bigger minimal requirments, > and not Debian. And now it's changed? > And this new minimal requirments making my computer completly obsolete? > It's madness! > Even Windows 7 don't making my computer completly obsolete, and Debian 6.0 > making it. > I can't understand. Do you want to better then Microsoft? > So why you cutting me from our community? > > P.S. I wanted to start donating Debian, but now I'll rather start donating > thing which I hate from bottom of heart - Microsoft! > Why you doing this to me and others? First at all: Why are you trying to forcing us (the mailinglist readers) to send you a reading notification? This is realy bad.. Disable it. To your post: Who said that we try to mess ourself with Windows or that we want to be closer to Windows? It is Linux, not Windows. Also I do not understand your requirements, do you have got references? And "who" is "cutting" you from the community? Sorry but your post seems to be a little trolling like.. If you are happy with Windows, use it, if not, use another system with that you are happy. - -- /* 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. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAksAODAACgkQ2XA5inpabMcuagCfSSFjczcZD6OpkGhMT97fIcC7 +rMAoIIu8+/kJh+7OMvAgRVonBl34pmM =zwn6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Debian means 'closer to Windows'?
When Debian started to mean 'closer to windows'? I want to use Debian, because I love this OS, but developers cutting this love by abadoning i386 arch. Sorry, but Windows making bigger minimal requirments, and not Debian. And now it's changed? And this new minimal requirments making my computer completly obsolete? It's madness! Even Windows 7 don't making my computer completly obsolete, and Debian 6.0 making it. I can't understand. Do you want to better then Microsoft? So why you cutting me from our community? P.S. I wanted to start donating Debian, but now I'll rather start donating thing which I hate from bottom of heart - Microsoft! Why you doing this to me and others? -- Marek Artur Penther -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
Frans Pop wrote: > On Sunday 15 November 2009, Joerg Jaspert wrote: >> dpkg v3 source format, compression [...] > Is there a policy for the use of bzip2? > As discussed earlier bzip2 is *much* slower that gzip and really hurts on > slower arches and systems, so I'd suggest that - especially for binary > packages - gzip should remain the default for all normal cases and bzip2 > should reserved for cases where there is a really significant size > decrease. ... or where upstream only offers tar.bz2. FWIW dpkg does the smart thing by default. It uses gzip (both for the debian packages and and debian.tar) but searches for both foo_42.orig.tar.bz2 and .gz. Explicitely passing an option is required to get bz2 compression for binary packages and/or debian.tar. cu and- happliy using v3 for gnutls -reas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the FTPMaster meeting
On Sunday 15 November 2009, Joerg Jaspert wrote: > dpkg v3 source format, compression > -- > As many already noticed, our archive now additionally supports 3.0 > (quilt) and 3.0 (native) source package formats. You can use either > gzip as usual or bzip2 for the compression within the binary packages - > and now also for the source files. We do not support lzma as a > compressor, as the format is already dead again. After squeeze we will > probably add support for its successor, xz. Is there a policy for the use of bzip2? As discussed earlier bzip2 is *much* slower that gzip and really hurts on slower arches and systems, so I'd suggest that - especially for binary packages - gzip should remain the default for all normal cases and bzip2 should reserved for cases where there is a really significant size decrease. > source-only uploads > --- > The current "winning" opinion is to go with the source+throw away > binaries route. We are close to being able to achieve this, it is > simply that it has not yet been enabled. I fully agree with that, but like to request that exceptions are allowed in special cases. Main use case I have is kernel udebs where it is sometimes necessary to upload udebs to unstable built from a kernel version in testing. Our own build methods support that, but it would get undone by a rebuild. Our build method also ensure that all uploads are based on the same kernel version, something that's much harder to ensure when it's left to the buildds. > The extra source case > - > This issue is the one traditionally known as the linux-modules-extra > problem but also exists for some compiler packages and in the past > existed for things such as apache2-mpm-itk and so is a more general > problem. It exists where a package needs to use source from another > package in order to build. And kernel udebs. > We intend to fix this by introducing a way of packages declaring that > they were Built-Using a certain source package,version and then tracking > that to ensure that the sources are kept around properly. Nice. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: GDM, getty and VTs
On Sat, Nov 14, 2009 at 03:45:11PM +0100, Josselin Mouette wrote: > * For desktop machines, the display manager starts on tty7, which > means there is a tty switch to display it. This causes a small > latency and can also create some bugs when you’re using a > graphical boot splash. Is that still true with KMS and framebuffer console? IMHO if the boot splash and gdm both use the same mode, then KMS can avoid re-programming the card on a VT switch, thus the latency goes away. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556363: ITP: libdata-dumper-concise-perl -- module for more shorter Data::Dumper-like output
Package: wnpp Owner: Jonathan Yu Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libdata-dumper-concise-perl Version : 1.001 Upstream Author : Matt S. Trout * URL : http://search.cpan.org/dist/Data-Dumper-Concise/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : module for more shorter Data::Dumper-like output Data::Dumper::Concise is a Perl module designed to produce useful debugging output, eliding unnecessary information. It exists as a convenient way to reproduce a set of Dumper options useful for most applications. . A similar module, Data::Dump::Streamer (libdata-dump-streamer) provides even shorter output but is overkill for most applications. In comparison, this module is Pure Perl, which means it is less likely to segfault. NOTE: this is needed for the upgrade of DBIx::Class (libdbix-class-perl) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GR proposal: the AGPL does not meet the DFSG (take 2)
Hello, I would like to move the discussion to debian-vote where it belongs. I'd like to apologize to have started this cross-post in the first place. (please CC me). On Sun, Nov 15, 2009 at 04:04:49AM +0100, Wouter Verhelst wrote: > > If you modify a GPL-licensed software and distribute the modified version in > > source form only, you do not have any long standing obligation. This is not > > the case here. > > That's not true. It says 'your modified version must offer', it does not > say 'you must offer'. In other words, if you don't run it on the public > Internet, there is no problem. The idea was that if you distribute it in source form, someone else might start to run the software on the public internet and then the 'your modified version must offer' clause take effect. ... > > So if you are as service provider, is the AGPL trivially bypassable by > > having someone doing the modification for you but never actually > > provide any service ? > After thinking about this a bit more, I'm actually not entirely sure > about my previous statement here anymore. > > Indeed, you would probably need to be providing the source of the > version you're running, even if you did not make any local modifications > yourself. I strongly doubt that the AGPL put any kind of limitation/liability on merely running the software, for various reasons: 1) Philosophy: the FSF stance is that * The freedom to run the program, for any purpose (freedom 0). 2) Copyright law: mere copyright law do not allow to limit use of the software once you legally have a copy, so you do not have to agree with the AGPL in order to merely use the software, and so the AGPL cannot impose any condition upon you. 3) the AGPL text: Section 9: 9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. So if you are a service provider, is the AGPL trivially bypassable by 1) not accepting it and 2) having someone else doing the modification for you but never actually providing any service themself? > > Assume this is web server. Are you suggesting it modify the page it serve to > > add the notice ? > > It says "in a prominent place", not "with every network conversation". It does not say either of that, it says 'your modified version must prominently offer all users interacting with it remotely through a computer network'. So it is not "with every network conversation", but it is "all users". Cheers, -- Bill. Imagine a large red swirl here. signature.asc Description: Digital signature
Re: GDM, getty and VTs
On Sun, Nov 15, 2009 at 12:06:27PM +, Ben Hutchings wrote: > If Fedora jumps off a cliff (I wouldn't put it past them ;-) should we > do it? No, but what does this have to do with the current thread? Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GDM, getty and VTs
On Sun, 2009-11-15 at 12:36 +0100, Julien Cristau wrote: > On Sun, Nov 15, 2009 at 12:29:33 +0100, Thilo Six wrote: > > > Christian Perrier wrote the following on 15.11.2009 07:13 > > > > > Not considering the technical backgorund (which is of course an easy > > > stance), it could be really interesting to have *by default* the > > > default X session on tty1, when a display manager is used, and > > > something like 2 other console sessions on tty2 and tty3. > > > > That would break *all* "How to fix my broken X11" on the net. Really bad > > especial for those who need them most - newbees. > > ALT-CTRL-F7 is somewhat of a standard. > > > It's already broken on fedora, at least. So if it's a standard, it's a > dying one. If Fedora jumps off a cliff (I wouldn't put it past them ;-) should we do it? Ben. -- Ben Hutchings The two most common things in the universe are hydrogen and stupidity. signature.asc Description: This is a digitally signed message part
Re: GDM, getty and VTs
On Sun, Nov 15, 2009 at 12:29:33 +0100, Thilo Six wrote: > Christian Perrier wrote the following on 15.11.2009 07:13 > > > Not considering the technical backgorund (which is of course an easy > > stance), it could be really interesting to have *by default* the > > default X session on tty1, when a display manager is used, and > > something like 2 other console sessions on tty2 and tty3. > > That would break *all* "How to fix my broken X11" on the net. Really bad > especial for those who need them most - newbees. > ALT-CTRL-F7 is somewhat of a standard. > It's already broken on fedora, at least. So if it's a standard, it's a dying one. Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GDM, getty and VTs
Hello Christian Perrier wrote the following on 15.11.2009 07:13 > Quoting Kurt Roeckx (k...@roeckx.be): > >>> * I don't think we need more than 2 of these. They are still >>> useful for servers or when some disaster happens in the GUI, but >>> who opens 6 console sessions nowadays? >> I still have 12 console sessions open, and use screen to have >> more of them. > > > I hardly think this is Joe Random User's setup..:-) > > Not considering the technical backgorund (which is of course an easy > stance), it could be really interesting to have *by default* the > default X session on tty1, when a display manager is used, and > something like 2 other console sessions on tty2 and tty3. That would break *all* "How to fix my broken X11" on the net. Really bad especial for those who need them most - newbees. ALT-CTRL-F7 is somewhat of a standard. > Of course, if no *dm is used, then the system should logically default > to N consoles with the first one on tty1. I'd say that N should, in > such case, be greater than 2. $ grep "ACTIVE_CONSOLES" /etc/default/console-setup ACTIVE_CONSOLES="/dev/tty[1-6]" I really wonder what else is needed then this? As long as this setting isn't going to be overwritten by some other software i fine it all. -- bye Thilo 4096R/0xC70B1A8F 721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
