Re: support for merged /usr in Debian
On Thu, 31 Dec 2015 01:51:45 +0100, m...@linux.it (Marco d'Itri) wrote: >We have a reasonably tested usrmerge package which can be used to >convert on the fly a system to merged /usr, and the good news is that >there are only three packages which need to be fixed to work on a merged >/usr system. Please consider keeping support for separate /usr as it is done today. Mounting /usr in initrd is an acceptable workaround. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Renaming the Debian Project
I believe Debian should retain its name, for the following reasons... * Debian is a well known brand. * Name changes are disruptive. Lot's of work would be involved in updating documentation and branding. * It would lead to confusion for users trying to search for help with a problem (do they search for Debian or the replacement name?). This would fragment existing documentation and support, which is a high price to pay. * Ian's (now deleted) tweets, although inappropriate, were not intended to be racist, or at least that's how I see it. It's all a matter of context. I think in this situation we can clearly see his tweets and outgoing manner are entirely out of character, when compared with previous tweets on the account. There are all sorts of factors to weigh in here, stress, mental health issues, possible head injuries, etc. It's entirely inappropriate to suggest a name change at this point in time, when there is grief enough to contend with. * Ian Murdoch has dedicated much of his life to the furthering of open source software. It would be a shame to steal his legacy away from him, after his untimely and unfortunate death.
Re: support for merged /usr in Debian
On Dec 31, Marc Haber wrote:
> Please consider keeping support for separate /usr as it is done today.
> Mounting /usr in initrd is an acceptable workaround.
The whole point of the merged /usr scheme is to support a separate /usr
file system, except that this way it is actually useful because you also
move /{bin,sbin,lib}/ in it.
--
ciao,
Marco
signature.asc
Description: PGP signature
Re: support for merged /usr in Debian
On Thu, Dec 31, 2015 at 1:30 PM, Marco d'Itri wrote:
> On Dec 31, Marc Haber wrote:
>
>> Please consider keeping support for separate /usr as it is done today.
>> Mounting /usr in initrd is an acceptable workaround.
> The whole point of the merged /usr scheme is to support a separate /usr
> file system, except that this way it is actually useful because you also
> move /{bin,sbin,lib}/ in it.
Yes I have some question. You do not answered point given in #767754
about dpkg-divert. Moreover guillem and me consider that symlinking
lib is evil.
Could you answer to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767754#47
And minimally give us the snippet of maint script used. We have some
doubt about safety at deinstall time (it will need review)
Moreover adding lintian check is really needed, in order to avoid
reintroducing bugs.
Bastien
> --
> ciao,
> Marco
Bug#809504: ITP: neat -- Nebular Empirical Analysis Tool - analysis of astronomical spectra with propagation of uncertainties
Package: wnpp Severity: wishlist Owner: Roger Wesson * Package name: neat Version : 1.8 Upstream Author : Roger Wesson * URL : http://www.nebulousresearch.org/codes/neat * License : GPL v3 Programming Lang: fortran 95 Description : Nebular Empirical Analysis Tool - analysis of astronomical spectra with propagation of uncertainties Code for rapidly calculating temperatures, densities and abundances in planetary nebulae, HII regions and other emission line objects. Propagates uncertainties using a Monte Carlo technique. NEAT is maintained and developed by me and two co-authors. It was released in 2012 and has been used in a number of studies published in the astronomical literature. It is already packaged and available via PPA at https://launchpad.net/~nebulousresearch/+archive/ubuntu/ppa
Re: support for merged /usr in Debian
On Dec 31, Bastien ROUCARIES wrote: > Yes I have some question. You do not answered point given in #767754 > about dpkg-divert. Moreover guillem and me consider that symlinking > lib is evil. Because I still do not really understand your objections nor which problems you are trying to solve, so I hope that somebody else more familiar with lintian development will be able to help. -- ciao, Marco signature.asc Description: PGP signature
Bug#809507: ITP: alfa -- Automated Line Fitting Algorithm
Package: wnpp Severity: wishlist Owner: Roger Wesson * Package name: alfa Version : 1.0 Upstream Author : Roger Wesson * URL : http://www.nebulousresearch.org/codes/alfa * License : GPL v3 Programming Lang: fortran 95 Description : Automated Line Fitting Algorithm ALFA measures the fluxes of emission lines in astronomical spectra. It is fully automated and takes a few seconds to measure a spectrum containing hundreds of emission lines. It uses a genetic algorithm to optimise the fit parameters. It can also directly read FITS data cubes, making it particularly useful for spatially resolved spectroscopy. The code is maintained by me, is under active development, and is already packaged and available via PPA at https://launchpad.net/~nebulousresearch/+archive/ubuntu/ppa
Bug#809518: ITP: dtiprep -- automatic pipeline for DWI/DTI QC and preparation
Package: wnpp Severity: wishlist Owner: Yaroslav Halchenko * Package name: dtiprep Version : 1.2.5 Upstream Author : DTIPrep Team * URL : http://www.nitrc.org/projects/dtiprep * License : Apache-2.0 Programming Lang: C++ Description : automatic pipeline for DWI/DTI QC and preparation DTIPrep performs a "Study-specific Protocol" based automatic pipeline for DWI/DTI quality control and preparation. This is both a GUI and command line tool. The configurable pipeline includes image/diffusion information check, padding/Cropping of data, slice-wise, interlace-wise and gradient-wise intensity and motion check, head motion and Eddy current artifact correction, and DTI computing.
Icedove now
Hi, Just a small question: does someone has an idea of the future of Icedove if Thunderbird is no longer developped by Mozilla? Will be updates? New features? Or maybe Thunderbird is still maintained by the community? Regards, -- Jean-Philippe MENGUAL HYPRA, progressons ensemble Tél.: 01 84 73 06 61 Mail: cont...@hypra.fr Site Web: http://hypra.fr
Re: Icedove now
Hey, On 31/12/15 11:59 AM, MENGUAL Jean-Philippe wrote: > Hi, > > Just a small question: does someone has an idea of the future of Icedove > if Thunderbird is no longer developped by Mozilla? Will be updates? New > features? Or maybe Thunderbird is still maintained by the community? Mozilla has not given up Thunderbird. It is just not longer developed by the Firefox inc. It now under the Mozzila Foundation. See: https://blog.mozilla.org/thunderbird/ > Practically what this means is that in 2016, Thunderbird will finally > be able to accept donations from users directed toward the update and > maintenance of Thunderbird. In the long run, Thunderbird needs to > rely on our users for support, and not expect to be subsidized by > revenue from Firefox. We welcome this help from the Mozilla > Foundation in moving toward our goal of developing independent > sources of income for Thunderbird. Icedove will continue to exist. Cheers, -- Alexandre Viau av...@debian.org signature.asc Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On Thu, Dec 31, 2015 at 3:22 PM, Marco d'Itri wrote:
> On Dec 31, Bastien ROUCARIES wrote:
>
>> Yes I have some question. You do not answered point given in #767754
>> about dpkg-divert. Moreover guillem and me consider that symlinking
>> lib is evil.
> Because I still do not really understand your objections nor which
> problems you are trying to solve, so I hope that somebody else more
> familiar with lintian development will be able to help.
It is not only about lintian it is about the quality of your maintscript.
Guillem and I said that your script is naive.
You said:
> + The package ships the two (or more) files with the same name
> + installed both in /{bin,sbin,lib*}/ and /usr/{bin,sbin,lib*}/.
> + This is incompatible with the everything-in-usr directories scheme.
> + .
> + Packages which need to do this must create in postinst one of the files
> + to be a symbolic link to the other one.
But you do not give example of script to do this. Moreover you do not
check the existance of dpkg-divert in
https://anonscm.debian.org/cgit/users/md/usrmerge.git/tree/convert-usrmerge
This is a RC bug to continue if they are dpkg-divert in place.
Moreover quoting guillem and me about creating symlink for library
under /lib if a pakage install both file in /lib /usr/lib
>> >> Moreover for library why do we need to create the symlink ? I think
>> >> one library shadow another and is still a bug. In this case you should
>> >> duplicate the tag and create a new tag for library.
>> > I do not understand your comment.
>>
>> I means that binaries under s?bin and libraries are different beast. I
>> think the solution for library is to not use symlink (and delete one
>> of copy) because LD_PATH is always used whereas for bin you could call
>> it directly.
>
>Right
.Moreover, quoting guillem
>In addition, from what I've seen from the submitted patches, I'd
>probably check for the ownership of the pathname being symlinked to
>or removed, and if it is owned by another package bail out. Because
>dpkg will not be performing such checks at unpack time.
Thus we want to check if the dpkg maint script applied in case of
conflicts are good. And it is not a lintian problem.
Bastien
> --
> ciao,
> Marco
Debian name change
As you may know you posted on you blog about the recent passing of our beloved Ian Murdock, by completely slandering his name, and the debian image. As a black American I find it thoroughly racist that you would even insist that changing the name to Euphemia is a good option. Euphemia is in no way relevant to the debian project no matter what excuse you come up with. Please do not try to include blacks in a project that has nothing to do with them. Signed Jermane King.
Bug#809533: ITP: lemur -- TLS certification manager
Package: wnpp Severity: wishlist Owner: Daniel Stender X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: lemur Version : 0.2.1 Upstream Author : Kevin Glisson * URL : https://github.com/Netflix/lemur * License : Apache-2.0 Programming Lang: Python Description : TLS certification manager Lemur [1] is a cert manager which helps to create and track certs. It acts as a broker between certification authorities and internal deployment tools, which uses templates for common use cases. Lemur is written in Python as a application. Currently, plugins for issuing certificates from Verisign/Symantec and for deployment certs into Amazon Web Services are included, but they are more to come. The binary is going to have the same name. DS [1] http://lemur.readthedocs.org/en/latest/index.html 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 LPI certified Linux admin (LPI000329859 64mz6f7kt4) http://www.danielstender.com/blog/
Re: Vale, Ian Murdock (1973-04-28 ??? 2015-12-28)
Bradley M. Kuhn published an eloquent and elegaic 'Requiem for Ian Murdock' on his blog at http://ebb.org/bkuhn/blog/2015/12/30/ian-murdock.html. As it is CC BY-SA 3.0 US licensed, I'm posting it here. Requiem for Ian Murdock Wednesday 30 December 2015 by Bradley M. Kuhn I first met Ian Murdock gathered around a table at some bar, somewhere, after some conference in the late 1990s. Progeny Linux Systems's founding was soon to be announced, and Ian had invited a group from the Debian BoF along to hear about “something interesting”; the post-BoF meetup was actually a briefing on his plans for Progeny. Many of the details (such as which conference and where on the planet it was), I've forgotten, but I've never forgotten Ian gathering us around, bending my ear to hear in the loud bar, and getting one of my first insider scoops on something big that was about to happen in Free Software. Ian was truly famous in my world; I felt like I'd won the jackpot of meeting a rock star. More recently, I gave a keynote at DebConf this year[1] and talked about how long I've used Debian and how much it has meant to me. I've since then talked with many people about how the Debian community is rapidly becoming a unicorn among Free Software projects — one of the last true community-driven, non-commercial projects. A culture like that needs a huge group to rise to fruition, and there are no specific actions that can ensure creation of a multi-generational project like Debian. But, there are lots of ways to make the wrong decisions early. As near as I can tell, Ian artfully avoided the project-ending mistakes; he made the early decisions right. Ian cared about Free Software and wanted to make something useful for the community. He teamed up with (for a time in Debian's earliest history[2]) the FSF to help Debian in its non-profit connections and roots. And, when the time came, he did what all great leaders do: he stepped aside and let a democratic structure form.[3] He paved the way for the creation of Debian's strong Constitutional and democratic governance. Debian has had many great leaders in its long history, but Ian was (effectively) the first DPL, and he _chose_ not to be a BDFL. The Free Software community remains relatively young. Thus, loss of our community members jar us in the manner that uniquely unsettles the young. In other words, anyone we lose now, as we've lost Ian this week, has died too young. It's a cliché to say, but I say anyway that we should remind ourselves to engage with those around us every day, and to welcome new people gladly. When Ian invited me around that table, I was truly nobody: he'd never met me before — indeed no one in the Free Software community knew who I was then. Yet, the mere fact that I stayed late at a conference to attend the Debian BoF was enough for him — enough for him to even invite me to hear the secret plans of his new company. Ian's trust — his welcoming nature — remains for me unforgettable. I hope to watch that nature flourish in our community for the remainder of all our lives. [1] http://ebb.org/blog/2015/aug/17/debian/ [2] https://www.debian.org/doc/manuals/project-history/ch-intro.en.html#s1.1 [3] http://www.linuxplanet.com/linuxplanet/editorials/4959/1 RM note: Brad also invites comment at https://identi.ca/bkuhn/note/EXXzcb0hT6Ob43gOcYaQYA
RE: Debian name change
Please do not get ANY conclusions before we _know_ for real if he wrote any of that, or not, and if he was on his own mind or not when writing. Just wait. er Envite Enviado de Samsung Mobile Mensaje original De: Jihadi Jermane Fecha:31/12/2015 19:12 (GMT+00:00) Para: debian-devel@lists.debian.org Asunto: Debian name change As you may know you posted on you blog about the recent passing of our beloved Ian Murdock, by completely slandering his name, and the debian image. As a black American I find it thoroughly racist that you would even insist that changing the name to Euphemia is a good option. Euphemia is in no way relevant to the debian project no matter what excuse you come up with. Please do not try to include blacks in a project that has nothing to do with them. Signed Jermane King.
Bug#809542: ITP: python-bond -- transparent remote/recursive evaluation between Python and other languages
Package: wnpp Severity: wishlist Owner: "Yuri D'Elia" * Package name: python-bond Version : 1.4 Upstream Author : Yuri D'Elia * URL : http://www.thregr.org/~wavexx/software/python-bond/ * License : GPL-2+ Programming Lang: Python Description : transparent remote/recursive evaluation between Python and other languages The Python module ``bond`` supports transparent remote/recursive evaluation between Python and another interpreter through automatic call serialization. In poorer words, a ``bond`` lets you call functions in other languages as they were normal Python functions. It *also* allows other languages to *call Python functions* as if they were native. Remote output is also transparently redirected locally, and since the evaluation is performed through a persistent co-process, you can actually spawn interpreters on different hosts through "ssh" efficiently. -- I'm the author. 'bond' has been available on pypi since 2014 and 1.4 is the latest stable release, which is used heavily and deployed on debian systems in my current workplace. I'm trying to increase availability through an official debian package.
Re: What is the correct way to set owner to package's files?
Hi!
On Wed, 2015-12-30 at 16:46:23 +0300, Konstantin Khomoutov wrote:
> Two caveats:
>
> 1) Be aware that a user "foo" on your build system might have different
>UID than the user "foo" on the customer's system, and files' metadata
>has owning user and group recorded as a pair of integers -- UID and
>GID, respectively.
The deb(5) format stores the file attributes as part of the tar archive,
which records both numeric ids and their string representation. The
string names are used if the system knows about those names, otherwise
dpkg will gracefully fallback to use the numeric ids.
>IOW, these integers are not portable across systems (unless user
>and group database is in LDAP or NIS or otherwise centralized and
>shared by these systems), and you have to make sure that when your
>package is unpacked to the target filesystem, the UIDs and GIDs on
>its files belong to the user they should.
Actually, you'd just need to make sure the user and group names exist
before the package gets extracted. You can do that in the preinst.
> 2) Newer Debian packaging often uses a generic helper sequencer, `dh`,
>wich is able to reduce debian/rules to a mere couple of lines.
> If this does not work (with the point (1) above being especially
> problematic, IMO), you might have better luck with post-installation
> fixup of the permissions. The idea is that the list of files a package
> contains is located in /var/lib/dpkg/info/{packagename}.list file,
> so in your postinst script (maybe even in preinst -- after the package
> is unpacked -- I can't remember the exact details, please refer to the
> Debian policy which explains all these things) you should be able to
> read this file and feed it to something fixing up permissions, like
>
> xargs -n 30 chmod foo:foo \
>< /var/lib/dpkg/info/{packagename}.list
The dpkg database is supposed to be private and an internal
implementation detail. There's a perfectly usable public interface for
this: «dpkg-query -L», please use that instead.
But in any case I think this is a bad idea, as it will stomp over
dpkg-statoverride(1)s.
> provided your script first called `useradd` to add that user and/or may
> be first verified it already exists via calls to `getent passwd foo`
> and `getent group foo` etc.
Depending on the usage you might want to use adduser instead. But then,
if you use it in preinst you'll need a Pre-Depends.
Thanks,
Guillem
Work-needing packages report for Jan 1, 2016
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 704 (new: 8) Total number of packages offered up for adoption: 171 (new: 2) Total number of packages requested help for: 49 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: dangen (#809543), orphaned today Installations reported by Popcon: 114 hashalot (#809257), orphaned 3 days ago Installations reported by Popcon: 165 imms (#809233), orphaned 3 days ago Description: Unobtrusive, automatic, and learning XMMS playlist manager Reverse Depends: imms-audacious Installations reported by Popcon: 64 mathomatic (#809189), orphaned 3 days ago Description: portable Computer Algebra System (CAS) Reverse Depends: mathomatic-primes Installations reported by Popcon: 494 nield (#809162), orphaned 4 days ago Description: generate logs related to network interfaces Installations reported by Popcon: 15 ocrad (#809544), orphaned today Reverse Depends: fuzzyocr ocrfeeder ogmrip Installations reported by Popcon: 1638 rrdcollect (#809235), orphaned 3 days ago Description: Round-Robin-Database Collecting Daemon Reverse Depends: rrdcollect-dbg Installations reported by Popcon: 93 v86d (#809062), orphaned 5 days ago Description: daemon to run x86 code in an emulated environment Installations reported by Popcon: 525 696 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: monkeystudio (#809109), offered 4 days ago Description: Qt 4 Integrated Development Environment (IDE) Reverse Depends: monkeystudio monkeystudio-dbg Installations reported by Popcon: 128 scilab-plotlib (#809073), offered 5 days ago Installations reported by Popcon: 374 169 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apt-xapian-index (#567955), requested 2159 days ago Description: maintenance tools for a Xapian index of Debian packages Reverse Depends: goplay muon muon-discover packagesearch Installations reported by Popcon: 45437 athcool (#278442), requested 4083 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 33 awstats (#755797), requested 526 days ago Description: powerful and featureful web server log analyzer Installations reported by Popcon: 4153 balsa (#642906), requested 1558 days ago Description: An e-mail client for GNOME Reverse Depends: balsa-dbg Installations reported by Popcon: 711 cardstories (#624100), requested 1711 days ago Description: Find out a card using a sentence made up by another player Installations reported by Popcon: 6 cups (#532097), requested 2399 days ago Description: Common UNIX Printing System Reverse Depends: bluez-cups boomaga chromium cinnamon-settings-daemon cloudprint cups cups-backend-bjnp cups-browsed cups-bsd cups-client (66 more omitted) Installations reported by Popcon: 159297 cyrus-sasl2 (#799864), requested 99 days ago Description: authentication abstraction library Reverse Depends: 389-admin 389-ds-base 389-ds-base-libs 389-dsgw adcli autofs-ldap cairo-dock-mail-plug-in claws-mail claws-mail-acpi-notifier claws-mail-address-keeper (124 more omitted) Installations reported by Popcon: 182923 debtags (#567954), requested 2159 days ago Description: Enables support for package tags Reverse Depends: goplay packagesearch Installations reported by Popcon: 2081 developers-reference (#759995), requested 488 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 17858 devscripts (#800413), requested 93 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero bzr-builddeb customdeb debci debian-builder debmake debpear (27 more omitted) Installations reported by Popcon: 12899 ejabberd (#767874), requested 423 days ago Description: distributed, fault-tolerant Jabber/XMPP server written in Erlang Reverse Depends: ejabberd-contrib ejabberd-mod-cron ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mo
Bug#694308: non-DFSG postscript embedded in fontforge
On Mon, 28 Dec 2015 13:55:48 +0100 Bastien ROUCARIES wrote: >If it is GPL-2+ it is not a problem but a few fonts file are released >under GPL-2 only... It is quite a mess. Yes... The best way to solve it is re-license those snippets to more permissive license like BSD-3-clause or MIT by Adobe, but it costs for them. >> And, how can I think about fontforge copies snippet to generate those >> *.pfb files? > >Could you modify comment on this code to add some fontforge comment ? >Like for instance "inserted by fontforge (debian someversion)". I >could teach lintian to check if font are regenerated. >What do you think? Probably I can, but is it necessary? Re-licensed to Apache-2.0 code is exactly same as previous proprietary one, no changes. Just treat it as DFSG-free code is enough, isn't it? -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane
Re: Renaming the Debian Project
I love it that trolls have the same freedom of speech to spew their crap that I have to defend against it. I mourn Ian's loss. I respect his right to choose his words. I VOW to SUPPORT the DEBIAN concept, distribution, and works. There's no racism here. Nor is there any room for trolls. FUCK political correctness. Ehud Tucson AZ US
Re: support for merged /usr in Debian
On 30 December 2015 at 22:51, Marco d'Itri wrote: > We have a reasonably tested usrmerge package which can be used to > convert on the fly a system to merged /usr, and the good news is that > there are only three packages which need to be fixed to work on a merged > /usr system. > > Thanks to my conversion program in usrmerge there is no need for a flag > day, archive rebuilds or similar complexity and we can even continue to > support unmerged systems. > > I welcome your comments, but if you have any questions then please read > the FAQ first: > https://wiki.debian.org/UsrMerge > https://anonscm.debian.org/cgit/users/md/usrmerge.git/plain/debian/README.Debian > > If you want to help then please have a look at the open bugs linked on > wiki.d.o about lintian and policy work. > > -- > ciao, > Marco The "solution" proposed here: https://wiki.debian.org/UsrMerge just stinks. Please, make sure this thing remains an option, never the default. Happy new year!
