Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
also sprach Philip Ashmore [2011.12.18.0834 +0100]: > If no one has any more issues with the new long description then > I'll assume all is well. Hello Philip, a long description is neither a text of marketing, nor should it be a complete list of features. The former can go on a website, the latter should be found in a README file. The long description should preemptively provide a user with enough information so that s/he can make a choice. It should be written with complete sentences in free text, with an informative, objective style. A rough guidelines of questions to be answered across three paragraphs could be: 1. What is the general purpose of the software in this package, or the collection of software that this package belongs to? 2. What distinguishes this software from other software? For what use cases was the software designed? 3. How does this package fit in into a collection (unless it's a single package)? Are there any other noteworthy things that the user might need to know to decide for or against a piece of software? Compare this to the description you propose in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652423#15 utility C/C++ include files libv3c - a C/C++ library v3c - a utility program meant to be used in scripts or from the command line makefile includes - see v3c's client projects "makefile" for examples automake/aclocal m4 macros - see v3c's client projects for examples What you are doing is providing a list of contents. Instead, I would suggest this: v3c is a C++ programming toolkit that …. It was written because …. The intended use cases of v3c are …. Compared to other software (e.g. example1, example2), it is optimised for …. This package provides a utility program to interact … and control …. -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "the unexamined life is not worth living" -- platon digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Bug#652433: ITP: v3c-qt -- v3c/automake wrapper for QT
On Sun, Dec 18, 2011 at 12:47:39AM +, Philip Ashmore wrote: > Should I file another ITP to change the spelling? You never need to do that (although you're not the only one with this confusion; I see a lot of people unnecessarily closing and re-filing ITPs, perhaps because the process is one of the ones often used by people new to Debian development). To change a bug title, see: http://www.debian.org/Bugs/server-control http://www.debian.org/Bugs/server-control#retitle -- Colin Watson [cjwat...@debian.org] -- 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/20111218085651.gb24...@riva.dynamic.greenend.org.uk
Bug#652528: ITP: python-vsgui -- simple Graphical toolkit of Python script
Package: wnpp Severity: wishlist Owner: "Hsin-Yi Chen (hychen)" * Package name: python-vsgui Version : 0.3 Upstream Author : Hsin-Yi Chen * URL : http://pypi.python.org/pypi/vsgui * License : BSD-2-clause Programming Lang: Python Description : simple Graphical toolkit of Python script It proides a simple functions to comuunicate with Zenity which is a program that will display GTK+ dialogs, and convert return value that user input to Python data type. This allows you to present information, and ask for information from the user in Python script. -- 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/20111218085532.16084.26536.reportbug@localhost6.localdomain6
Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
On 18/12/11 08:35, martin f krafft wrote: also sprach Philip Ashmore [2011.12.18.0834 +0100]: If no one has any more issues with the new long description then I'll assume all is well. Hello Philip, a long description is neither a text of marketing, nor should it be a complete list of features. The former can go on a website, the latter should be found in a README file. The long description should preemptively provide a user with enough information so that s/he can make a choice. It should be written with complete sentences in free text, with an informative, objective style. A rough guidelines of questions to be answered across three paragraphs could be: 1. What is the general purpose of the software in this package, or the collection of software that this package belongs to? 2. What distinguishes this software from other software? For what use cases was the software designed? 3. How does this package fit in into a collection (unless it's a single package)? Are there any other noteworthy things that the user might need to know to decide for or against a piece of software? Being too familiar with a package sometimes has it's drawbacks. Here's my revised long description, based on your feedback - thanks! v3c is a wrapper package that provides a standard means of interacting with packages by providing "boilerplate" code, programs and scripts, and allowing you to manipulate a package through "make" targets, such as . make check make dist make distcheck make git branch=1.3.5 release debian make install make distclean . Among its capabilities are doxygen documentation integration, Git version control integration, configurable build modes (for debug and release builds, for example), and the ability to specify most configurable options in the top-level makefile. It also provides a C++ class library for use in client projects. Run "make check" to see test/example C++ programs that use it. . See treedb, meta-treedb, v3c-dcom and v3c-qt as examples of projects that use the v3c build framework. Regards, Philip Ashmore -- 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/4eedb545.7010...@philipashmore.com
Re: ITP: v3c-qt -- v3c/automake wrapper for Qt4 (was ITP: v3c-qt -- v3c/automake wrapper for QT)
retitle 652433 ITP: v3c-qt -- v3c/automake wrapper for Qt4 thanks Done! Regards, Philip Ashmore -- 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/4eedbc1c.90...@philipashmore.com
Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
also sprach Philip Ashmore [2011.12.18.1041 +0100]: > Being too familiar with a package sometimes has it's drawbacks. Absolutely. Thank you for your patience! > v3c is a wrapper package that provides a standard means of interacting with > packages by providing "boilerplate" code, programs and scripts, and allowing > you to manipulate a package through "make" targets, such as > . > make check > make dist > make distcheck > make git branch=1.3.5 release debian > make install > make distclean How about: v3c is a build framework that ties in with GNU make, providing "boilerplate" code for the most common use cases of building software. I'd say that's enough, no need to enumerate example targets. > Among its capabilities are doxygen documentation integration, Git version > control integration, configurable build modes (for debug and release builds, > for example), and the ability to specify most configurable options in the > top-level makefile. Good! > It also provides a C++ class library for use in client projects. > Run "make check" to see test/example C++ programs that use it. Why would I want to use build framework from within C++? Maybe you can try to answer this question. The note about "make check" should go into the README file, IMHO. > See treedb, meta-treedb, v3c-dcom and v3c-qt as examples of > projects that use the v3c build framework. Ok. I am still somewhat confused why the project v3c-dcom and v3c-qt carry the name of the build framework in the package names, but I suppose I would look at those packages' descriptions to find out more. Cheers, -- .''`. martin f. krafft Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems "toleranz heißt, die fehler der anderen entschuldigen. takt heißt, sie nicht bemerken." -- arthur schnitzler digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: d-i doesn't even gives a clue on what WM is going to be installed (was: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning)
On 12/18/2011 04:43 AM, Otavio Salvador wrote: > This > is mostly as if I starting to try to convince to use Awesome WM as > default desktop install because I think it is more user-friendly (and it > is, for my type of use, but not for general use). Good example indeed. If the user has enough explanations as to why it's more user-friendly, and there's a choice that can be made, then I'd be for prompting the user the choice of the WM. Also, this doesn't have to be in the default mode, it's ok if the choice is only available in expert install. I have always felt uncomfortable with d-i just launching tasksel, which only has a checkbox for "Graphical desktop environment". - Why isn't tasksel asking which window manager? - Why "graphical interface" means in fact gnome, and why it's not written in clear text? - Why is it that we are one of biggest distributions with over 3k packages, so many GDE and WM, and so few choice of what to install in d-i? Especially, there's many better alternatives to tasksel. On 12/18/2011 04:43 AM, Otavio Salvador wrote: > I do think you ought to stop to try to push your personal opinion too > hard... it is clear on this thread that most people do not agree with > you so lets go ahead and move topic. I don't think Debian's path ought to be doing *less* and removing nice functionality, just because it may confuse some of our less knowledgeable users. I'm sorry if you think I'm voicing this opinion too much, but I strongly believe Debian should be more than a toy OS for newbies (there's Ubuntu and Mint aiming at them anyway). Thomas P.S: I removed the BTS from Cc, this has nothing to do with #652275. -- 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/4eede7af.70...@goirand.fr
Re: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On 12/18/2011 04:47 AM, Josh Triplett wrote: > Let me clarify: I can safely say it won't become *Debian's* > recommended configuration anytime soon. > It has strong enough arguments against it > that while a vocal minority might manage to keep it around, I doubt > it will become the default. The discussion would have to change quite > drastically for that to occur. I never wanted it to be the default. On 12/18/2011 04:47 AM, Josh Triplett wrote: > And do you seriously expect the average user to go through the process > of an LVM resize? Seriously, I never did!!! Again, I'm not talking about the "average user", my opinion is that "average joe" shouldn't be our only target. > "Possible" doesn't mean "easy". There are ways to please everyone, debconf priority is one way. Why can't the installer have more options for those who like them, and be more easy (with less confusing options) for the less knowledgeable? We should, if possible, not oppose ease of use, convenience, and the features. We should aim at all of that! ;) Thomas -- 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/4eedec39.4010...@debian.org
Re: Bug#652423: Acknowledgement (ITP: v3c -- C/C++/sh/make/automake/Debian utility toolkit)
On 18/12/11 10:34, martin f krafft wrote: also sprach Philip Ashmore [2011.12.18.1041 +0100]: Being too familiar with a package sometimes has it's drawbacks. Absolutely. Thank you for your patience! v3c is a wrapper package that provides a standard means of interacting with packages by providing "boilerplate" code, programs and scripts, and allowing you to manipulate a package through "make" targets, such as . make check make dist make distcheck make git branch=1.3.5 release debian make install make distclean How about: v3c is a build framework that ties in with GNU make, providing "boilerplate" code for the most common use cases of building software. I'd say that's enough, no need to enumerate example targets. Among its capabilities are doxygen documentation integration, Git version control integration, configurable build modes (for debug and release builds, for example), and the ability to specify most configurable options in the top-level makefile. Good! It also provides a C++ class library for use in client projects. Run "make check" to see test/example C++ programs that use it. Why would I want to use build framework from within C++? Maybe you can try to answer this question. The C/C++ library is just another goodie in the goodie-bag. It would help provide C/C++ developers with most everything they would need to start out with packages, using the v3c tests/examples as starting points. I'm not a huge automake fan, but until something much better comes along, it's widely used, so here we are. The note about "make check" should go into the README file, IMHO. See treedb, meta-treedb, v3c-dcom and v3c-qt as examples of projects that use the v3c build framework. Ok. I am still somewhat confused why the project v3c-dcom and v3c-qt carry the name of the build framework in the package names, but I suppose I would look at those packages' descriptions to find out more. It was either that or name them "dcom", "qt" etc. I've seen a few others like them. Treedb and meta-treedb escaped this because they're unique already. Also, v3c is an easy-to-type, easy-to-read C++ name space. I'm not on a branding exercise, it just seemed like the thing to do. Cheers, So how's this? v3c is a build framework that ties in with GNU make, providing "boilerplate" code for the most common use cases of building software. . Among its capabilities are doxygen documentation integration, Git version control integration, configurable build modes (for debug and release builds, for example), and the ability to specify most configurable options in the top-level makefile. It also provides a general purpose C++ class library for use in client projects. . See treedb, meta-treedb, v3c-dcom and v3c-qt as examples of projects that use the v3c build framework. Regards, Philip Ashmore -- 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/4eedf20b.4020...@philipashmore.com
Bug#652557: ITP: libmoosex-types-datetime-morecoercions-perl -- extensions to MooseX::Types::DateTime
Package: wnpp Owner: gregor herrmann Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libmoosex-types-datetime-morecoercions-perl Version : 0.08 Upstream Author : Dagfinn Ilmari Mannsåker * URL : http://search.cpan.org/dist/MooseX-Types-DateTime-MoreCoercions/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : extensions to MooseX::Types::DateTime MooseX::Types::DateTime::MoreCoercions builds on MooseX::Types::DateTime to add additional custom types and coercions. Since it builds on an existing type, all coercions and constraints are inherited. -- 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/20111218151553.ga29...@belanna.comodo.priv.at
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Josh Triplett writes: > On Fri, Dec 16, 2011 at 12:13:55PM +0100, Goswin von Brederlow wrote: >> Josh Triplett writes: >> > Russ Allbery wrote: >> >>Josh Triplett writes: >> >>> In all of the recent discussions about separate /usr partitions, most >> >>> people seem to acknowledge them as unusual, special-purpose >> >>> configurations, even those who use them. To the extent they have a use >> >>> at all, they primarily have a use for people who have very specific >> >>> reasons for wanting them, and all of those people will know how to >> >>> handle partitioning. To a lesser extent, that holds true for having >> >>> separate partitions for /var, /tmp, or other top-level directories. It >> >>> seems likely that any such setup will have custom requirements. >> >> >> >> I don't think these things are alike. Separating /var and /tmp from the >> >> rest of the file systems is done because those partitions contain varying >> >> amounts of data and often fill if something goes wrong, but can fill >> >> without impacting the rest of the system and allowing easy recovery if >> >> they're not on the same partition as everything else. >> > >> > Exactly what I had in mind when I said "To a lesser extent". :) >> >> There are strong reasons for a seperat /tmp and /var partitions. Most >> importantly because both are writable and written to. >> >> /tmp should default to tmpfs and D-I should not create a partition for >> it normaly. There could be recipies for a sperate /tmp partition but it >> shouldn't be the default. I agree that people that need a seperate /tmp >> partition will know that they do. > > As far as I know, /tmp currently does default to tmpfs. > >> As for /var that should be a seperate partition. The default setup >> should allow / to be mounted read-only even if that isn't the default. >> Besides that it also reduces fragmentation and lessens the risk of >> filesystem corruption on /. Overall it is a good idea and having it a >> seperate partition is no burden for the normal user. > > I disagree; I think it leads to a significant burden. Having /var > separate requires pre-determining an appropriate size for it, and that > will vary wildly between systems. At a minimum it needs enough space > for /var/cache/apt, which can grow to many gigabytes. Servers with mail Dude, run apt-get autoclean in cron daily. :) > spools (/var/spool/mail), large websites in the default location > (/var/www), or large databases (/var/lib/postgresql or similar) will > need a lot more. The same applies in reverse, when /var has space to > spare but other partitions don't. And even experienced sysadmins find > it painful to either resize disk partitions or create magic bind mounts > to partitions that have space. lvresize, resize2fs, done There will always be a war for space between partitions. No default will fit all cases. So I only see two scenarios that work for the general case: 1) just one partition using all the space 2) LVM with partitions kept small and free space to grow them as needed And I'm against having just one partition. But that is just me. >> > I still think the general statement applies: "It seems likely that any >> > such setup will have custom requirements.". Anyone installing a server >> > probably either wants one of the two other guided setups (all-in-one or >> > separate /home) or wants the manual partitioner because they have >> > specific ideas about which partitions and sizes they want. Thus, I >> > think the guided partitioner shouldn't offer a generic >> > pile-o'-partitions option, and particularly not one with a separate >> > /usr. >> > >> > - Josh Triplett >> >> Imho the default should be /, /var and /home as LVM LVs and /tmp as >> tmpfs. It is minimal but flexible. > > I understand your point in general, and I do like the idea of making > read-only / easier. I also think, though, that the setup you recommend > here will lead to complex problems that prove difficult for many users > to deal with. > > Now that the Linux kernel supports read-only bind mounts, making / > read-only does not actually require having separate partitions for > /home and /var. How would that work? Mount / somewhere temporary, read-only bind mount it to /real-root, read-write bind mount /var to /real-root/var (same for /home) and only then have the initramfs run-init? But I think that completly misses the point of having a read-only /. The point is to have the filesystem mounted read-only and unaffected by writes anywhere. A read-only bind mount only restricts access but does not leave the filesystem itself read-only and safe from corruption. > In any case, this doesn't seem like an argument against the bug I've > filed here; you don't seem to advocate the particular guided > partitioning option I've proposed the removal of. :) > > - Josh Triplett Only to the extend you recommend. The proposal to not have a seperate /usr partition seems sound. But lets just stop there for now. MfG G
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Sun, Dec 18, 2011 at 06:48:53PM +0100, Goswin von Brederlow wrote: > Josh Triplett writes: > > > I disagree; I think it leads to a significant burden. Having /var > > separate requires pre-determining an appropriate size for it, and that > > will vary wildly between systems. At a minimum it needs enough space > > for /var/cache/apt, which can grow to many gigabytes. Servers with mail > > Dude, run apt-get autoclean in cron daily. :) To be honest, I've always found apt's inability to manage its cache without manual intervention somewhat annoying. It should be perfectly capable of pruning its own cache rather than pointlessly filling up /var with thousands of downloaded packages. I'm surprised it doesn't automatically remove outdated .debs when you update, and require special configuration not to do that. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/20111218175635.gi23...@codelibre.net
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On 2011-12-18 18:48:53 +0100 (+0100), Goswin von Brederlow wrote:
[...]
> lvresize, resize2fs, done
[...]
> 2) LVM with partitions kept small and free space to grow them as
> needed
[...]
Since the advent of logical volume management I personally find this
the easiest solution and use it whenever possible, but LVM and
filesystem resizing tools aren't generally geared toward new users
(EVMS wasn't too bad in this regard but seems to have lost a lot of
market share in the community in more recent years). I'm not
entirely thrilled that D-I pushes users to allocate all their local
disk during installation rather than leaving room to grow in the
volume group, but some combination of education and user-friendly
disk management tools would be needed to shift this paradigm.
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl); }
--
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/20111218180115.gh...@yuggoth.org
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
Roger Leigh wrote: >To be honest, I've always found apt's inability to manage its >cache without manual intervention somewhat annoying. It should >be perfectly capable of pruning its own cache rather than >pointlessly filling up /var with thousands of downloaded >packages. I'm surprised it doesn't automatically remove >outdated .debs when you update, and require special configuration >not to do that. > I rather see it as conservative. Nowadays, a few extra hundreds of megabytes are not critical, or at least should not be. But imagine you update a package and it breaks your system - You have the older .deb cached right away. I know you could get it off another computer if you're having network problems, but I think the predefined caching has its advantages too. Daniel -- 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/0c6a2c7d-a957-4f28-9705-a0e593f66...@email.android.com
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Sun, Dec 18, 2011 at 18:56, Roger Leigh wrote: > On Sun, Dec 18, 2011 at 06:48:53PM +0100, Goswin von Brederlow wrote: >> Josh Triplett writes: >> >> > I disagree; I think it leads to a significant burden. Having /var >> > separate requires pre-determining an appropriate size for it, and that >> > will vary wildly between systems. At a minimum it needs enough space >> > for /var/cache/apt, which can grow to many gigabytes. Servers with mail >> >> Dude, run apt-get autoclean in cron daily. :) > > packages. I'm surprised it doesn't automatically remove > outdated .debs when you update, and require special configuration > not to do that. As you seem to know the one-size-fits-all sane default for the functionality implemented in apt's own cronscript, please report a wishlist with these values and i am sure we will be happy to incorporate it. And please provide a valid email address in this report so we can forward all messages complaining about these new default to you. While looking forward to your bugreport, Best regards David Kalnischkies -- 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/caaz6_fdtctf8vzg3eft9inozer1h5fhfnvm8h37lnmgk2yc...@mail.gmail.com
Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning
On Sun, Dec 18, 2011 at 06:48:53PM +0100, Goswin von Brederlow wrote: > Josh Triplett writes: > > On Fri, Dec 16, 2011 at 12:13:55PM +0100, Goswin von Brederlow wrote: > >> Josh Triplett writes: > >> > Russ Allbery wrote: > >> >>Josh Triplett writes: > >> >>> In all of the recent discussions about separate /usr partitions, most > >> >>> people seem to acknowledge them as unusual, special-purpose > >> >>> configurations, even those who use them. To the extent they have a use > >> >>> at all, they primarily have a use for people who have very specific > >> >>> reasons for wanting them, and all of those people will know how to > >> >>> handle partitioning. To a lesser extent, that holds true for having > >> >>> separate partitions for /var, /tmp, or other top-level directories. It > >> >>> seems likely that any such setup will have custom requirements. > >> >> > >> >> I don't think these things are alike. Separating /var and /tmp from the > >> >> rest of the file systems is done because those partitions contain > >> >> varying > >> >> amounts of data and often fill if something goes wrong, but can fill > >> >> without impacting the rest of the system and allowing easy recovery if > >> >> they're not on the same partition as everything else. > >> > > >> > Exactly what I had in mind when I said "To a lesser extent". :) > >> > >> There are strong reasons for a seperat /tmp and /var partitions. Most > >> importantly because both are writable and written to. > >> > >> /tmp should default to tmpfs and D-I should not create a partition for > >> it normaly. There could be recipies for a sperate /tmp partition but it > >> shouldn't be the default. I agree that people that need a seperate /tmp > >> partition will know that they do. > > > > As far as I know, /tmp currently does default to tmpfs. > > > >> As for /var that should be a seperate partition. The default setup > >> should allow / to be mounted read-only even if that isn't the default. > >> Besides that it also reduces fragmentation and lessens the risk of > >> filesystem corruption on /. Overall it is a good idea and having it a > >> seperate partition is no burden for the normal user. > > > > I disagree; I think it leads to a significant burden. Having /var > > separate requires pre-determining an appropriate size for it, and that > > will vary wildly between systems. At a minimum it needs enough space > > for /var/cache/apt, which can grow to many gigabytes. Servers with mail > > Dude, run apt-get autoclean in cron daily. :) Doesn't happen by default. I've encountered a number of users who didn't know about /var/cache/apt at all, and as a result they had quite a pile of wasted space there, contributing to their nearly-full disks. > > spools (/var/spool/mail), large websites in the default location > > (/var/www), or large databases (/var/lib/postgresql or similar) will > > need a lot more. The same applies in reverse, when /var has space to > > spare but other partitions don't. And even experienced sysadmins find > > it painful to either resize disk partitions or create magic bind mounts > > to partitions that have space. > > lvresize, resize2fs, done Doesn't make it any less painful. (Also, don't forget the resize2fs and lvresize of some other partition first, and figuring out the appropriate amount of space to move around.) This also assumes LVM, which we don't default to. > > Now that the Linux kernel supports read-only bind mounts, making / > > read-only does not actually require having separate partitions for > > /home and /var. > > How would that work? Mount / somewhere temporary, read-only bind mount > it to /real-root, read-write bind mount /var to /real-root/var (same for > /home) and only then have the initramfs run-init? Or just mount / over itself read-only, with /home and /var bind-mounted read-write. > > In any case, this doesn't seem like an argument against the bug I've > > filed here; you don't seem to advocate the particular guided > > partitioning option I've proposed the removal of. :) > > Only to the extend you recommend. The proposal to not have a seperate > /usr partition seems sound. But lets just stop there for now. While I'd still prefer removing the recipe in question from the guided partitioner, I'd settle for removing /usr from that recipe. - Josh Triplett -- 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/20111218185154.GA2518@leaf
Re: Bug#652432: Acknowledgement (ITP: v3c-dcom -- Baby steps to DCOM)
DCOM's package description. DCOM's danger. I studied Microsoft's DCOM. It's a lesser hack of Sun Java technology (which Microsoft patently attempted to steal, hide, and destroy). Object interfacing. (ie, apple's corba) It came out predictably much later than Java. While I think it's great to provide support or alternates for PATENDED material like DCOM. Surely it was allot of work I appreciate that. I think it's misleading to sweepingly say "virtually unlimited configuration and customization. What isn't? "Users and client programs can even create sandboxes on the fly" "for use with linux Makefiles." (how is dcom related to unix Makefiles again ??) Who knows a DCOM copy cat would probably bring yet another Microsoft lawsuit toward linux. Microsoft has often stole the X of Xerox Windows (ie, X-box which did not use any X technology, while sony ps3 does or did). That DOESN'T mean microsoft won't try to sue if it's the other way around. Doesn't anyone remember "lindows"? Wishing to make computing ubiquitous? That linux team got sued and LOST in court. Remember anyone? What I mean is: "Baby steps toward DCOM?" Yea. But is this baby a 500lb Gorilla baby? It's SURELY against Debian Rules to write incorrect package descriptions. DCOM doesn't provide sandboxes. Description: see Microsoft for copyright material on DCOM's purpose, function, form, and compatibility. repeating it out of band could be infringement. I'm sorry. Microsoft "paid to make it" (or said they did) and they don't wish to share it, am I not completely correct? That's life I'm not saying I like it or not. Nothing to like or not like about object interfaces after all (security lapses aside). v3c-dcom provides a plug-in system as an alternative COM implementation. Unlike COM, v3c-dcom encourages the use of "sandboxes" of registered plug-ins, -- 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/4eee5224.8070...@cox.net
Re: Bug#652432: Acknowledgement (ITP: v3c-dcom -- Baby steps to DCOM)
On 18/12/11 20:50, John D. Hendrickson and Sara Darnell wrote: DCOM's package description. DCOM's danger. I studied Microsoft's DCOM. It's a lesser hack of Sun Java technology (which Microsoft patently attempted to steal, hide, and destroy). Object interfacing. (ie, apple's corba) It came out predictably much later than Java. You forgot to mention DCE. While I think it's great to provide support or alternates for PATENDED material like DCOM. Surely it was allot of work I appreciate that. It's being used in Samba on Linux now. Not forgetting Wine. I think it's misleading to sweepingly say "virtually unlimited configuration and customization. What isn't? "Users and client programs can even create sandboxes on the fly" "for use with linux Makefiles." (how is dcom related to unix Makefiles again ??) The package provides a plug-in system. Each plug-in file contains two dictionaries, one mapping ProdIDs to GUIDS and another mapping GUIDS to plug-in filenames. I don't recall saying "for use with linux Makefiles.", please include the relevant text. Who knows a DCOM copy cat would probably bring yet another Microsoft lawsuit toward linux. Microsoft has often stole the X of Xerox Windows (ie, X-box which did not use any X technology, while sony ps3 does or did). That DOESN'T mean microsoft won't try to sue if it's the other way around. Doesn't anyone remember "lindows"? Wishing to make computing ubiquitous? That linux team got sued and LOST in court. Remember anyone? Qt provides a plug-in system but it's system-wide and shared between programs and users. v3c-dcom provides the same system but inside a file, and programs and users can choose to share them by specifying their path in an environment variable. There's not much to v3c-dcom, and it really could become part of a boot loader. What I mean is: "Baby steps toward DCOM?" Yea. But is this baby a 500lb Gorilla baby? It's SURELY against Debian Rules to write incorrect package descriptions. DCOM doesn't provide sandboxes. v3c-dcom provides a library to allow anyone to create a sandbox - it's a file. Description: see Microsoft for copyright material on DCOM's purpose, function, form, and compatibility. repeating it out of band could be infringement. Again, Samba, Wine. I'm sorry. Microsoft "paid to make it" (or said they did) and they don't wish to share it, am I not completely correct? Then there's ATL - the C++ wrapper. I deliberately limited myself to the contents of "Inside ATL" Copyright© 1999 by George Shepherd, Brad King, ISBN 1-57231-858-9. Yes, it states that "No part of the contents of this book may be reproduced or transmitted in any form or by any means without the written permission of the publisher." and that's Microsoft Press. If you think about it, I broke copyright right there, by telling you how I broke copyright! There is an aspect of copyright law that allows people to discuss and communicate their opinions on published works, by making reference to them, and their contents. Oh and, by the way, you can't reference anything you read in this email. Hell, you can't even read it. We're all free to voice legal-sounding mumbo-jumbo that will never see a court room. Here in Ireland there's a company called UPC and they state in some legaleze document I read somewhere, something along the lines of "non-UPC equipment cannot be connected to the UPC TV outlet". How about a TV then? Believe it or not there are libraries for sale that you have to sign a non-disclosure agreement for before you can even read the documentation. And they don't have snippet galleries, discussion forums, help groups learning centres that are two clicks away from a web search. I think that's called due diligence, but I'm not at liberty to discuss it. There comes a point when discussions reference other discussions and the subject matter becomes so widely discussed on the web that it enters the public domain, and someone who hasn't bought or read about the subject from a privileged source can become quite knowledgeable about it. And so to the crux of the matter, I wrote v3c-dcom firstly because I think it's a really neat plug-in system. I used Microsoft's naming scheme as it may be familiar with some software developers. I could change all the names by adding an "idily" at the end - CoCreateInstanceExIdily() - would that be OK? Then someone would publish a header file to #define them back so they could compile their code on Windows and Linux. If you like, I can change the projects name to "v3c-dcomidily". I hope you're getting the point by now. That's life I'm not saying I like it or not. Nothing to like or not like about object interfaces after all (security lapses aside). v3c-dcom provides a plug-in system as an alternative COM implementation. Unlike COM, v3c-dcom encourages the use of "sandboxes" of registered plug-ins, Regards, Philip Ashmore -- To UNSUBSCRIBE, e
Re: from / to /usr/: a summary
I demand that Ben Hutchings may or may not have written...
> On Sat, 2011-12-17 at 20:42 +, Philip Hands wrote:
[snip]
>> I've read all of these threads, but I'm afraid I'm still a little
>> befuddled about the pros and cons.
>> Pro seems to be saving some effort for packagers when RedHat as upstream,
>> say, makes changes that assume /usr is always available, that's clear.
> This isn't specific to 'Red Hat as upstream'. It's simply very hard for a
> general-purpose distribution to know all executables and libraries that may
> be wanted by init scripts and daemons before all volumes are mounted, and
> it can be disruptive to move executables between directories.
I'd say exactly enough to mount /usr and to be able to do filesystem checks.
So, for me, /sbin/mount, /sbin/fsck.ext{3,4} and the minimum necessary to
support these.
I keep *small* boot partitions, and I may have a few kernels in them;
initramfs is, for me, bloat.
[snip]
> We're now debating what, if any, effort we should make to continue to
> support running init scripts without /usr mounted. There is also
> discussion of whether separate / and /usr partitions should be supported or
> deprecated, but I think that's quite separate.
If /usr gets mounted earlier, fine. I'm happy if / can be used without
needing /usr for basic recovery.
I fully intend to continue with lilo, separate /usr and no initramfs/initrd.
I *may* decide to stop using a separate /usr should I need to replace
hardware – but probably not before then.
I will NOT use an initramfs just to have /usr mounted early enough.
[snip]
--
| _ | Darren Salt, using Debian GNU/Linux (and Android)
| ( ) |
| X | ASCII Ribbon campaign against HTML e-mail
| / \ | http://www.asciiribbon.org/
Syntax is another name for conscience money.
--
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/524936de54%li...@youmustbejoking.demon.co.uk
Re: from / to /usr/: a summary
On Mon, 2011-12-19 at 01:03 +, Darren Salt wrote: [...] > I fully intend to continue with lilo, separate /usr and no initramfs/initrd. > I *may* decide to stop using a separate /usr should I need to replace > hardware – but probably not before then. > > I will NOT use an initramfs just to have /usr mounted early enough. Your custom kernel with everything built in has absolutely no bearing on what a *general-purpose distribution* has to do. Ben. -- Ben Hutchings Humans are not rational beings; they are rationalising beings. signature.asc Description: This is a digitally signed message part
uscan, watch files, and gihub tags
Hi, For XCP (Xen Cloud Platform) that I'm helping to package (the first version is nearly finished), upstream doesn't releases tarballs, but instead, just adds tags to its Git repository, and git-buildpackage does the rest of the magic (eg: selecting the correct tag on the master branch to build the orig.tar.gz). Is there currently a way, or is it planned, or is it even possible, that watch files are used to check git tags? Cheers, Thomas -- 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/4eeecb9b.1080...@debian.org
Re: uscan, watch files, and gihub tags
On Mon, Dec 19, 2011 at 12:28 AM, Thomas Goirand wrote: > Hi, > > For XCP (Xen Cloud Platform) that I'm helping to package (the first > version is nearly finished), upstream doesn't releases tarballs, but > instead, just adds tags to its Git repository, and git-buildpackage does > the rest of the magic (eg: selecting the correct tag on the master > branch to build the orig.tar.gz). > > Is there currently a way, or is it planned, or is it even possible, that > watch files are used to check git tags? Since your title said "github tags," I think you're looking for: http://githubredir.debian.net/ The source code is there if you're not on github. Cheers, Scott -- 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/cang8-dcwtxawgkz1no57xfbuoogujhu9vdwvyziy_xalpso...@mail.gmail.com
Re: uscan, watch files, and gihub tags
On Mon, Dec 19, 2011 at 1:55 PM, Scott Howard wrote: > Since your title said "github tags," I think you're looking for: > http://githubredir.debian.net/ There is no need to use githubredir, just do something like this: version=3 https://github.com/celeron55/minetest/tags .*/tarball/(.*) -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6h_35rv-12s-yxc69qmqzezdyh1qcxardsnt4zot2e...@mail.gmail.com
Re: uscan, watch files, and gihub tags
On 12/19/2011 01:55 PM, Scott Howard wrote: > Since your title said "github tags," I think you're looking for: > http://githubredir.debian.net/ > > The source code is there if you're not on github. > > Cheers, > Scott > Hi Scott, thanks for your quick answer. I'm now cross-posting in -mentors. In my case, upstream tagged "master/1.3", and I'm getting issues still, with uscan. zigo@node4407:~/sources/xen-api/xen-api$ cat debian/watch version=3 http://githubredir.debian.net/github/jonludlam/xen-api (.*).tar.gz but then, I have the following error: zigo@node4407:~/sources/xen-api/xen-api$ uscan --verbose --report -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: http://githubredir.debian.net/github/jonludlam/xen-api (.*).tar.gz -- Found the following matching hrefs: /github/jonludlam/xen-api/0~master.tar.gz /github/jonludlam/xen-api/master/1.3.tar.gz dpkg: warning: version '/master/1.3' has bad syntax: version number does not start with digit Newest version on remote site is /master/1.3, local version is 1.3 dpkg: warning: version '/master/1.3' has bad syntax: version number does not start with digit => Newer version available from http://githubredir.debian.net/github/jonludlam/xen-api/master/1.3.tar.gz -- Scan finished FYI, I really am packaging version 1.3, so uscan should find out that I'm up-to-date. I tried to poke with opts="uversionmangle=s/^master\///" to remove "master/" from the version of upstream git repo, but no luck... Upstream is friendly, so I can ask to remove the annoying bits of the versions, but there's already 9 packages involved, so I'd be glad to find a solution keeping upstream scheme, that would be less work and forcing "git push/pull --force --tags" to everyone working on the project is annoying. Cheers, Thomas Goirand (zigo) -- 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/449f.2090...@debian.org
