Re: Bits from the dpkg project: 1.17.x series, general news
Le dimanche 19 avril 2015, 12:25:28 Didier 'OdyX' Raboud a écrit : > Le dimanche, 19 avril 2015, 10.25:11 Cyril Brulebois a écrit : > > Thanks so much for all the hard (and not only technical) work, > > Raphaël! > > Indeed, thank you buxy! > > OdyX +1. Thanks a lot Raphaël. Cheers, Thomas signature.asc Description: This is a digitally signed message part.
Re: Bug#720202: ITP: qreator -- utility for creating QR codes
Le lundi 19 août 2013 23:24:48 Chow Loong Jin a écrit : > Package: wnpp > Severity: wishlist > Owner: Chow Loong Jin > > * Package name: qreator > Version : 13.05.3 > Upstream Author : David Planella > * URL : https://launchpad.net/qreator > * License : GPL-3 > Programming Lang: Python > Description : utility for creating QR codes > > Qreator enables you to easily create your own QR codes to encode different > types of information in an efficient, compact and cool way. Greetings Loong Jin, Since it seems there is already a qr generator in Debian (qrencode), I suppose qreator has some feature that are lacking in qrencode. Could you develop those? That would be especially useful in the long description so that a user looking for a tool creating a qr code have enough information to choose between these two packages. Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Re: MBF: transition from texi2html to texinfo
Le mardi 28 mai 2013 16:48:50, Ryan Kavanagh a écrit : > On Mon, May 27, 2013 at 08:28:37PM -0400, Ryan Kavanagh wrote: > > See attached for a dd-list of affected packages. > > On Tue, May 28, 2013 at 04:37:44PM +0200, Emilio Pozuelo Monfort wrote: > > Please attach a list of packages run through dd-list before doing the > > MBF. > > Sorry, I guess I forgot to actually attach the list. Let's try that > again :) Thomas Preud'homme tcc Thomas Preud'homme tcc Fixed upstream already and I cherry-picked the patch for the next upload so -1 :) > > Best wishes, > Ryan Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Re: Temporary solution for changelog problem in binNMUs
Le vendredi 17 mai 2013 15:36:02, Julien Cristau a écrit : > On Fri, May 17, 2013 at 14:14:20 +0200, Thomas Preud'homme wrote: > > Also, it wouldn't help for the case of a binNMU on a subset of all arches > > since only some of them would have the entry. The solution proposed by > > ansgar cover this case. > > No it doesn't. dpkg will still refuse to install a m-a same package at > different versions. Yeah, right. Thanks for correcting me. The sentence should instead be "it would automatically cover this case if dpkg behavior was changed in this regards". But if I remember well there was some opposition to this idea. > > Cheers, > Julien signature.asc Description: This is a digitally signed message part.
Re: Temporary solution for changelog problem in binNMUs
Le vendredi 17 mai 2013 13:40:13, Dominique Dumont a écrit : > > This may be a dumb question, but looking at this example of different > binNMU changelogs [1], I wonder what is the point of having a log specific > to each build system ... > > In other word, can't we have a binNMU log generated by *the* system that > will trigger the rebuild ? So the log would be common for all binary > packages. You would have to make the date in the trailline the same for all buildd. Also, it wouldn't help for the case of a binNMU on a subset of all arches since only some of them would have the entry. The solution proposed by ansgar cover this case. signature.asc Description: This is a digitally signed message part.
Re: Do opaque struct changes break C library ABIs
Le vendredi 17 mai 2013 07:17:48, Guillem Jover a écrit : > (…) I agree dlopen()ing shared libraries in general should not > be supported (I'd even go further and say this should be outright > banned, given the pain it causes, and optional library support should > always be implemented by loading a plugin properly linked against such > library with an ABI under the control of the program loading it). I know of at least one case where I think it makes sense. TCC compiler uses dlopen to run a C file as a script. It compiles to memory and then dlopen all the libraries it needs and resolve the symbol itself. If the library in question is also used by the compiler (eg. glibc), it's going to be opened twice. However the dlopening is done shortly after the compiler is run so it's very unlikely that the dlopened version of the library is different than the one loaded by the dynamic linker so I don't think it's a problem in practice. Surely such a case shouldn't be banned. signature.asc Description: This is a digitally signed message part.
Re: jessie release goals
Le lundi 13 mai 2013 15:37:28, Philip Hands a écrit : > > If you must see the man page from a particular package: > > dget apache2.2-common > mkdir -p ./tmp/apache2.2-common > dpkg -X apache2.2-common_2.2.22-13_amd64.deb ./tmp/apache2.2-common JTYI, you could also use debman -p apache2.2-common $cmdname Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part.
Re: Bug#705169: RFH: iproute2 -- networking and traffic control tools
Le mercredi 10 avril 2013 21:33:32, Andreas Henriksson a écrit : > Package: wnpp > Severity: normal > > I request assistance with maintaining the iproute2 package. > > Help is welcome in all areas, but following ones would be > extra appreciated: > > "Please perform a full source scan and document all licensing information." > As requested by ftp-masters. > I didn't find a bug report mentionning this request. Is there a place mentionning it where progress to review the licensing could be posted? I'm willing to help on this point. I might have some time this WE to start looking at it. Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Re: Interactive package management via aptitude
Le mardi 9 avril 2013 13:29:09, Wookey a écrit : > > I too am a huge aptitude fan. The curses UI is brilliant for working > out what's up when things are a bit broken. However it doesn't deal > with multiarch well so I've been stuck with apt-get trying to work out > fro the tealeaves what's wrong. Is anyone actually working on making > the aptitude multiarch-friendly, or planning to? Or has at least > tthought about how hard a problem it is? I had the problem for a few month when I enabled multiarch but then things went fine again after the upload of aptitude 0.6.8.1-1 and its set of multiarch-related bug fix (Debian #672340, LP #831768 and LP #968412). > > Wookey Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Re: Bug#705015: ITP: ie7-js -- help Internet Explorer behave like a standards-compliant browser
Le lundi 8 avril 2013 23:35:42, David Prévot a écrit : > Hi, > > Le 08/04/2013 16:41, Jonas Smedegaard a écrit : > > For general use I believe, however, that html5shiv has proven a better > > shim. It is part of Modernizr already packaged for Debian. > > AFAICT, html5shiv is not in Debian, nor part of the modernizr package. > Did I miss something? Seems to be part of usr/share/javascript/modernizr/modernizr.js from line 1006 onwards. > > Regards > > David Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Re: alternative debian/rules
Le vendredi 5 avril 2013 13:41:50, Adam Borowski a écrit : > > It can be done, here's an example how to use a JIT C compiler (tcc) > this way: > dget http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc > although you might have trouble smuggling this through the FTPmasters :p > > On the other hand, one of fresh DDs already thanked me for this example, > so be afraid. Be very afraid. I'd be scared if it was uploaded to Debian but as the maintainer of tcc I'm quite amused and happy to see people use it to do crazy stuff. > > Hope this helps :) Best regards, Thomas signature.asc Description: This is a digitally signed message part.
Bug#703917: ITP: urwid-satext -- curse-based widget library based on Urwid
Package: wnpp Severity: wishlist Owner: "Thomas Preud'homme" * Package name: urwid-satext Version : 0.2.0 Upstream Author : Jérôme Poisson * URL : http://wiki.goffi.org/wiki/Urwid-satext/en * License : LGPL-3+ Programming Lang: Python Description : curse-based widget library based on Urwid Urwid-satext is a Python library providing a set a widgets based on top of Urwid: buttons, text fields, frames, etc. Please refer to the official web page for the complete list of features. Urwid-satext is needed for Salut à Toi (see ITP #703659) for its console frontend. Note about license: despite the copyright notices, the software is indeed under LGPL-3+ and not GPL-3+. The license was changed and the notices were not updated. Upstream author is going to do another release with the notice change. -- 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/20130325182658.22009.12550.report...@cerclon.rsr.lip6.fr
Re: [cut-team] Time to merge back ubuntu improvements!
Le samedi 12 janvier 2013 15:21:24, Jonas Smedegaard a écrit : > > I recommend instead of redefining logic of unstable, branch off new > suites with new logic. > > ...and then back to that issue of "maintainers should concentrate on the > release" again: I do sincerely worry that additional suites _will_ > affect how many of us developers will concentrate on getting the release > out. It would also probably affect how many users would test unstable which would undermine the efficiency of the transition from unstable to testing since bugs in unstable are more likely to not be noticed. Thomas signature.asc Description: This is a digitally signed message part.
Re: Time to merge back ubuntu improvements!
Le vendredi 4 janvier 2013 05:44:57, The Wanderer a écrit : > > That doesn't seem to match my experience. > > I most commonly encounter apt-listbugs bug lists via 'apt-get > dist-upgrade'. If I say "no" in response to the list of bugs, and then run > 'apt-get dist-upgrade' again, I see the same list of bugs. (I just did > this again, and checked /et/apt/preferences ; that file does not exist, > and /etc/apt/preferences.d/ is empty.) > > I don't nearly as often encounter apt-listbugs bug lists via 'apt-get > install [packagename]', but I do seem to recall that in cases where I have > done so, saying "no" and re-running the same command likewise produced the > same bug list; at the very least, it didn't try to prevent me from > installing the version which had been listed as buggy. (Nor would I want > it to, at least not without a way to override the block just as > conveniently as it was set up in the first place.) > > So either I'm not understanding what you mean by this description, or what > you're describing doesn't seem to be happening on my system. I think Gregor is describing the behavior when choosing p instead of n. In that case it sets a pinning and you don't see the bugs again. Best regards. signature.asc Description: This is a digitally signed message part.
Re: [PROPOSAL v2] Orphaning another maintainer's packages
Le mardi 30 octobre 2012 16:03:35, Stuart Prescott a écrit : > > I think four weeks would be much better. A maintainer might > > reasonably go abroad for 2-3 weeks - we even have a VAC process for > > handling absences. (And we don't want to complicate this third-party > > orphan process with references to VACs.) > > Remember that we do not really have a VAC process for the ~50% of > maintainers who are not DDs [1]. That group of maintainers have no real way > of letting the rest of the project know that they are on VAC [2]. They actually can send an email to debian-private to notify other DD that they are on VAC. They cannot subscribe to this mailing list but they can send mail to it. > > cheers > Stuart Cheers, Thomas signature.asc Description: This is a digitally signed message part.
Re: (seemingly) declinging bug report numbers
Le vendredi 19 octobre 2012 09:40:12, Christian PERRIER a écrit : Greetings Christian, First, let me take advantage of this mail to thank you for your tireless work on localization. > > Nowadays, would someone bet a coin that the same is happening? I would > not. In my daily job, I see students coming for post-graduate or > thesis work in scientific research departments (in optics, fluid > mechanics, material science, etc.). I talk to them (this > is my job to manage the needs of scientific departments wrt IT, in > our institution), I talk about their needs for their research work, I > talk to their staff. > > Definitely, the free software and Linux "culture" exists among people > in our universities (or in our typically French "Grandes Écoles"). But > Debian? Really? Not that much. I even heard (when people learn that I > am involved in the project) questions like "oh, Debian? Does it still > exist?". And, yes, here, Ubuntu comes up more often (I would bet that > more than half of students laptops installed with a Linux brand > nowadays are using it). Couldn't it be that the proportion of Debian users among Linux users has decreased but not the raw number? It's probably safe to say that Ubuntu attracted many new Linux users which could have changed that proportion. About the contributors, I believe most contributors in Ubuntu have an interest in working in Debian as well to reduce the diff size. > > For sure, this kind of "decline" is not that visible. We still have > new contributors, we still manage to do releases, we still have an > ever growing number of packages. But, we have less bug reports. We have > partly abandoned packages, including in the "core" of the > distribution. We have an installer that has just been "rescued" by > nearly a "one-man" effort. And I probably forget many other examples. Maybe the problem stems from the fact that contributions are focused on different components of the distribution than its core. Maybe it's even worse and potential contributors are more interested in doing android apps than working on Debian packages. > > This is sometimes hidden by the incredible work and investment of > several people in the project (yes, that's probably mean whoever is > reading this). I don't think it's mean to recognize the amazing work some people do. At least I don't feel offended. Best regards, Thomas Preud'home signature.asc Description: This is a digitally signed message part.
Re: Changes to Debian Maintainer upload permissions
Le lundi 24 septembre 2012 23:53:01, Kurt Roeckx a écrit : > On Mon, Sep 24, 2012 at 07:33:03PM +0200, Joachim Breitner wrote: > > package X would depend on the maintainer field of the packages *already* > > in Debian, not the one in the package he uploads. Just the way it is at > > One way to read your "bonus points" would allow the DM to > upload a new package with the maintainer set to > pkg-haskell-maintainers. That can also be interpreted as allowing > the DM to upload/NMU any package as long as he sets the maintainer > field to pkg-haskell-maintainers. Hence it's not what was proposed. > > But I can also read it as a DD first needs to upload the package > with the maintainer field set to pkg-haskell-maintainers, and > from then on any DM in that group can upload that package. AFAIUI, that's the proposed change. > > > Kurt Thomas signature.asc Description: This is a digitally signed message part.
Re: nacl and CPU frequency.
Le dimanche 23 septembre 2012 01:42:01, Ben Hutchings a écrit : > > So the build process is trying to determine which method will work? > Then what if it settles on some method that is available on the build > machine's kernel, but not the target distribution's kernel? I think you > need to either (1) make it defer this to run-time or (2) force the > decision at build-time, and be conservative. If I understood correctly he is ready to patch the build system to use a specific method for this precise reason but is asking which method would work on all Debian system. signature.asc Description: This is a digitally signed message part.
Re: Proposal: Making Debian compiler agnostic
Le mardi 28 août 2012 18:27:23, Ben Hutchings a écrit : > > Are all alternate compilers expected to implement gcc extensions? Must > the code be changed to use appropriate '#ifdef __GNUC__' guards? (And > what happens the next time gcc adds a new extension...?) I maintain tcc and it clearly doesn't support all the options gcc support. It emits a warning for all options it doesn't know. Does that sentence mean that the user defining CC to another compiler than gcc must make sure it support all options of gcc? Best regards. signature.asc Description: This is a digitally signed message part.
Re: EFI in Debian
Le mardi 10 juillet 2012 13:08:57, Russell Coker a écrit : > On Tue, 10 Jul 2012, "Thomas Preud'homme" wrote: > > When the flaws was exploited, then the attacker had sufficient access to > > change e.g. EFI and could thus have done whatever nasty things he wanted > > on the system. And as long as the system is not rebooted, nothing can > > prevent it to do so. > > http://etbe.coker.com.au/2011/12/28/secure-boot-protecting-against-root/ > > I've written a blog post about some of the issues related to secure boot at > the above URL. Some of the problems include the fact that workstations > have a lot of uptime nowadays (so a machine that has a trojan in RAM is > likely to stay that way for a while) and that an attack which is performed > once can be performed on every boot. > > http://www.coker.com.au/selinux/play.html Ah yeah, I read that blog post. I like your blog by the way. Anyway, I had the exact same impression. That's why I came to the conclusion it's only useful after fixing a flaw in order to be sure the problem is fixed on next reboot. But for machine which never reboot it's indeed useless. > > Also in that post I address the apparently common misconception that > "secure boot" makes it impossible for a remote "root" user to damage the > system. As an aside I have a Wheezy based SE Linux Play Machine online > right now, it demonstrates "root" as an account that can't damage the > system - but that "root" account also can't be used for system > administration... Of course, if you are root you can do whatever you want. That's the definition of root. > > The problem with that is the wide variety of ways that the system is > configured. We would need some way to verify, inspect, or revert every > change to a security sensitive config file to restore a compromised > system. Signing every config file isn't viable as you can't sign it > locally (and taking every changed config file from a disconnected system > is a PITA). Inspection isn't good as even competent sysadmins will have a > hard time recognising every potential mistake in a config file. > > Reverting changes (IE wiping /etc on upgrade) is unpleasant, but maybe we > could have a patch management system to treat all changes to /etc as > patches. This might be viable. Mmmmh, indeed I didn't think about all these important files. But then, if not everything is signed it reduce the number of ways an exploit can survive accross fix+reboot to files. Yes, it's still a large surface. Actually if you go down that road you'd need to sign everything you use. No matter that the kernel, bootloader and firmware are intact if your webserver is infected and giving access to important files of your system for example. The problem is that it becomes very hard to implement for a rather small benefit (IMHO). > > > At last, there is the question of what to sign. If we want secure boot to > > be really useful then we should sign all the way from the bootloader to > > the kernel modules. > > No. The easiest way of doing that properly would be to have a filesystem > that includes signing and not allow high integrity processes (either > processes with a high integrity label according to Biba or a system domain > in SE Linux) to read files that weren't signed. > > The harder way of doing that would be to have the system dynamic loader, > every interpreter (the shell, Perl, etc), and every important process that > reads a config file (IE most daemons) check signatures on all files. > > There's really not much benefit in having a signed kernel and modules if > you can have a trojan loaded from /root/.bashrc ! Yes, true. That's what in the end everything you care about should be signed. But I don't think it's doable. So either we don't do secure boot at all (benefit is it requires no additional work), or we do secure boot on part of the system which guarantee that when this part of the system is upgraded to fix a flaws, it will only be booted if it was not compromised before the fix. Sort of it provides a way of knowing cryptographically if part of the system was infected or not. Best regards. signature.asc Description: This is a digitally signed message part.
Re: EFI in Debian
Le lundi 2 juillet 2012 18:42:13, Steve McIntyre a écrit : > Hey folks, > > As you might have seen from recent discussions about the Fedora and > Ubuntu strategies for how to deal with EFI and Secure Boot, there are > potentially major issues in the area. In Debian we don't (yet) have a > plan, so it's high time that we had some discussion. I've set up a BoF > at DebConf for this: > > https://penta.debconf.org/penta/schedule/dc12/event/925.en.html > > That's Monday 9th July, 15:00 local time (21:00 UTC). Sorry for my naive questions but I want to be sure I understand the goal behind secure boot correctly. I'm not talking about Microsoft here but as stated by Bdale yesterday there is many people who see a value in secure boot to protect their system. Please correct any mistake I do in my reasonning and if I'm plain wrong just ignore my email or send me a notice on IRC or private email. Suggestions for the implementation are after the questions. What I'd really like to understand is why is protecting the boot so important for these people? Secure boot is designed to prevent booting code anywhere in the boot sequence which is infected by a malware. But if such an infection happens, it means a flaws in the system was used during the last run. It should normally not be possible to modify any of the code in the boot sequence without appropriate privilege. When the flaws was exploited, then the attacker had sufficient access to change e.g. EFI and could thus have done whatever nasty things he wanted on the system. And as long as the system is not rebooted, nothing can prevent it to do so. From this, I came to the conclusion that secure boot only provides additional security when the administrator discover the flaws, either via a CVE/DSA/whatever announce, or because he realized the system is having a strange behavior (ex: something suspicious in the logs). Then, he will try to patch the flaw by upgrading its kernel and want to be sure at reboot that the malware didn't manage to infect the patched kernel in the mean time. In other words, the administrator want to be sure at reboot that the problem is solved (at least for this flaw, there could be other flaws of course but they need to be found). If I understood all this correctly and that my conclusions are correct then I believe there could be an interest the secure boot functionality. Don't get me wrong, I'm really concerned about all the side effect of this technology with regards to locked down systems. There is an important need to both be able to disable secure boot and to be able to change and add main/CA keys. But there is nothing we can do technically about this. Implementation So the first question is wether we play secure boot or not. I believe that by playing it we don't remove anything to the users. No matter we play it or not, they will not be free to install whatever software they want as long as secure boot is activated (and this become a "forever" on ARM systems with windows certified logo). But by providing a signed image of Debian we provide at least a bit more security for people with secure boot enabled. Second question is with what key to sign Debian image and our bootloader. Should we use Microsoft key or use our own key and ask the users who wants to benefit from secure boot to install the Debian key. I personnally don't like the idea of using the key of Microsoft as we give them a switch to prevent Debian systems from being booted. On the other hand, I don't know if it will be easy to install new CA keys. At last, there is the question of what to sign. If we want secure boot to be really useful then we should sign all the way from the bootloader to the kernel modules. Thoughts about this? Best regards. signature.asc Description: This is a digitally signed message part.
Re: Bug#679236: O: ckport -- portability analysis and security checking tool
Le mercredi 27 juin 2012 22:22:17, Ian Jackson a écrit :
> Philipp Schafft writes ("Bug#679236: O: ckport -- portability analysis and
security checking tool"):
> > The package as made hardy useful by Ron Lee's personal vendetta against
> > me.
>
> I searched a bit and AFAICT this is a reference to these threads:
> bugs.debian.org/674634
> http://lists.debian.org/debian-release/2012/06/msg00388.html
> http://lists.keep-cool.org/pipermail/announce/2012-May/86.html
>
> From
> http://packages.qa.debian.org/c/celt.html
> I see that Ron Lee is indeed the maintainer of celt.
>
> It seems to me from reading these conversations that Ron has no
> vendetta against you. That kind of accusation is totally
> inappropriate.
>
> Ron does indeed have something against the package celt, and his
> explanations make perfect sense to me. That is, he appears to be
> right. He is also doing, AFAICT, the right thing.
>
> I think NMUing the rdepends of celt is the right thing to do, if it is
> necessary. (That is, if they haven't already been updated to turn off
> celt.)
What is the link between celt and ckport? I mean, why does this orphaning
message refers (implicitely) to celt?
>
> Ian.
Anyway, I didn't know this package and it seems interesting. I'd be happy to
adopt this package but since I'm quite busy now it wouldn't make any sense to
adopt it now. I'll add a bookmark for it and will adopt it in september if
nobody does before.
Best regards,
Thomas Preud'homme
signature.asc
Description: This is a digitally signed message part.
Re: What to do with bug reports against non-existing/removed packages
Le vendredi 18 mai 2012 17:41:55, Manuel A. Fernandez Montecelo a écrit : > 2012/5/18 Neil Williams : > > There's a big difference between these bugs and the rest - here there > > are clear migration paths to later packages which can be used to triage > > the bug reports in order not to lose reports. A lot of the rest *can* > > be closed without more triage work because the package was removed, not > > replaced. e.g. gcc-4.4 bugs may be applicable with gcc-4.7 and need to > > be triaged. The opensync/multisync bugs just had to be closed without > > even looking at any of them. > > Yes, I fully agree with that for the packages-removed-for-good. > > The thing is that a big % of the initial bugs (1500+ when I brought > this up, 1200+ now) is made up of the "gcc like" cases: gcc, emacs, > linux, libdb, python2.4, various java stuff, tomcat5.5... > > I don't know if they're 30, 50 or 80%, but definitely there is a big > amount of real bugs still related to current software shipped in > Debian. > > Another question, perhaps unrelated is, what happens with the bugs > closed from egroupware or salome (removed from unstable/testing but > still present in stable releases) when their users look for them in > the BTS? They would be closed and archived, I suppose, and users of > stable wouldn't be able to find them easily -- and them maybe report > them again. According to [1] salome is not part of any debian release now. Did I miss something? IIRW, for package still in stable, if the -done mail contains the right version then the bug will still be visible as long as it affects stable. [1] http://packages.qa.debian.org/s/salome.html > > So at the moment I left those bugs alone. I assume that they will be > autodeleted by some process when they're not present in stable > anymore, but perhaps are wrong and that's why there are such high > number of orphan bugs. > > > Cheers. Cheers. signature.asc Description: This is a digitally signed message part.
Re: Bug#673071: ITP: vodstok -- Voluntary Distributed Storage Kit
Le mercredi 16 mai 2012 09:22:46, Jonathan Wiltshire a écrit : > Hi, > > On 2012-05-15 21:33, Pierre Jaury wrote: > > This is an opensource, free and viral project > > Viral? I hope this is just a translation artefact; can you explain > exactly what you mean by it? From the website linked in the ITP: 4. Why is this project "viral" ? Once your Vodstok server functional, please drop the last version of Vodstok in the root directory of this web application. A webpage will be displayed when browsing the index page, and the kit would be available from this page. This is the "viral" part. Not exactly the definition of viral I have. > > Thanks, signature.asc Description: This is a digitally signed message part.
Re: Bug#672847: ITP: python-nbxmpp -- Non blocking Jabber/XMPP module
Le lundi 14 mai 2012 11:45:01, Thomas Preud'homme a écrit : > Le lundi 14 mai 2012 07:57:11, Yann Leboulanger a écrit : > > Package: wnpp > > Severity: wishlist > > Owner: Yann Leboulanger > > > > * Package name: python-nbxmpp > > > > Version : 0.1 > > Upstream Author : Yann Leboulanger > > > > * URL : http://nbxmpp.gajim.org > > * License : GPLv3 > > > > Programming Lang: Python > > Description : Non blocking Jabber/XMPP module > > The URL does not seem to work at the moment. Is the website being brought > up? > > Best regards, > > Thomas Preud'homme Answering to myself: the link should be http://python-nbxmpp.gajim.org/ Best regards. signature.asc Description: This is a digitally signed message part.
Re: Licenses not in /usr/share/common-licenses
Le lundi 14 mai 2012 01:59:41, Russ Allbery a écrit : > "Thomas Preud'homme" writes: > > Back to the redistribution. In the section 4 (Conveying Verbatim > > Copies), what is discussed is the redistribution of the Program as > > source code form. Every word is part of the same sentence, whose > > structure is: You may convey verbatim copies (…) provided that ; > > ; ; . > > > > I agree that the fact section 6 refers to section 4 is very (at least to > > me) ambiguous. I think the sentence must be read this way: > > > > You may convey, in object code, a covered work which is under the terms > > of sections 4 and 5, provided that … > > That reading seems strained to me. > > What I think is the intended structure of the GPL v3 goes like this: If > you want to convey X, you have to do A and B. If you want to do Y, you > have to do everything you'd have to do for X plus C. If you want to do Z, > you have to do everything you'd have to do for Y plus D. This means that, > if you want to do Z, you have to do A, B, C, and D. All the terms are > cumulative; each action listed in the GPL requires doing everything listed > for the previous actions plus some additional things. That's a reasonable reading indeed and the only reason I didn't consider this one is because of the structure of section 4. But I agree with you now, see below. > > In this case, section 4 says: > > You may convey verbatim copies of the Program's source code as you > receive it, in any medium, provided that you [...] give all recipients > a copy of this License along with the Program. > > and section 6 says: > > You may convey a covered work in object code form under the terms of > sections 4 and 5, provided that you also [...] > > So you have to comply with the terms of section 4 and 5, including the > added provisions, which means that you have to give all recipients a copy > of the license. > > > That is, "under the terms of sections 4 and 5" applies to "covered > > work", not "covered work in object code". > > But it doesn't say that. It says "convey a covered work in object code > under the terms of sections 4 and 5." The corresonding wording in the GPL > v2 was more of a mess; this is much clearer. > > > Also, since the license always requires the source to be distributed, it > > doesn't seem very important to have the license in both binary code and > > source code. > > But it *doesn't* always require the source to be distributed: > > b) Convey the object code in, or embodied in, a physical product > (including a physical distribution medium), accompanied by a written > offer, valid for at least three years and valid for as long as you > offer spare parts or customer support for that product model, to give > anyone who possesses the object code either (1) a copy of the > Corresponding Source for all the software in the product that is > covered by this License, on a durable physical medium customarily used > for software interchange, for a price no more than your reasonable > cost of physically performing this conveying of source, or (2) access > to copy the Corresponding Source from a network server at no charge. > > Also 6c, 6d, and 6e, all of which specify circumstances in which you don't > have to distribute the source. So without the requirements in section 4, > it's quite possible for someone to end up with a covered work without a > copy of the license. That part convince me your reading is right. Someone needs the license to know he is allowed to ask for the source if it's not provided. Just giving the copyright and the mention "this program is licensed under GPLv3" is not enough to inform the user of its rights. Besides, I checked a binary archive of emacs yesterday and it comes with the license. It's not a proof of anything per se but a good indication of what is the meaning of this section for the FSF. I still think however that section 4 should have been worded better to make it more clear from the first reading (before reading section 6) that it also applies to binary code form. Right now the structure is "To distribute copies of the source code, the requirements are A, B, C and D". Only because section 6 refers to this the text must be reinterpreted by replacing "source code" by "binary code". But maybe it's just me… Anyway, thanks for taking the time to explain me. Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part.
Re: Licenses not in /usr/share/common-licenses
Le samedi 12 mai 2012 22:56:39, Russ Allbery a écrit : > "Thomas Preud'homme" writes: > > Are you referring to [1]? Because the full paragraph is about Program's > > source code. > > > > [1] http://lists.debian.org/debian-policy/2000/11/msg00260.html > > > > " 1. You may copy and distribute verbatim copies of the Program's source > > code as you receive it, in any medium, provided that you conspicuously > > and appropriately publish on each copy an appropriate copyright notice > > and disclaimer of warranty; keep intact all the notices that refer to > > this License and to the absence of any warranty; and give any other > > recipients of the Program a copy of this License along with the > > Program." > > > > To me Program should be read here as "Program in source code form" > > Program is explicitly defined in the GPL and that's not what the > definition is. > > This License applies to any program or other work which contains a > notice placed by the copyright holder saying it may be distributed > under the terms of this General Public License. The "Program", below, > refers to any such program or work, and a "work based on the Program" > means either the Program or any derivative work under copyright law: > that is to say, a work containing the Program or a portion of it, > either verbatim or with modifications and/or translated into another > language. > > So Program is anything with a notice saying that the GPL applies to it. > And since you're required to preserve such a notice in derivative works as > another one of the requirements in point 1 (which is incorporated into > point 3), all derivative works will have such a notice. Agreed. > > It's not phrased very clearly, certainly. The GPL 3 fixes this. But you > have to split a lot of hairs to convince yourself that Program refers only > to source code distributions. (Which didn't stop people in that > discussion from splitting those hairs, but I didn't find it convincing.) After considering the definition of Program you pasted above, I come now to a new interpretation. I will consider GPL-3 from now on as differences with GPL-2 can be seen as a clarification of the intent of GPL-2. My understanding is that Program refers to any form in which the copyrighted work can be expressed. GPL-3 explicitely writes about source form and non- source form of a work. So a Program, whose definition is given as being a copyrighted work under GPL, has a source code form and a object code form. Program doesn't equal object code form but any form. Back to the redistribution. In the section 4 (Conveying Verbatim Copies), what is discussed is the redistribution of the Program as source code form. Every word is part of the same sentence, whose structure is: You may convey verbatim copies (…) provided that ; ; ; . I agree that the fact section 6 refers to section 4 is very (at least to me) ambiguous. I think the sentence must be read this way: You may convey, in object code, a covered work which is under the terms of sections 4 and 5, provided that … That is, "under the terms of sections 4 and 5" applies to "covered work", not "covered work in object code". Maybe I'm just reading it the way I want to read it. However the structure of section 4 really leads me to consider only source code. The whole section is dedicated to source code redistribution, object code has nothing to do with it as it is the object of section 6. Also, since the license always requires the source to be distributed, it doesn't seem very important to have the license in both binary code and source code. > > > As to point 3 referring to points 1, it says: > > > > " 3. You may copy and distribute the Program (or a work based on it, > > under Section 2) in object code or executable form under the terms of > > Sections 1 and 2 above provided that you also do one of the > > following(…)" > > > > I don't think it means the object code must provide a license, just that > > the program which is redistributed respect points 1 and 2. > > Point 3 says that, when distributing the Program, you have to comply with > all of the requirements of point 1. Point 1 says "...and give any other > recipients of the Program a copy of this License along with the Program." > > In order to believe that this requirement does not apply, you have to > believe that, because point 1 says "the Program's source code" at the > start, that means that it doesn't apply to distributions of the Program > that are not source code, despite the fact
Re: Licenses not in /usr/share/common-licenses
Le samedi 12 mai 2012 04:25:08, Russ Allbery a écrit : > Michael Gilbert writes: > > So, I think [0] is the most astute message in that thread. > > > > [0] http://lists.debian.org/debian-policy/2000/11/msg00251.html > > I thought that too when I first read it, but later in the thread are very > cogent arguments for why it's wrong and providing a complete copy of the > GPL with binaries is required. Are you referring to [1]? Because the full paragraph is about Program's source code. [1] http://lists.debian.org/debian-policy/2000/11/msg00260.html " 1. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program." To me Program should be read here as "Program in source code form" As to point 3 referring to points 1, it says: " 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following(…)" I don't think it means the object code must provide a license, just that the program which is redistributed respect points 1 and 2. Best regards. signature.asc Description: This is a digitally signed message part.
Re: Licenses not in /usr/share/common-licenses
Le mardi 8 mai 2012 07:56:35, Peter Miller a écrit : > On Mon, 2012-05-07 at 20:23 -0400, Joey Hess wrote: > > Conversely, debhelper contains actual, > > documented, and non-insane interfaces that could be used to do > > this properly. For some value of "properly" that the ftpmasters > > would probably still insta-REJECT. > > I has always puzzled me that there are not license packages that one > could Depends on, and get the appropriate license placed in the > appropriate place. Apt-get is an excellent mechanism for that kind of > thing, why not use it? Because every package must have a license delivered with it. The case of licenses in base-files is a compromise given that they are very popular and that this package is normally installed on any Debian system. signature.asc Description: This is a digitally signed message part.
Re: [Pkg-javascript-devel] Node.js and it's future in debian
Le dimanche 6 mai 2012 21:49:11, Jonas Smedegaard a écrit : > Greetings, dear Debian developer, > > [replying via bugreport as I am not subscribed to tech-ctte@d.o] > > On 12-05-06 at 10:22am, Steve Langasek wrote: > > On Sat, May 05, 2012 at 03:07:27AM +0200, Jonas Smedegaard wrote: > > > We have until now maintained Nodejs only in unstable because > > > requests to rename axnode was met with either silence or refusal > > > with the reasoning that axnode was more widely used in Debian than > > > Nodejs. > > > > > > Obviously Nodejs is not widely used in Debian when initially > > > packaged. So I've simply waited until it was really sensible to > > > make such comparison of popularity among the users of Debian. Which > > > seems to be the case now - even if still impaired by Nodejs only > > > offered to our users of unstable and experimental Debian. > > > > I find this response from you *very* disappointing. It implies that > > you knew that you had a responsibility to rename the Nodejs binary > > according to Policy, but that rather than acting in a timely manner to > > persuade upstream of the importance of renaming, you decided to wait > > until momentum was on your side so that you could have an outcome in > > your favor. > > No, that is not what it means. You are reading timings into it that I > did not write there, and you are reading those timings wrong! I believe the writing was just misleading and Steve just misunderstood it. I understood the same myself and I don't think I have any a priori on this since I am not at all involved. I believe this feeling come from the sentence "I've simply waiting until it was really sensible to make such a comparison of popularity". So let's just assume it was a misunderstanding and go back to technical argument in order to avoid this discussion to become too heated. > > > My understanding is that Node.js is a three-year-old project, and that > > the namespace issue was first raised upstream at least a year and a > > half ago. We would have been in a much better position to resolve this > > in a manner that does right by our existing ham community if you had > > lived up to your moral obligations as a Debian developer *then* > > instead of letting the issue fester. > > Your moral obligation, before throwing accusations like that, is to at > least investigate the issue, and ideally first asking nicely. > > You can read from nodejs packaging changelog and git commits when I got > involved in the maintainance, and you can read from bugreports and > mailinglists how my fellow maintainer, Jérémy Lal, conducted those moral > obligations which you claim that I should've done before I even knew > what "node" meant. > > > 'node' is a stupid name for a program, and this should have been > > impressed upon Node.js upstream early and often. We would have been > > in a position, together with other distributions, to force a sensible > > upstream name. I believe we no longer are in a position to do so, and > > even if we did, the transition now would be many times more disruptive > > for users than if this had been dealt with in 2010. > > > > > If Debian is frozen tomorrow, then Nodejs will not be part of it, > > > for the very reason that I *did* respect Policy. > > > > It may not be part of the release, but it will still be a mess for > > everyone involved. > > Thanks to stpid actions by people not doing their homework, yes. > > > - Jonas Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part.
Re: eglibc 2.14 for wheezy?
Le samedi 14 avril 2012 20:37:14, Svante Signell a écrit : > On Sat, 2012-04-14 at 20:27 +0200, Cyril Brulebois wrote: > > Svante Signell (14/04/2012): > > > As the title says, are there plans to use eglibc 2.14 for wheezy?? > > > It has been out for some time now. > > > > Again, ask the maintainers. Not dd@. > > OK, I will, where? egl...@packages.debian.org signature.asc Description: This is a digitally signed message part.
Re: A DM/DD should know how to watch his mouth (code of conduct).
Le dimanche 4 mars 2012 22:55:46, Russ Allbery a écrit : > Sergio Cipolla writes: > > I'm just a Debian user for some years and I'm writing to this list > > because I found that at > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660814 the Debian > > Multimedia maintainer Fabian Greffrath was very wrong, by being not > > only wrong in what he said but also very impolite. > > I wrote to a follow-up of that bug report ( > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660924 ) about what I > > thought of it: > > "Fabian, who do you think you are to call d-m-o's packages as 'crappy'? > > d-m-o is a traditional and very respected 3rd party repository for > > Debian and has been for years. > > I can't tell the same of you. > > Er... the first person to use the word "crappy" in that entire bug > discussion is, um, you. Usually when you put quote marks around things > that's supposed to indicate that it's a quote. You probably missed [1] then. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660814#10 > > That whole bug discussion is rather frustrating due to a collection of > misunderstandings and misconceptions that weren't made easier by a very > aggressive bug reporter, but it looks like it mostly got sorted out. I'm > not seeing, in that thread, what you're upset about; Fabian could have > probably phrased a few things better, but he de-escalated a > confrontational bug report reasonably well. 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: 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: help with git
Le jeudi 21 juillet 2011 10:11:37, Jonas Smedegaard a écrit : > On 11-07-21 at 11:10am, Norbert Preining wrote: > > I now want to include upstream git into a branch, either the upstream > > branch itself, or some other/new one, but I have no idea how > > to set that up? > > > > Can someone help me here? The remote is some > > > > git://gitorious.org//.git > > > > By now I have added a remote to my .git/config: > > [remote "upstream-git"] > > > > url = git://gitorious.org/mu/mu-ng.git > > fetch = +refs/heads/*:refs/remotes/upstream-git/* > > tagopt = --tags > > > > Set up with git remote add --tags upstream-git > > git://gitorious.org/mu/mu-ng.git > > > > But somehow I don't manage to get a branch that follows that remote. > > I tried to add: > > [branch "upstream-new"] > > > > remote = upstream-git > > merge = refs/heads/master > > > > but that tells me: > > Your configuration specifies to merge with the ref 'master' > > from the remote, but no such ref was fetched. > > > > Sorry, I am a bit at loss here. Any suggestions how to do this > > properly? > > I would, instead of editing the config, use this command: > > git checkout -B --track upstream-git/foo bar I would also precede it with git remote add upstream-git to ease the use of upstream repository. > > With foo being the branch as named upstream and bar being what you want > to call it locally. > > > The core Sugar packages track upstream git as well. You may find some > inspiration in the debian/README.source file of e.g. sugar-base > (ignoring the CDBS parts if you don't use that). > > > Hope that helps, > > - Jonas signature.asc Description: This is a digitally signed message part.
Re: Bug#631002: ITP: swift-im -- The Swift IM client
Le dimanche 19 juin 2011 18:22:01, Kevin Smith a écrit : > Package: wnpp > Severity: wishlist > Owner: Kevin Smith > > > Package name: swift-im > Version : 1.1 > Upstream Author : Swift Developers > URL : http://swift.im/ > License : GPL > Programming Lang: C++ > Description : The Swift IM client Could you provide a longer description? And also it would be good to mention XMPP in the short description. Best 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/201106192146.11152.robo...@celest.fr
Re: glibc: causes segfault in Xorg
Le mercredi 04 mai 2011 14:23:19, Aurelien Jarno a écrit : > Le 04/05/2011 14:06, Raphael Hertzog a écrit : > > a nice behaviour, it would be way better to print > > a warning and fallback to a correct behaviour. Users can then report the > > problems without experiencing a non working-application. > > Printing a warning on a thing that is potentially used everywhere, > especially in scripts is not a good idea. It will simply corrupt the > data that the othe part of the script is waiting for, and that even on > stderr, a lot of scripts are not (correctly?) designed for that. Is there a usertag to track the memcpy bugs? Regards. signature.asc Description: This is a digitally signed message part.
Re: New version of DEP-5 parser
Le mardi 22 février 2011 20:24:02, Dominique Dumont a écrit : > Le mardi 22 février 2011 19:06:27, vous avez écrit : > > Can't call method "fetch_element" on an undefined value at > > /usr/share/perl5/Config/Model/Backend/Debian/Dpkg/Copyright.pm line 121. > > > > Do you want me to fill a bug report in addition to this email? > > Yes, please. And also include the copyright file (or an extract) that shows > the bug. Done, see 614776. > > All the best > > Dominique Best regards. > -- > http://config-model.wiki.sourceforge.net/ -o- > http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont > -o- http://ddumont.wordpress.com/ signature.asc Description: This is a digitally signed message part.
Re: New version of DEP-5 parser
Le vendredi 21 janvier 2011 21:16:59, Dominique Dumont a écrit : > Hello > > I've fixed upstream [1] most (hopefully all) the issues > regarding the DEP5 parser based on Config::Model that > were mentioned on these lists or in the BTS. I've just discovered now but config-edit fail when header section contain a License stanza. It fails with: Can't call method "fetch_element" on an undefined value at /usr/share/perl5/Config/Model/Backend/Debian/Dpkg/Copyright.pm line 121. Do you want me to fill a bug report in addition to this email? > > The new version is already (thanks gregoa) available > on Debian/Sid in libconfig-model-perl 1.230 > > I've updated the parser so as to upgrade older version > of copyright file (even pre DEP-5 versions) into the > current format. All old keywords are translated into new > keywords (except the old keywords I do not know yet about :-p ) > > For those who missed the previous thread, you can find > more details in my blog [2]. > > Last but not least, I'll present Config::Model and its > applications (including OpenSsh config and DEP-5 copyright) > in the cross-distro dev room at FOSDEM in 2 weeks. Feel free > to come by and let's discuss DEP5 or other possible applications. > > > All the best Thanks for this tool > > Dominique Thomas Preud'homme > > [1] http://search.cpan.org/dist/Config-Model/ > [2] > http://ddumont.wordpress.com/2011/01/13/debian-copyright-dep5-parsereditor > validatormigrator-is- released/ > > -- > http://config-model.wiki.sourceforge.net/ -o- > http://search.cpan.org/~ddumont/ http://www.ohloh.net/accounts/ddumont > -o- http://ddumont.wordpress.com/ signature.asc Description: This is a digitally signed message part.
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
Le jeudi 13 janvier 2011 16:35:06, Picca Frédéric-Emmanuel a écrit : > Le Thu, 13 Jan 2011 13:47:53 +0100, > Dominique Dumont a écrit : > > hello, another try :) > > picca@grisette:~/Debian/tango/tango$ config-edit -application > dpkg-copyright -ui none You should install Config::Model::TkUI or > Config::Model::CursesUI for a more friendly user interface 2011/01/13 > 16:30:47 Invalid line: Copyright : � 1997-1999 AT&T Laboratories Cambridge > > > 2011/01/13 16:30:47 Invalid line: Copyright : � 2010, The Tango team > > > > 2011/01/13 16:30:47 Invalid line: Copyright : � 2010, The Tango team > > > > 2011/01/13 16:30:47 Invalid line: Licence LGPL-3+ > > > 2011/01/13 16:30:47 Invalid line: Copyright : � 2010, The Tango team > Could it be because of the space between Copyright and the colon? > > > Element 'Format-Specification' of node 'Debian::Dpkg::Copyright' is > deprecated In configuration root: (function 'create_element') unknown > element 'Upstream-Author' (configuration class 'Debian::Dpkg::Copyright') > Expected: > 'Format','Upstream-Name','Upstream-Contact','Source','Disclaimer','Comment > ','Copyright','Files','License','Format-Specification','Name','Maintainer', > 'Upstream-Maintainer','Upstream-Source' or an acceptable parameter matching > 'X-.*' I guess you don't have a problem with this one. > > I attached the copyright file > > See you > > Frederic Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part.
Bug#604178: ITP: gcp -- Advanced command line file copy system
Package: wnpp Severity: wishlist Owner: "Thomas Preud'homme" * Package name: gcp Version : 0.1 Upstream Author : Jérôme Poisson * URL : http://www.goffi.org/index.php * License : GPLv3 Programming Lang: Python Description : Advanced command line file copy system gcp is an advanced command line file copy system with an interface similar to that of cp. It features: - transfer progression indication - continuous copying on error (skip to next file) - copy status logging - name mangling to handle target filesystem limitations - forced copy serialization - transfer lists management I'm not sure about the homepage as: 1) this is a blog 2) it is written in french -- 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/20101121004740.16851.30027.report...@cerclon
Bug#599008: ITP: ultracopier -- Advanced graphical file copy system
Package: wnpp Severity: wishlist Owner: "Thomas Preud'homme" * Package name: ultracopier Version : 0.2.0.15 Upstream Author : Herman Brule * URL : http://ultracopier.first-world.info/contact.html/ * License : GPLv3 Programming Lang: C++ Description : Advanced graphical file copy system Ultracopier is a graphical file copy system featuring: - transfer suspend - speed control - transfer list management - advanced name colision and error management . Ultracopier also supports multiple skins and languages. Upstream developer has agreed to co-maintain this package with me. -- 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/20101003184300.2.57721.report...@olivaw.celest.fr
Re: RFH: bashisms in configure script
On mercredi 26 mai 2010 02:39:52 Raphael Geissert wrote: [SNIP] > > Yes, $BASH_SOMETHING is just used to make it easier to see that the > following code (probably a bashism) is only executed after checking the > shell is actually bash. That and the other FP are the most common ones, yet > not that easy to fix (the latter, of course, the former is not a FP.) > > > I'm seeing only these for gxine, xine-lib and xine-ui, which is slightly > > odd because testing with dash has shown up an actual bashism in > > xine-lib's configure.ac (which I've just fixed upstream): use of "test x > > == y". > > Could you please send me by email the files with false negatives? those are > very likely bugs in checkbashisms' quotes handling code. Among other false positive there is warning about scripts removed in clean target of debian/rules. Anyway, thanks for the massive run of checkbashism, it made me discover a few bashism in 2 upstream scripts in my packages. > > Thanks. > > Cheers, Best regards signature.asc Description: This is a digitally signed message part.
Re: autoconf method in ifupdown
On samedi 18 avril 2009 00:06:52 Guillem Jover wrote: > On Fri, 2009-04-17 at 19:14:14 +0200, Thomas Preud'homme wrote: > > I'm ready to do it but I think this makes more sense to submit the bug to > > the upstream dev. Unfortunetely I couldn't find the web page of the > > ifupdown upstream development. It's not a software specific to debian, > > isn't it ? > > The Debian maintainers are the upstream devs, so filing a bug report > to the BTS is what you are looking for. Although it's not specific to > Debian, I think other distros also use it. Perfect, I'll do in within a few days. Thanks > > regards, > guillem Regards, Thomas Preud'homme -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: autoconf method in ifupdown
On mercredi 08 avril 2009 04:42:38 Guillem Jover wrote: > Hi! > > On Sun, 2009-03-29 at 18:00:14 +0100, Thomas Preud'homme wrote: > > I was looking a method to just have ipv6 with autoconf network and > > found this patch > > http://mlblog.osdir.com/linux.debian.devel.ipv6/2005-05/msg00012.shtml > > This link didn't seem to work, got this instead: Strange, this is the page I came from before writing this e-mail. > > <http://lists.debian.org/debian-ipv6/2005/05/msg00012.html> > > > Does anybody know the answer of upstream dev to this patch proposition ? > > Checking the ifupdown bug reports, it does not seem this ever got > submitted. It might make sense to file one with the patch. I'm ready to do it but I think this makes more sense to submit the bug to the upstream dev. Unfortunetely I couldn't find the web page of the ifupdown upstream development. It's not a software specific to debian, isn't it ? > > regards, > guillem Regards, Thomas Preud'homme -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
autoconf method in ifupdown
Hi all, I was looking a method to just have ipv6 with autoconf network and found this patch http://mlblog.osdir.com/linux.debian.devel.ipv6/2005-05/msg00012.shtml Does anybody know the answer of upstream dev to this patch proposition ? Regards, Thomas Preud'homme -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian PopCon & Linux Counter: Statistics
Le dimanche 27 juillet 2008, vous avez écrit : > Thomas Preud'homme wrote: > > Le dimanche 27 juillet 2008, RalfGesellensetter a écrit : > >> Dear list, > >> > >> today I got a reminder from Linux Counter [1] to update my > >> registration. Since their announcement in 2001 [2] it seems that > >> the amount of registered users didn't grow much - as opposed to > >> the perceived growth of GNU/Linux popularity. > >> > >> It is mainly interesting to view statistics on how GNU/Linux is > >> spreaded over different countries, distros etc. Maybe a > >> cooperation with Popularity Contest could be of interest, > >> providing an anonymous auto-registration with this package? > >> > >> What do you think? Are you registered yet? > >> Regards > >> Ralf. > >> > >> [1] http://counter.li.org/ > >> [2] http://www.linux-community.de/Neues/story?storyid=1953 > >> > >> P.S.: It is quite easy to estimate the real amount of Linux users > >> within some homogeneous population if you know what proportion of > >> actual Linux users is registered at li.org. > > > > If an anonymous registration is done in popcon package then a > > debconf dialog should ask the user if he already has an account on > > counter.li.org > > No, the installation of the popularity-contest should be minimal. The > README.Debian may contain such a pointer and popcon.debian.org or > other pages of Debian may be ornamented with a link to the linux > counter. > > Steffen I agree with you. I just answered to make sure if this happen, the package should not register 2 times the same user. Though a note somewhere in the package is nice but I don't think it will be of any help since most users don't read it and it's not related to package IMO. I don't know yet the rules concerning the long description of a debian package but maybe a sentence could be added to recommend users to create an account on counter.li ? Regards -- Thomas Preud'homme Why Debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
Re: Debian PopCon & Linux Counter: Statistics
Le dimanche 27 juillet 2008, RalfGesellensetter a écrit : > Dear list, > > today I got a reminder from Linux Counter [1] to update my > registration. Since their announcement in 2001 [2] it seems that the > amount of registered users didn't grow much - as opposed to the > perceived growth of GNU/Linux popularity. > > It is mainly interesting to view statistics on how GNU/Linux is > spreaded over different countries, distros etc. Maybe a cooperation > with Popularity Contest could be of interest, providing an anonymous > auto-registration with this package? > > What do you think? Are you registered yet? > Regards > Ralf. > > [1] http://counter.li.org/ > [2] http://www.linux-community.de/Neues/story?storyid=1953 > > P.S.: It is quite easy to estimate the real amount of Linux users > within some homogeneous population if you know what proportion of > actual Linux users is registered at li.org. If an anonymous registration is done in popcon package then a debconf dialog should ask the user if he already has an account on counter.li.org Regards -- Thomas Preud'homme (just a user) Why Debian : http://www.debian.org/intro/why_debian signature.asc Description: This is a digitally signed message part.
