Re: single-debian-patch
]] Raphael Hertzog | On Fri, 23 Sep 2011, Tollef Fog Heen wrote: | > Could we please have the old behaviour back? | | No, it's a bit late to request this. Before doing this change, we had the | discussion here on debian-devel and it was relatively consensual: | http://lists.debian.org/debian-devel/2011/05/msg01130.html | | I think you are misunderstanding the impact of this change because | it's not as bad as you seem to imply. It makes packages that built fine before now fail to build. I think that's pretty bad. I guess I'll work around this by just using native packages instead, since they seem to map better to the case of keeping packaging in a VCS and using 3.0 (quilt) (and to some extent non-native 1.0) effectively is like trying to use two VCS-es at the same time, which does cause grief. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/8762kimneq@qurzaw.varnish-software.com
Bug#642586: ITP: mmtk -- The molecular modeling toolkit
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" Dear Maintainer, * Package name: mmtk Version : 2.7.5 Upstream Author : Konrad Hinsen * URL : http://dirac.cnrs-orleans.fr/MMTK/ * License : CeCILL-C Programming Lang: C, Python Description : The molecular modeling toolkit The Molecular Modeling Toolkit (MMTK) is a library for molecular simulation applications. It provides the most common methods in molecular simulations (molecular dynamics, energy minimization, normal mode analysis) and several force fields used for biomolecules (Amber 94, Amber 99, several elastic network models). MMTK also serves as a code basis that can be easily extended and modified to deal with non-standard situations in molecular simulations. this will be a dependency for nMOLDYN http://dirac.cnrs-orleans.fr/plone/software/nmoldyn/ -- 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/20110924080513.16311.23811.reportbug@mordor
Re: Format 3.0 (git)
* Charles Plessy [110924 08:30]: > If in a large number of cases where one would like to turn off the patch > system > of the 3.0 (quilt) format, the source package is stored in a Git repository, > then one way to move forward would be to make the format 3.0 (git) available > in Debian. What are the blocking points ? Apart from license problems, practical problems with reviewability and stuff like that, people like me are very much opposed as it is quite against the ideals of Debian in some very important aspects: - Debian is about freedom. Freedom in software is about about enabling people to "scratch their itch", to modify the software to suite their need and what they consider best for them. It's not about "pay us and we will make it work for you", it is not about "tell us, we will make it work for you (if we think it is worthwhile)", it is about "*you* can do it, if you want". VCSes are good for professional work and I think it is good if DDs use them. But there are many of them, with quite serious differences in concepts and ways to interact in them. Sadly they are either extremly complex for casual users (git), not very well suited for packaging (cvs), both (svn) or slow and too fragile implementations (everything else I've met; all examples my personal opinion). A DD should be able to understand VCSs, a user should not need much more than some reading skills in the language a program is implemented in order to understand what the Debian version does and a little bit of writing skills to make a modified version. - Debian is about giving back. It has been better than that BSD like model where stuff is imported in some VCS (and each having their own favorite), heavily modified and then merged till eternity with new versions (and sometimes not) so that it is practically impossible to find out why things are changed. It has been better at that than rpm where you always look for another perl script in the net that is able to make a cpio out of that version of source rpm you run into, so you can actually look at what they do. "3.0 (quilt)" even improved that as we now also are able to split changes in easer to read and understand parts, still universally understandable. The patch-tracker improves the situation even more. We now have a possibility to nicely show exactly what changes we do relative to upstream in a clear way. Anything that offers that possibility can be trivially converted to "3.0 (quilt)", everything that cannot be converted in this is lacking in that aspect. Bernhard R. Link -- 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/20110924093521.ga...@server.brlink.eu
Re: Format 3.0 (git)
"Bernhard R. Link" writes: > It has been better at that than rpm where you always look for > another perl script in the net that is able to make a cpio out of > that version of source rpm you run into, so you can actually look at > what they do. I always just alien --to-tgz the SRPM and then I see each patch as a separate file. -- 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/84pqiq6y85@sauna.l.org
Re: Bug#642586: ITP: mmtk -- The molecular modeling toolkit
Le samedi 24 septembre 2011 10:05:13, Picca Frédéric-Emmanuel a écrit : > Package: wnpp > Severity: wishlist > Owner: "Picca Frédéric-Emmanuel" > > Dear Maintainer, > > * Package name: mmtk > Version : 2.7.5 > Upstream Author : Konrad Hinsen > * URL : http://dirac.cnrs-orleans.fr/MMTK/ > * License : CeCILL-C > Programming Lang: C, Python > Description : The molecular modeling toolkit > > The Molecular Modeling Toolkit (MMTK) is a library for molecular > simulation applications. It provides the most common methods in > molecular simulations (molecular dynamics, energy minimization, > normal mode analysis) and several force fields used for biomolecules > (Amber 94, Amber 99, several elastic network models). MMTK also > serves as a code basis that can be easily extended and modified to > deal with non-standard situations in molecular simulations. > > > this will be a dependency for nMOLDYN > http://dirac.cnrs-orleans.fr/plone/software/nmoldyn/ I should have been faster to do the ITP for the other MMTk: Memory Management Toolkit. Anyway, no problem, I'll use something like mmtk-gc or the like. signature.asc Description: This is a digitally signed message part.
Re: Bug#642586: ITP: mmtk -- The molecular modeling toolkit
Le samedi 24 septembre 2011 12:55:27, Thomas Preud'homme a écrit : > Le samedi 24 septembre 2011 10:05:13, Picca Frédéric-Emmanuel a écrit : > > Package: wnpp > > Severity: wishlist > > Owner: "Picca Frédéric-Emmanuel" > > > > Dear Maintainer, > > > > * Package name: mmtk > > > > Version : 2.7.5 > > Upstream Author : Konrad Hinsen > > > > * URL : http://dirac.cnrs-orleans.fr/MMTK/ > > * License : CeCILL-C > > > > Programming Lang: C, Python > > Description : The molecular modeling toolkit > > > > The Molecular Modeling Toolkit (MMTK) is a library for molecular > > simulation applications. It provides the most common methods in > > molecular simulations (molecular dynamics, energy minimization, > > normal mode analysis) and several force fields used for biomolecules > > (Amber 94, Amber 99, several elastic network models). MMTK also > > serves as a code basis that can be easily extended and modified to > > deal with non-standard situations in molecular simulations. > > > > this will be a dependency for nMOLDYN > > http://dirac.cnrs-orleans.fr/plone/software/nmoldyn/ > > I should have been faster to do the ITP for the other MMTk: Memory > Management Toolkit. Anyway, no problem, I'll use something like mmtk-gc or > the like. Since this second mmtk is written in java, I meant mmtk-gc-java of course. Regards. signature.asc Description: This is a digitally signed message part.
Re: Format 3.0 (git)
Hi Bernhard. If I may briefly summarise your objections against the source format 3.0 (git): 1) It increases the risk of distributing non-free files. 2) It reduces our user's freedom to modify the software we redistribute, because they may not be comfortable with git. 3) Compared to 3.0 (quilt), it does not present well the changes made by Debian. I think that all these three points can be worked out. 1) Debian packages using the 3.0 (git) format have more content that their counterparts, but we could compromise on some limits. For instance, to not include any history in new packages. Second, the past versions contained in the package could be limited to one or two release horizons. This way, a user following Debian accros multiple releases with the source CDs would have the history over the period he used Debian, and of course possibly more with Internet acceess as the git clone downloaded by debcheckout would contain everything. 2) The format 3.0 (git) is a dpkg-source format, which means that the usual commands will give to the users the same unpacked package as if using other formats, with the exception of a .git directory that can be ignored. Moreover, I think that we are gradually shifting to an era where the VCS comments are an integral part of the source code. I therefore see the 3.0 (git) format as more free than the 1.0 or the 3.0 (quilt) formats for any source package that I maintain as a Git repository, because it preserves the VCS comments. 3) As all other formats, the 3.0 (git) is neutral in terms of presenting the changes introduced by Debian in an intelligble or obsfucated way. The patch tracker is a very useful ressource, that can also be used with the 3.0 (git) format, either in a purely descriptive way, or because a patch system is used on the top of Git. In conclusion, I think that the 3.0 (git) format is actually quite in line with the ideals of Debian: it provides the full source with VCS comments, in a way that eases the creation of patches for Upstream or the maintainer, and that does not hide problems as intermediate revisions are available. To this paraphrasing of our Social Contract, I would add that 3.0 (git) also fits with another Debian ideal, technical excellence. Cheers, -- 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 Archive: http://lists.debian.org/20110924123601.gc21...@merveille.plessy.net
Re: Format 3.0 (git)
]] "Bernhard R. Link" | * Charles Plessy [110924 08:30]: | > If in a large number of cases where one would like to turn off the patch system | > of the 3.0 (quilt) format, the source package is stored in a Git repository, | > then one way to move forward would be to make the format 3.0 (git) available | > in Debian. What are the blocking points ? | | Apart from license problems, practical problems with reviewability and | stuff like that, people like me are very much opposed as it is quite | against the ideals of Debian in some very important aspects: I find reviewing what's changed between two arbitrary versions in git much easier than doing the same with debian source packages, so I think it's pretty clear this is a matter of preference. | - Debian is about freedom. Freedom in software is about about enabling | people to "scratch their itch", to modify the software to suite their | need and what they consider best for them. Yes, and to continue that thread: The way we do that is to distribute the source of our work. The most useful definition of source I've come across is the GPL's: The preferred form for modification. Given I maintain my packages in git, it's quite clear that the preferred form for modification of my packages is through git and not debian source packages. That we don't have a good way of distributing the source of packages is a fault I think we should address. I don't put much weight on the «it should be simple to hack on packages and VCSes make it hard» argument. IME, there are many more people who know how to drive git than there are people who know how to usefully hack on Debian packages. git used to be hard to use back in the olden days, but it isn't particularly hard nowadays. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ipoirpoq@qurzaw.varnish-software.com
Bug#642655: ITP: brebis -- fully automated backup checker
Package: wnpp Severity: wishlist Owner: Carl Chenet * Package name: brebis Version : 0.1 Upstream Author : Carl Chenet * URL : http://www.brebisproject.org/ * License : GPL Programming Lang: Python Description : Fully automated backup checker Brebis parses backups (archives and file tree) to perform several different checks in order to verify your backup integrity and its associated content. -- 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/20110924143336.25496.68393.reportbug@bureau
Bug#642677: ITP: python-repoze.sendmail -- mail sending library with transactions
Package: wnpp Severity: wishlist Owner: "Matthias Kümmerer" * Package name: python-repoze.sendmail Version : 2.3 Upstream Author : Chris Rossi * URL : http://www.repoze.org * License : ZPL-2.1 Programming Lang: Python Description : mail sending library with transactions repoze.sendmail allows coupling the sending of email messages with a transaction, using the Zope transaction manager. This allows messages to only be sent out when and if a transaction is committed, preventing users from receiving notifications about events which may not have completed successfully. Messages may be sent directly or stored in a queue for later sending. The queued mail approach is the more common and recommended path. A console application which can flush the queue, sending the messages that it finds, is included for convenience. . repoze.sendmail is a fork of zope.sendmail. Functionality that was specific to running in a Zope context has been removed, making this version more generally useful to users of other frameworks. This is a dependency of pyramid_mailer, which I intend to package also. -- 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/20110924153216.15100.33874.report...@klio.matthias-k.org
Re: Format 3.0 (git)
Tollef Fog Heen writes ("Re: Format 3.0 (git)"):
> I don't put much weight on the «it should be simple to hack on packages
> and VCSes make it hard» argument. IME, there are many more people who
> know how to drive git than there are people who know how to usefully
> hack on Debian packages.
More to the point, it is not effectively possible to work on Debian
source packages without using Debian tools. (It used to be when there
was just the tarball and perhaps one patch, but now that we have all
these different source formats it certainly isn't any more.)
So all that is needed is for those Debian tools (dpkg-source,
primarily) to do "the right thing" and then working with a git format
source package is just as easy or hard as working with (say) quilt or
the old 1-patch format.
So I don't buy this argument. From the point of view of someone who
doesn't want to learn git, they can use dpkg-source and the git stuff
is an implementation detail.
Ian.
--
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/20093.64277.304864.100...@chiark.greenend.org.uk
Re: Bits from dpkg developers - dpkg 1.16.1
Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Raphael Hertzog wrote:
> > * dpkg-buildpackage no longer exports
> > CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
>
> | You don't know how many packages are broken or no longer
> | policy compliant because they were relying on those environment
> | variables
>
> Who said that? Oh, yeah it was you.
>
> How are we supposed to deal with packages that have been broken or made
> policy incompliant by this change to dpkg?
I'm one of the submitters of one of the bugs which requested this
change. This is a reversion of dpkg to a previous behaviour, and it
/un/breaks packages. Or at least I think it unbreaks much more than
it breaks.
It was always completely wrong of dpkg-buildpackage to set these
variables. Source packages are entitled to assume that strange
environment variables which cause their tools to do odd things will
not be set.
Ian.
--
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/20093.64447.724751.724...@chiark.greenend.org.uk
Bug#642694: ITP: python-pyramid-mailer -- mail sending library for Pyramid
Package: wnpp Severity: wishlist Owner: "Matthias Kümmerer" * Package name: python-pyramid-mailer Version : 0.4.1 Upstream Author : Dan Jacob * URL : https://pylonsproject.org/projects/pyramid_mailer/dev/ * License : BSD-3-clause Programming Lang: Python Description : mail sending library for Pyramid pyramid_mailer is a package for the Pyramid framework to take the pain out of sending emails. It has the following features: * A wrapper around the low-level email functionality of standard Python. This includes handling multipart emails with both text and HTML content, and file attachments. * The option of directly sending an email or adding it to the queue in your maildir. * Wrapping email sending in the transaction manager. If you have a view that sends a customer an email for example, and there is an error in that view (for example, a database error) then this ensures that the email is not sent. * A DummyMailer class to help with writing unit tests, or other situations where you want to avoid emails being sent accidentally from a non-production install. -- 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/20110924163610.23068.90313.report...@klio.matthias-k.org
Re: Format 3.0 (git)
* Timo Juhani Lindfors [110924 12:17]: > I always just alien --to-tgz the SRPM and then I see each patch as a > separate file. Ever tried to install rpm on a system you do not have root on? Bernhard R. Link -- 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/20110924163039.ga2...@server.brlink.eu
RE : Bug#642586: ITP: mmtk -- The molecular modeling toolkit
> Since this second mmtk is written in java, I meant mmtk-gc-java of course. In fact this source package will provide only a python module. So the binary packages will be python-mmtk python-mmtk-doc don't know yet Regards. -- 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/a2a20ec3b8560d408356cac2fc148e5324cf8...@sun-dag1.synchrotron-soleil.fr
Bug#642703: general: Scan lines appear in drop-down menus. LibreOffice also shows artifacts when starting. Might be something to do with the version of fglrx.
Package: general Severity: normal Accessing drop-down menus in LibreOffice shows scan lines. Starting LibreOffice shows artifacts on-screen. Then loads OK * What was the outcome of this action? * What outcome did you expect instead? -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20110924184050.2955.79055.report...@puppypc.lan
Re: Format 3.0 (git)
* Tollef Fog Heen [110924 16:16]: > I find reviewing what's changed between two arbitrary versions in git > much easier than doing the same with debian source packages, so I think > it's pretty clear this is a matter of preference. But if it is some other version control system, which is easier then? > Yes, and to continue that thread: The way we do that is to distribute > the source of our work. The most useful definition of source I've come > across is the GPL's: The preferred form for modification. > > Given I maintain my packages in git, it's quite clear that the preferred > form for modification of my packages is through git and not debian > source packages. That we don't have a good way of distributing the > source of packages is a fault I think we should address. "Preferred form" explicitly does not say which one's preferred form. I might prefer some code with German comments stating those details that are significant to me, and not some English comments also describing things that are clear to me because I use such constructs all of the time. I also do not prefer at all to work on something without my default editor settings, still I do not consider them part of the source. > I don't put much weight on the «it should be simple to hack on packages > and VCSes make it hard» argument. Usefully hacking on Debian packages is only a part of my complaint, and I am sad that it is reduced to that. First of all it is not only about only even Debian users, giving back is about the whole software community. I remember adopting some program and looking around for patches floating around in the net some years ago by looking what the other Linux distributions and BSDs did. Having to install and learn another VCS, and another one, and another one, and then another one. Most of the time people only caring about history but not about visibilty of changes. Having to grok one source format after the other and trying to find programs being able to look into them. Comparing that to those source formats Debian has, which are even no problem to look into from a years old Solaris university lab made me very proud of Debian. Then looking at the Debian ecosystem, it is not only about developers. Or users with enough skills to become developers if they wanted to be. It is also about users with very little skills yet, that have some problems and want to do something. Like understanding why some piece of software on their Debian system behaves differently than on some other Linux system they have. Or doing some crude hack (crude hacks is what you usually can do before you can do anything else) to make something work on their system. If we enable those that administrate their computer or the other systems they care about (how many DDs started by administrating some computers in university? I'd guess that might be >= 10%), they can gain skill after skill, until they are able to proper things with Debian packages and also do this using using VCSes. > git used to be hard to use back in the olden days, but it isn't > particularly hard nowadays. Learning git is not that hard anymore, I guess (, though I am not really able to assess that from having looked at it for a long time). But trying to use to access some stuff must still be quite hard: it has some model of things and some private nomenclature (think: index, tree, commitish) that will not make it that easy to come from zero to be able to locate some commit and do the right diff in some not too long time, even if knowing some other VCSes. Bernhard R. Link -- 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/20110924173551.gb2...@server.brlink.eu
Re: Format 3.0 (git)
Bernhard R. Link wrote: > * Tollef Fog Heen [110924 16:16]: > > I find reviewing what's changed between two arbitrary versions in git > > much easier than doing the same with debian source packages, so I think > > it's pretty clear this is a matter of preference. > > But if it is some other version control system, which is easier then? Arguing against the developer's/maintainer's freedom of choice based on a "feeling" about the learning curve imposed on an intangible group of future contributors is faulty. People that really want to contribute will simply take the time and effort to learn. If they aren't able to sufficiently educate themselves, then they weren't really qualified to participate anyway, so it's not really a net loss. Best wishes, Mike -- 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/20110924143052.ae80b146e4bbc48e91f93...@gmail.com
Re: single-debian-patch
Hi, On Sat, 24 Sep 2011, Tollef Fog Heen wrote: > It makes packages that built fine before now fail to build. I think > that's pretty bad. Not packages on ftp-master at least. Only if you consider "your package" = "your VCS". And frankly adding one option to enable the behaviour you want is not too much to ask IMHO. Yes quilt is a mini-VCS and the new command --commit only make it more evident. --single-debian-patch means precisely I'm not using it in the mode where the quilt patches are significant, I just want to use debian/patches as a big diff representing the changes in my VCS. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110924183230.gh7...@rivendell.home.ouaza.com
Re: Format 3.0 (git)
* Michael Gilbert [110924 20:24]: > Bernhard R. Link wrote: > > > * Tollef Fog Heen [110924 16:16]: > > > I find reviewing what's changed between two arbitrary versions in git > > > much easier than doing the same with debian source packages, so I think > > > it's pretty clear this is a matter of preference. > > > > But if it is some other version control system, which is easier then? > > Arguing against the developer's/maintainer's freedom of choice based on > a "feeling" about the learning curve imposed on an intangible group of > future contributors is faulty. Why do you state this tautology? Do you think it is in any way related to what I have written? How? Bernhard R. Link -- 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/20110924185219.ga3...@server.brlink.eu
Re: Format 3.0 (git)
Bernhard R. Link wrote: > * Michael Gilbert [110924 20:24]: > > Bernhard R. Link wrote: > > > > > * Tollef Fog Heen [110924 16:16]: > > > > I find reviewing what's changed between two arbitrary versions in git > > > > much easier than doing the same with debian source packages, so I think > > > > it's pretty clear this is a matter of preference. > > > > > > But if it is some other version control system, which is easier then? > > > > Arguing against the developer's/maintainer's freedom of choice based on > > a "feeling" about the learning curve imposed on an intangible group of > > future contributors is faulty. > > Why do you state this tautology? Do you think it is in any way > related to what I have written? How? Not a tautology (as there's no repetition in that sentence); but simply a consideration of a very important unstated consequence of your argument. Freedom is a balance. Your argument boils down to taking away a particular aspect of the maintainer's freedom (his/her freedom to use a git format source package; if that ever becomes an option) in favor of making itch scratching simpler (via git avoidance). Not considered is the fact that that contributors are certainly still free to scratch their itches even when they're difficult to reach. And hey, they can even solicit help in that case, and they may learn and one day be able to scratch that itch themselves ;) Best wishes, Mike -- 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/20110924155522.36e22372b309245ca6ebf...@gmail.com
Re: Format 3.0 (git)
On Sat, Sep 24, 2011 at 04:16:21PM +0200, Tollef Fog Heen wrote: > | - Debian is about freedom. Freedom in software is about about enabling > | people to "scratch their itch", to modify the software to suite their > | need and what they consider best for them. > Yes, and to continue that thread: The way we do that is to distribute > the source of our work. The most useful definition of source I've come > across is the GPL's: The preferred form for modification. > Given I maintain my packages in git, it's quite clear that the preferred > form for modification of my packages is through git and not debian > source packages. That we don't have a good way of distributing the > source of packages is a fault I think we should address. I am sympathetic to the problems caused by the interactions between quilt and VCS-hosted packages, but I object strongly to this attempt to cast git repositories as "the preferred form for modification" of a work. Under the GPL, this is tantamount to claiming that it's *illegal* to distribute a tarball of the work without the git history! git is a container, not a "preferred form for modification". It's a container with some nice added features, like access to the full history, but the history of the work is not part of "the work". This is evident from a simple question: is access to this history a benefit because it allows you to modify the history? When submitting changes upstream or planning to maintain the code in the long-term, access to the VCS is invaluable. But neither of those things is equivalent to modification of a work, and modifying the work does not require access to a VCS. I'm pretty sure anyone who can modify the code in a git repository can also modify it without a git repository. > I don't put much weight on the «it should be simple to hack on packages > and VCSes make it hard» argument. IME, there are many more people who > know how to drive git than there are people who know how to usefully > hack on Debian packages. There are more people who know how to drive svn than there are people who know how to drive git. Let's make svn repositories the preferred source format. :-P -- 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 -- 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/20110924200452.gb3...@virgil.dodds.net
Re: Format 3.0 (git)
]] "Bernhard R. Link" | * Tollef Fog Heen [110924 16:16]: | > I find reviewing what's changed between two arbitrary versions in git | > much easier than doing the same with debian source packages, so I think | > it's pretty clear this is a matter of preference. | | But if it is some other version control system, which is easier then? In my experience and with my knowledge, I find git the easiest. It's much easier than CVS, SVN and baz/tla. bzr is about as hard, but since I use git more frequently I find it easier to use. For you or some other contributor I expect the list to look different. | > Yes, and to continue that thread: The way we do that is to distribute | > the source of our work. The most useful definition of source I've come | > across is the GPL's: The preferred form for modification. | > | > Given I maintain my packages in git, it's quite clear that the preferred | > form for modification of my packages is through git and not debian | > source packages. That we don't have a good way of distributing the | > source of packages is a fault I think we should address. | | "Preferred form" explicitly does not say which one's preferred form. That is correct. | I might prefer some code with German comments stating those details | that are significant to me, and not some English comments also | describing things that are clear to me because I use such constructs | all of the time. If you consider German comments preferable over English comments, you should distribute the version with German comments. If there is no version with German comments it can't be the preferred form. The preferred form has to actually exist. | I also do not prefer at all to work on something without my default | editor settings, still I do not consider them part of the source. I don't see how this is relevant any more than whether you prefer to hack while sitting in a chair or lying on a sofa. That preference does not make said char or sofa part of the source. Maybe I'm completely misunderstanding your point above, but your two previous paragraphs look a lot like strawmen to me. If they aren't, please feel free to explain what you mean. | > I don't put much weight on the «it should be simple to hack on packages | > and VCSes make it hard» argument. | | Usefully hacking on Debian packages is only a part of my complaint, | and I am sad that it is reduced to that. | | First of all it is not only about only even Debian users, giving | back is about the whole software community. It's much easier for me to give patches back upstream when I can give them patches that apply directly to their development tree, rather than having to guess at what kind of metadata their system wants. (git format-patch and git send-email springs to mind.) So if you want to make it easier to contribute patches back, we should all be using the same VCS as upstream where at all feasible. [...] | > git used to be hard to use back in the olden days, but it isn't | > particularly hard nowadays. | | Learning git is not that hard anymore, I guess (, though I am not | really able to assess that from having looked at it for a long | time). But trying to use to access some stuff must still be quite | hard: it has some model of things and some private nomenclature | (think: index, tree, commitish) that will not make it that easy | to come from zero to be able to locate some commit and do the | right diff in some not too long time, even if knowing some other | VCSes. Of course it has nomenclature, just like Debian packages has: build-depends, depends, suggests, recommends, maintainers, uploaders, standards-versions, rules files with targets, patches that are magically applied and unapplied at various times. Building packages is complex business and we are not working towards making it simpler. I don't think 3.0 (git) would make much of a difference either way there, tbh. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87zkhtr9f8@qurzaw.varnish-software.com
Re: Bits from dpkg developers - dpkg 1.16.1
berta...@ptitcanardnoir.org wrote: > On Fri, Sep 23, 2011 at 11:53:36AM +0200, Marco d'Itri wrote: > > On Sep 23, Raphael Hertzog wrote: > > > > > Two hardening features are not enabled by default: PIE and bindnow. > > Why? > > I guess because they have more impact on performance than the others. Hi, I think it would be better to enable all security-enhancing flags by default (at least all of the included ones so far, which are fairly well-tested). Yes, these two do have a larger potential to reduce performance, but its also sufficiently straightforward to add -pie,-bindnow to disable them. Thus, maintainers that do find performance issues after adding the flags, can easily solve the problem they've created. As it stands now being a non-default setting, most packages will end up not getting these protections, which I think is less desirable than having most fully protected and only a small subset with reduced protections. Best wishes, Mike -- 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/20110924171133.68c6c6af9e5cb45dc9fca...@gmail.com
Bug#642703: general: Scan lines appear in drop-down menus. LibreOffice also shows artifacts when starting. Might be something to do with the version of fglrx.
Hi there. Do you have swap space enabled? How much memory do you have? I get this problem, including font corruption (one or two characters per font), whenever I run something that causes the system to start using swap space. For me, it seems to happen most to Gnome apps, including Google Chrome. Did you notice excessive hard disk activity when you started the program, I mean, apart from the activity involved in loading the program. Check: try closing other programs first, starting LibreOffice, and see if there's any difference. Regards, Philip -- 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/4e7e6933.3070...@philipashmore.com
Re: Bits from dpkg developers - dpkg 1.16.1
On Sun, Sep 25, 2011 at 5:11 AM, Michael Gilbert wrote: > I think it would be better to enable all security-enhancing flags by > default (at least all of the included ones so far, which are fairly > well-tested). Yes, these two do have a larger potential to reduce > performance, but its also sufficiently straightforward to add > -pie,-bindnow to disable them. Thus, maintainers that do find > performance issues after adding the flags, can easily solve the problem > they've created. IIRC the Debian GCC maintainer did not want to enable these security-enhancing flags. The only way to get these flags enabled by default would be to talk with GCC upstream and hope that the Debian GCC maintainer does not disable them. > As it stands now being a non-default setting, most packages will end up > not getting these protections, which I think is less desirable than > having most fully protected and only a small subset with reduced > protections. Agreed. -- 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/CAKTje6GN=TFTdNTWwADWhMwFGzwq_pZSYV+=m-jgbzlfb1t...@mail.gmail.com
Re: Bits from dpkg developers - dpkg 1.16.1
Ian Jackson wrote: > I'm one of the submitters of one of the bugs which requested this > change. This is a reversion of dpkg to a previous behaviour, and it > /un/breaks packages. Or at least I think it unbreaks much more than > it breaks. > > It was always completely wrong of dpkg-buildpackage to set these > variables. Source packages are entitled to assume that strange > environment variables which cause their tools to do odd things will > not be set. I'm willing to not worry about the likelihood that many packages added or updated over the past few years, while dpkg-buildpackage was forcing build flags, will not be built properly optimised now. That seems unlikely to completely break many of them, and as you say, forced build flags were always wrong, and we may just have to suck it up and deal with the breakage to get back to sanity. My concern is that we now have a whole history of ill-considered changes to the build flags. To the point that it's possible to argue that every build flag change save one* has been ill-considered. So why are we continuing to add interfaces where the build flags are changed centrally/globally, with the same processes that have not worked before? The build flags interface either needs some sort of compatability versioning, or the default build flags need to be specified in policy, and only changed with the same care we take with other policy changes that can make massive numbers of packages instabuggy. -- see shy jo * As the exception that proves the rule, there was a proper cost/benefit analysis of adding -Werror=format-security, concluding that the 5% or so of packages that it breaks are likely to have security holes that it will aid in fixing. signature.asc Description: Digital signature
Re: Format 3.0 (git)
Bernhard R. Link wrote: > - Debian is about freedom. > - Debian is about giving back. Well! It's very interesting to have work that I have done, in the vain hope of somehow finding another way to make Debian better, elicit push-back like this. I suppose this will influence me some way or other, can't say how right now. -- see shy jo signature.asc Description: Digital signature
Re: Format 3.0 (git) (was: Re: single-debian-patch (was Re: Bits from dpkg developers - dpkg 1.16.1))
On Sat, Sep 24, 2011 at 2:30 PM, Charles Plessy wrote: > If in a large number of cases where one would like to turn off the patch > system > of the 3.0 (quilt) format, the source package is stored in a Git repository, > then one way to move forward would be to make the format 3.0 (git) available > in Debian. What are the blocking points ? The main blocking point is that ftpmasters will not allow it into the archive. The folks on debian-devel are not the ones you need to convince about the format, this mail should have been directed to the ftpmasters instead. -- 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/CAKTje6F-GetEFnOyD9kxB=ypoj70q8t2-qqh6gtjpadic0k...@mail.gmail.com
Re: Format 3.0 (git) (was: Re: single-debian-patch (was Re: Bits from dpkg developers - dpkg 1.16.1))
On Sat, 24 Sep 2011, Charles Plessy wrote: > If in a large number of cases where one would like to turn off the patch > system > of the 3.0 (quilt) format, the source package is stored in a Git repository, > then one way to move forward would be to make the format 3.0 (git) available > in Debian. What are the blocking points ? AFAIK, the _real_ problem is that the ftpmasters do not consiter it acceptable to packages to ship their entire history, and that's a fatal problem that has no simple solution. Shipping the whole history means you have to check the entire history for DFSG compliance. There's also the nasty detail that you have to destroy history past any point where an undistributable blob exists to make the whole thing distributable. Another problem is that you either face an unbounded increase in size over time, or you have to ship git shallow clones, which are not self-contained and very nasty to work with. I don't think we will have 3.0 (git) in Debian anytime soon, if ever. Corrections by any of the ftpmasters if I got any of this wrong, are very welcome. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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/20110925024542.ga32...@khazad-dum.debian.net
Re: Format 3.0 (git)
]] Steve Langasek | > Given I maintain my packages in git, it's quite clear that the preferred | > form for modification of my packages is through git and not debian | > source packages. That we don't have a good way of distributing the | > source of packages is a fault I think we should address. | | I am sympathetic to the problems caused by the interactions between quilt | and VCS-hosted packages, but I object strongly to this attempt to cast git | repositories as "the preferred form for modification" of a work. Under the | GPL, this is tantamount to claiming that it's *illegal* to distribute a | tarball of the work without the git history! Yes, I think it might well be. | git is a container, not a "preferred form for modification". It's a | container with some nice added features, like access to the full history, | but the history of the work is not part of "the work". This is evident from | a simple question: is access to this history a benefit because it allows | you to modify the history? No, it's primarily because it gives me richer metadata for the current state of the project, using git blame, git log and so on. Having access to the history is similar to having sensible file names rather than naming all the files in a project a.c, b.c, c.c, d.c and so on. Having useless names does make hacking on the source harder, but it does not prevent it completely. There are other obfuscation techniques one could apply as well, and at some point, the source would be so obfuscated or lacking so much metadata we would no longer consider it the source. The main point here might not be the git repository but «the files including their history» and a fast-export of the repository would be as acceptable as the git repository itself. | When submitting changes upstream or planning to maintain the code in the | long-term, access to the VCS is invaluable. But neither of those things is | equivalent to modification of a work, and modifying the work does not | require access to a VCS. I'm pretty sure anyone who can modify the code in | a git repository can also modify it without a git repository. Can? Yes, I suppose so. That does not make it the preferred way, though. | > I don't put much weight on the «it should be simple to hack on packages | > and VCSes make it hard» argument. IME, there are many more people who | > know how to drive git than there are people who know how to usefully | > hack on Debian packages. | | There are more people who know how to drive svn than there are people who | know how to drive git. Let's make svn repositories the preferred source | format. :-P That is a strawman if I ever saw one. :-) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87sjnlqk0m@qurzaw.varnish-software.com
Bug#642801: ftp.debian.org: Please support dpkg-source format 3.0 (git) in our archive.
Package: ftp.debian.org Severity: wishlist Dear FTP team, There are now 4,921 source packages maintained in Git repositories (http://upsilon.cc/~zack/stuff/vcs-usage/), and for some of them the dpkg-source format 3.0 (git), for which support is available in Squeeze, would be natural and convenient (not to mention innovative). According to Russ Allbery's notes from the notes from the DebConf 2010 source format BoF (http://lists.debian.org/87wrrxhlr7@windlord.stanford.edu), there are worries that the Git history may contain non-free or unredistributable files. I propose to discuss this in this bug report what would be the steps or the policy to implement in order to have the format 3.0 (git) acceptable for our archive. For instance, we could decide that new packages enter Debian without history, and limit the depth of the history to one or two release cycles. We could also decide to trust fully the packages native to Debian or developped by Debian developers. There are more suggestions in the notes that Russ has taken (see above), as well as other concerns not related to the redistribution of files from the Git history. What is the current position of the FTP team ? Have a nice Sunday, -- Charles -- 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/20110925061400.3448.4192.reportbug@aqwa.igloo
