Packaging icons in a DEB
Hello everyone, I'm trying to create a deb file that will install icons in the menu. I've created .desktop files and placed them under /usr/share/applications. These icons do appear, but under KDE, they appear under the "Lost and found" category. I have not been able to find a guide on how to control which category they should appear under. Ideally, they should appear under a new category (more accurately, a sub-category) I create. If anyone can direct me to a guide, that would be very helpful. Thank you, Shachar
Library interface version question
Hi all, I am maintaining a package (libargtable2, not that it matters). This library had a recent backwards compatible interface version upgrade. The previous version was 0, and the new version is 1, backwards compatible to 0. It got the version number of "1:1:1" in libtool terms, which translated to "libargtable2.so.0.1.1" in file name. There are a couple of problems. First, if I understand correctly, programs linked against this new library (which should still be called "libargtable2-0") should have a specific ">=" version in their dependencies. This does not currently happen. I realize I must be doing something wrong in the debianization of the library, but I'm not sure what it is. The second is that, again, if I understand correctly, a link should have been created from libargtable2.so.0.1 to libargtable2.so.0.1.1. This did not happen. Is this wrong? Thanks, Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library interface version question
Henning Makholm wrote: >Scripsit Shachar Shemesh <[EMAIL PROTECTED]> > > > >>First, if I understand correctly, programs linked against this new >>library (which should still be called "libargtable2-0") should have a >>specific ">=" version in their dependencies. This does not currently >>happen. >> >> > >You are supposed to write an appropriate shlibs file, as described in >policy §8.6. Have you done so? > > My file is currently automatically generated by dh_shlibdeps, and says "libargtable2 0 libargtable2-0". I realize that I should place any version restrictions there, if I want them. The question is whether I should just state the version at which the interface advance there, or whether I should do some other version tricks? >Why? This does not happen with the libraries with three-part version >numbers that I have on my system. > > In a nutshell - because then the information regarding which backwards compatible interface to use is lost. I guess it's ok IF it is not possible for a given interface version to be backwards compatible in some versions but not in others. Thanks, Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
I am not a lawyer. I am a consultant trying to understand the world he lives in, and as such, studied the applicable law a little. Eric Dorland wrote: So, I don't feel I can accept the agreement offered by the Mozilla Foundation, because of my objections to it and because I don't feel empowered to make an agreement like this on behalf of Debian. If however, the DPL wished to step forward and broker such a deal I would not oppose (he is our elected representative for the project after all). If the DPL does not step forward to make some sort of agreement, what will I do? Renaming seems to be a very unpopular option. So I believe my best option is to ignore the trademark policy altogether and have the Mozilla Foundation tell us when they want us to stop using their marks. It should just be noted that such a move does have consequences as well. This is not a no-op move. The no-op move would have been to rename the package. Now I originally said we shouldn't do this, but it does have certain advantages. First of all, I think we can ignore the trademark policy because it is only a policy, is not distributed with the software (although having said that, that might change) and it is my understanding that in most jurisdictions the trademark holder has to police use of their trademark anyway. Quite like the GPL, it boils down to whether we are required, by law, to have the MoFo's approval. If we are, then the policy holds true for us. If we are not, then not signing an agreement with them is a sane move. Now the advantage of doing this is foremost to not have to rename Firefox unless the MoFo ask us to. There is also protects us from looking like the bad guy in the case of a rename (eg the /. headline will read "MoFo tells Debian not to use 'Firefox'" rather than "Free software nuts stop using 'Firefox'"). What it does not protect us from, however, is a lawsuit. I'm not saying MoFo would sue, but if they would, it would put the Debian project under complete legal liability. Normally, one can claim "innocent infringement", which means you are not liable for the infringement done prior to becoming aware of the problem. As a side note, this holds true for patents as well. In this case, however, we cannot claim that we did not know, as this has been discussed on a public forum. Of course the other advantage is not having to make an agreement that I think compromises our principles. Of course the disadvantage would be that by ignoring the issue we're implicitly agreeing to the MoFo's proposal. No, it's quite worse. By ignoring the issue, we are forcing MoFo to either sue us or lose the trademark. That's the way trademark law works. Just like we can no longer claim we didn't know these things were trademarked, they will not be able to claim they didn't know Debian was using their trademarks without an agreement. This means that if they don't do something legal to us now, they will never be able to do anything regarding their trademark to anyone else ever. In effect, not signing the agreement and keeping the name means that we are forcing them to sue or lose. I'm afraid the only way of not taking an active stance on the issue of whether free software should have registered trademarks is to rename our version of Firefox. If we do not sign and not rename, we are taking an anti-trademark stance by forcing MoFo to take legal action against us (which will hurt them dearly as well), or to drop the Trademark idea. If we do sign the contract we're implicitly saying that we think that the MoFo course of action is the right way to go. To put another way, once MoFo decided to issue a trademark, they have no choice BUT to ask Debian to sign such an agreement. Debian is too widely used for MoFo to claim they didn't know that we are infringing (and if they can't claim that, trademark law says they cannot enforce their trademark against anyone else), and they likely don't WANT us to stop using the name "Firefox". Both because they likely really do want the software to be free, and because that weakens the trademark, not strengthens it. Two important notes: 1. The above is my understanding of trademark law, and does not include my opinion as for what we SHOULD do. Not being a Debian Developer (yet), I don't think my opinion on the matter matter that much. In any case, this is more down to personal beliefs than actual reasoned discussion. 2. I am not a lawyer, so the above may be a distorted view of the real state of affairs. The correct thing to do with anything I write on the matter is to take it to a real lawyer, and ask his/her opinion about it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Ongoing Firefox (and Thunderbird) Trademark problems
John Hasler wrote:
This means that if they don't do something legal to us now, they will
never be able to do anything regarding their trademark to anyone else
ever.
You assume that our usage is infringing. I don't think that is
established.
If our usage is non-infringing, then no contract is necessary.
In other words, I'm only assuming they assume our usage is infringing.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A new debhelper program required?
Hi all,
I came across the following need, and was wondering what the best way to
solve it would be. I'm packaging a Thunderbird extension that is 100%
javascript. I.e. - it's an "Architecture: All" package. Thunderbird
expects that all files from such a package that would normally go into
/usr/lib to go into /usr/share/lib. So far, so good.
The problem is that Thunderbird really expects to see its extensions at
/usr/lib/thunderbird/extensions/{guid}. I'm having the not very uncommon
problem of having to have a file in one place due to Debian policy, and
another due to program's requirement.
For the case of a configuration file inside the package, this was solved
simply by moving the file, as part of the build process, to /etc, and
using dh_link to create a symlink from the old to the new location. For
the {guid} directory, dh_link refuses to create a link to a directory,
and I ended up manually creating the symbolic link from
/usr/lib/thunderbird/extensions/{guid} to
/usr/share/lib/thunderbird/extensions/{guid}. It works, and is linda and
lintian clean.
I'm wondering about two things:
1. Should I have solved the problem differently? Perhaps creating a dual
directory structure and symlinking individual files (seems insane to me)?
2. How open are we to the idea of adding a debhelper called, oh, say,
dh_relocate, that does both the move and the symlink creation? It should
also allow moving directories, as all redirections I know are using them.
Ideas, anyone?
Shachar
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A new debhelper program required?
Hendrik Sattler wrote: > How about patching thunderbird to look at both directories? > > HS > I can, somehow, grok maintaining a thunderbird extension, but delving into the actual thunderbird code is way over my available time at the moment. :-( Yes, I know, I can open a bug and dump this on the poor thunderbird maintainer (hi Alexander). It seems incorrect to wait until that bug is resolved before this extension is uploaded, however. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397295: ITP: bitefusion -- Simple 15 level snake game
Package: wnpp Severity: wishlist Owner: Shachar Shemesh <[EMAIL PROTECTED]> * Package name: bitefusion Version : 1.0.1 Upstream Author : J¸rgen Jacobsen <[EMAIL PROTECTED]> and Morten Hustveit <[EMAIL PROTECTED]> * URL : http://www.junoplay.com/ * License : GPL Programming Lang: C Description : Simple 15 level snake game A snake game with 15 levels. Great if you need to shut off your brain for a few minutes and occupy your hands in the meantime. Guaranteed no adrenaline rush! -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Re: fresh blood gets congested: long way to become DD
Yaroslav Halchenko wrote: Indeed to do THE WORK it is not necessary to be a DD. It is just that for upload of packages into debian non-DD needs to interact with a sponsor. Also administrativa like voting can't be done by non-DD. Besides that I don't see any difficulties as to do packaging and to interact_with/influence the debian community This is free software. Personally, my kicks come from knowing people use what I've done. The long delays involved with sponsored uploads, and even more when new packages are involved, are hurting the fun, and ultimately, the incentive to contribute. Don't get me wrong. I am not in the least bit resentful to my sponsor when things get slow. I realize full well he is also busy, and has other things to do. Isn't that just the point, though? I wish to become a DD, not because I don't think I can get my packages into Debian otherwise, but because I want to help the project. It seems that the lack of time everybody has is a self aggravating problem. No time -> Longer time to approve new DDs -> People have no time. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: possible ICU transition
Steinar H. Gunderson wrote: On Fri, Aug 05, 2005 at 09:04:34PM +0200, Andreas Fester wrote: being involved in an i18n project currently, I also learned about ICU recently. I was a littlebit disappointed to find only a very old version in the Debian archive, so its very good to see that the package is still maintained and that you are working on the current 3.4 version :-) While we're at all the i18n (is there a more proper list for this, BTW?) business: Is there a good way for a given locale of getting ordinal numbers? Ie. func(1) = “1st”, func(2) = “2nd”, func(3) = “3rd” etc. for LANG=en_US, func(1) = “1ère”, func(2) = “2ème”, func(3) = “3ème” etc. for LANG=fr_FR and so on... /* Steinar */ Actually, ICU can do that. Search for the word "ordinal" at http://icu.sourceforge.net/apiref/icu4c/classRuleBasedNumberFormat.html for a lead. I would recommend against, however, for two reasons: 1. ICU's link requirements are horrible. If you link with a particular version of ICU, the version number gets mangled into the function name, so that replacing the shared object at a later point is just a big no-no. In addition to that, if your project is not C++, you are creating a dependency on the C++ runtime library, which is often a problem. I introduced ICU dependency into Wine to put in BiDi support, and the code is rotting away there, because it is basically unmaintainable. 2. The actual concept is flawed. ICU is trying to give the impression that you can just type in a number and get it translated into textual representation without knowing in advance anything about the language (http://www-950.ibm.com/software/globalization/icu/demo/locales). The problem is that the people doing the designing are usually western people. This means that it works great for Latin based languages, but the further away you travel, the less well it works. Example: In English: 1st (or "first"). In French, 1ère. In Hebrew? Well, it depends. If you are counting male object (and in Hebrew, nouns have a gender), that would be "ראשון", otherwise it would be "ראשונה". The description is dependent on the noun. About a year ago, ICU simply did not have an answer to that problem. I just looked again to find out the answer for your original question, and they do appear to have a muscular vs. feminine forms. Give them 10/10 for effort. I fail to see how that can solve the problem, though. Even if you were somehow made aware that some languages have this distinction (a great advancement already), you have no clue what the object's gender should be. Please bear in mind that Hebrew is not the only language to have gendered nouns. Also bear in mind that while "Table" is male in Hebrew, it may well be female in another language. In short, please think carefully before using an automatic solution for generating your numbers. Things may not be as simple as you think. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#325289: ITP: debian-hebrew -- Hebrew support in the Debian desktop
Lior Kaplan wrote: > This meta package will install Hebrew desktop related Debian > packages for use by Hebrew debian users. > . > It also includes a script 'hebrew-settings' to reconfigure > the system to have a fully Hebrew-ized desktop. > . > Homepage: http://debian-hebrew.alioth.debian.org/ > > What do you intend to do regarding "msttcorefonts", which are pretty much a requirement? Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333055: ITP: xparam -- a general-purpose librariy for parameter handling in C++
Package: wnpp Severity: wishlist Owner: Shachar Shemesh <[EMAIL PROTECTED]> * Package name: xparam Version : 1.22 Upstream Author : Ronnie Maor and Michael Brand <[EMAIL PROTECTED]> * URL : http://xparam.sourceforge.net/ * License : Revised GPL, LGPL compatibile Description : a general-purpose librariy for parameter handling in C++ XParam is an extensible, type-safe, non-intrusive, object-oriented tool for general-purpose object serialization and deserialization in C++, good for parsing command-line parameters and cross-program/cross-platform communication. It can handle named parameters as well as object streams. It recognizes class hierarchies, abstract interfaces, and polymorphism, and can therefore serve as a plug-in management framework -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SONAME in C++ libraries
Hi all, I'm working on packaging xparam (http://xparam.sf.net). It's a C++ library for object serialization. The problem is that upstream does not belive in SONAME versioning for C++ libraries. He claims that he has no choice but to break interface with each and every release. As a result, he is giving all libraries a "1.0.0" version. I'm thinking of changing that to "0.0.0", so that the nature of the incompatibility is clear. The question is whether such a change from upstream is considered legitimate? Thanks, Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SONAME in C++ libraries
Andreas Fester wrote: >If upstream is unwilling to change the SONAME each time the binary >compatibility breaks, then IMHO the only choice is that you do it >yourself for the Debian package. Otherwise trouble begins when other >packages within the Debian archive start linking against your library. >See also http://www.trolltech.com/developer/faqs/index.html?catid=&id=362 >for what breaks binary compatibility of C++ libraries. > >Best Regards, > > Andreas > > That doesn't make sense. If I start inventing my own SO versions, I'll be in trouble should upstream change their mind some time in the future. What I thought was to use "0" as SO version, which is a standard way to state that the interface is not guarenteed to remain stable. I'll also add a comment to readme.Debian to the effect that, when linking against the library, you should include the precise version number in the dependencies. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Lintian over sensitivity?
Hi all, I'm packaging a new version of fakeroot-ng, and I get the following warning from Lintian -iI: W: fakeroot-ng: copyright-without-copyright-notice N: N: The copyright file for this package does not appear to contain a N: copyright notice. You should copy the copyright notice from the N: upstream source (or add one of your own for a native package). A N: copyright notice must consist of Copyright, Copr., or the Unicode N: symbol of C in a circle followed by the years and the copyright N: holder. N: N: If the package is in the public domain rather than copyrighted, be N: sure to mention "public domain" in the copyright file. Please be aware N: that this is very rare and not the same as a DFSG-free license. True N: public domain software is generally limited to such special cases as a N: work product of a United States government agency. N: N: Refer to http://ftp-master.debian.org/REJECT-FAQ.html for details. N: This is the copyright file: his package was debianized by Shachar Shemesh <[EMAIL PROTECTED]> on Tue, 08 Jan 2008 20:27:55 +. It was downloaded from http://sourceforge.net/projects/fakerootng Fakeroot-ng is copyrighted (C) 2007-2008 by Shachar Shemesh Further copyright and credits can be found at /usr/share/doc/fakeroot-ng/AUTHORS License: This package is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This package is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this package; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA On Debian systems, the complete text of the GNU General Public License can be found in `/usr/share/common-licenses/GPL'. The Debian packaging is (C) 2008, Shachar Shemesh <[EMAIL PROTECTED]> and is licensed under the GPL, see above. At least superficially, the copyright file lives up to all of the requirements that lintian asks for. Lintian version 1.23.45 Changing the line to read: Copyright (C) 2007-2008 by Shachar Shemesh pacifies lintian, but I still think this is over sensitivity on its behalf. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFH: porting fakeroot-ng to more platforms
Fakeroot-ng is a clean reimplementation of fakeroot, using a totally different technology. Fakeroot-ng uses the ptrace interface to track the syscalls performed by the fooled program. This means fakeroot-ng is immune to problems that may happen as a result of races, cross-library interactions, different versions of glibc and statically compiled executables. As a result, tracking "difficult" syscalls, such as open(2), is possible. For example, as of version 0.12 (the latest version), fakeroot-ng has complete support for chroot, symlink resolving included. Obviously, there is a down side. Due to the low level interaction with the kernel, fakeroot-ng has to be specifically ported to each new platform. This porting is a non-trivial process, involving parsing of the register arguments as they are being passed to the kernel. It is a more complicated process than merely extracting the sources on a new platform and running "make". That said, the porting is not an extremely complicated process either. There is a README.porting file that explains most of the tasks required. Every attempt has been made to place all platform dependent code into a separate library, and many of that library's functions apply to all Linux platforms and need not be rewritten. I have personally ported fakeroot-ng to x86, amd64 and PowerPC, with the later two being platforms that I have access to, but have never learned before the porting effort. The PowerPC port took me about three hours, and the AMD64 port took not much longer. I would like to receive help in either one of two ways. Either someone with platform access and the know how can do the porting, or someone can provide me with access to a development machine running one of the other platforms, and I can perform the porting there. I have tried to shell machines Debian currently has, and they proved insufficient. Either they were far too slow for repeated compilations (or any interactive work, for that matter), or they lack some of the tools needed (objdump, compilation tools, etc.) Any help would be greatly appreciated. Thanks, Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Considerations for lilo removal
William Pitcock wrote: It seems like moving to grub for everything may be a good choice on the archs where lilo is used. Lilo has one killer feature that is totally missing from GRUB - the -R option. It allows me to upgrade a kernel on remote servers, knowing that if the upgrade fails, I will get the original kernel after a few minutes without asking a local hand to push the reset button. Until Grub has something similar, removing Lilo entirely seems like a bad idea to me. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
Package: wnpp Severity: wishlist Owner: Shachar Shemesh <[EMAIL PROTECTED]> * Package name: privbind Version : 0.2 Upstream Author : Shachar Shemesh <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/privbind * License : GPL Programming Lang: C Description : Allow unprivileged apps to bind to a privileged port This program allows running another program as a non-root user, except the other program will be able to bind to privileged (<1024) ports. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US, LC_CTYPE=he_IL (charmap=ISO-8859-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
Russell Coker wrote: > On Tuesday 05 June 2007 16:52, Shachar Shemesh <[EMAIL PROTECTED]> wrote: > >> Package: wnpp >> Severity: wishlist >> Owner: Shachar Shemesh <[EMAIL PROTECTED]> >> > > What benefits does this offer over authbind which has been in Debian for ages? > > It uses a (I think) much more secure mode of operation. In particular: - No SUID executables - User who launches the daemon must be root - Privileges go down, never up And, as a result: - No global configuration necessary (though one will probably be added later if necessary). Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#427605: ITP: privbind -- Allow unprivileged apps to bind to a privileged port
Russell Coker wrote: > On Wednesday 06 June 2007 20:05, Shachar Shemesh <[EMAIL PROTECTED]> wrote: > >>> What benefits does this offer over authbind which has been in Debian for >>> ages? >>> Before I begin answering your questions, the bug report has a link to technical explanation of how privbind is implemented. Have you read it? >> It uses a (I think) much more secure mode of operation. In particular: >> - No SUID executables >> - User who launches the daemon must be root >> > > Having a daemon instead of a SUID executable does not inherently make it more > secure (there has been no shortage of exploits for bugs in daemons in the > past). > s/daemon/program that needs low port binding/ privbind does not allow regular users to bind to low ports. Privbind allows root to run program that bind to low port as non-root. > The usual system is that a process with UID != 0 can not bind to ports below > 1024. Breaking this involves increasing the privileges of some programs. > Please read the privbind man page. It does not do what you think it does. > >> And, as a result: >> - No global configuration necessary (though one will probably be added >> later if necessary). >> > > How can there be no global configuration needed? Please read the privbind man page. It does not do what you think it does. > The sysadmin needs to decide > which users are granted the privilege to bind to low ports and which ports > those users may bind to. > Please read the privbind man page. It does not do what you think it does. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FTBS twice - what is the priority for it?
Hi all, I am preparing an upload to Sid, with the intent of getting it into Lenny, for a package of mine (to solve bug #493061 for fakeroot-ng, if it matters). While working on it, I found out that the package also has a FTBS twice bug, which resulted from empty lines (with no leading tab character) in debian/rules in the clean target. My question is - what to do? Do I open a FTBS twice bug for the package and upload the fix? If so, what priority should the new bug be? I saw FTBS bugs ranging from "wishlist" to "important". I don't think it is an actual policy violation (am I wrong? Can someone point me to the relevant section?) Alternatively, as the delta has only white spaces between fixing the tabs and not fixing it, I can just put the fix in and hope the release managers (hi!) don't catch me when I ask them to allow the fix for 493061 through. Then again, if the bug is not important enough, I can upload a fix that only handles 493061, and doesn't touch the double FTBS bug at all. What should I do? Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-security updates between stable releases?
Tim Hull wrote: > > > I knew about that, though it's not actually an official Debian > repository (to my knowledge). If I were looking for a date that was tall yes compact, what would you tell me? How about a date with fair brown eyes? What you are asking for is a contradiction. There are only two ways to update "stable" once it's out: Issue another "stable" or lie about its stability. There are specific exceptions to this rule. In particular, not updating certain programs is, in itself, a problem. One such example is an anti-virus, which needs fresh definitions, and sometimes, fresh code as well. If that is where your interests lie, I suggest you have a look at the "debian-volatile" repository. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to start porting to a new ARCHITECTURE?
David Given wrote: > You've got two major tasks ahead of you: > > - - port gcc > > - - port the kernel > > - - cross-compile a basic userland > Nobody expects the Spanish inquisition. Actually, there is one more major headache, which is porting a boot loader. Probably uBoot or something similar. Memory needs to be set up so it can be accessed by the kernel, the kernel (and initrd) pulled from the flash, and flow passed into it. If the system uses hardware controllers that exist elsewhere, the kernel port may be easier than that. It may be that the system has an ethernet controller that is already supported under Linux. Of course, the startup code and everything else under the "arch" directory will still need to be handled, but at least as far as the drivers are concerned, some work may be saved. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
David Anderson wrote: > Therefore, question: how should I get from this situation to having a > working .deb (including the cross-compiled driver), while at the same > time playing nicely with Debian packaging policies? > In the general case, the problem is much wider. Let me give you an example. We currently package Xen and other free virtualization solutions. Some of them can even run proprietary OSes, such as Windows. Now, suppose that one would like to improve the way Windows runs under Xen by writing, say, a custom mouse driver for Windows that para-virtualizes the mouse on Windows. Such things are quite common in todays' world. The problem is that this driver is a kernel level driver for Windows. If it were user space we could still claim it could be compiled with cross-mingw, but this is not the case here. Setting up an environment for compiling Windows kernel drivers merely so we can build this tiny blob seems out of proportion. I think we need a change in policy for handling cases where free software requires free software in order to compile which is, non the less, non buildable on the same platform. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reordering the boot for fun and profit
Petter Reinholdtsen wrote: And of course, it also make it possible to dynamically order the scripts based on their dependencies. When you said "and of course", I thought you were going to say "allow scripts that have no inter-dependency to start in parallel". Having a concurrency level of at least 2 should speed the start up considerably, especially when packages are taking long to start mostly because they do a sleep in wait for some hardware to settle. Coming to think of it, maybe concurrency level of 2 is a little low. Shachar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFH - fakeroot-ng and ptrace, not Debian specific
Hi all, I'm sending this request for help in the hope that it randomly hit one of the smart people on this list, but it is, as far as I can tell, not Debian specific. Fakeroot-ng is a clean re-implementation of the fakeroot principle, based on ptrace rather than LD_PRELOAD. As a result it can go where fakeroot cannot (no problem with statically compiled binaries, can do almost full chroot with full chroot planned) on the one hand, but has some drawbacks as well (no hope of being as quick as fakeroot, has some highly platform specific code, fairly complex). You can read more about it at http://fakeroot-ng.lingnu.com The version currently in trunk has an attempt to remove some Linux specific hacks when attaching to a newly created process. It does so by changing a "fork" into "clone", and adding the "CLONE_PTRACE" whether the original specified it or not. This is the exact same thing strace does. Unlike strace, however, fakeroot-ng is failing to attach itself to newly created threads. I'd say I was passing the wrong flags to the kernel, but if I watch all system calls performed by the debugger (yes, using strace), I seem to see that strace and fakeroot-ng do exactly the same thing. The only difference is that for strace it works. I need someone who is either a ptrace expert, or who has a fresh set of eyes and some patience, to help me look at it and figure out what I'm doing wrong. Thanks, Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d09c41b.70...@debian.org
Re: Safe File Update (atomic)
On 30/12/10 13:46, Henrique de Moraes Holschuh wrote: Is there a code snippet or lib function that handles this properly? I don't know. I'd be interested in the answer, though :-) I'm working on one under the MIT license. Will probably release it by the end of this week. Will also handle copying the permissions over and following symlinks. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d1c9d3b.6060...@debian.org
Re: Safe File Update (atomic)
On 30/12/10 17:02, Olaf van der Spek wrote: On Thu, Dec 30, 2010 at 3:51 PM, Shachar Shemesh wrote: I'm working on one under the MIT license. Will probably release it by the end of this week. Will also handle copying the permissions over and following symlinks. Sounds great! Got a project page already? No. I was doing it as code to accompany an article on my company's site about how it should be done. I was originally out to write the article, and then decided to add code. A good thing, too, as recursively resolving symbolic links is not trivial. There is an extremely simple way to do it on Linux, but it will not work on all platforms (the *BSD platforms, including Mac, do not have /proc by default). What aboue file owner? Meta-data (ACL)? Olaf The current code (I'm still working on it, or I would have released it already, but it's about 80% done) does copy owner data over (but ignores failures), but does not handle ACLs. I decided to postpone this particular hot potato until I can get a chance to see how to do it (i.e. - never had a chance on Linux) AND how to do it in a cross-platform way (the code is designed to work on any Posix). Pointers/patches once released are, of course, welcome :-) Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d1ca143.9020...@debian.org
Re: Safe File Update (atomic)
On 30/12/10 13:46, Henrique de Moraes Holschuh wrote: Is there a code snippet or lib function that handles this properly? I don't know. I'd be interested in the answer, though :-) I'm working on one under the MIT license. Will probably release it by the end of this week. Will also handle copying the permissions over and following symlinks. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d1c9c74.2050...@shemesh.biz
Re: Safe File Update (atomic)
On 30/12/10 19:48, Henrique de Moraes Holschuh wrote: It doesn't. You need a "copy inode without the file data" filesystem interface to be able to do that in the first place. It might exist, but I never heard of it. If my (extremely leaky) memory serves me right, Windows has it. It's called "delete and then rename". It is not atomic (since when do Windows care about not breaking stuff), but it does exactly that. If you delete a file and quickly (yes, this feature is time based) rename a different file to the same name, the new file will receive all metadata information the old file had (including owner, permissions etc.) Just thought I'd share this little nugget to show you how much worse non-posix has it. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d1ccc38.6000...@debian.org
Re: Safe File Update (atomic)
On 30/12/10 17:17, Olaf van der Spek wrote: On Thu, Dec 30, 2010 at 4:12 PM, Shachar Shemesh wrote: No. I was doing it as code to accompany an article on my company's site about how it should be done. I was originally out to write the article, and then decided to add code. A good thing, too, as recursively resolving symbolic links is not trivial. There is an extremely simple way to do it on Linux, but it will not work on all platforms (the *BSD platforms, including Mac, do not have /proc by default). Depending on /proc is probably not reasonable. Are you sure it will be atomic? ;) open old file, get fd (we'll assume it's 5). Do readlink on /proc/self/fd/5, and get file's real path. Do everything in said path. It's atomic, in the sense that the determining point in time is the point in which you opened the old file. How do you preserve owner (as non-root)? I thought I answered that. Best effort. You perform the chown, but do not bother with the return code. If it succeeded, great. If not, well, you did your best. The reason I asked for a kernelland solution is because it's hard if not impossible to do properly in userland. But some kernel devs (Ted and others) don't agree. They reason that the desire to preserve all meta-data isn't reasonable by itself. I'm with Henrique on that one. I am more concerned with the amount of non-Posix code that needs to go into this than preserving all attributes. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d1ccd81.3010...@debian.org
Re: Safe File Update (atomic)
On 30/12/10 17:02, Olaf van der Spek wrote: Got a project page already? Watch this space. Actual code coming soon(tm). https://github.com/Shachar/safewrite Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d1d743b.8080...@shemesh.biz
Re: Safe File Update (atomic)
On 02/01/11 17:37, Olaf van der Spek wrote: A userspace lib is fine with me. In fact, I've been asking for it multiple times. Result: no response. Excuse me? You (well, Henrique, but you were CCed) said "how about a user space lib"? I said "I'm working on one, will be ready about this weekend". I even gave a URL to watch (https://github.com/Shachar/safewrite). If you check it out right now, you will find there a fully implemented and fairly debugged user space solution, even including a build tool and man page. BTW - feedback welcome. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d21a67b.50...@debian.org
Safe file update library ready (sort of)
Hi all, I've promised to get a library out there, and here it is. The base URL is https://github.com/Shachar/safewrite, and the actual code is at https://github.com/Shachar/safewrite/blob/master/safewrite.c This is not a formal release just yet (plus one function is still missing an implementation, trivial though it might be). It's just that the list obviously has a few people knowledgeable on the subject who can give my code a second look and see whether there is anything I have missed. I'll probably make an official release over the next couple of days. Feedback most appreciated. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d21a84c.4060...@debian.org
Re: Safe file update library ready (sort of)
On 03/01/11 14:10, Adam Borowski wrote: There's a race condition: while [ 1 ]; do ln -s /etc/passwd somefile.tmp; done "Hey root, could you please use this program using libsafewrite on 'somefile'?" Two questions: 1. Is this race a regression from the single file case? 2. Is this race avoidable? In essence, it is impossible, as far as I know (patches welcome) to avoid a race when symlinks are involved (with specific exceptions). The assumption is, and has always been, that the directory resides inside a location that is secure from attacks. In this particular case, for example, you don't need this race at all. Simply do "ln -s /etc/passwd somefile" and ask root to write to somefile, with or without safewrite. That would work equally well, and does not require to race with anything. You might be wondering, if that is the case, why I'm unlinking somefile.tmp before opening it with O_CREAT|O_TRUNC. The reason is that it might have permissions (say, from a previous run that failed - unlikely, but not impossible) that prevent proper functioning. It has nothing to do with permissions. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d21d59c.3010...@debian.org
Re: libsafewrite
On 03/01/11 14:54, Olaf van der Spek wrote: That's one of the more interesting parts. It sure is to you. I'm not sure about other users. I'll tell you what - I'll make the project's home page a wiki, and you can document these to your heart's content. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d21d64d.3070...@debian.org
Re: libsafewrite
On 03/01/11 16:05, Olaf van der Spek wrote: Doesn't the Debian project care about regressions (and quality in general)? I'm sorry, but from scanning the conversation so far, no one but you seems to regard this as either a regression or a loss of quality. I will shut up at this point to let anyone who disagrees with this statement come forward and say so. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d21d87f.5020...@debian.org
Re: Safe file update library ready (sort of)
On 03/01/11 14:10, Adam Borowski wrote: There's a race condition: while [ 1 ]; do ln -s /etc/passwd somefile.tmp; done "Hey root, could you please use this program using libsafewrite on 'somefile'?" Two questions: 1. Is this race a regression from the single file case? 2. Is this race avoidable? In essence, it is impossible, as far as I know (patches welcome) to avoid a race when symlinks are involved (with specific exceptions). The assumption is, and has always been, that the directory resides inside a location that is secure from attacks. In this particular case, for example, you don't need this race at all. Simply do "ln -s /etc/passwd somefile" and ask root to write to somefile, with or without safewrite. That would work equally well, and does not require to race with anything. You might be wondering, if that is the case, why I'm unlinking somefile.tmp before opening it with O_CREAT|O_TRUNC. The reason is that it might have permissions (say, from a previous run that failed - unlikely, but not impossible) that prevent proper functioning. It has nothing to do with permissions. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d21d57d.1030...@shemesh.biz
Re: Safe file update library ready (sort of)
On 04/01/11 16:24, Ian Jackson wrote:
Shachar Shemesh writes ("Safe file update library ready (sort of)"):
This is not a formal release just yet (plus one function is still
missing an implementation, trivial though it might be). It's just that
the list obviously has a few people knowledgeable on the subject who can
give my code a second look and see whether there is anything I have missed.
I think this kind of approach is the wrong way to solve most instances
of this kind of problem. A better way is userv, which I wrote over a
decade ago and have been using with success on chiark since.
Ian.
I'm sorry, it might be me, but I fail to see the overlap between the
functionalities of safewrite vs. userv. The premises for safewrite is
that a program wants to make sure data integrity is maintained when
writing files. Userv seems to be about trust and a user level tool. The
two seem to revolve around two completely different interpretations to
the word "safe", as well as two completely different use scenarios.
Am I missing something here?
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
--
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/4d2330be.2070...@debian.org
Re: Safe file update library ready (sort of)
On 26/01/11 13:03, Goswin von Brederlow wrote:
Some things I noticed:
safewrite.h:
- missing headers, e.g. for mode_t
No. That's intentional. I'm assuming the people who will use safewrite.h
are going to RTFM, where it clearly says that those includes are needed.
I might reconsider if valid reasons are provided, but I would like to
avoid keep including the same headers over and over.
- no 'extern "C" {'
You are right. Fixed now.
I don't like how your functions are destructive to the path argument.
I don't think that is a major issue, but I do think that the reliance on
PATH_MAX is. I think the current implementation solves both of these
concerns.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
--
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/4d4d984b.9070...@debian.org
Re: Safe file update library ready (sort of)
On 06/02/11 18:40, Goswin von Brederlow wrote: I absolutely hate that. A header file should be compilable on its own. The times when #include would slow down the compiler are long gone and all include files are protected with #ifndef NAME so duplicate includes are harmless. On the other hand finding out what include files to include and in what order is a real pain if you have multiple files. Even if you have read the manual you will have to reread it every time you start a new project again and again to get that right. The includes necessary for safe_open are those necessary for open, plus safe_write.h itself. I don't see that as particularly burdensome. I'm not sure how platform independent any includes I put inside my header are going to be, and would rather not open this particular can of worms. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d51bcb3.7010...@debian.org
Re: Fun with libtool and cross-builds
On 09/02/11 22:10, Simon Josefsson wrote: Please try to debug where the -L/usr/lib comes from, I don't believe libtool is adding this by itself but instead it is told to add it by some incorrect .la file or similar. This is from memory, as I also ran into the same problem. The problem is, if my memory serves me right, in the following scenario: Cross build library A and install it with DESTDIR (obviously) to /tmp/otheroot Try to cross build library B, that needs library A. Obviously, you're going to give it -L /tmp/otheroot/usr/lib. The problem is that the .la files in /tmp/otheroot/usr/lib point to /usr/lib as the place to find the library. This only becomes a problem when a native version of library A is installed on the real system, at which point the compiler prefers that version, and then fails as it is of the wrong architecture. In my projects I wound up "fixing" the la file with sed as part of the build process, but that was an embedded project where: 1. The la files were not installed to the destination machine, and 2. The entire build was controlled by a single governing makefile. If either one of these conditions is not present, my solution simply wouldn't work. Another solution is to build A with --prefix=/tmp/otheroot/usr, but I think we can all see how that might break stuff in the library if the destination path is used inside the code. The only real solution I see for this is for libtool to have specific support for linking against DESTDIR installed libraries (maybe make it respect DESTDIR if it's defined during the build? That could be a solution that is both easy to understand and simple to integrate) Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com
Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
Package: wnpp Severity: wishlist Owner: Shachar Shemesh * Package name: libsafewrite Version : 1.00 Upstream Author : Shachar Shemesh * URL : http://www.lingnu.com/opensource/safewrite.html * License : MIT Programming Lang: C Description : Simple functions for performing safe atomic file updates Safewrite is a library for simple, almost drop-in replacement to the usual open and close calls. Using safewrite, however, guarantees that the files be updated in an atomic way - anyone trying to read the file is guaranteed to get a complete version, either the old or the new, but never a partially updated 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/20110222144115.9844.58744.report...@dellosun.office.lingnu.com
Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
On 22/02/11 19:54, Ben Hutchings wrote: Judging by what you consider 'small bugs' in <https://github.com/Shachar/safewrite/commit/efafcd4260375a41257709c7eb5a8d6065366849> why should anyone trust their important data to this library? Feel free not to use it/file bugs against it. Giving feedback over the upstream trustworthiness is not the purpose of ITP bugs, and I have been warned by the list masters that discussing a specific package's upstream bugs on Debian-devel is off topic. I quickly reviewed the code and found: Did you read the accompanying manual pages first? safe_open() might not return correct error codes, since the library and system calls in its cleanup code may overwrite the original error code. Thank you for your input. I'll fix it. It uses a fixed extension for the temporary file name, and unlinks whatever was there before; this could be a security flaw. The matter has been discussed before. If you have a specific scenario where this will cause a security flaw, please feel free to file a bug or contact me directly. Pending that happening, my analysis is that there is no security flaw in that case. It doesn't check for failure of fstat() (this is unlikely but possible, e.g. when using a network filesystem). Interesting point. I'll have to think about it. Copying setuid and setgid bits to an empty file is pointless, since they are cleared by write() (this is a good thing!). Frankly, I was not aware of this. I could not find it documented in the man pages. In any case, this is no regression from the non-safe_open case, as these would get cleared on write either way. If this is a Linux only feature, I'm actually inclined to leave the code in (which is why I needed the manual pages). safe_close() doesn't actually close the file or free the 'context' if fsync() fails. This is inconsistent with close(). But consistent with what the man page says about it. The alternative is to not allow the user to retry saving the file's content, which I don't see as preferable. Thank you for your feedback. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d648429.5010...@debian.org
Re: discussing upstream software on -devel (Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
On 23/02/11 12:23, Holger Levsen wrote: Hi, On Mittwoch, 23. Februar 2011, Shachar Shemesh wrote: Giving feedback over the upstream trustworthiness is not the purpose of ITP bugs, oh, hell yes, it is. Where else should we discuss what software fits into Debian? debian-qa@ when it's too late? Sorry. I phrased it wrong. I committed a largish change to git and then tested when I had the chance (a few days later). Upon testing, I used the wrong variable in a couple of places, which obviously caused things to not work. I committed this with the log message "Fix bugs a few small bugs." Redundant word aside, the word "small" is what brought The Wrath of Ben on my head. Don't get me wrong. After the initial instinct to flame subsided, I didn't mind that much. I got a bunch of comments, about 50% of which were actually useful to some degree (all of which are already fixed), and I learned something about the Linux kernel that I didn't before. If a maintainer's decision to relate to the size of the fix rather than the size of the consequence is a reason to boycott a package from Debian, then do let me know, because as things stand I intend to continue with the submitting process. and I have been warned by the list masters that discussing a specific package's upstream bugs on Debian-devel is off topic. I dont think this is neither true nor what they said. Surely a discussion about upstream bugs can become off-topic on debian-devel though. I'm sorry, Neil, but I'm quoting your message almost in full. Neil Williams sent me the following on January 3rd, regarding the previous thread about safewrite: Please remember,debian-devel@lists.debian.org is for discussion between Debian developers about issues within Debian (like problems within groups of packages or with particular tools), it's not intended for individual source code project development. This issue is general filesystem/programming issues, it is not Debian specific. Please can you find / setup a list for this project and move the discussion elsewhere from here on? If you want to keep it within the realm of source code related to Debian, an Alioth mailing list would be better. To which I replied that I cannot terminate an already running thread, and the setting up a mailing list for a project which is likely to reach maturity in a couple of versions is a bit of a waste, but that I'll try to wind down the discussion thread. I'm assuming that his lack of response indicates that he found my answer satisfactory. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d675de4.4050...@debian.org
Re: potential MBF: first alternate depends not available in main
On 02/03/11 12:45, Paul Wise wrote: On Wed, Mar 2, 2011 at 5:53 PM, Emilio Pozuelo Monfort wrote: If you have non-free enabled and install a package from main, it should install the dependencies from main. So you should have e.g. "rar | rar-nonfree" instead of the other way round. non-free stuff shouldn't be in main depends at all IMO, even as an alternative. Then please state what you think should happen in the case pointed out by Emilio. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d6e2409.20...@debian.org
Re: oops I sent a courtesy copy in violation of the code of conduct
On 12/03/11 05:14, jida...@jidanni.org wrote: Therefore perhaps http://www.debian.org/MailingLists/#codeofconduct could be amended to mention that adding a Mail-Followup-To header might add an additional wall of defense for those who wish to cut down even further the possibility they might receive a courtesy copy from the less technically adept. Personally, I think the code of conduct should be amended, along with the list software. So far, my research shows that the difference between people (like myself) who prefer to get the two copies and people who don't does not depend on level of technical knowledge, but specifics of method of reading the lists. I am subscribed to lots and lots of mailing lists. All mail from those lists gets automatically delivered to dedicated folders automatically. This means I'm highly likely to miss a reply to my own emails to the list unless I get another, direct, copy (which doesn't have the list hidden headers, and therefor stays in my inbox). I *like* to get two copies, as it increases the chance that I actually get to see the replies to my own emails. I understand and respect the fact that other people, due to using a mail client that does not allow filtering based on hidden headers, because they are only subscribed to a couple of mailing lists, or for whatever other reason, do not appreciate the extra copy. The problem is that I cannot tell them apart. Since the default for all non-mailing list communication should be "reply to all" (after all, if someone decided to CC a third party on a conversation they started with you, it's a bit impolite to cut said third party off from the reply), I think the current internet trend to treat the use of "reply to all" as a mistake is misguided. The solution I propose is already implemented in mailing list software such as mailman. In it, there is a per-user settable flag called "avoid duplicates". If it is set, if the mailing list detects that a CC or To recipient is also a mailing list subscriber, that subscriber does not get mailed a copy of the mail. This allows everyone to always hit 'reply to all', and have those who wish to receive an extra copy get it, and those who do not (such as most other subscribers to this list) not. I should point out that several mailing lists I'm subscribed to where this topic was a constant cause of bickering among the mailing participants switched to mailman, and the result was quiet on the 'reply to all' front for several years now. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d7aea4c.2060...@debian.org
Re: oops I sent a courtesy copy in violation of the code of conduct
On 13/03/11 08:19, Ben Finney wrote: Shachar Shemesh writes: Personally, I think the code of conduct should be amended, along with the list software. While this shouldn't turn into a counting of popularity, I'd like to register that there are people who think the list behaviour currently (leave the Reply-To field untouched) is correct. Never mentioned Reply-To, don't think Reply-To munging is correct, and don't understand why you brought it up. When talking about change to the list software, I was referring to the "Avoid duplicates" option, discussed below. I am subscribed to lots and lots of mailing lists. All mail from those lists gets automatically delivered to dedicated folders automatically. This means I'm highly likely to miss a reply to my own emails to the list unless I get another, direct, copy (which doesn't have the list hidden headers, and therefor stays in my inbox). I *like* to get two copies, as it increases the chance that I actually get to see the replies to my own emails. If you like to get two copies, why can't you arrange to generate the extra copies you want without involving anyone else's configuration? Any suggestions on how to do it? Conversely, I *don't* want any message to the forum to also be sent to me individually via email. In some cases that's because the individual message arrives first, is often read first, yet is the one that I want to avoid receiving. No filter can help with that, since it has no “other copy” to work with at the time it's needed. In other cases that's because I don't participate in the forum via email at all, so I don't want to receive any messages in that forum via email. I'm not trying to start an argument here, but I will point out that disregarding unwanted messages is easier to do with filters than generating new ones (and, more importantly, automatically figuring out for which messages duplicates should be generated). I understand and respect the fact that other people, due to using a mail client that does not allow filtering based on hidden headers, because they are only subscribed to a couple of mailing lists, or for whatever other reason, do not appreciate the extra copy. The problem is that I cannot tell them apart. Why do you need to tell those classes of people apart? Why is being unable to tell them apart a problem? As an example - the list charter clearly states that if someone indicates they wish to receive a copy you should CC him. I do not think I could have more clearly indicated my wish to do so than in my previous email, and yet you didn't. The reason I need to tell those apart from those is because that's what the list's charter says I should do. This is impossible to follow, and therefor should be amended. Since the default for all non-mailing list communication should be "reply to all" (after all, if someone decided to CC a third party on a conversation they started with you, it's a bit impolite to cut said third party off from the reply) I object to this idea quite strongly. The “forgot to include someone” mistake you identify is easily rectified after the message is sent; the “included someone whom I didn't intend” is impossible to rectify after the fact. For that reason among others, “reply to all” should not be the default but should be a deliberate decision in each instance. I totally accept that argument in the context of automatically adding "reply to" to lists, but not as a code of conduct for email at large. This is why I specifically said "non-mailing list communication". If I wrote you an email, and thought it necessary to CC someone, then this discussion is obviously part of a discussion said someone need to be aware of. It would be impolite of you to exclude him from your answer unless there is a good reason to do so. In other words, the default (not the software's default - your default as a human) should be to reply to all. There is a growing trend to make hitting reply to all illegitimate under any and all circumstances, which I think is in error. The solution I propose is already implemented in mailing list software such as mailman. In it, there is a per-user settable flag called "avoid duplicates". I'm not a “user” recognised by the mailing list servers of many of the forums in which I participate, so your proposal is not a solution for my case. I know I'm not the only one who participates in Debian (and other) mailing lists as non-email forums. But I believe that this is also something that can be resolved using technical means. I think the current policy is unnecessarily complex if followed, and in practice is not followed at all, leading to sub-optimal behavior. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. ht
Re: oops I sent a courtesy copy in violation of the code of conduct
On 13/03/11 11:29, Andrei Popescu wrote: Any suggestions on how to do it? By setting 'Reply-To:' appropriately, this is what it's for. If I set "reply-to" to myself, the mail won't go to the list. If I set it to the list, it won't go to me. Either way, the desired effect isn't achieved. Also, reply-to is the wrong tool for this job (this is NOT what it's for), as it prohibits distinction between replies to the list and reply to me. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d7d04b9.2050...@shemesh.biz
Re: oops I sent a courtesy copy in violation of the code of conduct
On 13/03/11 20:55, Andrei Popescu wrote: At least with mutt I distinctively recall it replied both to the list and CCd the poster on list-reply. That is a specific Mutt work around for broken lists that add "reply-to" automatically. It is not generally available. Not sure about other mailers though and you could also set Reply-To: to both the list and your address. A. I'm not at all sure what the standard says about multiple "Reply-To:" headers. I don't think they are supported B. Even if they are, they still don't allow people to reply privately. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com -- 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/4d7d9e6f.1060...@shemesh.biz
Re: Being part of a community and behaving
On 13/11/14 18:22, Tobias Frost wrote: > Sometimes, a joke is just inappropriate, regardless how funny it may seem. > Sometimes, a joke is better not made, regardless how funny it is. > > We have enough bad karma these days, no need to pour gasoline on the fires. Civility ism after all, so important to free speech (http://www.popehat.com/2014/09/06/u-c-berkeley-chancellor-nicholas-dirks-gets-free-speech-very-wrong/). I mean, people have the right not to be offended (http://rationalwiki.org/wiki/Freedom_of_speech#Right_not_to_be_offended). > I assume we're all adults after all. Including the ones doing the reading? Seriously. You are free to feel the joke was in poor taste. My stake in this particular game is not deep enough for me to think so, but taste is a matter of opinion. Which is precisely the point. Taste is a matter of opinion. Limiting speech to only the things everyone agree are in good taste greatly limits the speech (see first link for in depth explanation of why). I don't think I'd like this forum to regress to that point. I'd say more, but I just feel like I'm repeating what the two links I provided are saying. I suggest we do, indeed, act like adults. Please try to refrain from jokes other will find offending. If you see such a joke, please try to refrain from stirring the fire by saying it's wrong. Just, you know, be adults... Shachar
Re: Being part of a community and behaving
On 16/11/14 17:16, Scott Kitterman wrote: > The cure for inappropriate speech is more speech. Calling people on things > that are inappropriate or that cause problems in the project is exactly the > right thing to do. I was trying to point out the futility of trying to ask people to show restraint, as calling a (subjectively) innocent joke offensive is every bit as offensive as the original joke. > "Refrain from stirring the fire by saying it's wrong" is backwards. Over a decade ago I worked for a company I will not name. Suffice it to say it is a company producing firewalls. In the course of debugging one feature, I managed to create a RST storm. It is the same as an ACK storm[1], only with RST packets. The discussion here reminds me of those times. I am not telling anyone to shut up. Everyone are free to criticize whatever and wherever. I am merely suggesting that shutting up might be a smarter course of action. Of course, I'm sure there are those who will find my mail offensive, and will be most prudent in letting me, and everyone else, know about it. As such, I promise to henceforth accept my own advice. This is my last email on this thread. Shachar 1 - http://security.stackexchange.com/questions/49827/how-are-ack-storms-created-and-whats-a-good-mitigation-strategy-for-them
Specifying a C++11 compatible pre-dependency
Hi all, I have a package[1] that will not transition to testing due to failed compilation on powerpc. The problem is that the actual package requires a fairly complete C++11 support in order to compile. I have tried to signify this by adding "Build-Depends: gcc (>= 4:4.7)" to the dependencies. On PowerPC, despite gcc version 4.7 (and, indeed, 4.8) being available, the "gcc" package is for version 4.6.4. This means that without some platform specific tricks in the package (as I don't have a PowerPC platform, these tricks are hard to know), the package fails dependencies. Even if that were not the case, the package would fail to build, as gcc points to gcc-4.6.4. Is there some better way to cause the system to use a C++11 capable compiler? Shachar P.S. I no longer have a PowerPC platform to test with, and qemu-user isn't emulating deep enough for fakeroot-ng to work under (and is extremely buggy for PowerPC emulation anyways). As such, the best I can tell at the moment is that under ppc, when specifying gcc-4.8 compiler, the code compiles. 1 - http://packages.qa.debian.org/f/fakeroot-ng.html
Specifying a C++11 compatible pre-dependency
Hi all, I have a package[1] that will not transition to testing due to failed compilation on powerpc. The problem is that the actual package requires a fairly complete C++11 support in order to compile. I have tried to signify this by adding "Build-Depends: gcc (>= 4:4.7)" to the dependencies. On PowerPC, despite gcc version 4.7 (and, indeed, 4.8) being available, the "gcc" package is for version 4.6.4. This means that without some platform specific tricks in the package (as I don't have a PowerPC platform, these tricks are hard to know), the package fails dependencies. Even if that were not the case, the package would fail to build, as gcc points to gcc-4.6.4. Is there some better way to cause the system to use a C++11 capable compiler? Shachar P.S. I no longer have a PowerPC platform to test with, and qemu-user isn't emulating deep enough for fakeroot-ng to work under (and is extremely buggy for PowerPC emulation anyways). As such, the best I can tell at the moment is that under ppc, when specifying gcc-4.8 compiler, the code compiles. 1 - http://packages.qa.debian.org/f/fakeroot-ng.html
Re: Valve games for Debian Developers
On 23/01/14 13:45, Richard Hartmann wrote: > The risk of any "outsider" to become a DD for this offer alone is slim to > none. You're forgetting the free LWN subscription. Shachar
Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* -> and I can prove it)
On 26/03/14 17:13, Kevin Toppins wrote: > I am going to have to respectfully disagree with you on my post being useless. With the hope of contributing constructive criticism, I'll answer that. As far as the systemd vs. upstart discussion, I was leaning in upstart (more precisely, against systemd). As such, your email was very interesting to me. Unfortunately, it was unreadable. You said you'll start with background, but instead of providing technical background, you provided meaningless and irrelevant "he said, I said" arguments. Trying to skim ahead to find where the meat starts did not easily detect such a point. At this point, I simply assumed the email had nothing more to say. If I'm wrong, feel free to answer with the technical gist of your arguments. If you want me to read it, please adhere to the following guidelines: * No more than one page. * No *asterisks* and -> arrows. * No references to previous discussions, or other people's arguments for/against systemd. I believe in free discussion. As such, feel free to ignore these suggestions, just as I'll feel free to ignore your email if you do so. Shachar
Re: Having fun with the following C code (UB)
On 10/04/14 20:59, Ian Jackson wrote:
> Vincent Lefevre writes ("Re: Having fun with the following C code (UB)"):
>> On 2014-04-10 11:48:44 +, Thorsten Glaser wrote:
>>> And GCC is a repeat offender which actually does do that.
>> If you don't like that, you should use the -fwrapv option.
> Sadly that doesn't deal with all of these malicious optimisations.
>
I never did understand what people expect. gcc uses the undefined
behavior to not emit checks it would otherwise have to, so that your
code runs faster. This affects not only those corner cases, where you
are relying on this behaving a certain way, but especially in everyday
code, where those undefined behavior allows GCC to save you lots of cycles.
Are you really sure you want to have slower code just so that your
corner cases are easier for you? How is that a reasonable trade-off to make?
Shachar
Re: Having fun with the following C code (UB)
On 11/04/14 13:49, Ansgar Burchardt wrote: > Hi, > > On 04/11/2014 12:42, Ian Jackson wrote: >> >> What people expect is that the compiler compiles programs the way C >> was traditionally compiled. > Shouldn't -O0 come close to that expectation? I think that Ansgar's answer is spot on, but against all good sense, I still want to expand it. Neither the compiler nor its authors are doing anything out of spite. It is, indeed, painful when a compiler optimizes away a security check due to some standard defining a feature to be "undefined behavior". However, for any such case there are hundreds in which this optimization saves on an "if" that would strain the branch prediction cache, or allows coalescing operations that would otherwise need to be done one after the other, or any number of other cases in which the output machine language looks nothing like your written high level C or C++. Not only is this good for performance, it is also good for security. For example, in C++ I can run the following code: for( unsigned int i=0; i
Re: Having fun with the following C code (UB)
On 12/04/14 23:38, Henrique de Moraes Holschuh wrote:
> On Thu, 10 Apr 2014, Shachar Shemesh wrote:
>> I never did understand what people expect. gcc uses the undefined
> Warn the hell out of any line of code with per-spec undefined behaviour, if
> not by default, at least under -Wall.
I have no argument with that, in those places it is possible.
I will point out that it is not always is possible, and is quite often
not easy. For example, the famous "undefined after NULL dereference"
would probably cause a warning every time a function uses a pointer it
was given without first validating its non-NULLness.
> THAT would be a good start. Too bad not even gcc knows every time it hits
> undefined behaviour...
My understanding of things is that undefined behaviors are fairly
common, and almost always benign. Look at the following code:
int add( int a, int b )
{
return a+b;
}
Do you really want to get a "Warning: signed integer overflow yields
undefined behavior" on this function?
Shachar
Re: Having fun with the following C code (UB)
On 13/04/14 05:39, Russ Allbery wrote:
> One can make a good argument that such checks are exactly what you should
> be doing.
Then the answer is very simple. Write in Java.
>> My understanding of things is that undefined behaviors are fairly
>> common, and almost always benign. Look at the following code:
>> int add( int a, int b )
>> {
>> return a+b;
>> }
>> Do you really want to get a "Warning: signed integer overflow yields
>> undefined behavior" on this function?
> I would certainly like to be able to enable such a thing. I write a lot
> of code where I'd love the compiler to double-check that I've established
> bounds checks on a and b before doing the addition that guarantee that it
> won't overflow.
I am not a compiler writer, so I have no actual data. I suspect your
common 20k line will yield about a thousand such warnings, the huge
majority of which there will be nothing for you to do about.
Also, it turns out gcc does have such an option. See
http://www.airs.com/blog/archives/120. -Wstrict-overflow will let you
know when the optimizer uses the assumption of no overflow to change
other code.
>
> Put a different way, the answer to your question is quite different if
> that function were instead:
>
> int compute_offset_into_network_packet( int a, int b )
> {
> return a+b;
> }
>
> No?
>
In most cases, you will overflow the packet long before you overflow the
integer. If that's the case, the compiler won't help you. There is a
good case to claim that the warning would be appropriate for the
following code:
int compute_offset_into_network_packet( int a, int b )
{
int offset = a+b;
if( offset<0 || offset>PACKET_SIZE )
offset = 0;
return offset;
}
But, then again, what should the warning be? Like I said before, if you
don't like to deal with overflows, use Java and take Java's performance
hit. In fact, most of the world is doing precisely that.
Like I said before, I am not against the compilers warning about such
cases. I just think that these warnings need to be done very carefully,
or they become worse than useless. As such, if you see a case in which
you feel gcc (or clang, or whatever) should warn, by all means open a
bug for it. Just make sure you make it a "feature request" and not a
"security hole" severity. In other words, don't get mad merely because
the compiler author did not read your mind.
I don't know whether -Wstrict-overflow is on for -Wall (or -Wextra). If
it isn't, I do think it should be. Just checked, and it is on for -Wall,
sort of. See http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html.
Shachar
Re: Having fun with the following C code (UB)
On 13/04/14 06:32, Russ Allbery wrote: >> Like I said before, I am not against the compilers warning about such >> > cases. I just think that these warnings need to be done very carefully, >> > or they become worse than useless. As such, if you see a case in which >> > you feel gcc (or clang, or whatever) should warn, by all means open a >> > bug for it. Just make sure you make it a "feature request" and not a >> > "security hole" severity. In other words, don't get mad merely because >> > the compiler author did not read your mind. > I'll be sure to keep that in mind, since I've never reported a bug or > discussed issues with compiler writers before. No issues with most of what you said. It boils down to this: Different people write in C/C++ for different reasons, and therefor have different needs. I think the compiler writers are doing what they can, but there really is no pleasing everyone. Personally, I simply try to have my code compile on as broad a range of compilers as I can, and thus enjoy their combined warnings. The thing about the above is this. In the past, we've seen some people really explode over these issues. I think this is incorrect. The bug is, when all is said and done, in the code. While it's perfectly acceptable, in my eyes, to ask the compiler to help you find that bug, getting mad at it for not doing so makes no sense. Shachar
Re: Having fun with the following C code (UB)
On 15/04/14 19:45, Jakub Wilk wrote: > * Thorsten Glaser , 2014-04-15, 11:24: >> we need to go further. We need a programming language (with at least >> two compiler implementations), which I will call Ͻ, that looks like C >> so much that *every* C program¹ is also a valid Ͻ program, and >> *every* Ͻ program that does not make use of the additional guarantees >> (i.e. no C UB) is also a valid C program. > […] >> find a non-sucking name that is ISO 646 IRV, > > Let's call it Cava. > If we didn't have C, we'd all still be writing in obol,.pasal and basi. Oh, and Fortran, of course. Shachar
Gcc and undefined behavior
Just a quick FYI for anyone who missed it. Following the discussion from a few days ago about Cava (C like language with no undefined behavior), gcc 4.9 is now out[1]. One of the changes there is a runtime check for undefined behavior. Just compile with -fsanitize=undefined, and your program will crash with log if it performs an operation that C/C++ considers to be undefined. Have not tried it myself, but feedback would be great. Shachar [1] http://gcc.gnu.org/gcc-4.9/changes.html
Policy 12.3: should I rename?
I am working on bringing the libargtable2 package up to date with both upstream changes and the Debian policy. One of the changes state: recommend to ship additional documentation for package |pkg| in a separate package |pkg-doc| and install it into |/usr/share/doc/pkg|. The package currently ships the docs in a package calles "libargtable2-docs" (plural). I am wondering whether I should rename it, and how to do it. As far as I can tell, I have three options: 1. Don't rename. It's only a "recommends". 2. Rename with full transitional package 3. Rename without transitional package The incentive for doing 3 is that the dev package already depends on the docs package, so a transitional package might not be all that important. Another question I have is regarding packaging. The Policy suggests that libargtable2-doc should install the docs to /usr/share/doc/libargtable2. It seems that debhelper is not a friend in that regard, pushing me to install to /usr/share/doc/libargtable2-doc. Am I missing some option that would make that easy? Shachar
