Bug#734040: ITP: flask-migrate -- SQLAlchemy database migrations for Flask applications using Alembic
Package: wnpp Severity: wishlist Owner: Thomas Bechtold * Package name: flask-migrate Version : 1.1.0 Upstream Author : Miguel Grinberg * URL : https://github.com/miguelgrinberg/flask-migrate/ * License : MIT Programming Lang: Python Description : SQLAlchemy database migrations for Flask applications using Alembic Flask-Migrate is an extension that handles SQLAlchemy database migrations for Flask applications using Alembic. The database operations are provided as command line arguments for Flask-Script. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103094405.18914.49051.reportbug@steinpilz
Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to remove "XS-" ?
On Fri, Dec 27, 2013 at 06:09:51PM +0100, Niels Thykier wrote: > On 2013-12-27 17:35, Guillem Jover wrote: > > Do you know how many packages are there with autopkgtest support, > > and how many do not declare the field? > > For the former, apt-file search -a source debian/tests/control should > do[0]. For the latter, there is a lintian check finds packages with > without the field (or with the field, but without tests)[1]. To save others the time of doing this, in attachment the results of checking for debian/tests/control with apt-file and of grep-dctrl'ing Sources to check for "Testsuite: autopkgtest" field entry. I've computed them on unstable and experimental, considering main, contrib, and non-free. The relevant numbers are as follows: zack@usha:~$ wc -l have-* 251 have-debian-tests-control.txt 189 have-testsuite-autopkgtest.txt 64 have-debian-tests-control-but-no-testsuite-autopkgtest.txt For the latter file I also attach a dd-list. If you find mistakes in the results, please shout. FWIW, an old MBF about absent "Testsuite: autopkgtest" is at [1] and looks halfway through completion. Some of the already resolved issues were initially marked wontfix, but have then been corrected. Most of the remaining bugs seem to be affecting zope-related packages and other zope packages have been fixed already. Cheers. [1]: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=missing-testsuite-header;users=autopkgtest-de...@lists.alioth.debian.org -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » Adam Schmalhofer apipkg execnet pytest-xdist Alessio Treglia apt-clone (U) Alexander Neumann task Antonio Terceiro rake (U) ruby-switch (U) Arnaud Fontaine python-mechanize (U) zc.buildout (U) zope.testbrowser (U) Barry Warsaw tox Bradley Smith delta Brian Sutherland bobo (U) python-chameleon (U) python-mechanize (U) sourcecodegen (U) transaction (U) zc.buildout (U) zc.lockfile (U) zconfig (U) zdaemon (U) zodb (U) zope.authentication (U) zope.browser (U) zope.cachedescriptors (U) zope.configuration (U) zope.contenttype (U) zope.copy (U) zope.dottedname (U) zope.event (U) zope.hookable (U) zope.i18n (U) zope.i18nmessageid (U) zope.location (U) zope.proxy (U) zope.publisher (U) zope.schema (U) zope.security (U) zope.sendmail (U) zope.sqlalchemy (U) zope.testbrowser (U) zope.testing (U) zope.traversing (U) Christian Perrier samba4 (U) Christoph Berg postgresql-common (U) Clint Adams haskell-yesod (U) D Haley libstxxl (U) D Haley libstxxl (U) Debian Bazaar Maintainers bzr-rewrite bzr-stats bzr-svn Debian Haskell Group haskell-yesod Debian PostgreSQL Maintainers postgresql-common Debian Python Modules Team gamera (U) pyqt5 python-byteplay (U) Debian Ruby Extras Maintainers rake ruby-switch Debian Science Maintainers libstxxl Debian/Ubuntu Zope Team bobo python-chameleon python-mechanize sourcecodegen transaction zc.buildout zc.lockfile zconfig zdaemon zodb zope.authentication zope.browser zope.cachedescriptors zope.configuration zope.contenttype zope.copy zope.deprecation zope.dottedname zope.event zope.hookable zope.i18n zope.i18nmessageid zope.location zope.proxy zope.publisher zope.schema zope.security zope.sendmail zope.sqlalchemy zope.testbrowser zope.testing zope.traversing Dmitry Shachnev pyqt5 (U) Fabio Tranchitella bobo (U) python-chameleon (U) python-mechanize (U) sourcecodegen (U) transaction (U) zc.buildout (U) zc.lockfile (U) zconfig (U) zdaemon (U) zodb (U) zope.authentication (U) zope.browser (U) zope.cachedescriptors (U) zope.configuration (U) zope.contenttype (U) zope.copy (U) zope.dottedname (U) zope.event (U) zope.hookable (U) zope.i18n (U) zope.i18nmessageid (U) zope.location (U) zope.proxy (U) zope.publisher (U) zope.schema (U) zope.security (U) zope.sqlalchemy (U) zope.testbrowser (U) zope.testing (U) zope.traversing (U) Holger Levsen munin (U) Ian Jackson dgit Jakub Wilk cuneiform dawgdic delta gamera libb64 python-byteplay task Jelmer Vernooij bzr-rewrite (U) bzr-svn (U) python-fastimport samba4 (U) Jérémy Bobbio python-mechanize (U) Koichi Akabe bzr-stats (U) Martin Pitt postgresql-common (U) udisks (U) Matthias Klose python-mechanize (U) zope.dottedname (U) zope.testing (U) Michael Biebl udisks (U) Michael Vogt apt-clone Munin Debian Maintainers munin Nicolas B
[RFH] !!SOS!! totally hosed init system
Hi *, after a dist-upgrade, my sid system wouldn’t boot at all any more: no network (because udev didn’t rename eth1 to eth0), read-only filesystem, I was dumped into a root shell after being asked for the root password, but by then the filesystem was read-write. I was running file-rc and decided to revert to sysv-rc. Bad idea, now I had /etc/rc2.d/S01sendsigs and /etc/rc2.d/S24single – you can imagine this was not any better. I blame 3dab3d4d3e911c779a3d6c998b20609053dd5b88 in collab-maint/sysvinit for this. I installed upstart. Now I had network, at least, and *some* services would start, and I could login on tty2. I had to purge then dpkg -i initscripts, though. But things like kdm, openvpn, BOINC, etc. still won't start. tglase@tglase:~ $ ll /etc/*/*boinc* -rw-r--r-- 1 root root 2603 Jun 7 2013 /etc/bash_completion.d/boinc -rw-r--r-- 1 root root 2490 Jun 7 2013 /etc/default/boinc-client -rwxr-xr-x 1 root root 7673 Jun 7 2013 /etc/init.d/boinc-client* lrwxrwxrwx 1 root root 22 Jan 3 10:00 /etc/rc0.d/K01boinc-client -> ../init.d/boinc-client* lrwxrwxrwx 1 root root 22 Jan 3 10:00 /etc/rc1.d/K01boinc-client -> ../init.d/boinc-client* lrwxrwxrwx 1 root root 22 Jan 3 11:07 /etc/rc2.d/S09boinc-client -> ../init.d/boinc-client* lrwxrwxrwx 1 root root 22 Jan 3 11:07 /etc/rc3.d/S09boinc-client -> ../init.d/boinc-client* lrwxrwxrwx 1 root root 22 Jan 3 11:07 /etc/rc4.d/S09boinc-client -> ../init.d/boinc-client* lrwxrwxrwx 1 root root 22 Jan 3 11:07 /etc/rc5.d/S09boinc-client -> ../init.d/boinc-client* lrwxrwxrwx 1 root root 22 Jan 3 10:00 /etc/rc6.d/K01boinc-client -> ../init.d/boinc-client* Now, question to both sysvinit/sysv-rc and upstart people: how do I “un-hose” this system? I need this for $dayjob, and I can’t even run Kontact because Akonadi won’t start (and I need the PIM functionality from it). And: why did this happen in the first place? PS: Broken lines courtesy of GMane.org and, please Cc me. Thanks in advance, //mirabilos -- 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/loom.20140103t111541-...@post.gmane.org
Re: [RFH] !!SOS!! totally hosed init system
Hi Thorsten, Le vendredi 03 janvier 2014 à 10:20 +, Thorsten Glaser a écrit : > I was running file-rc > And: why did this happen in the first place? I think you answered to that question yourself. PS: and you keep wondering why people want to change anything to our s well working init system… _o/ -- .''`.Josselin Mouette : :' : `. `' `- -- 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/1388745422.7783.833.camel@dsp0698014
Re: Registering a media type for Debian binary packages ?
Hi Charles! On Fri, 2014-01-03 at 10:42:09 +0900, Charles Plessy wrote: > Le Mon, Dec 30, 2013 at 02:23:00AM +0100, Guillem Jover a écrit : > > This sounds great in theory, but I'm worried that in practice this > > might just make the situation worse, by making applications having > > to support not two, but three media types for undetermined periods > > of time? > > > > OTOH, this might make it clearer for developers, what's the proper > > media type to use, so I will note down to possibly prepare a draft > > for this in the coming weeks, if it ends up making sense to do it. > I could not help giving it a try. What do you think of the following ? > (see http://www.iana.org/form/media-types for background). For local-only applications a transition to this new mime type can be done pretty fast, as long as the local database has been updated, not so for any application handling remote files, because they depend on the information sent from the server, and there's really no timeframe as when they will be able to drop support for the deprecated types. So my question still stands though, is it really worth it? Does the IANA recommend actively switching legacy types, or just discourages creating them anew? In any case here's some comments on the draft: > Type name: > application > > Subtype name: > vnd.debian.binary-package > > Required parameters: > None. > > Optional parameters: > None. > > Encoding considerations: > binary > > Security considerations: > > Debian binary packages can contain arbitrary commands that will be executed Maybe state that these are “scripts containing arbitrary commands”, so that further down it's a bit more clear that those are not required to extract the package for inspection, for example? > with administrator privileges during installation. It is therefore essential > to trust the origin of the package. The recommended way is to download > packages from APT (Advanced Packaging Tool) archives that are authenticated > with > a trusted cryptographic key (see the manual page of apt-secure for details). > As a lesser alternative for cases where APT tools are not available, the > package should be downloaded with secured protocols such as HTTPS. There also > exists a mechanism for signing packages directly (called ‘debsigs’), but it is > not deployed. Could this be made generic as to not recommend a specific frontend implementation, but just what's needed from it? Some systems do not use apt, some users might want to use something else, etc. But maybe that's not how other mime type entries are written? > The contents of the Debian binary packages are compressed (see the ‘deb’ > manual > page for details on the format); it is therefore possible to inspect them > without actually install the package. An estimate of the uncompressed size of > the package may be available in its ‘control’ file, but it can only be trusted > if the package itself is trusted. One of the important points of the format is that it should be extractable with “common UNIX tools”, so maybe specify this in passing, how about something like: The contents of the Debian binary packages are placed inside tarballs (possibly compressed) wrapped in an ar archive (see …); it is therefore possible to inspect them with standard UNIX tools (although the recommended way is through ‘dpkg-deb’) without actually installing the package. > Since the Debian packages vehiculate programs to be installed on a computer, > the monitoring of a user's downloads over non-secured transport protocols such > as HTTP or FTP may reveal information pertaining to the user's privacy, or > suggest information related to the system's security such as the precise > version numbers of programs in use. > > Interoperability considerations: > > Arbitrary Debian binary packages can be installed on any system where the > ‘dpkg’ package manager is used, but it is recommended to only install packages > that have been built for a given release of Debian or a Debian derivative. I don't think it'd be appropriate to make this Debian specific, .debs and dpkg are used in many distributions, some not even Debian derived. How about: … but it is recommended to only install packages that have been built for a release matching the distribution installed on the system. (maybe s/installed/running/ to avoid duplication?) > Published specification: > http://manpages.debian.org/deb Unfortunately this does not seem to contain the latest version. Maybe I could place one under http://dpkg.alioth.debian.org/, or maybe even better, try to resuscitate the (fractal) dpkg.org domain and place it there. > Applications that use this media type: > > The Debian binary packages are manipulated by system programs such as ‘dpkg’, > ‘apt-get’, graphical front-ends such as ’Synaptic’ but also generic archive > decompressors such as ‘File Roller’. After downloading a package with a web > browser or after clicking on its icon, front-ends or de
Re: Removing packages from unofficial repositories
Hi all, I recently decided to migrate my Debian system away from deb-multimedia.org, where official packages exist. I used apt preferences to help me downgrade packages from deb-multimedia back to Debian testing, where an alternative version from testing exists. However, I would expect that most users would not have the patience to do this via apt preferences, and if there is an easier way, I was not aware of it. AFAIK the apt_preferences method is rather simple: Package: * Pin: release o=Debian Pin-Priority: 1001 With that setting 'apt-get dist-upgrade' downgrades DMO packages to official ones. At least it did in my case. For me, finding out the correct preference setting was the hardest part here :) -- With best regards, Vitaliy Filippov -- 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/op.w83z22x6xpoh24@vitalif.vhome
Re: Removing packages from unofficial repositories
On 01/03/2014 07:41 AM, Виталий Филиппов wrote: > AFAIK the apt_preferences method is rather simple: > > Package: * > Pin: release o=Debian > Pin-Priority: 1001 > > With that setting 'apt-get dist-upgrade' downgrades DMO packages to > official ones. At least it did in my case. > > For me, finding out the correct preference setting was the hardest part > here :) Yes, but it's an unsafe operation, since downgrades are still not supported, and also does not discriminate between DMO packages and non-DMO packages, so this could break unrelated packages. Ben -- 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/52c6a8c2.6000...@sanctuary.nslug.ns.ca
Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to remove "XS-" ?
Hi Jakub! On Fri, 2013-12-27 at 17:35:28 +0100, Guillem Jover wrote: > On Fri, 2013-12-27 at 17:41:26 +0900, Charles Plessy wrote: > > the use of autopkgtest as documented in DEP 8 is taking momentum. > > > > How about allowing a "Testsuite" field to replace the "XS-Testsuite" field? > > Last time this came up here, it didn't look like we got consensus on > whether the field was needed at all. Do you know how many packages > are there with autopkgtest support, and how many do not declare the > field? Given that you (at least) seemed to show opposition to the field (AFAIR), and that you've done an independent implementation of the runner; does 692704 mean that you changed mind? If so, I can change dpkg-dev for 1.17.6 to recognize the field. Thanks, Guillem -- 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/20140103121310.ga5...@gaara.hadrons.org
Re: Registering a media type for Debian binary packages ?
Guillem Jover writes ("Re: Registering a media type for Debian binary packages
?"):
> On Fri, 2014-01-03 at 10:42:09 +0900, Charles Plessy wrote:
> > Magic number(s):
> > Files usually start with the following string:
> > !
>
> This is not enough, this just marks any ar archive, the distinguishing
> magic for a .deb is the debian-binary ar member.
Conveniently, the exact format of this is constant and appears at the
start of the file. A .deb file[1] starts with "!\ndebian-binary".
[1] Strictly speaking I'm talking about the version 2.0 .debs that we
are all using nowadays.
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21190.44665.512477.310...@chiark.greenend.org.uk
Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to remove "XS-" ?
Stefano Zacchiroli writes ("Re: [DEP 8] About "XS-Testsuite: autopkgtest": time
to remove "XS-" ?"):
> To save others the time of doing this, in attachment the results of
> checking for debian/tests/control with apt-file and of grep-dctrl'ing
> Sources to check for "Testsuite: autopkgtest" field entry. I've computed
> them on unstable and experimental, considering main, contrib, and
> non-free. The relevant numbers are as follows:
I see I myself am on this list. Oops.
> FWIW, an old MBF about absent "Testsuite: autopkgtest" is at [1] and
> looks halfway through completion. Some of the already resolved issues
> were initially marked wontfix, but have then been corrected. Most of the
> remaining bugs seem to be affecting zope-related packages and other zope
> packages have been fixed already.
Perhaps rather than having another MBF, a better approach would be a
lintian warning ?
Ian.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/21190.44758.927676.766...@chiark.greenend.org.uk
Re: [RFH] !!SOS!! totally hosed init system
On Fri, Jan 03, 2014 at 10:20:57AM +, Thorsten Glaser wrote: > after a dist-upgrade, my sid system wouldn’t boot at all any more: no > network (because udev didn’t rename eth1 to eth0), read-only filesystem, > I was dumped into a root shell after being asked for the root password, > but by then the filesystem was read-write. > > I was running file-rc and decided to revert to sysv-rc. Bad idea, now > I had /etc/rc2.d/S01sendsigs and /etc/rc2.d/S24single – you can imagine > this was not any better. I blame 3dab3d4d3e911c779a3d6c998b20609053dd5b88 > in collab-maint/sysvinit for this. > Now, question to both sysvinit/sysv-rc and upstart people: > how do I “un-hose” this system? I need this for $dayjob, and > I can’t even run Kontact because Akonadi won’t start (and I > need the PIM functionality from it). Did you try running insserv by hand to restore the links? Did the maintainer scripts restore any of the links for you? > And: why did this happen in the first place? If you're referring to the commit above, it's because we've fully transitioned to dependency-based boot for wheezy, so the hardcoded runlevel ordering isn't used any more (at all), even for file-rc. Note that file-rc was also updated to use insserv, so it too was also using dynamic ordering. So the above removal should have had zero effect upon use of either system--both systems were already using the "defaults" option implicitly. The real problem here is probably that the maintainer scripts for handling the transition between the file-rc and sysv-rc systems may not be doing their job robustly. It should be possible for it to transition seamlessly between the two since they are just describing the same stuff in a different way. This is probably a bug in the file-rc prerm/postrm and/or the sysv-rc preinst/postinst. IIRC file-rc should restore the sysv-rc links and sysv-rc should make sure insserv is run again. If any file-rc users could investigate this in more detail, that would be much appreciated. I thought this was all working for wheezy from my own testing of it in VMs, but I'm not a file-rc user, and there may be cases where the configuration isn't being migrated. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [RFH] !!SOS!! totally hosed init system
On Fri, 3 Jan 2014, Josselin Mouette wrote: > Le vendredi 03 janvier 2014 à 10:20 +, Thorsten Glaser a écrit : > > I was running file-rc > > > And: why did this happen in the first place? > > I think you answered to that question yourself. Yes, with a simple BSD-style /etc/rc script this would not have happened: no runlevels, no symlinks, no dependency hell, etc. > PS: and you keep wondering why people want to change anything to our > s well working init system… Someone broke the setup. This happens with any system. I just can’t figure it out because, thanks to insserv, even with file-rc it became too complex to fix. And: please do not respond to eMails from me any more. Thanks, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- 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/alpine.deb.2.10.1401031410350.3...@tglase.lan.tarent.de
Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to remove "XS-" ?
[ adding autopkgtest-devel to Cc: ] On Fri, Jan 03, 2014 at 12:36:38PM +, Ian Jackson wrote: > > FWIW, an old MBF about absent "Testsuite: autopkgtest" is at [1] and > > looks halfway through completion. Some of the already resolved issues > > were initially marked wontfix, but have then been corrected. Most of the > > remaining bugs seem to be affecting zope-related packages and other zope > > packages have been fixed already. > > Perhaps rather than having another MBF, a better approach would be a > lintian warning ? Lintian is already aware of this, as mentioned by Niels: http://lintian.debian.org/tags/inconsistent-testsuite-field.html but the tag is currently not a warning. Did you mean to suggest that we ask the lintian maintainers to promote that tag to an actual warning? FWIW, I'd welcome that. Regarding the MBF, I didn't mean to propose another one. I was merely pointing to the old one to observe its evolution over time. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: porting OpenRC on kFreeBSD and Hurd
On Thu, 2013-11-14 at 01:49 +0800, Thomas Goirand wrote: > After rebuilding ifupdown, sysvinit, udev and openssh, I could install > OpenRC normally, as I was used to. Hoping that source-full uploads will > happen before I fix the /sbin/rc issue, otherwise I'll ask for BINnmu. How come OpenRC is still not available? -- 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/1388755374.27169.23.ca...@g3620.my.own.domain
Re: [RFH] !!SOS!! totally hosed init system
On 01/03/2014 02:11 PM, Thorsten Glaser wrote: > Someone broke the setup. This happens with any system. > I just can’t figure it out because, thanks to insserv, > even with file-rc it became too complex to fix. I actually agree with Joss, here, sorry. And going back to the 80ies isn't really what most people want. Dependencies are necessary to suit the needs for various setups like servers, desktops, tablets, notebooks and so on. > And: please do not respond to eMails from me any more. Come on, no need to be huffy here. Joss really has a point. I guess he could have said it more politely, but I think a bit of schadenfreude from his side isn't too bad. At least you get the idea now why people are arguing over this issue. Just imagine now something like this happens to a home NFS server in a company department with 1200 users. They'd be flooding the IT hotline in no time and yes, I have experienced that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- 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/52c6bd5a.1080...@physik.fu-berlin.de
Re: [RFH] !!SOS!! totally hosed init system
Roger Leigh codelibre.net> writes: > Did you try running insserv by hand to restore the links? Did > the maintainer scripts restore any of the links for you? I’ve tried both (unsure if what I tried was right; dpkg-reconfigure initscripts and insserv with most combinations of -d, -f, the name of an initscript with or without /etc/init.d/ before, or just the directory), but all I got was those /etc/rc2.d/S24single etc. links since insserv happily ignored the LSB Default-Start header. Once I installed upstart, purged and dpkg-i’d initscripts, I’ve had the links “mostly” in the right places, but now still, half of the init scripts are called and the other half aren’t. (Also, having had few exposure to upstart before, I’m even less sure how much it uses /etc/rc*.d/ for operation.) For example, openvpn, kdm and boinc were missing but ssh was started. > > And: why did this happen in the first place? > > If you're referring to the commit above, it's because we've fully > transitioned to dependency-based boot for wheezy, so the hardcoded > runlevel ordering isn't used any more (at all), even for file-rc. > Note that file-rc was also updated to use insserv, so it too was > also using dynamic ordering. So the above removal should have had > zero effect upon use of either system--both systems were already > using the "defaults" option implicitly. Right, but “defaults” translates to “start 2345 stop 06” here, happily ignoring the LSB header. I didn’t actually refer to that commit though, but to the why did a working file-rc setup suddenly become unbootable like that issue. Unfortunately, I didn’t have bootlogd installed at first, but later when I did install it, it only wrote to /var/log/boot once, and then never again (I’ve had a dozen boots or so today). (Oh goodies. Now /var/log/boot doesn’t even exist, and boot.log is 0 bytes still.) > The real problem here is probably that the maintainer scripts for > handling the transition between the file-rc and sysv-rc systems > may not be doing their job robustly. This may be the issues I’ve seen _after_ switching from file-rc back to sysv-rc, yes. But the other issues (filesystems readonly, /dev/net/tun ENOENT, eth1 not renamed, etc.) were common to both of them; most (but not all) of those went away with upstart though… > and sysv-rc should make sure insserv is run again. If any insserv was run again but spewed lots of warnings about invalid dependencies, and about ignoring the "Default-Start: S" value for eg. the single script in favour of the "2 3 4 5" it installed. > be much appreciated. I thought this was all working for wheezy I think it was working for wheezy, yes. Anyway, is there a way to tell update-rc.d or insserv or whatever to just ignore the existing /etc/rc*.d/ structure completely and build a new one just from the LSB headers? (Also, how much of it do I need for upstart? I could probably switch back to sysvinit, too – if things will work there again.) Thanks already, //mirabilos PS: @Adrian: I just do not want to be replied to by Joss, no matter what, totally unrelated to this. -- 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/loom.20140103t144803-...@post.gmane.org
Re: [RFH] !!SOS!! totally hosed init system
On Fri, Jan 03, 2014 at 01:57:00PM +, Thorsten Glaser wrote: > Roger Leigh codelibre.net> writes: > > > If you're referring to the commit above, it's because we've fully > > transitioned to dependency-based boot for wheezy, so the hardcoded > > runlevel ordering isn't used any more (at all), even for file-rc. > > Note that file-rc was also updated to use insserv, so it too was > > also using dynamic ordering. So the above removal should have had > > zero effect upon use of either system--both systems were already > > using the "defaults" option implicitly. > > Right, but “defaults” translates to “start 2345 stop 06” here, > happily ignoring the LSB header. If file-rc and/or the maintainer scripts somehow restored the links incorrectly, then insserv will ignore the header and preserve your customisations (not the link ordering, but the runlevels to start and stop in). This would certainly be the cause of all the warnings you see. If you set them this way in your file-rc config, it may be simply preserving your state? If anything is assuming defaults means "start 2345 stop 06" and ignores the LSB header, then that's an RC bug I think. I can't see such behaviour looking with a quick grep in either sysv-rc or file-rc. If you can identify what caused that, it would be very useful. We do need to start looking at migration from file-rc to $replacement after the tech-ctte decides. If sysvinit will remain supported in jessie, then ensuring a clean migration to sysv-rc may be sufficient. But keeping it going via insserv for wheezy was a step too far maybe-- it would have been desirable to have dropped it for wheezy. Anyway, we need to sort out a transition in the near future in any case. > > The real problem here is probably that the maintainer scripts for > > handling the transition between the file-rc and sysv-rc systems > > may not be doing their job robustly. > > This may be the issues I’ve seen _after_ switching from file-rc > back to sysv-rc, yes. > > But the other issues (filesystems readonly, /dev/net/tun ENOENT, > eth1 not renamed, etc.) were common to both of them; most (but > not all) of those went away with upstart though… I can't comment on the upstart side, let's not overcomplicate with a third system ;) These sound like separate issues to the file-rc → sysv-rc switch; if so, they need investigating independently once you have a standard functional booting system again. > > and sysv-rc should make sure insserv is run again. If any > > insserv was run again but spewed lots of warnings about invalid > dependencies, and about ignoring the "Default-Start: S" value > for eg. the single script in favour of the "2 3 4 5" it installed. > > > be much appreciated. I thought this was all working for wheezy > > I think it was working for wheezy, yes. > > Anyway, is there a way to tell update-rc.d or insserv or whatever > to just ignore the existing /etc/rc*.d/ structure completely and > build a new one just from the LSB headers? (Also, how much of it > do I need for upstart? I could probably switch back to sysvinit, > too – if things will work there again.) "insserv -d" should revert to the defaults. And there's not usually any reason to deviate from them. If not, you could remove the structure entirely and then try re- running "insserv -d" again. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#734075: ITP: astroid -- rebuild a new abstract syntax tree from Python's AST
Package: wnpp Severity: wishlist Owner: Sandro Tosi * Package name: astroid Version : 1.0.0 Upstream Author : Logilab * URL : http://www.astroid.org/ * License : LGPL Programming Lang: Python Description : rebuild a new abstract syntax tree from Python's AST The aim of this module is to provide a common base representation of python source code for projects such as pychecker, pyreverse, pylint... Well, actually the development of this library is essentially governed by pylint's needs. It used to be called logilab-astng. It provides a compatible representation which comes from the `_ast` module. It rebuilds the tree generated by the builtin _ast module by recursively walking down the AST and building an extended ast. The new node classes have additional methods and attributes for different usages. They include some support for static inference and local name scopes. Furthermore, astroid builds partial trees by inspecting living objects. Main modules are: * `bases`, `node_classses` and `scoped_nodes` contain the classes for the different type of nodes of the tree. * the `manager` contains a high level object to get astroid trees from source files and living objects. It maintains a cache of previously constructed tree for quick access. -- 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/20140103142336.26110.95988.report...@oracle.matrix.int
Re: porting OpenRC on kFreeBSD and Hurd
On Fri, Jan 03, 2014 at 02:22:54PM +0100, Svante Signell wrote: > How come OpenRC is still not available? The binary name `rc' was taken by src:rc, so zigo was working with the Gentoo upstream folks on fixing this together, so there'd be little (to no) delta. I very much appreciate how long of a process that can take, and I commend zigo for not just patching around it and re-duputting, even with all this pressure. Cheers, Paul -- .''`. Paul Tagliamonte | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Re: [RFH] !!SOS!! totally hosed init system
On Fri, 03 Jan 2014, Roger Leigh wrote: > If file-rc and/or the maintainer scripts somehow restored the links > incorrectly, then insserv will ignore the header and preserve your > customisations (not the link ordering, but the runlevels to start > and stop in). This would certainly be the cause of all the ... > > Anyway, is there a way to tell update-rc.d or insserv or whatever > > to just ignore the existing /etc/rc*.d/ structure completely and ... > "insserv -d" should revert to the defaults. And there's not usually > any reason to deviate from them. > > If not, you could remove the structure entirely and then try re- > running "insserv -d" again. We really should have an easy way to address "my system is screwed up, please remove the entire sysv-rc admin-configured state and recreate it from the LSB headers and override files, for all initscripts". While something rarely needed, it would help a great deal when it is in fact required... "insserv -d" helps, but apparently it doesn't do the full sysv-rc reset. You'd need to call it for every initscript, at the very least. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103154608.ga20...@khazad-dum.debian.net
Re: Bug#733912: RFP: s6 - a small suite of programs for UNIX, designed to allow process supervision
Control: reassign -1 wnpp On Jo, 02 ian 14, 06:24:40, Sergiusz Pawlowicz wrote: > Package: s6 > Version: 1.1.1 > Severity: wishlist > > Please pack s6[0], a small suite of programs for UNIX, designed > to allow process supervision (a.k.a service supervision), in > the line of daemontools and runit. > > [0] http://skarnet.org/software/s6/ Could you maybe provide more information about this software, like what makes it better than daemontools and runit, etc. Also, the typical ITP/RFP template also requires Author's name and licence under which the software is available. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: Removing packages from unofficial repositories
On 01/03/2014 03:41 AM, Виталий Филиппов wrote: > AFAIK the apt_preferences method is rather simple: > > Package: * > Pin: release o=Debian > Pin-Priority: 1001 > > With that setting 'apt-get dist-upgrade' downgrades DMO packages to > official ones. At least it did in my case. Does it work if you have Debian, deb-multimedia, another third-party repo, and you just want to remove deb-multimedia? Thanks. -- 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/52c6f111.5020...@alvarezp.ods.org
Re: Removing packages from unofficial repositories
Does it work if you have Debian, deb-multimedia, another third-party repo, and you just want to remove deb-multimedia? If you have other 3rdparty repos, you'll also need to set 1001 for all of them (except DMO), that should be enough. And of course strictly speaking it may be unsafe, but I think it's OK in case of debian-multimedia... -- With best regards, Vitaliy Filippov -- 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/op.w84gnznfxpoh24@vitalif.vhome
Re: Bug#733860: ITP: pond -- Forward secure, asynchronous messaging for the discerning.
]] Ximin Luo > Package: wnpp > Severity: wishlist > Owner: Ximin Luo > > * Package name: pond > Version : 0:git~2014-01-01 You might want to use a version number such as 0~20140101+git+$sha1 or similar. 0:git probably isn't even valid as a Debian version number, since : is used for epochs. > So Pond is not email. Pond is forward secure, asynchronous messaging > for the discerning. Pond messages are asynchronous, but are not a > record; they expire automatically a week after they are received. Pond > seeks to prevent leaking traffic information against everyone except a > global passive attacker. Am I understanding it correctly that this is somewhat like sending an encrypted message to a key's fingerprint in a DHT with an expiration tacked on, or is this completely off the mark? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2a9fdarir@rahvafeir.err.no
Re: GnuTLS in Debian
]] Russ Allbery Wildly off-topic, but hey. :-) > Yeah, I saw that also in Bernhard's reply. That confusion had honestly > never occurred to me before since, despite the visual similarities, the > words are completely unrelated in English. The etymologies are disjoint: > idiot comes from French and hence from Latin and dates back to the 1400s, > whereas idiosyncratic has an independent derivation from Greek root words > meaning "mixed together" and has existed independently with roughly its > current meaning since the 1600s. Actually, idiot comes from greek too (from wikipedia): Idiot as a word derived from the Greek ἰδιώτης, idiōtēs («person lacking professional skill», «a private citizen», «individual»), from ἴδιος, idios («private», «one's own»).[1] In Latin the word idiota («ordinary person, layman») preceded the Late Latin meaning «uneducated or ignorant person».[2] Its modern meaning and form dates back to Middle English around the year 1300, from the Old French idiote («uneducated or ignorant person»). The related word idiocy dates to 1487 and may have been analogously modeled on the words prophet[3] and prophecy.[4][5] The word has cognates in many other languages. An idiot in Athenian democracy was someone who was characterized by self-centeredness and concerned almost exclusively with private—as opposed to public—affairs. [...] I think they have the same root too, roughly «individual», which fits well with the definition of idiosyncratic too. > I'm sorry for the confusion for non-native speakers. English has a > bad habit of drawing words from all sorts of different languages and > thus creating a lot of accidental similarities between words that have > no relationship to each other. I don't think you can blame English for ancient Greek being confusing. :-) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m261q1ar1u@rahvafeir.err.no
Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to remove "XS-" ?
* Guillem Jover , 2014-01-03, 13:13: Given that you (at least) seemed to show opposition to the field (AFAIR), and that you've done an independent implementation of the runner; does 692704 mean that you changed mind? No, it just means that I gave up. -- Jakub Wilk -- 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/20140103184054.ga5...@jwilk.net
'tty' output on kFreeBSD, etc. within sbuild
Hi, Can anyone answer the following question which is puzzling me; I have a piece of csh code which gets called during the build of a package i'm maintaining. it does the following: echo "useful information" > /dev/tty within the script. (stdout, stderr being redirected, I think). This fails on kFreeBSD at least, so i've patched it to: set ttyf=`tty` ... echo "useful information" > $ttyf This works on Linux, and on the command line for me on a kFreeBSD machine, but under sbuild I get: $ttyf: Ambiguous. Unable to build Makefile - fix above errors and re-run. Any ideas as to whats happening and what I should do about it? Regards Alastair -- Alastair McKinstry , , http://diaspora.sceal.ie/u/amckinstry Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist.
Re: 'tty' output on kFreeBSD, etc. within sbuild
On Fri, Jan 03, 2014 at 06:51:08PM +, Alastair McKinstry wrote: > Can anyone answer the following question which is puzzling me; > I have a piece of csh code which gets called during the build of a package > i'm maintaining. it does the following: > > echo "useful information" > /dev/tty > > within the script. (stdout, stderr being redirected, I think). > This fails on kFreeBSD at least, so i've patched it to: > > set ttyf=`tty` > > ... > echo "useful information" > $ttyf > > > This works on Linux, and on the command line for me on a kFreeBSD machine, > but under sbuild I get: > > $ttyf: Ambiguous. > Unable to build Makefile - fix above errors and re-run. > > Any ideas as to whats happening and what I should do about it? You aren't guaranteed to have a controlling terminal, particularly when run via buildd. So while stdin/out/err are all connected and functional, they are either null (stdin) or pipes (out/err). If you need to output anything, then just use stdout/err as appropriate and it will be logged, but /dev/tty may well be unavailable. I would recommend not using `tty` or doing any IO on /dev/tty since in all likelihood isatty/ttyname(_r) will most likely return ENOTTY and any IO on /dev/tty will simply fail. We have looked at using ptys in the past for running the builds in order to guarantee a tty, but decided against it. Too many programs make the assumption that they are interactive and freeze the build waiting on IO that never happens and then block forever. There may well have been other considerations I don't recall offhand e.g. relating to job control. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
VLC, video stuttering with ALSA sound output
Hi!
Starting somewhere around VLC 2.x, I experience "video stuttering"
problems on some files, mostly >= 720P, MKV/H.264+AC3, but not only on
such files - for example I also experience it on some of MPEG2 files (mpeg
container, mpeg2 video and audio codecs). HW acceleration is disabled, the
problem always reproduces at least on 2 different Debian machines (laptop
and PC, both 32-bit and both with snd-hda-intel kernel module), and on
both debian-multimedia and normal VLC/libav* packages. The same files play
without problem in mplayer/mplayer2/mpv.
vlc -vvv output shows many "ES_OUT_SET_(GROUP_)PCR is called too late"
errors; on each error the video playback temporarily stops ("stutters").
...
[0x87a0a30] main audio output warning: playback way too early (-563272):
playing silence
[0x87a0a30] main audio output debug: inserting 27037 zeroes
[0xf4c11150] main input error: ES_OUT_SET_(GROUP_)PCR is called too late
(pts_delay increased to 300 ms)
[0xf4c11150] main input error: ES_OUT_RESET_PCR called
[0xf4c11150] main input debug: Buffering 0%
...
[0xf0c45bc0] main decoder debug: End of audio preroll
...
[0xf4c11150] main input debug: Stream buffering done (334 ms in 3 ms)
[0xf4c11150] main input debug: Decoder buffering done in 0 ms
[0x87a0a30] main audio output debug: inserting 9553 zeroes
[0xebc00c58] main vout display debug: auto hiding mouse cursor
[0xf0c36aa8] main decoder debug: End of video preroll
[0xf4c11150] main input error: ES_OUT_SET_(GROUP_)PCR is called too late
(pts_delay increased to 320 ms)
[0xf4c11150] main input error: ES_OUT_RESET_PCR called
...
The key point is, first I thought it's some video decoder problems, but I
was wrong!
I've tried different setups and discovered that the problem is in _direct_
ALSA sound output - i.e. it works without any problem with PulseAudio!
Also it works with sound disabled or if the "discard all samples" audio
device is selected (so it's not an audio decoder problem).
I don't want to install PulseAudio, just because for me it's an useless
ALSA wrapper (everything always worked fine without it) and because I
don't like Lennart's creations. :-)
In any case I think it's a bug if ALSA output doesn't work in VLC...
Does anyone know something about this problem? Any upstream bugs or
possible ideas of fixing? Or should I just report it to debian
(-multimedia?) or even directly to upstream and wait for the solution?
--
With best regards,
Vitaliy Filippov
--
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/op.w84litv0xpoh24@vitalif.vhome
Re: Bug#734053: please remove the base pseudo package
On Fri, 03 Jan 2014, Holger Levsen wrote: > http://qa.debian.org/data/bts/graphs/b/base.png and > http://qa.debian.org/data/bts/graphs/g/general.png also underline my point. Instead of removing it, I'd like to just prominently mark it as deprecated, and coordinate with reportbug to never show it as an option. Would that be good enough? -- Don Armstrong http://www.donarmstrong.com Three little words. (In order of importance.) █ █ ▌ ▞▀▖▌ ▌▛▀▘ █ ▌ ▌ ▌▝▞ ▛▀ you █ ▀▀▘▝▀ ▘ ▀▀▘ █ -- hugh macleod "Three Words" -- 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/20140103194328.gc4...@rzlab.ucr.edu
Re: porting OpenRC on kFreeBSD and Hurd
Hello,
Good news, I see it there:
http://packages.qa.debian.org/o/openrc.html
https://buildd.debian.org/status/package.php?p=openrc&suite=experimental
Thanks a lot.
Kind regards,
--
Julián Moreno Patiño
Debian Developer
.''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `' http://debian.org/
`- GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513
--
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/CAGevevfeVyHCK=wmyz3bwdnoywbbkctkiqait4qd5gcrlkq...@mail.gmail.com
Re: Bug#734053: please remove the base pseudo package
Hi Don, On Freitag, 3. Januar 2014, Don Armstrong wrote: > Instead of removing it, I'd like to just prominently mark it as > deprecated, and coordinate with reportbug to never show it as an option. why? and then you'd want to remove the base package in 5 years or keep it forever or?? > Would that be good enough? Honestly, I don't see the point. The base system is gone. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Removing packages from unofficial repositories
On 03/01/14 01:39 PM, Виталий Филиппов wrote: > If you have other 3rdparty repos, you'll also need to set 1001 for all > of them (except DMO), that should be enough. Simon wanted "a general, user-friendly way to deal with situations like this". This is neither. > And of course strictly speaking it may be unsafe, but I think it's OK in > case of debian-multimedia... Every downgrade whether from DMO back to Debian or within Debian runs the risk of running into the kinds of breakage inherent to downgrades (as indicated in the quote I gave earlier). I don't think that risk should be downplayed. Ben -- 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/52c71aa7.60...@sanctuary.nslug.ns.ca
Re: 'tty' output on kFreeBSD, etc. within sbuild
On Fri, Jan 03, 2014 at 07:12:51PM +, Roger Leigh wrote: > You aren't guaranteed to have a controlling terminal, particularly when > run via buildd. So while stdin/out/err are all connected and > functional, they are either null (stdin) or pipes (out/err). If you > need to output anything, then just use stdout/err as appropriate and it > will be logged, but /dev/tty may well be unavailable. I would > recommend not using `tty` or doing any IO on /dev/tty since in all > likelihood isatty/ttyname(_r) will most likely return ENOTTY and any > IO on /dev/tty will simply fail. > > We have looked at using ptys in the past for running the builds in > order to guarantee a tty, but decided against it. Too many programs > make the assumption that they are interactive and freeze the build > waiting on IO that never happens and then block forever. There may > well have been other considerations I don't recall offhand e.g. > relating to job control. There are some limited situations (e.g. test suites) where it can come in handy. For these, I'd recommend lifting the debian/script.py I wrote from the python2.7 source package, which gives you a pty in a way that's known to work well within builds and writes output to a file. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103202904.ga29...@riva.ucam.org
Re: Bug#734053: please remove the base pseudo package
On Fri, 03 Jan 2014, Holger Levsen wrote: > On Freitag, 3. Januar 2014, Don Armstrong wrote: > > Instead of removing it, I'd like to just prominently mark it as > > deprecated, and coordinate with reportbug to never show it as an option. > > why? > > and then you'd want to remove the base package in 5 years or keep it > forever or?? If I don't keep it somewhere, then someone could potentially upload a package named base. On the other hand, I'm not sure that it actually matters if someone was to upload such a package at some time in the future. -- Don Armstrong http://www.donarmstrong.com I would like to be the air that inhabits you for a moment only. I would like to be that unnoticed & that necessary. -- Margaret Atwood "Poetry in Motion" p140 -- 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/20140103210637.gh4...@rzlab.ucr.edu
Bug#734112: ITP: b2sum -- BLAKE2 family of hash functions -- command-line tool
Package: wnpp Severity: wishlist Owner: Robert Ransom X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: b2sum Version : 20130131 Upstream Author : cont...@blake2.net * URL : https://blake2.net/ * License : CC0 Programming Lang: C Description : BLAKE2 family of hash functions -- command-line tool The BLAKE2 family of hash functions is an improved version of the SHA-3 finalist BLAKE. . BLAKE2b is optimized for 64-bit platforms and produces up to 64 bytes of output; BLAKE2s is optimized for 32-bit platforms and produces up to 32 bytes of output. . BLAKE2bp and BLAKE2sp are parallel versions of BLAKE2b and BLAKE2s designed for increased performance on multicore and large-vector SIMD processors. . b2sum is a command-line tool to hash files using the BLAKE2 functions, similar to the standard md5sum, sha1sum, etc. utilities. -- 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/CABqy+sod6_j3R_CA0SiXXEFiLL1+QORdK=mqlrbqqudyesa...@mail.gmail.com
Re: Bug#734053: please remove the base pseudo package
Hi, On Freitag, 3. Januar 2014, Don Armstrong wrote: > If I don't keep it somewhere, then someone could potentially upload a > package named base. > > On the other hand, I'm not sure that it actually matters if someone was > to upload such a package at some time in the future. I cannot see any problem with that and I believe there have been cases of package-name-takeovers in the past as well... cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#734131: ITP: python-jmespath -- JSON Matching Expressions
Package: wnpp Owner: tak...@debian.org Severity: wishlist * Package name: python-jmespath Version : 0.2.1 Upstream Author : James Saryerwinnie * URL or Web page : https://github.com/boto/jmespath * License : MIT Description : JMESPath is python library which allows you to declaratively specify how to extract elements from a JSON document. -- 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/87eh4owjha.wl%tak...@debian.org
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On Wed, Jan 01, 2014 at 10:58:32AM +0100, David Weinehall wrote: > That's also why I *don't* use BSD-style licenses for software that > I write, but rather GPLv2 or LGPLv2.1. So if someone takes your LGPLv2.1-only software and adds GPLv2-only code to it, do you feel similarly betrayed because you can't take that code back? -- 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/20140104031301.ga30...@scru.org
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On Tue, Dec 31, 2013 at 08:59:53AM -0600, Matt Zagrabelny wrote: > > So your doomsday scenario is that if you license something > > GPLv2+, someone might fork and modify it to be GPLv3+, > > I was under the impression that forks couldn't change licenses. Is the > scenario which Clint describes (legally) possible? I drew up this table a few weeks back when someone was misunderstanding the GPL combination stuff. / | HELPFUL GPL UPGRADE TABLE | | | +---++---++ | | GPL-2 | GPL-2+ | GPL-3 | GPL-3+ | <= | +---+---++---++ \\ | | GPL-2 | GPL-2 | GPL-2 | NO!!! | NO!!! | || | +---+---++---++ || | | GPL-2+| GPL-2 | GPL-2+ | GPL-3 | GPL-3+ | || | +---+---++---++ || | | GPL-3 | NO!!! | GPL-3 | GPL-3 | GPL-3 | || | +---+---++---++ || | | GPL-3+| NO!!! | GPL-3+ | GPL-3 | GPL-3+ | || | +---+---++---++ || | ^^ || | || || |Take the license of your work|| | || | and match it with the license of the work you want | to include into your work (linking, static linking, | copying into, any sort of memory sharing) | | |Find the grid that matches the two entries. |This value is the license that you may distribute |the derived work under. | |If the value is "NO!!!", then you're violating the |terms of the GPL and *MAY NOT* distribute this work. \ Didn't think I'd have to post it to a Debian mailing list, but alas. The resulting license is the work, when it's all jumbled up and combined, *not* the original code that was GPL-2+. That will stay 2+ regardless of what it's being used in, and can be taken out to restore it's 2+-eyness. Cheers, Paul -- .''`. Paul Tagliamonte | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
