Re: Imminent mass-bug-filing warning for multiarch:same bugs
On 28 October 2013 12:17, Jakub Wilk wrote: > Done. > #724749 > #720031 > #723665 > #720036 > #720029 > #720030 > #724974 > > -- > Jakub Wilk Jakub, Thanks for pointing these out - sorry, should have checked before posting. The remainder have now been filed. Jenny -- 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/CALZB=vYgj5Ph_azwsjCN3ZkfqzmDfr7UTYgOZU7vEGGe=u3...@mail.gmail.com
Bug#728859: ITP: gnome-online-miners -- Crawls through your online content
Package: wnpp Severity: wishlist Owner: Dennis Ruhe * Package name: gnome-online-miners Version : 3.10.0 Upstream Author : Debarshi Ray * URL : http://www.gnome.org/ * License : GPL Programming Lang: C Description : Crawls through your online content GNOME Online Miners provides a set of crawlers that go through your online content and index them locally in Tracker. It has miners for Flickr, Google, ownCloud and SkyDrive. -- 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/20131106094752.7109.69020.reportbug@debian-desk.debian-desk.local
Re: Bug#728859: ITP: gnome-online-miners -- Crawls through your online content
Are you planning to package this as part of the Debian GNOME team? -- 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/20131106115623.ga22...@bryant.redmars.org
Bug#728870: ITP: mate-themes -- Official themes for the MATE desktop
Package: wnpp Severity: wishlist Owner: Mike Gabriel * Package name: mate-themes Version : 1.6.1 Upstream Author : Stefano Karapetsas * URL : http://www.mate-desktop.org/ * License : LGPL, CC-BY-SA Programming Lang: Artwork Description : Official themes for the MATE desktop This package contains the official desktop themes of the MATE desktop environment. -- 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/20131106120036.16151.22735.report...@minobo.das-netzwerkteam.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, 5 Nov 2013 18:00:09 -0500 Paul Tagliamonte wrote: > What? Sorry, what? Are you disagreeing with yourself? If it's so > important to a UNIX system, why do you say it's not technical ... I said it's not *only* technical. > > Big companies all over and over again show they care much more about their > > economic interests than about interests of free software community. As of > > my understanding, Debian should be an independent project, devoted to > > interest of its community (users), and not the interests of any companies. > > However, it is obvious companies push their software because they control > > their development, but then if such software becomes essential for Debian, > > they control Debian. If you read free software principles elaborated by > > Richard M. Stallman and FSF, it is clear that the point is exactly in > > having control over your life, i.e. being independent (or in other words > > not under control) of any companies. > > No, that's not what RMS and the FSF means. They claim, by ensuring > software you use is free, you can ensure that you retain your rights > when using your computer by granting you basic freedoms (the four > freedoms). > > One of those freedoms is to use the software commercially, just FYI. I didn't say I am against commercial usage of software. RMS did say something like I said: "That’s the fundamental issue: while non-free software and SaaSS are controlled by some other entity (typically a corporation or a state), free software is controlled by its users. Why does this control matter? Because freedom means having control over your own life." http://www.wired.com/opinion/2013/09/why-free-software-is-more-important-now-than-ever-before/ > We shall not stand in the way of progress. logind, systemd (such as > socket based activation, dependency booting) in particular, and friends > are technical wins. We'd be silly to not take them. We are not standing in the way, if Red Hat wants to test systemd it can do it in Fedora. systemd is obviously more powerful than sysvinit, but I am afraid of implications. UNIX philosophy is to do only one thing right. They replace login system and it can obviously have even security implications. > > And SysVInit just works well and it is simply enough. It has much less > > dependencies than systemd. Do not make unneeded weight on people to learn > > systemd in addition to shell scripts, if systemd is powerful that also > > means there is a lot to learn. I really doubt non-standards task can be > > solved with systemd without shell scripts (or similar), and every serious > > UNIX admin must know shell programming anyway. > > This is like saying "A horse drawn carrage works well enough, why do you > need an airplane". You need an airplane because Earth is 40,000 km in round and because you have a reason to travel to a distant location. Or just you want to do some sport? But I know my possibilities and I wouldn't spend my money on an airplane just for sport, to produce an airplane you have to take raw materials out of this planet, you have to spend power, human time, make pollution, etc. -- http://mr.flossdaily.org signature.asc Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Tue, 5 Nov 2013, Paul Tagliamonte wrote: > > First of all, I do not agree Debian community is hurt because of > > split about init system, > > I disagree strongly. Please read through every flame thread over the > last 4 years and try to say this with a straight face. That’s why I say let’s just support them all. > > such software becomes essential for Debian, they control Debian. If > > you read free software principles elaborated by Richard M. Stallman > > and FSF, it is clear that the point is exactly in having control > > over your life, i.e. being independent (or in other words not under > > control) of any companies. > > No, that's not what RMS and the FSF means. They claim, by ensuring > software you use is free, you can ensure that you retain your rights > when using your computer by granting you basic freedoms (the four > freedoms). That’s the general idea, yes. But there are, of course, new developments that make the “ensuring X” no longer be enough. Do remember that this is not about the (freeness of the) software but of the users. http://mako.cc/copyrighteous/freedom-for-users-not-for-software Hence why I insist on freedom of choice, even though I’d never choose systemd for myself, since I see that others would want it. > One of those freedoms is to use the software commercially, just FYI. I think that’s not his point. I read Marko’s mail as an argument against vendor lock-in, and, let’s face it, systemd is company-backed (RedHat, mostly), as is Upstart (Canonical, mostly). But, IMHO now, even if this were not so, there’s already way too much vendor lock-in in the (GNU) world, for example autoconf > 2.62 depending on GNU m4, whereas older versions worked perfectly fine with BSD m4, and so on. Let’s not add to it. > it's urgent, and it *is* causing social problems in Debian. ACK. > > We don't want free software becomes just a marionette of big business. > > The fun thing about F/OSS is free software *can* become a marionette and > we're still much more free than before (and can still express the same > rights as if it wasn't a mega-corp). Yes, but by becoming a marionette of either systemd or upstart (and, funnily – as my stances towards Canonical/*buntu/Shuttleworth are known – currently I perceive systemd as a much larger threat) we lose wrt. the current state of having sysvinit usable. > We shall not stand in the way of progress. logind, systemd (such as > socket based activation, dependency booting) in particular, and friends > are technical wins. We'd be silly to not take them. NO! We’d be silly to take them, because they lead to vendor lock-in, and *especially* the systemd side has shown, time and time again, that they won’t stop there. They intend to wholly change the ecosystem, to get away from Unix and GNU and towards this thing some people now call “FLOS” (one ‘s’). And Debian is, fundamentally, still a Unix of sorts. I believe they should do their FLOS experiments in a downstream. > If you want to hold your own system back, there's nothing stoping you Bad suggestion. I don’t even want to follow this thought. > This is like saying "A horse drawn carrage works well enough, why do you > need an airplane". In some cases, the airplane is too much. Think, to transport one person a dozen kilometres. Think about costs. Sometimes, the benefits do *not* outweigh the costs. But sometimes, they do – an æroplane is the perfect tool to transport several dozen people from Europe to the Americas, for example (other than a ship). Which is another reason for us to actively support both sysvinit and one of the newcomers (such as upstart, since it’s much less hostile). This way, people (actual users!) can choose. It’s not necessary to install the whole systemd stack on a small one-purpose VM, for example. Or on a tightly secured, small VM _host_ (when the guests have all the power). > "without deviation from the norm progress is not possible" > -- Frank Zappa Without competition, progress is not possible either. A systemd monoculture – which clearly is what “the systemd/GNOME crowd” (they really mesh together) want – will not help anyone. > I believe this is a purely technical issue I’m with you on this, but… >, and one that is near 100% > invisible to the user. … most definitely not on this. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C" -- 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.1311061350390.14...@tglase.lan.tarent.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
And SysVInit just works well and it is simply enough. It has much less dependencies than systemd. Do not make unneeded weight on people to learn systemd in addition to shell scripts, if systemd is powerful that also means there is a lot to learn. I really doubt non-standards task can be solved with systemd without shell scripts (or similar), and every serious UNIX admin must know shell programming anyway. This is like saying "A horse drawn carrage works well enough, why do you need an airplane". You need an airplane because Earth is 40,000 km in round and because you have a reason to travel to a distant location. Or just you want to do some sport? But I know my possibilities and I wouldn't spend my money on an airplane just for sport, to produce an airplane you have to take raw materials out of this planet, you have to spend power, human time, make pollution, etc. That's exactly how I feel when I want to create a small daemon using a SystemV init script. I feel like building an airplane from scratch while I would just use a bike. Introducing the concept of "possibilities" is interesting: sometimes, you need some choices in your available tools to perform the same task, depending on your current need… Adrien -- 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/527a3e75.5050...@antipoul.fr
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
Thorsten Glaser writes: > On Tue, 5 Nov 2013, Paul Tagliamonte wrote: > >> > First of all, I do not agree Debian community is hurt because of >> > split about init system, >> >> I disagree strongly. Please read through every flame thread over the >> last 4 years and try to say this with a straight face. > > That’s why I say let’s just support them all. Please no. That's a maintenance nightmare. I'm fine with one on GNU/Linux, another everywhere else (but I'll treat everything else as secondary), but supporting all of them, everywhere they're available, is madness. > Do remember that this is not about the (freeness of the) software but > of the users. > > http://mako.cc/copyrighteous/freedom-for-users-not-for-software > > Hence why I insist on freedom of choice, even though I’d never choose > systemd for myself, since I see that others would want it. Freedom of choice remains even when there's a default. We have a default desktop, default syslogd, default MTA, default-this, default-that, yet, we have alternatives for all of those. We have a default init now, and alternatives to that too. If we choose a different default, the alternatives can still co-exist, like they do now. Freedom is not lost. >> One of those freedoms is to use the software commercially, just FYI. > > I think that’s not his point. I read Marko’s mail as an argument against > vendor lock-in, and, let’s face it, systemd is company-backed (RedHat, > mostly), systemd is company-backed only as much as glibc or GNOME is. >> We shall not stand in the way of progress. logind, systemd (such as >> socket based activation, dependency booting) in particular, and friends >> are technical wins. We'd be silly to not take them. > > NO! We’d be silly to take them, because they lead to vendor lock-in, > and *especially* the systemd side has shown, time and time again, that > they won’t stop there. They intend to wholly change the ecosystem, to > get away from Unix and GNU and towards this thing some people now call > “FLOS” (one ‘s’). And change is bad, because...? I'm not sure about you, but I prefer to improve my systems instead of holding them hostage to ancient technologies, just because there's only one implementation of a particular solution. > But sometimes, they do – an æroplane is the perfect tool to transport > several dozen people from Europe to the Americas, for example (other > than a ship). Which is another reason for us to actively support both > sysvinit and one of the newcomers (such as upstart, since it’s much > less hostile). This way, people (actual users!) can choose. It’s not > necessary to install the whole systemd stack on a small one-purpose > VM, for example. Or on a tightly secured, small VM _host_ (when the > guests have all the power). This is a misguided reasoning. Just because we select *one* default, does not mean that all alternatives will be dropped. We have systemd and upstart in Debian, they're usable, yet, sysvinit is the default. Switching to systemd/upstart/OpenRC will not mean the rest will be dropped. The choice will remain. >> "without deviation from the norm progress is not possible" >> -- Frank Zappa > > Without competition, progress is not possible either. A systemd > monoculture – which clearly is what “the systemd/GNOME crowd” (they > really mesh together) want – will not help anyone. See above. -- |8] -- 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/87k3glvemn.fsf@algernon.balabit
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Nov 06, 2013 at 02:33:36PM +0100, Gergely Nagy wrote: > Please no. That's a maintenance nightmare. I'm fine with one on > GNU/Linux, another everywhere else (but I'll treat everything else as > secondary), but supporting all of them, everywhere they're available, is > madness. This is now in the hands of the tech-ctte, discussing it here further serves no useful purpose at the moment. -- 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/20131106140012.ga24...@bryant.redmars.org
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 6 Nov 2013, Gergely Nagy wrote: > Please no. That's a maintenance nightmare. I'm fine with one on > GNU/Linux, another everywhere else (but I'll treat everything else as > secondary), but supporting all of them, everywhere they're available, is > madness. And: > Freedom of choice remains even when there's a default. We have a default > desktop, default syslogd, default MTA, default-this, default-that, yet, > we have alternatives for all of those. We have a default init now, and > alternatives to that too. > > If we choose a different default, the alternatives can still co-exist, > like they do now. Freedom is not lost. Do you read what you write? These two blocks are the inverse of each other. Either you support them all or they cannot coëxist. [ vendor lock-in ] > And change is bad, because...? I'm not sure about you, but I prefer to Experience shows that vendor lock-in is always bad, because it prevents you from exchanging one bad component with another. The fact that things are OSS doesn’t change this, either, especially as it still leads to massive effort. > improve my systems instead of holding them hostage to ancient > technologies, just because there's only one implementation of a > particular solution. This is contrary too… you want to switch to one “more modern” init system, just because it’s the only one that offers you the features you now think you want, holding you hostage to whatever technology Poettering thinks nice right now (consider his track report of abandoning things, too) and preventing you from using something else instead. (Or something more suited to a particular job.) > Switching to systemd/upstart/OpenRC will not mean the rest will be > dropped. But that’s just the thing: you said above: one on GNU/Linux, one on the others, period. This in effect means that all other systems will be dropped because you don’t want to support them (unless we keep sysvinit as lowest common denominator, require maintainers to write init scripts (which can be very short with a helper, as recent Planet Debian posts showed), and use the other init systems in compat mode; but the propo- nents of systemd, upstart *and* openrc (to a lesser amount) alike *all* want to *not* keep supporting init scripts). bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) -- 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.1311061508230.14...@tglase.lan.tarent.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Nov 06, 2013 at 03:14:14PM +0100, Thorsten Glaser wrote: [snip] Some good points made all around, more for the ctte to consider. As Jonathan says, it's in ctte's hands now, let's agree to disagree and let the poor souls on the commitee do their job Cheers, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Debian HA team MIA?
Hi, I was just pointed to http://qa.debian.org/developer.php?login=debian-ha-maintain...@lists.alioth.debian.org and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714210 both of which bring up the question whether the team still exists and is actively working on the packages. Do we have a MIA process for teams? Michael P.S.: I couldn't find anything in the archives but should I have missed an existing thread, please point me to it. -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- 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/20131106162226.ga29...@feivel.credativ.lan
Re: Debian HA team MIA?
On 6 November 2013 17:22, Michael Meskes wrote: > > I was just pointed to > http://qa.debian.org/developer.php?login=debian-ha-maintain...@lists.alioth.debian.org > and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714210 both of which > bring > up the question whether the team still exists and is actively working on the > packages. If new manpower is needed in the team I'm ready :) Let me know. -- Arturo Borrero González -- 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/caoksjbja+ycremyiusexoqjo-khhk3prip-4nue-qxewgo3...@mail.gmail.com
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, 06 Nov 2013 14:04:53 +0100 Adrien CLERC wrote: > >>> And SysVInit just works well and it is simply enough. It has much less > >>> dependencies than systemd. Do not make unneeded weight on people to learn > >>> systemd in addition to shell scripts, if systemd is powerful that also > >>> means there is a lot to learn. I really doubt non-standards task can be > >>> solved with systemd without shell scripts (or similar), and every serious > >>> UNIX admin must know shell programming anyway. > >> This is like saying "A horse drawn carrage works well enough, why do you > >> need an airplane". > > You need an airplane because Earth is 40,000 km in round and because you > > have a reason to travel to a distant location. Or just you want to do some > > sport? But I know my possibilities and I wouldn't spend my money on an > > airplane just for sport, to produce an airplane you have to take raw > > materials out of this planet, you have to spend power, human time, make > > pollution, etc. > > > That's exactly how I feel when I want to create a small daemon using a > SystemV init script. I feel like building an airplane from scratch while > I would just use a bike. Use /etc/init.d/skeleton and you'll see it's very simple. > > Introducing the concept of "possibilities" is interesting: sometimes, > you need some choices in your available tools to perform the same task, > depending on your current need… > > Adrien Shell is a programming language. It cannot be less flexible then config files. But there is also an interesting point. We are currently not using BASH features for init scripts. As I remember, BASH was bloated or smt, but certainly less than systemd is. -- 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/20131106174319.0535e...@eunet.rs
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
This discussion isn't really furthering the development of Debian and the init system question is already with the technical committee so can we please take such discussions off-list, if one is determined to continue them. -- 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/20131106171114.ga27...@bryant.redmars.org
Re: New ksh/ksh93 package, half the size, ten times the features!!!!
On Tue, Nov 5, 2013 at 1:14 PM, Joshuah Hurst wrote: > FYI > -- Forwarded message -- > From: ольга крыжановская > Date: 5 November 2013 02:15 > Subject: astksh.2013-10-10 Debian prototype package > To: Oliver Kiddle , Oliver Kiddle > , Cedric Blancher , > Giovanni Rapagnani , Phi Debian > , WNPP Monitor > > > I have uploaded a prototype of the new ksh Debian package to > http://www.nrubsig.org/people/fleyta/debian/ksh/astksh20131010_deb_prototype/ksh_93v-20131010-1_amd64.deb > > * Now working parts are: > - Despite being much more powerful, the binary package should be half > the size of the current 'unstable' Debian package size > - The shell is now stable, and we did not find a way to intentionally crash it > - POSIX builtins, which are fully compatible to GNU coreutils, are > enabled by default, as Sun did in Opensolaris PSARC/2006/550. This > brings ksh93 in parity with busybox, minus platform specific builtins, > like mount(1) > - The ksh93 test suite, now passes, minus bugs, which are generic on > all platforms > - We mostly pass the POSIX shell test suite, minus issues caused by > Debian Linux itself > - libast/libdll/libcmd/libsum/libshell.so.1 are shipped by default, > and go into lib, so that ksh can later be used to do the work of both > /bin/sh, and busybox > - AST localization utilities, are now shipped by default, so users can > generate their own localised shell scripts, using $"..." string > literals, in their own scripts > - Documentation is more complete > > * Todo: > - Support more platforms, than just AMD64 > - Find a mentor > - Integrate feed back > - Add a default /etc/ksh.kshrc > - Add binfmt support for compiled shell scripts from shcomp > > $ openssl sha1 * > SHA1(ksh_93v-20131010-1.debian.tar.gz)= > 2c9940a40d3cd0de7a11dc57d7f0150a494b21b7 > SHA1(ksh_93v-20131010-1_amd64.deb)= 2ffb260c53852db1de6af536f05964ea4d56c7a2 > SHA1(ksh_93v-20131010.orig.tar.gz)= 0b6b1100a282de622ee59c920f3f2f735806174f > $ openssl md5 * > MD5(ksh_93v-20131010-1.debian.tar.gz)= c642d5a59b89181f98b67e5b16536d27 > MD5(ksh_93v-20131010-1_amd64.deb)= fcee4312fd7fd180305a07eb20df1054 > MD5(ksh_93v-20131010.orig.tar.gz)= 97c74d2d07907a870f342f4063099711 Feedback for the (contents of the) package would be very welcome... Josh -- 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/caeemktpgk0k6l10yvaxhwoy03b8wscjvmwo0yy3wctv2hj4...@mail.gmail.com
Re: New ksh/ksh93 package, half the size, ten times the features!!!!
On Wed, Nov 06, 2013 at 06:21:48PM +0100, Joshuah Hurst wrote: > > I have uploaded a prototype of the new ksh Debian package to > > http://www.nrubsig.org/people/fleyta/debian/ksh/astksh20131010_deb_prototype/ksh_93v-20131010-1_amd64.deb > > Feedback for the (contents of the) package would be very welcome... If you want feedback, we'll need the source package as well. No one can solely work on a provided binary package. Please upload the package to mentors and I'll have a look at it. I already sponsored several previous uploads of ksh. 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/20131106173416.ga2...@physik.fu-berlin.de
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
* Thorsten Glaser: > On Thu, 31 Oct 2013, Florian Weimer wrote: > >> Curiously, a lot of system administrators do not do this correctly >> using sysvinit, causing system daemons to start unexpectedly after >> installing package updates. > > What *is* the correct way, anyway? Renaming the S symlinks to K symlinks. update-rc.d is intended for packaging scripts only. > So I ended up writing 'exit 0' as the first line into the > respective /etc/default/ file to disable them… or changing > the initscript directly (also 'exit 0' as first line after > the shebang), leading to conffile prompts. Yes, that's what I usually do as well because it's more reliable. As far as I'm concerned, this is the number one reason why the Debian init system needs an overhaul. -- 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/87d2mdifh7@mid.deneb.enyo.de
Bug#728894: ITP: cpl-plugin-vimos -- ESO data reduction pipeline for VIMOS
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org * Package name: cpl-plugin-vimos Version : 2.9.7 Upstream Author : ESO * URL : http://www.eso.org/sci/software/pipelines/vimos/vimos-pipe-recipes.html * License : GPL Programming Lang: C Description : ESO data reduction pipeline for VIMOS This is the data reduction pipeline for the VIMOS instrument of the Very Large Telescope (VLT) from the European Southern Observatory (ESO). . VIMOS is a visible (360 to 1000 nm) wide field imager and multi-object spectrograph mounted on the Nasmyth focus B of UT3 Melipal. The instrument is made of four identical arms with each a field of view of 7' x 8' with a 0.205" pixel size and a gap between each quadrant of ~2'. Each arm is equipped with 6 grisms providing a spectral resolution range from ~200-2500 and with one EEV CCD 4k x 2k. . VIMOS operates in three different modes: Imaging (IMG), Multi-Object Spectroscopy (MOS), and with Integral Field Unit (IFU). Further information about VIMOS can be found under http://www.eso.org/sci/facilities/paranal/instruments/vimos/ A git repository is created at http://anonscm.debian.org/gitweb/?p=debian-science/packages/cpl-plugin-vimos.git The recipe will be based on the same template as the other plugins created so far (cpl_plugin_amber, cpl_plugin_fors, cpl_plugin_giraf, cpl_plugin_hawki, cpl_plugin_sinfo). Best regards Ole -- 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/527a870f.2020...@liska.ath.cx
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Wed, Nov 06, 2013 at 06:53:40PM +0100, Florian Weimer wrote: [...] Again, good points, but ones we've discussed. Perhaps we should end this thread? Fondly, Paul -- .''`. Paul Tagliamonte : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
❦ 6 novembre 2013 18:53 CET, Florian Weimer :
>>> Curiously, a lot of system administrators do not do this correctly
>>> using sysvinit, causing system daemons to start unexpectedly after
>>> installing package updates.
>>
>> What *is* the correct way, anyway?
>
> Renaming the S symlinks to K symlinks. update-rc.d is intended for
> packaging scripts only.
update-rc.d has now a "disable" command. I think this is intended for
administrators. It is compatible with SysV and systemd. Dunno about
upstart.
--
die_if_kernel("Penguin instruction from Penguin mode??!?!", regs);
2.2.16 /usr/src/linux/arch/sparc/kernel/traps.c
signature.asc
Description: PGP signature
Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
❦ 6 novembre 2013 17:43 CET, Marko Randjelovic :
>> That's exactly how I feel when I want to create a small daemon using a
>> SystemV init script. I feel like building an airplane from scratch while
>> I would just use a bike.
>
> Use /etc/init.d/skeleton and you'll see it's very simple.
The restart part of this script is buggy and documented as this:
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
# If the above conditions are not satisfied then add some other code
# that waits for the process to drop all resources that could be
# needed by services started subsequently. A last resort is to
# sleep for some time.
This is why we have so many scripts with "sleep". On 138 init.d script I
have on my system, 52 are using sleep. This is full of race
conditions. If your system is slow, a restart will likely fail because
sleep will not wait enough time.
--
panic ("Splunge!");
2.2.16 /usr/src/linux/drivers/scsi/psi240i.c
signature.asc
Description: PGP signature
Re: New ksh/ksh93 package, half the size, ten times the features!!!!
Hi, The sources are here: http://www.nrubsig.org/people/fleyta/debian/ksh/astksh20131010_deb_prototype/ksh_93v-20131010-1.debian.tar.gz http://www.nrubsig.org/people/fleyta/debian/ksh/astksh20131010_deb_prototype/ksh_93v-20131010.orig.tar.gz On 06/11/13 18:21, Joshuah Hurst wrote: > On Tue, Nov 5, 2013 at 1:14 PM, Joshuah Hurst wrote: >> FYI >> -- Forwarded message -- >> From: ольга крыжановская >> >> I have uploaded a prototype of the new ksh Debian package to >> http://www.nrubsig.org/people/fleyta/debian/ksh/astksh20131010_deb_prototype/ksh_93v-20131010-1_amd64.deb > Feedback for the (contents of the) package would be very welcome... > > Josh I haven't been able to compile the package neither on debian testing nor on debian wheezy. The package is based on the alpha build dated 2013-10-10 and the debian/rules build target calls a script (buildksh93.sh) which comes from opensolaris project. As far as I can see, the script is only able to build i386 and x86_64 binaries (when using a linux kernel) but I personally couldn't get it to work. Olga, I don't understand why you did the package like this for the following reasons: 1/ recently Glenn has worked on ksh sources so that it now support debian multiarch. Starting with the INIT-2013-10-30 and ast-ksh-2013-10-10 releases, I have verified that the sources compile just fine on debian wheezy, debian testing and even on ubuntu 12.04 LTS and raspbian wheezy on ARM without relying on an external script. Have a look at this post if you want to get the last release http://lists.research.att.com/pipermail/ast-developers/2013q4/003669.html 2/ when I look at your debian/rule, the way you call the buildksh93.sh script makes usage of just a small part of the whole content of the script. Half the script is about solaris stuff and another amount of it handles pathcc and pcc compilers which are not available in debian. Wouldn't it be worth to get rid of this script? We could use quilt patches to enable/disable features (like Oliver did with the current ksh package in debian) or just directly provide the required builtin header file (instead of creating it with a cat >file.h
Bug#728934: ITP: yara -- help to identify and classify malwares
Package: wnpp Severity: wishlist Owner: Joao Eriberto Mota Filho * Package name: yara Version : 1.7 Upstream Author : Victor M. Alvarez , Mike Wiacek * URL : http://code.google.com/p/yara-project * License : Apache-2.0 Programming Lang: C Description : help to identify and classify malwares YARA is a tool aimed at helping malware researchers to identify and classify malware samples. With YARA you can create descriptions of malware families based on textual or binary patterns contained on samples of those families. Each description consists of a set of strings and a Boolean expression which determines its logic. This is useful in forensics analysis. . Complex and powerful rules can be created by using binary strings with wild-cards, case-insensitive text strings, special operators, regular expressions and many other features. . Are examples of the organizations and services using YARA: . - VirusTotal Intelligence (https://www.virustotal.com/intelligence/) - jsunpack-n (http://jsunpack.jeek.org/) - We Watch Your Website (http://www.wewatchyourwebsite.com/) - FireEye, Inc. (http://www.fireeye.com) - Fidelis XPS (http://www.fidelissecurity.com/network-security-appliance/ \ Fidelis-XPS) -- 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/20131107005358.21730.55222.reportbug@scutum.local
Bug#728938: ITP: plsense -- Omni Completion Tool for Perl
Package: wnpp Severity: wishlist Owner: KURASHIKI Satoru * Package name: plsense Version : 0.10 Upstream Author : Hiroaki Otsu * URL : https://github.com/aki2o/plsense * License : Artistic or GPL-1+ Programming Lang: Perl Description : Omni Completion Tool for Perl This is a development tool for Perl using the type inference by analyzing source code. This tool is for highly functional editor like Emacs/Vim. -- 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/20131107021824.26600.78223.report...@build.yoikaze.org
Bug#728940: ITP: alienfeed -- Reddit command-line client
Package: wnpp Severity: wishlist Owner: "Javier P.L." * Package name: alienfeed Version : 2013.11.06 Upstream Author : Jared Wright * URL : https://github.com/jawerty/AlienFeed * License : MIT Programming Lang: Python Description : Reddit command-line client AlienFeed is a command line application made for displaying and interacting with Reddit submissions. The client can return a list containing the top submissions in a subreddit, and even open the links up if you'd like. -- 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/20131107024602.27491.57175.reportbug@ip-10-113-46-116.ec2.internal
Bug#728942: ITP: libclass-std-storable-perl -- Support for creating serializable "inside-out" classes
Package: wnpp Severity: wishlist Owner: KURASHIKI Satoru * Package name: libclass-std-storable-perl Version : 0.0.1 Upstream Author : Luke Meyer * URL : https://metacpan.org/pod/Class::Std::Storable * License : Artistic or GPL-1+ Programming Lang: Perl Description : Support for creating serializable "inside-out" classes Class::Std introduced the "inside-out" model for classes (perldoc Class::Std for details). Among its salient features is complete encapsulation; that is, an object's data may only be accessed via its methods, unlike the usual hashref model that permits direct access by any code whatsoever. However, the drawback of complete encapsulation is that normal mechanisms for serialization won't work, as they rely on direct access to an object's attributes. This class provides the class-building functionality from Class::Std, and in addition provides an interface to allow Storable to freeze and thaw any declared attributes of this class and any superclasses that were built via Class::Std::Storable. -- 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/20131107025315.3801.87389.report...@build.yoikaze.org
Bug#728946: ITP: python-praw -- PRAW, an acronym for "Python Reddit API Wrapper", is a python package that allows for simple access to reddit's API.
Package: wnpp Severity: wishlist Owner: "Javier P.L." * Package name: python-praw Version : 2.1.11 Upstream Author : Timothy Mellor * URL : https://github.com/praw-dev/praw * License : GPL Programming Lang: Python Description : PRAW, an acronym for "Python Reddit API Wrapper", is a python package that allows for simple access to reddit's API. PRAW aims to be as easy to use as possible and is designed to follow all of reddit's API rules. You have to give a useragent that follows the rules, everything else is handled by PRAW so you needn't worry about violating them. -- 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/20131107051548.11108.42507.reportbug@ip-10-113-46-116.ec2.internal
