Re: Policy consensus on transition when removing initscripts.
> "Sam" == Sam Hartman wrote: > "Simon" == Simon Richter writes: > "Sam" == On 6/29/23 01:56, Sam Hartman wrote: Sam> It also seems a bit strange to require more from the maintainer Sam> when they are dropping an init script than we would if a Sam> maintainer started depending on a feature like socket activation Sam> such that their package simply would not work without systemd. Simon> This would be a case where the init script and the systemd Simon> unit deviate in functionality. I don’t see a problem with Simon> that, and my expectation is generally that the people running Simon> sysvinit and the people running systemd have different Simon> expectations here anyway. That’s my impression as well. Personally, I’m not going to expect for daemons started via different init mechanisms to behave identically, either. Sam> It would be entirely permitted under GR 2019-002 for me to build Sam> a version of krb5-kdc that was compiled to depend on socket Sam> activation and would not work without systemd. Sam> I would not be required to provide any transition when doing that. Sam> (To be clear, I have no such plans, and in the case of krb5kdc Sam> don’t currently think it would be a good idea). I’m not sure it’s solely within the scope of the GR. When doing development and testing, I’ve found it useful to be able to start server processes from my own code. So, for example, I’d have a wrapper that’d do initdb on a temporary directory, start a PostgreSQL server process there, load the schema and test data, run a test suite, kill the server and remove the directory. No system-wide PostgreSQL instance is ever started on that system, so the choice of the init system is hardly relevant. (Never had a reason to start a KDC in such a way, but I’m not going to swear no one will ever need it, either.) I’d rather appreciate if this particular rug isn’t pulled from under my feet at some future date. Not that I’d expect it to be, mind. So far my experience with Debian packages has been that they tend to come with as much upstream features enabled as possible (to the point where I sometimes wish it weren’t the case.) If there’re concerns that a package maintainer might decide to deviate from such a practice for ill reasons, I suppose it should be codified within the policy. Otherwise, so long as as a given daemon can be started via fork and exec, it can be started from an init.d script just as well; while removing support for such use might affect users beyond those who rely on init.d. PS. The orphan-sysvinit-scripts package now has my attention. -- FSF associate member #7257 np. A Gentle Place by Lisa Lynne
[i386] adlibtracker2 and fp-units-i386
>>>>> On 2023-06-07, Sune Vuorela wrote: >>>>> On 2023-06-07, Paul Wise wrote: >> I note that there are a number of packages available on i386 but not >> available on amd64, is anyone planning on an MBF about this issue? > I got curious. Some of them are hurd specific. Others are a i386 > specific version, either for fewer processor capabilities or just a > specific one, like signed bootloader packages and such. Lets remove > those and see what we have left. [...] > Old soundblaster card related: >> adlibtracker2 deb sound optional arch=i386 "Related," yet not "dependent." This package allows one to compose /and play/ music composed for the OPL3 FM synthesis chip (and its clones), such as was (historically) used in Adlib and compatible boards. Naturally, it contains an OPL3 emulator and, in recent versions, has no support for hardware OPL3 chips. This package is similar in spirit to, e. g., goattracker for SID (or the recently removed aylet for AY-3-8912.) I've been meaning to check why it's i386-only for a while now. As a (not particularly educated) guess, it might have something to do with it being written in Free Pascal. >> sb16ctrl-bochs deb otherosfs optional arch=any-i386 [...] > i386-version of something and helpers and hardware enablement: >> fp-units-i386 deb devel optional arch=i386 >> fp-units-i386-3.2.2 deb devel optional arch=i386 ... For instance, at [1], I only see "Kylix" mentioned for: fp-units-i386 Free Pascal - Kylix compatibility units dependency package fp-units-i386-3.2.2 Free Pascal - Kylix compatibility units [1] http://packages.debian.org/sid/source/fpc -- FSF associate member #7257 http://am-1.org/~ivan/
Re: i386 in the future
> On 2023-05-19, Steve McIntyre wrote: > Colin Watson wrote: > On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote: > LB == Luca Boccassi wrote: LB> +1 for stopping publishing installers for i386, it has been LB> mentioned many times but it's always worth repeating: electricity LB> costs to keep running i386 hardware are already way higher than LB> what it costs to buy a cheap, low-power replacement like a LB> raspberry pi, that also provides better performance. I'm living within some 200 km distance from a major hydroelectric plant, so I can afford being more concerned about freedom than electricity costs [*]. I admit I haven't researched this question properly, but my understanding is that while, say, the AMD SB740 chipset from c. 2008 (that my primary box is built on) is very well-documented (and well supported by free software), many newer ones are not nearly as much (regardless of their power efficiency.) Granted, it's amd64, but it's still a 'retro' machine already. Specifically, while I have little experience with RPis (and SBCs in general), http://wiki.debian.org/CheapServerBoxHardware suggests that RPis aren't all that well supported by Debian main. CSBH> Unsuitable CSBH> * RaspberryPi: requires nonfree software to start up CSBH> * RaspberryPi2: requires nonfree software to start up CSBH> * RaspberryPi3: requires nonfree software to start up [*] My electricity bill is under 20 USD / month. >>> Well, maybe not a strong view, but a sense of vague unease--possibly >>> an ill-informed one. As someone who has used SIMH for "real" >>> work, I have to ask how someone would conduct an install to a 32-bit >>> x86 machine running under emulation, assuming no OS on the simulated >>> machine. >> I occasionally use 32-bit x86 even today (mostly for not very good >> historical reasons, but nevertheless), and I do it by using a 32-bit >> container on a 64-bit x86 machine instead. It's much faster to run, >> and it doesn't depend on installer support. There are doubtless >> edge cases where you need a completely separate kernel, but they >> aren't really ones I run into. > ACK. For people needing/testing i386 stuff, even just a simple > debootstrap and {s,}chroot will cover the vast majority of needs. > That's how we've been building i386 software already for ages in > Debian already. > More complex things can be done if needed: loopback mount an image, Or: attach a disk, partition it, mkfs and mount as needed... > debootstrap, install a kernel, etc. I don't see this as something > we should be spending much effort on in the future. FWIW, I'm using debootstrap to install Debian on my boxes for something like a full decade now. Personally, I wouldn't be inconvenienced in the least were Debian to stop providing D-I images for i386, or any other architecture for that matter. But I'd rather appreciate if it'd still be possible to run i386 binaries on Debian, including running a full Debian install on a i386 (i686) machine, real or emulated. (For i586 and other older platforms, I've found I could happily rely on NetBSD instead.) -- FSF associate member #7257 np. Border Line by Paolo Pavan
Re: An email address for drive-by bug reports?
>>>>> On 2023-03-23 05:30:01 +0100, Don Armstrong wrote: >>>>> On Fri, 17 Mar 2023, Ivan Shmakov wrote: >> It would’ve likely helped me if #1006801 were listed on >> http://bugs.debian.org/src:tinysshd . >> (I’m not entirely sure as to /why/ it got archived, TBH: it’s found in >> 20190101-1, which is still in the archive, and fixed in 20220305-1; as >> such, I’d expect it to remain open until Bullseye itself is archived.) > Bugs that are fixed in testing, unstable (and experimental) but > not RC severity (serious and above) are archived if they have > been closed for more than 28 days. ACK, thanks. Somewhere along the way I’ve picked a mistaken understanding of the process. The end result is that I should pay more attention to archived bugs, I suppose. -- FSF associate member #7257 http://am-1.org/~ivan/
Re: An email address for drive-by bug reports?
>>>>> On 2023-03-01 16:30:01 +0100, Sam Hartman wrote: > Honestly, if there is not currently a submitter behind a bug---someone > who cares about it and is willing to look into requests for more > information or to help confirm a fix---I'm not particularly interested > in working on such a bug. We’re all volunteers here. If someone doesn’t want to work on a particular issue, they’re IMO at full liberty to not do any such work. (There are exceptions, but ultimately, it boils down to whether the person does or doesn’t want to put effort into a particular issue / package / etc., possibly to the detriment of their other commitments.) > To me, that's often a sign the bug should be closed until someone > comes along who cares about the issue enough to interact with it. > There are exceptions. > So I'd be fine with a nosubmitter command or similar, but also with > the understanding that it's entirely reasonable for maintainers > to close nosubmitter bugs as wontfix-until-some-specific-person-cares. > Socially and culturally I do want to emphasize the idea that if you > aren't willing (any more) to put energy behind your problem report, > it's entirely fine if no one is going to put energy behind fixing it. > Having a bunch of problem reports that no one is interested in > cluttering up package pages has a cost. Just for the same reasons > you don't want these reports cluttering up your bugs from page, > I perhaps don't want them cluttering up my bugs on my package > pages if you no longer care. My long-time opinion is that so long as the bug is reproducible, and does affect Debian users, it’s ought to be in the BTS, open. The maintainer(s) can of course indicate their lack of desire to invest effort into solving the issue via the wontfix tag; no opposition to that. For an example, I’ve once spent hours trying to determine the cause of a particular problem I was having. Turns out tinysshd(8) from Bullseye has an interoperability issue with openssh-client from the same. It would’ve likely helped me if #1006801 were listed on http://bugs.debian.org/src:tinysshd . (I’m not entirely sure as to /why/ it got archived, TBH: it’s found in 20190101-1, which is still in the archive, and fixed in 20220305-1; as such, I’d expect it to remain open until Bullseye itself is archived.) The problem with the logic quoted above is that a bug that the original submitter isn’t interested in can still be affecting those who use Debian now; and, unless fixed, can still affect those who will use Debian at some later point. The absence of a /record/ of a person interested in the issue is not the same as the absence of such a /person/ themselves. Personally, I find Debian BTS to be a valuable source of what issues there /are./ On occasion, I’d choose between two packages based on what bugs are filed for each. Othertimes, I’ll find workarounds there. Or I might find why a particular issue is infeasible to fix in a given package, and start searching for another option for the task at hand. It’d be sad to see Debian BTS devolve into a bunch of maintainers’ personal TODO lists. -- FSF associate member #7257 http://am-1.org/~ivan/
Bug#974048: ITP: devuan-keyring -- GnuPG archive key of the devuan repository
Package: wnpp Severity: ITP X-Debbugs-CC: debian-devel@lists.debian.org Greetings. I was wondering if it would be possible to start maintaining the devuan-keyring package on salsa, and have it being built upstream in Debian? This way it would be possible to unify our efforts in debootstrap maintenance, and provide a separate script for Devuan releases, much like what is happening with Ubuntu and the gutsy target right now. If this is possible, following it, I would submit a patch to debootstrap where an extra Devuan target would be added, instead of the current symlinks to "sid". Thank you for your consideration, Ivan
Bug#974047: TAG: devuan-keyring -- GnuPG archive key of the devuan repository
Package: wnpp Severity: ITP X-Debbugs-CC: debian-devel@lists.debian.org Greetings. I was wondering if it would be possible to start maintaining the devuan-keyring package on salsa, and have it being built upstream in Debian? This way it would be possible to unify our efforts in debootstrap maintenance, and provide a separate script for Devuan releases, much like what is happening with Ubuntu and the gutsy target right now. If this is possible, following it, I would submit a patch to debootstrap where an extra Devuan target would be added, instead of the current symlinks to "sid". Thank you for your consideration, Ivan
possible MMBF regarding Depends: locales without | locales-all?
Сс: debian-b...@lists.debian.org [Cross-posting to tasksel maintainers, debian-boot@; but please keep the discussion on debian-devel@.] Unless I deeply misunderstand how locales work in Debian, I believe that any dependency on the ‘locales’ package is ought to be satisfied with locales-all as well. Could the maintainers of the packages below please check if the ‘| locales-all’ alternative can indeed be added to Depends:? (I’ve tried to limit the list to testing, but some slippage from stable might have occurred. My apologies if that’s the case.) Otherwise, would there be any problem with me mass-filing bug reports on this issue? TIA. cloud-init 20.1-2 …, locales, … collatinus 11-1+b2 …, locales, … kopano-contacts 8.7.0-7 …, locales kopano-l10n 8.7.0-7 locales live-task-standard 11.0.2 …, locales, … orthanc 1.6.1+dfsg-1…, locales, … task-bosnian3.58…, locales task-croatian 3.58…, locales task-english3.58…, locales task-norwegian 3.58…, locales task-swedish3.58…, locales task-turkish3.58…, locales, manpages-tr x2gothinclient-displaymanager 1.5.0.1-5 …, locales, … localehelper0.1.4-3 locales, perl:any localepurge 0.7.3.8 …, locales, ucf, procps The last two packages seemed like they could benefit from closer inspection. As it turns out, at least localehelper is just a wrapper to run localedef on missing locales; presumably this code path would simply never be followed with locales-all installed. Background I prefer locales-all over locales on my systems for the following reasons: 1. interest in languages in general; I want for any locale provided by Debian to be at hand at all times; 2. several of the systems I maintain are multi-user; I don’t want to spend brain cycles deciding which locales they may or may not want to use; 3. on backup, I feel safe to ignore anything that matches its md5sum – as recorded in the respective .deb --ctrl-tarfile; locales-all have that aplenty; locales, not as much (IIUC.) -- FSF associate member #7257 http://am-1.org/~ivan/
You removed Weboob package over pollitical reasons?Whole Internet laughs at you
>500 comments at Slashdot, >200 at Phoronix and >1000 at linux org ru! See now? When a technical project starts making their decisions over pollitical reasons rather than technical, it is doomed. Good time to switch to a similar distro with mentally sane leadership, like Devuan. Also what's good about Devuan : Devuan does not use System8==D as its' init system! SystemD contains >1 million lines of bloated code and lots of vulnerabilities have been found there and countless haven't, also the SystemD creators are arrogant and refuse to fix many discovered security vulnerabilities, to a point where they've been awarded a " Pwnie award " for refusing to fix a critical vuln. That is why I prefer the distros which are using something else as init system: either good old SysV, or something more modern like OpenRC (at Artix Linux) or runit (at Void Linux) , just not systemd! There are only a few such distros left because of Redhat pressure, and luckily Devuan is one of them. If you found Debian as useful before it went nuts then maybe you'd like Devuan, or even some other distros that I mentioned: Artix Linux =Arch with a human face (has GUI + everything configured by default, nice GUI package manager and convenient to use even for the beginners), and Void Linux -amazingly fast distro really suitable for old PCs, but lacks some packages so you'd need to compile the things from source once in a while, in comparison Artix has almost the same set of packages as Arch. Both Artix and Void are very stable despite their packages are really new and they are among the first to get new Linux kernels with fresh drivers. Or maybe MX Linux, one of the top popularity distros nowadays which is also "no systemd" and somehow only recently I learned about it Best regards, Ivan Ivanov, open source firmware developer
Re: no{thing} build profiles
>>>>> Jonathan Dowland writes: >>>>> On Tue, Oct 23, 2018 at 11:45:26PM +0200, Marco d'Itri wrote: >>>>> On Oct 23, Tollef Fog Heen wrote: >>> Wouldn’t it make more sense for mutt to just go «oh, no GPG >>> installed, let’s note that there are signatures here, but they >>> can’t be verified, since there’s no GPG installed on the system» >>> and let the user know that? No need to actually disable PGP >>> support. >> Yes. Because this way the default configuration will be useful both >> before and after gnupg will have been installed. > That is sort-of what is happening for neomutt (20171215+dfsg.1-1) at > least, it reports >sh: 1: gpg: not found > There’s room for improvement there. mutt (1.9.2-1) is worse >Error: verification failed: Unsupported protocol > both with the default configurations. What are the values of the crypt_use_gpgme setting in each case? Could it be that mutt and neomutt actually have different defaults (one using gpg(1) directly and the other using GPGME) here? -- FSF associate member #7257 http://am-1.org/~ivan/
Re: no{thing} build profiles
>>>>> Wouter Verhelst writes: >>>>> On Mon, Oct 22, 2018 at 11:12:57PM +0200, Adam Borowski wrote: >>>>> On Mon, Oct 22, 2018 at 01:22:12PM -0700, Russ Allbery wrote: […] >>> I think the prerequisite for making a change like this would be for >>> the library to be able to surface this transitive requirement in >>> metadata so that debhelper could support automatically adding it >>> to the dependencies of all linked programs (and I’m not sure that >>> sort of collapse of our dependency structure is a good idea). >> That would be a bad idea – we don’t want gratuitous dependencies >> all around. Just because I use xfce doesn’t mean I want a daemon >> for some old kinds of iApple iJunk > Why not? What does it cost you, other than a few bits on your hard > disk, to have those things installed? > It is an actual cost for users who do not (want to) understand the > technical background in why their iSomething doesn’t communicate with > Debian properly, and it costs *us* time in support questions if we > have to explain to them that they just need to install this one > little thing here that takes a few MB (if that; haven’t checked). It works both ways, actually. I’ve recently seen a problem with a newly installed system ending up with /two/ configured IPv4 addresses (where one was expected.) The cause of this surprise? Recommends:¹. More specifically, the admin there installed isc-dhcp-client and configured interfaces(5) accordingly. He also installed lxqt, which Recommends: cmst, which in turn Depends: connman (entirely appropriately, I guess, as the former is a GUI for the latter), which /also/ configures network interfaces. ¹ Not entirely, obviously. But the claim that ‘more is better,’ and leads to ‘lack of surprise’ and a ‘more straightforward user experience’ isn’t without a flaw when it comes to practice. > My laptop, which has a 240G SSD, is mostly full. That is, however, > *not* because of the amount of software that’s installed; 90% of that > storage is in my /home. > I suspect that the same is true for most users, and therefore that we > just shouldn’t care about it. The disk usage is indeed a concern, even if likely minor for an average user. Consider, for instance, that you run a dozens of VMs and want Mutt installed on every single one. Unless you use LXC on Btrfs with transparent deduplication there, the gnupg and its own dependencies may accumulate into a non-trivial disk usage. Alternatively, if you perform incremental block-level backups of the root filesystem (and I do), every update to the gnupg package (within the archive retention time) – as well as each of its unique dependencies – will add the respective Installed-Size: to the archive size. Another issue is that GnuPG, being called from Mutt automatically by default, /does/ increase the attack surface. Of course, you can (remember to) turn it off in the configuration, but the more /straightforward/ way to avoid that is /not to install/ the package in the first place. In general, the software that you do /not/ have installed, is most certainly /not/ going to break. Then, there’s the issue of surprise. The software which hooks into other software that you use /can/ surprise you. For example, the bash-completion package makes Bash completion function unusable to me; so I usually do not install it at all, and where it is installed, I make sure to disable it with ‘complete -r’ in my personal configuration. To summarize, I’d expect for a non-trivial fraction of experienced users to actually put effort into minimizing the amount of /code/ installed – precisely to /ensure/ straightforward and unsurprising behavior. As for GnuPG, well, as Mario points out, – it’s useless unless configured by the user, /and/ is prone to result in ‘cryptic’ error messages even if correctly installed. In turn, to configure GnuPG, the user will presumably have to invoke it directly, or perhaps from some UI wrapper, at which point he either will notice the absence of the command, /or/ the absence of said wrapper – for which it /would/ be entirely reasonable to depend on gnupg. So the particular point that Mutt is going to misbehave without GnuPG installed is moot: the cause for its misbehavior wouldn’t be the lack of GnuPG, but rather the lack of user’s knowledge of it – or motivation to use. -- FSF associate member #7257 http://am-1.org/~ivan/
Re: tinysshd dependency on systemd
>>>>> Jonathan Dowland writes: >>>>> On Sun, Oct 21, 2018 at 09:57:45PM +, Ivan Shmakov wrote: >> I disagree; to the best of my knowledge, anyone can do the testing >> and suggest any fixes he or she deems necessary. As such, having an >> issue recorded in the BTS is preferable to not having it recorded, >> and having a (semi-correct) > > You win the prize for the most Orwellian spelling of "untested and > broken" that I've seen today. (so far.) If this comment has some purpose conductive to free software development, I’m afraid it has so far eluded me. (Though I suppose I can be glad for you if you’ve found my wording amusing.) > Whilst you wasted your time (and ours) on this side-show, If reading my messages on debian-devel@ takes a non-trivial amount of time for you, may I suggest that you filter them out? As for the assessment of how productive my efforts are – please don’t; I’m perfectly capable of doing that myself. > the actual maintainer has actually fixed the dependency problem > (a one line change in the control file) From whence I’ve found it adequate to probe if an effort to fix the apparent violation of Policy 9.11 (quoted below) would be appreciated. […] However, any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV-style init script with the same name as and equivalent functionality to any init-specific job, as this is the only start-up configuration method guaranteed to be supported by all init implementations. — http://debian.org/doc/debian-policy/ch-opersys.html#alternate-init-systems -- FSF associate member #7257 http://am-1.org/~ivan/
Re: no{thing} build profiles
>>>>> Jonathan Dowland writes: >>>>> On Sun, Oct 21, 2018 at 10:00:43PM +, Ivan Shmakov wrote: >> It can be argued that libgpgme11 does not “provide a significant >> amount of functionality” (7.2) without gnupg. > It won’t function at all without gnupg. As I’ve said before, having libgpgme11 installed enables me to install (neo)mutt. It’s all the functionality that I need from that package. If you know of a way to install the latter without also installing the former – I’d appreciate if you’d share. (There’s of course an easy way to install libgpgme11 without installing gnupg, which is via the equivs package.) >> However, and it seems to be a common practice in Debian, for a >> shared library package that ‘functionality’ can be understood first >> and foremost as /allowing the packages dependent on said shared >> library package to run correctly./ (The ubiquity of said practice >> is evident from how libmariadbclient18 does /not/ depend on MariaDB > That’s because a MariaDB client can be installed on a different > machine to a MariaDB server. Or not; it’s perfectly sensible to install libmariadbclient18 on one host and have no MariaDB server running anywhere at your site. It’s something I’ve been doing since before it was called ‘MariaDB.’ Similarly for, say, libaudio2: it was quite a while ago that I ran nasd(1), but I still have the library installed – simply because it allows me to install mpg123. Or libavahi-client3, libdbus-1-3, libpulse0, and probably several other packages I cannot recall the names of right noow that I’m not interested in running the respective servers for anywhere on my network. […] > The same is not true for libgpgme11. I beg to differ, per the above. -- FSF associate member #7257 http://am-1.org/~ivan/
Re: no{thing} build profiles
>>>>> Andrey Rahmatullin writes: >>>>> On Sun, Oct 21, 2018 at 05:33:57PM +, Ivan Shmakov wrote: >>> "Every package must specify the dependency information about other >>> packages that are required for the first to work correctly." >>> Policy 3.5. >> The gnupg package is not required for (neo)mutt to work correctly, >> at least as of Debian Stretch. > That's why neomutt only Suggests gnupg. Arguably, libgpgme11 should do the same. It can be argued that libgpgme11 does not “provide a significant amount of functionality” (7.2) without gnupg. However, and it seems to be a common practice in Debian, for a shared library package that ‘functionality’ can be understood first and foremost as /allowing the packages dependent on said shared library package to run correctly./ (The ubiquity of said practice is evident from how libmariadbclient18 does /not/ depend on MariaDB, or how libxt6 does /not/ depend on an X server package, and so on, and so forth.) >> Could you please clarify your point? > I was quoting you and saying that you are contradicting the Policy. I think I’ve provided sufficient evidence to refute this claim. -- FSF associate member #7257 http://am-1.org/~ivan/
Re: tinysshd dependency on systemd
>>>>> Vincent Bernat writes: >>>>> ❦ 21 octobre 2018 18:12 GMT, Ivan Shmakov : >>> so if you were an actual user, I would propose you file a bug >>> report against the package to let the maintainer knows the >>> dependency is too strong for your use (and maybe propose a patch to >>> integrate with inetd). >>> As you are not, please, do not. Our resources are scarce and we >>> already cater for the need of many non-existent users. >> You know, in almost twenty years of using GNU/Linux, I think it’s >> the first time I’m requested /not/ to report bugs and contribute >> patches. How times did change, indeed! > Well, reporting bugs about software you don’t care or patches you > don’t test is not always useful. For example, you clearly didn’t > test your wrapper (shebang is #!/usr/sh) nor the init script > (/lib/init/init-d-script is expecting the daemon to fork.) Indeed; I even said that much in my posting. (Meanwhile, one another issue I’ve found is that the wrapper lacks a trailing ‘exit 1’.) AFAICT, the init.d script issue can be fixed by adding START_ARGS=--background there. > The maintainer would have to do the testing, possibly the immediate > fixes and all the future maintenance. Just for you to make a point. I disagree; to the best of my knowledge, anyone can do the testing and suggest any fixes he or she deems necessary. As such, having an issue recorded in the BTS is preferable to not having it recorded, and having a (semi-correct) patch on file is preferable to not having any patch at all. If maintainer decides resolving the issue is not worth the effort, the (wishlist) bug can stay in the BTS indefinitely. The maintainer can as well make /that/ a point. -- FSF associate member #7257 http://am-1.org/~ivan/
tinysshd dependency on systemd
>>>>> Vincent Bernat writes: >>>>> ❦ 21 octobre 2018 13:15 GMT, Ivan Shmakov : >>>>> ‘TFH’ == Tollef Fog Heen writes: […] TFH> tinysshd only ships a systemd unit file; neomutt links against TFH> libgpgme11 which again Depends on gnupg. It’s the kind of TFH> dependencies that individually make sense, >> I beg to differ; I suppose (though haven’t actually tried) I can >> start tinysshd straight from rc.local just as well, or even write my >> own init.d script, right? Having the dependency in place just makes >> it harder to me to contribute an init.d script for the package. > tinysshd requires some kind of socket server to run. It could run > from inetd, Reading tinysshd(8), I see that it can also be started from tcpserver(8) or BusyBox’ tcpsvd (which doesn’t seem to be available in Debian yet.) Or, I suppose, socat(1)? Say: # setsid -- socat TCP6-LISTEN:22,fork \ EXEC:"tinysshd -v /etc/tinyssh/sshkeydir" & Contrary to running from Inetd, the use of the likes of socat(1) and tcpserver(8) can readily be adapted for an init.d script (or, rather, init-d-script(5) DAEMON wrapper), which in turn allows the user to control the daemon with the usual service(8). Examples (untested) of such a wrapper and a corresponding init.d script are MIMEd. > so if you were an actual user, I would propose you file a bug report > against the package to let the maintainer knows the dependency is too > strong for your use (and maybe propose a patch to integrate with inetd). > As you are not, please, do not. Our resources are scarce and we > already cater for the need of many non-existent users. You know, in almost twenty years of using GNU/Linux, I think it’s the first time I’m requested /not/ to report bugs and contribute patches. How times did change, indeed! -- FSF associate member #7257 http://am-1.org/~ivan/ #!/usr/sh ### tinysshd-wrapper -*- Sh -*- ## Run tinysshd via socat(1) or tcpserver(8), whichever is available. ### Ivan Shmakov, 2018 ## To the extent possible under law, the author(s) have dedicated ## all copyright and related and neighboring rights to this software ## to the public domain worldwide. This software is distributed ## without any warranty. ## You should have received a copy of the CC0 Public Domain Dedication ## along with this software. If not, see ## <http://creativecommons.org/publicdomain/zero/1.0/>. ### Code: set -e TINYSSHD=/usr/sbin/tinysshd SSHKEYDIR=/etc/tinyssh/sshkeydir PORT=22 PREFERENCE="socat tcpserver" test -r /etc/default/tinysshd-wrapper \ && . /etc/default/tinysshd-wrapper run_socat () { ## . exec socat TCP6-LISTEN:"$PORT",fork \ EXEC:"$TINYSSHD -l -v $SSHKEYDIR" } run_tcpserver () { ## . exec tcpserver -HRDl0 0.0.0.0 "$PORT" \ "$TINYSSHD" -v "$SSHKEYDIR" } for p in ${PREFERENCE} ; do type "$p" > /dev/null || continue ## . run_"$p" done printf %s\\n "FATAL: Neither of ${PREFERENCE:-(none?)} are available" >&2 ### tinysshd-wrapper ends here #!/lib/init/init-d-script ### BEGIN INIT INFO # Provides: tinysshd # Required-Start: $remote_fs $syslog # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description:minimalistic (subset of) SSHv2 server ### END INIT INFO DESC="minimalistic (subset of) SSHv2 server" DAEMON=/usr/sbin/tinysshd-wrapper
Re: no{thing} build profiles
>>>>> Andrey Rahmatullin writes: >>>>> On Sun, Oct 21, 2018 at 01:15:21PM +, Ivan Shmakov wrote: >>>>> Tollef Fog Heen writes: >>> tinysshd only ships a systemd unit file; neomutt links against >>> libgpgme11 which again Depends on gnupg. It’s the kind of >>> dependencies that individually make sense, >> Semantically, Depends: declares that the package has to be installed >> to proceed. It doesn’t specify whether the package has to actually >> be used. Which kind of invalidates the point. > "Every package must specify the dependency information about other > packages that are required for the first to work correctly." Policy 3.5. The gnupg package is not required for (neo)mutt to work correctly, at least as of Debian Stretch. There’s evidence that neither is systemd required for tinysshd, although I haven’t tested that myself. > "The Depends field should be used if the depended-on package is > required for the depending package to provide a significant amount of > functionality." Policy 7.2. Also doesn’t apply; I’ve used stretch/mutt alongside a dummy ‘Provides: gnupg (= 2.0)’ package rather extensively without encountering any ill effects. At the same time, tinysshd(8) provides examples on how to run the daemon via tcpserver(8) and inetd(8) (and hence without systemd.) Could you please clarify your point? -- FSF associate member #7257 http://am-1.org/~ivan/
Re: Debian Buster release to partially drop non-systemd support
>>>>> Ian Jackson writes: >>>>> KatolaZ writes: >> The problem that spurred this thread is that sysvinit needs a >> maintainer. That’s why some of us are here: our intention is to >> help with maintaining sysvinit in Debian if possible, since we will >> keep maintaining it in Devuan nevertheless. > Thank you. That would be awesome. Indeed; I’m going to seize this opportunity to express my gratitude to those who now volunteer to take care of sysvinit and related packages in Debian! And I’m looking forward to contribute to the effort myself. […] > Please come to debian-init-divers...@chiark.greenend.org.uk. Do you plan to also make that list accessible via NNTP (perhaps via either Gmane or the bofh.it gateway operated Marco d’Itri)? TIA. […] -- FSF associate member #7257 http://am-1.org/~ivan/
Re: no{thing} build profiles
> Sune Vuorela writes: > On 2018-10-21, Jonas Smedegaard wrote: > Tollef Fog Heen writes: [I see I’ve managed to botch References: for the news:linux.debian.devel readers; my apologies for that.] >>> tinysshd only ships a systemd unit file; neomutt links against >>> libgpgme11 which again Depends on gnupg. It’s the kind of >>> dependencies that individually make sense, I beg to differ; I suppose (though haven’t actually tried) I can start tinysshd straight from rc.local just as well, or even write my own init.d script, right? Having the dependency in place just makes it harder to me to contribute an init.d script for the package. Semantically, Depends: declares that the package has to be installed to proceed. It doesn’t specify whether the package has to actually be used. Which kind of invalidates the point. >>> but where libgpgme11 should probably have a Recommends: gnupg, not >>> Depends. >> I disagree that libgpgme11 should depend/recommend/suggest gnupg >> at all: As a library it cannot possibly declare how tight a >> relationship to declare - instead, all _consumers_ of the library >> must declare whether they depend/recommend/suggest gnupg. I suppose I can agree with that. AFAICR, the libgpgme11 maintainer was concerned that some of the users of the library may break if gnupg is not available. (Investigating that is still in my to-do list. Don’t hold your breath, however.) > libgpgme is completely useless without gnupg. In the context of the present discussion, the libgpgme11 package /is/ useful even in absence of gnupg: it allows neomutt to be installed. Much like libmariadbclient18 allows me to install exim4-daemon-heavy, and libxt6 does the same for mpg123. The fact that I’m not interested in transparent OpenPGP support under NeoMutt, or that I don’t typically run mpg123(1) under X (much less use NAS for audio output), or that I never use MariaDB at all, – is utterly irrelevant. > I think it is perfectly fine for these kind of relations, unless we > really are in corner-case territory. See for example fam. Could you please elaborate on that? -- FSF associate member #7257 np. Cybernoid 2 Piano Live — Noviello Pippo
no{thing} build profiles
> Bastian Blank writes: > On Sat, Oct 20, 2018 at 06:54:07PM +0200, Arne Babenhauserheide wrote: > Ansgar Burchardt writes: >>> Should Debian also support “noalsa”, “noavahi”, “nocups”, >>> “nopulseaudio”, “nosysvinit”, “nodbus”, “nopam”, “nowayland”, So long as there’s sufficient interest among the developers? Sure, why not? >> Are alsa, avahi, cups, pulseaudio, sysvinit, dbus, pam and wayland >> all similar in scope to systemd? If not, then this question is a >> strawman. > Yes, they all completely took over their field and have a lot of haters. AFAICT, that’s, for the most part, untrue. For instance, I do /not/ run Avahi (why for?), Cups (I use an ad-hoc wrapper around foo2zjs instead), Pulseaudio (for there’s ALSA, but also NAS and JACK should I need them), D-Bus (although I admit I’ve had to implement a “no-dbus.perl” stub non-server to work around Bug#868453), or Wayland (huh?) And I suppose those who run Systemd don’t run SysVinit just as well. Granted, I know of no way to use audio on Debian GNU/Linux without ALSA; and I know of no way to avoid running PAM, either. Now, unless I be mistaken, “build profiles,” as suggested in this subthread, are meant to allow for building packages with specific changes to their run-time library dependencies? Frankly, I don’t see much of a problem with that – assuming that the libraries are “well-behaving,” that is. I can see an application's run-time dependency on the presence of client PostgreSQL, MySQL and MS SQL libraries at run-time as necessary evil. Having that application pull one or more of the respective servers per Depends: is something I tend to consider a bug. (BTW, while we're at it, could someone please explain me what tinysshd [1] does need systemd for? Or why installing neomutt has to invite gnupg along?) [1] http://packages.debian.org/sid/tinysshd -- FSF associate member #7257 np. Green Beret (title theme) — Johan Andersson
Bug#885906: ITP: piu-piu -- Horizontal scroller game in bash for cli
Package: wnpp Severity: wishlist Owner: Ivan Marov * Package name: piu-piu Version : 1.0.0 Upstream Author : Ivan Marov * URL : https://github.com/vaniacer/piu-piu-SH * License : MIT Programming Lang: bash Description : Horizontal scroller game in bash for cli This is an Old School horizontal scroller 'Shoot Them All' game in bash. With multiplayer modes team and duel. You have to defeat 100 aliens to fight with Boss. I'm using netcat for client-server exchange in multiplayer mode. So netcat have to be installed on system if you wish to play with friend. Terminals on both hosts have to be with equal dimensions.
Re: debian/control file: how to selectively suppress recommends?
>>>>> Marcel Partap writes: > Dear fellow Debianauts, right now I am in the process of migrating my > selection of manually installed packages to a freshly debootstrapped > install using a set of meta-packages built with equivs. While that > works nice and well, in some instances, I would like to limit the > number of recommends being pulled in, without turning recommends off > completely (the meta-packages themselves use > Recommends:dependencies). So the --no-install-recommends parameter > or APT::Install-Recommends "0" are of no help in this case. Any > ideas how to block installation of only some packages' > recommendations? Use apt_preferences(5)? Like, say: $ cat < /etc/apt/preferences.d/thanksbutnothanks.pref Explanation: Certain packages are not welcome here. Package: systemd-sysv upstart dbus dbus-x11 gconf-service ssl-cert acpi-support-base tsconf Pin: release c=main Pin-Priority: -42 $ -- FSF associate member #7257 http://am-1.org/~ivan/7D17 4A59 6A21 3D97 6DDB
Re: make dpkg-buildpackage default locale UTF-8
>>>>> Tollef Fog Heen writes: >>>>> Ivan Shmakov >>>>> Hans-Christoph Steiner writes: >>> Package: dpkg-dev >>> More and more packages are adding unicode files >> I assume you mean “UTF-8 filenames” here (per below), right? >>> as unicode support has become more reliable and available. >> What are the use cases for such filenames? > Accurate representation of what they contain. wnorwegian contains a > file «bokmål» which is the word list for the form of Norwegian known > as bokmål. There's a convenience link between it and bokmaal so that > people without Norwegian keyboard (or without compose keys) can type > it too, but the canonical name is bokmål, not bokmaal. It does indeed seem natural, when it comes to packages providing support for a specific language, to use filenames in that same language; I’m not going to strongly object to that. However, I’d like to note that other wordlist packages appear to stick to English (and ASCII) filenames. For instance, wfrench uses ‘french’ (instead of français) and witalian uses ‘italian’ (instead of italiano.) At the same time, were these files intended for mainly ‘machine’ use, I guess I’d rather prefer them to stick to ISO 639 instead. Just like the ‘locale’ system already does. I’m still curious, are there any other uses in the archive beside the above? > (I see there's a small bug where the symlink is the wrong way around, > I'll get that fixed.) > å is in latin1, though so fonts should not be a problem in your > particular case. Yes. -- FSF associate member #7257 np. Graceful Flame — Radiarc 3013 B6A0 230E 334A
Re: make dpkg-buildpackage default locale UTF-8
> Hans-Christoph Steiner writes: > Package: dpkg-dev > More and more packages are adding unicode files I assume you mean “UTF-8 filenames” here (per below), right? > as unicode support has become more reliable and available. What are the use cases for such filenames? FWIW, I more than just occasionally use Debian in environments with fonts lacking good (as in: ≥ 90%) Unicode, or even BMP, coverage. (Specifically, I’m for the most part interested in Latin-1, -3, and Cyrillic characters only.) Do you suggest that there’re filenames in Debian packages that cannot be rendered in such environments? If so, that’d certainly be a nuisance for me. > The package building process is not guaranteed to happen in a unicode > locale since the Debian default locale is LC_ALL=C, which is ASCII > not UTF-8. Reading UTF-8 filenames when the system is using ASCII > causes errors (Python makes them very visible, for example). […] -- FSF associate member #7257 np. Fear of the Dark — Iron Maiden B6A0 230E 334A
Naming of network devices
> Marvin Renich writes: […] > The only benefit I have seen between the new scheme and the previous > one is that there is no state file. While getting rid of the state > file is a nice goal, it is extremely minor compared to having short, > simple names in common use cases like inserting a wifi usb dongle. > And no, enp2s0f1 is neither short nor simple. It requires > remembering three numbers and three letters that identify internal > parts of the hardware hierarchy that are irrelevant to the sysadmin. > With the previous scheme, an interface would be assigned a short, > simple name the first time it was seen. The sysadmin could easily > edit the state file to give it a more meaningful name, if desired. > The state file already had all the other information needed to > identify the interface; a simple one-word change in the file was > sufficient. Whatever name was in the state file was used for that > piece of hardware from then on. The names were at least as > predictable as they are with the new scheme. Somewhat recently I’ve got a bunch of nearly identical servers to care about. With the /persistent/ (pre-Stretch) interface names, were I to, say, move an HDDs from one box and into another, I'd likely to end up with some “new” ethN interface names unaccounted to in interfaces(5), and possibly other places. Some manual intervention would be required. With the /predictable/ (Stretch) interface names, I’d get a fully operational system outright. I admit that the new scheme makes considerably less sense for the cases where you have /no/ spare identical hardware. (As such, I’ve added a -persistent-net.rules to the udev configuration on my few new Debian installs.) > With the new scheme, if I want to rename the interface to something > more meaningful, I have to go find an older machine that already has > a persistent-net.rules file or read through a lot of documentation to > figure out the correct syntax. I then have to determine the correct > ATTR elements to identify the interface in question, and type all of > that information by hand, hoping I type everything correctly. I concur that there ought to be some more user-visible documentation concerning the differences and how to get the behavior the user desires. > There is an easy fix to revert the default behavior while still > allowing knowledgeable sysadmins to get the new behavior. On the > other hand, those who need to administer systems but are not > sysadmins by trade (and thus will have to do significantly more > research to even know that the older behavior is possible) are the > ones who need the older behavior as the default. -- FSF associate member #7257 np. Home (Instrumental) — Jeff Burgess 230E 334A
Recommends-If-Manual: ?
>>>>> Russ Allbery writes: >>>>> Ivan Shmakov writes: >>>>> Adam Borowski writes: >>> libtasn1-doc: libtasn1-6-dev >>> * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is), >>> pulled in by a very-widespread library (gnutls) >> That’s Abstract Syntax Notation One (or ASN.1), and while I use it >> all the time (notation, that is; not this specific library at the >> moment), I see no reason for a -dev package to depend on a -doc one >> any stronger than with a mere Suggests:. > We have some specific Policy about this: > https://www.debian.org/doc/debian-policy/ch-docs.html#s-docs-additional […] > package should declare at most a Suggests on package-doc. Otherwise, > package should declare at most a Recommends on package-doc. > If you feel that this should cap the dependency at Suggests across > the board, feel free to submit a bug against debian-policy. Actually, no, “transitively bad” above seems like a correct assessment. While I dislike adding any more complexity to APT dependencies, can there perhaps be a separate Recommends-If-Manual: list of packages to only be installed when the depending package is marked as manually installed (as per apt-mark(8); and when recommended packages are otherwise considered for installing, as per APT::Install-Recommends)? To ensure backward compatibility, this condition would have to also apply for the packages also in the Recommends: list. Moreover, for one release cycle, any packages with Recommends-If-Manual: would have to have that same dependencies duplicated in Recommends: as well. […] -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: Too many Recommends (in particular on mail-transport-agent)
> Adam Borowski writes: > On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote: >> Maybe someone has a list of things they view as Recommends inflation >> that have (a) been reported as bugs to the appropriate package >> maintainers, and (b) have been rejected by those package >> maintainers? Those are the controversial ones that we'd need to >> talk about. […] > bash-completion: bash dput-ng licensecheck > * DEBATABLE: I like the Tab key to do something reasonable, > "bash-completion" means you never know what you'll get. FWIW, I agree wholeheartedly with this one. (The only reason I don’t have ‘complete -r’ in my ~/.bashrc is that bash-completion is rarely if ever installed on the systems I frequently use.) […] > freedoom | game-data-packager: prboom-plus > * DEBATABLE: freedoom is too ugly to live, shareware Doom has assets > missing for running pretty much anything Doom-related (and AFAIK its > license forbids add-ons). On the other hand, this is an excuse for > Doom engines in main. The latter seems like a good enough reason for this dependency. > freepats: libwildmidi-config timidity > * BAD: freepats is too ugly to live: abysmal quality, lacks > instruments for pretty much any .mid file in the wild. We do have a > bunch of good alternatives. timgm6mb-soundfont for one is 5.6 times > smaller yet is complete. Probably a relic of the days long gone; I guess it should be updated to include some more alternatives (in preference to freepats) – so long as timidity can (be made to) actually use any of them “out-of-box.” Package: freepats Version: 20060219-1 … Description-en: Free patch set for MIDI audio synthesis … It is, however, the sole DFSG-compliant patch set in existence so far. New patches (including those in better formats, such as SF2 SoundFont banks) are welcome. […] > gfortran-mingw-w64: gcc-mingw-w64 > * BAD: seriously, Fortran? Fortran is still widely used (in niche applications; WRF comes to mind), but I see no good reason for this dependency. > ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm > * BAD: why would editing images care about a grossly obsolete > _document_ format? So that one can $ convert pic.ps pic.png? Or (I suspect) $ convert file.pdf file.png, for that matter. (Or perhaps more sensibly: $ display pic.ps pic.pdf.) Moreover, PostScript is a programming (code) language – not a (data) format. I’m neutral on this dependency, though. I do like PostScript for a document format as much as I do like JavaScript for the same, but I see how it may be nice to support .ps (and .pdf?) rasterization in ImageMagick and Gimp “out-of-box.” […] > gnat-mingw-w64: gcc-mingw-w64 > * BAD: see Fortran. Agreed. > gnupg-l10n: gnupg > * DEBATABLE: I don't think anyone tech skilled enough to use GPG > would have problems with English, but localization is important. > On the other hand, this is 4.5MB in the default install. Well, ‘locales’ is about 9 MiB in the same, so… […] > libhtml-format-perl: libhtml-tree-perl libwww-perl > * : wut? … Me neither. > libhttp-daemon-perl: libwww-perl > * TRANSITIVELY BAD: dependency comes from a client package; if I want > to run a http server I know where to find it That’s only Installed-Size: 71, so I don’t see much of a problem. AIUI, libwww-perl (as per upstream) had the HTTP::Daemon library for decades, thus not installing one by default in Debian may easily surprise an unsuspecting user. […] > libpackage-stash-xs-perl: libpackage-stash-perl > * TRANSITIVELY BAD: dependencies pulling more dependencies, why? I suppose that’s so one’s Perl script can be Architecture: all, instead of depending on either pure-Perl or an XS (binary) implementation of the package – depending on the architecture. […] > libpurple-bin: libpurple0 > * BAD: a library has no reason to install programs My exact reaction on seeing that Mutt transitively Depends: on GnuPG – all thanks to libgpgme11 depending on the latter. I do not know about this specific case, but I very much agree with the principle. […] > libtasn1-doc: libtasn1-6-dev > * TRANSITIVELY BAD: probably useful if you do TASN (whatever it is), > pulled in by a very-widespread library (gnutls) That’s Abstract Syntax Notation One (or ASN.1), and while I use it all the time (notation, that is; not this specific library at the moment), I see no reason for a -dev package to depend on a -doc one any stronger than with a mere Suggests:. […] > transfig: inkscape > * BLOAT: a badly obsolete image format, pulls in ghostscript and > other crap Curiously enough, I still find XFig – with all its nume
Re: when should we esmtps our mxes?
>>>>> Ben Hutchings writes: >>>>> On Mon, 2016-10-24 at 15:15 +, Ivan Shmakov wrote: >>>>> Ben Hutchings writes: […] >>> Those certificates look as expected. Since TLS encryption of SMTP >>> between servers is opportunistic, there's no particular reason to >>> use a widely trusted CA for server certificates. A MITM can just >>> as easily block STARTTLS as substitute their own key. My point is: the absence of ‘TLS’ in Received: is a cleaner indication of the possible tampering of the message. On the contrary, its presence in the headers and (or) MX logs may turn to be misleading when the sending side routinely disregards the absence of a valid signature on the certificate. The “opportunisticity” of ESMTPS does not seem relevant. >> That’s not necessarily any different to the HTTP(S) case. >> For instance, when the user first uses ‘example.com’ as the resource >> identifier, the Web user agent (usually) issues a GET request to the >> said host’s HTTP server in the plain. At which point the server >> responds with a 302 redirect, pointing to the resource proper (say, >> https://example.com/.) >> That behavior is hardly any less opportunistic, and is prone to the >> very same attack, as demonstrated by ‘sslstrip’. > Although that's mitigated by HSTS and bookmarking of https: URLs. It’s been argued that, as all the CAs are trusted equally (if at all) by the user agent, it makes sense to minimize the number of CAs trusted by any specific user – so to reduce the “attack surface” – and, if necessary, rely on “security exceptions” instead for the HTTPS sites that use X.509 certificates signed by marginal (with respect to that same specific user) CAs. Obviously, implementing RFC 6797 “No User Recourse” provision to the letter makes that impossible. Now, given that it seems way easier to disable HSTS support altogether in the user agent than to patch one up to get some more sensible behavior… That said, I see no reason there can’t be some STRICTSECURITY EHLO keyword, analogous in function to the HSTS header. Of course, so long as non-TLS ESMTP remains functional – something that, unfortunately, gradually goes away for HTTP. […] PS. Now, it makes me wonder, since when are we standardizing applications to give more heed to the whims of the remote’s administrator than to the application’s own user? Free software used to be better than that; or so I recall. -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: when should we esmtps our mxes?
> Ben Hutchings writes: […] > Those certificates look as expected. Since TLS encryption of SMTP > between servers is opportunistic, there's no particular reason to use > a widely trusted CA for server certificates. A MITM can just as > easily block STARTTLS as substitute their own key. That’s not necessarily any different to the HTTP(S) case. For instance, when the user first uses ‘example.com’ as the resource identifier, the Web user agent (usually) issues a GET request to the said host’s HTTP server in the plain. At which point the server responds with a 302 redirect, pointing to the resource proper (say, https://example.com/.) That behavior is hardly any less opportunistic, and is prone to the very same attack, as demonstrated by ‘sslstrip’. Yet, I’d find that quite an uncommon reason to argue that we don’t need some widely trusted CAs for the HTTPS certificates. On the other hand, my MX setup relies on ‘exim4/relay_tls_dn’ files that contain the list of CNs of the remotes the MTA permits relaying mail from (that is: acts as a smarthost for.) Hence, TLS becomes rather mandatory in this case. (Although I have to admit that I don’t currently apply this approach in the “downstream” direction with any consistency.) -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: when should we esmtps our mxes?
>>>>> Julien Cristau writes: >>>>> On Mon, Oct 24, 2016 at 11:45:33 +, Ivan Shmakov wrote: […] >> Speaking of which. Does the gnutls-cli transcript MIMEd signify of >> an ongoing MitM attack, or is it just a misconfiguration? > Neither. > _25._tcp.bendel.debian.org. 3600 IN RRSIG TLSA 8 5 3600 > 20161202211237 20161023203831 7866 debian.org. > uCQU3vi1LA/bhjW51xETwZn3wWsLPFUvvW4BU1uUE8uJqzsQTdzNBWgW > +aIE9gOphLZ+zMdni/16QvAV8FWqJ77RZm5RoZFBZ9NbvF/OBgYqlKx/ > NpR79goHcI6NHMezAh6BF3PEE3gQjogAXlA9pLhf8hVyQh117sLHyVPt > sc/d+mJv9CTCiwSUqiG/e3V0je2dt7SpIcI+uxDL/pe/6dt3qSOE5hpH > xtvG1xaoYcF1UWGMP12j8LIK2V+sNRbq > _25._tcp.bendel.debian.org. 3600 IN TLSA 3 1 1 > 7D8AC6B95A22EFBE727768523798BC914AFA9F22A10F7847023E2D8A B982D234 Makes sense, thanks. Although I gather I won’t be seeing it actually working with my MX anytime soon. -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: when should we esmtps our mxes?
>>>>> Andrey Rahmatullin writes: >>>>> On Mon, Oct 24, 2016 at 11:45:33AM +, Ivan Shmakov wrote: >> $ gnutls-cli --starttls -p 25 bendel.debian.org […] >> Connecting to '82.195.75.100:443'... > I cannot reproduce gnutls-cli connecting to :443 when asked :25. Indeed, my mistake; I somehow managed to MIME the wrong transcript. Here’s the correct one. […] -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A Processed 173 CA certificate(s). Resolving 'bendel.debian.org'... Connecting to '2001:41b8:202:deb:216:36ff:fe40:4002:25'... - Simple Client Mode: 220 bendel.debian.org ESMTP Postfix EHLO test 250-bendel.debian.org 250-PIPELINING 250-SIZE 3072 250-STARTTLS 250-ENHANCEDSTATUSCODES 250 8BITMIME STARTTLS 220 2.0.0 Ready to start TLS *** Starting TLS handshake - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=bendel.debian.org,EMAIL=hostmas...@bendel.debian.org', issuer `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using RSA-SHA1, activated `2016-02-09 00:00:13 UTC', expires `2017-02-08 00:00:13 UTC', SHA-1 fingerprint `d99dffbab982a0bbca0f95cf88401f75d75a0194' Public Key ID: a6fa6354cd66e04bba4f3c3e5f45bf82afe17b61 Public key's random art: +--[ RSA 2048]+ | | |.| | . +. | |+ = . . | | +S+. .| | o+. .E .| | ...+ oo... | | .+oo.. | |.o.ooo.++. | +-+ - Certificate[1] info: - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org', issuer `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using RSA-SHA1, activated `2009-04-04 22:40:56 UTC', expires `2019-04-02 22:40:56 UTC', SHA-1 fingerprint `2bd080f1a4c79bae4d8ce3728fd2483b49ce4ca5' - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed
when should we esmtps our mxes?
> Kristian Erik Hermansen writes: > On Mon, Oct 24, 2016 at 1:59 AM, Adrian Bunk wrote: […] >> For the kind of attacks you are describing, https is just snake oil. > Profusely disagree and so do other members of this list. I'll leave > it at that, but also I should point out that your email is being > routed insecurely via welho.com and lacks TLS in transit, so I also > probably shouldn't consider your TLS knowledge very highly… Speaking of which. Does the gnutls-cli transcript MIMEd signify of an ongoing MitM attack, or is it just a misconfiguration? -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A $ dig +nocomment mx lists.debian.org … lists.debian.org. 3600IN MX 0 bendel.debian.org. … $ gnutls-cli --starttls -p 25 bendel.debian.org Processed 173 CA certificate(s). Resolving 'bendel.debian.org'... Connecting to '2001:41b8:202:deb:216:36ff:fe40:4002:443'... Connecting to '82.195.75.100:443'... - Simple Client Mode: *** Starting TLS handshake - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=bendel.debian.org,EMAIL=hostmas...@bendel.debian.org', issuer `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using RSA-SHA1, activated `2016-02-09 00:00:13 UTC', expires `2017-02-08 00:00:13 UTC', SHA-1 fingerprint `d99dffbab982a0bbca0f95cf88401f75d75a0194' Public Key ID: a6fa6354cd66e04bba4f3c3e5f45bf82afe17b61 Public key's random art: +--[ RSA 2048]+ | | |.| | . +. | |+ = . . | | +S+. .| | o+. .E .| | ...+ oo... | | .+oo.. | |.o.ooo.++. | +-+ - Certificate[1] info: - subject `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org', issuer `C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=Debian SMTP CA,EMAIL=hostmas...@puppet.debian.org', RSA key 2048 bits, signed using RSA-SHA1, activated `2009-04-04 22:40:56 UTC', expires `2019-04-02 22:40:56 UTC', SHA-1 fingerprint `2bd080f1a4c79bae4d8ce3728fd2483b49ce4ca5' - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** Handshake has failed
Re: client-side signature checking of Debian archives
> Eugene V Lyubimkin writes: […] > I'm not sure that benefits outweigh the costs. HTTPS requires that > I trust the third-parties – mirror provider and CA. Gpgv doesn't > require third parties. It does; you have to trust whatever source you’ve /initially/ got the public key from. Also, TLS does /not/ actually preclude the user from comparing the remote’s key with a copy stored locally. For Firefox/HTTPS, the respective functionality could be found in the Certificate Patrol add-on [1], for instance. > To me, that makes HTTPS (even with HPKP) principally weaker than > offline medium-agnostic cryptographic content checks. Or I am wrong > here, will the suggested HTTPS+HPKP+… scheme protect me from > government players? My understanding is that the suggestion being discussed is to use TLS /alongside/ the usual Debian/APT signatures – not instead of them; and the primary goal is to improve user’s privacy. That is: only the mirror operator will remain empowered to know the packages the user’s interested in. (As opposed to: the operators of all the networks the APT HTTP request passes through.) My concerns would be along the lines of [2] (“Remember that all mirror sites are donated to Debian: the hardware, […], and the sysadmin work to keep it running.”) Specifically, a plain-HTTP server is easier to configure and maintain. For one thing, when your server does /not/ use TLS, you don’t need to be concerned with the bugs and vulnerabilities of any TLS library whatsoever. [1] http://patrol.psyced.org/ [2] https://lists.debian.org/msgid-search/20161017142819.72lbe3kh346c4h62@exolobe3 -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: non-Debian software on ftp*.*.debian.org mirrors
>>>>> Lars Wirzenius writes: >>>>> On Sun, Oct 16, 2016 at 11:50:46AM +, Ivan Shmakov wrote: >> Doesn’t the presence of the ‘non-free’ section in the official >> Debian Release (InRelease) files /already/ mislead inexperienced >> people into thinking that such software is either part of Debian or >> endorsed by the project (or both)? > https://www.debian.org/social_contract point 5. > We're not exactly unclear about non-free and contrib. I'd say that those who can discern Debian non-free from Debian proper are at low risk of confusing, say, [1] with the "software [...] endorsed or even produced by Debian." [1] http://ftp.se.debian.org/mirror/opensolaris.com/ -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
non-Debian software on ftp*.*.debian.org mirrors
> Jakub Wilk writes: […] > On a semi-unrelated note: > Some of ftp*.*.d.o and cdimage.d.o mirrors serve random free (and > sometimes non-free) software that is not Debian[*]. This may mislead > inexperienced people into thinking that this software is endorsed or > even produced by Debian. Should we insist that only Debian is served > from these domains? > [*] See e. g.: https://ftp.se.debian.org/ Ahem. Speaking of non-Debian software… $ head < ftp.debian.org/debian/dists/stable/Release Origin: Debian Label: Debian Suite: stable Version: 8.6 Codename: jessie Date: Sat, 17 Sep 2016 11:38:03 UTC Architectures: amd64 arm64 armel armhf i386 mips mipsel powerpc ppc64el s390x Components: main contrib non-free Description: Debian 8.6 Released 17 September 2016 MD5Sum: $ Doesn’t the presence of the ‘non-free’ section in the official Debian Release (InRelease) files /already/ mislead inexperienced people into thinking that such software is either part of Debian or endorsed by the project (or both)? -- FSF associate member #7257 58F8 0F47 53F5 2EB2 F6A5 8916 3013 B6A0 230E 334A
Re: hdparm needs a new maintainer
Excellent point Ginfranco That will help me for sure when I had all the changes on package ready to upload. I was trying to build it for testing purposes, so as my very much appreciated debian mentor told me, adding the options -us -uc would suffice. Regards Ivan On Wed, Mar 2, 2016 at 10:57 AM, Gianfranco Costamagna < costamagnagianfra...@yahoo.it> wrote: > Hi, > > >igimenez@debian:~/debian/hdparm$ gbp buildpackage --git-ignore-new > [...] > running debsign failed > > > yes, you have to sign them. > By default the key is searched with a match on the debian/changelog last > entry. > You can override it by exporting > export DEBEMAIL='youremail' > export DEBFULLNAME='name surname' > export DEBSIGN_KEYID='key fingerprint' > export DEB_SIGN_KEYID='key fingerprint' > > on your bashrc file. > > this way you can sign with no issues and your key changes file with a > signature > from somebody else > (e.g. your sponsor will have to do it) > > cheers, > > G. >
Re: hdparm needs a new maintainer
Hi Alex Sorry if the question is dumb... Just cloned and while trying to build the package I got igimenez@debian:~/debian/hdparm$ gbp buildpackage --git-ignore-new [...] Now signing changes and any dsc files... signfile hdparm_9.48-1.dsc Alexandre Mestiashvili < a...@biotec.tu-dresden.de> gpg: skipped "Alexandre Mestiashvili ": secret key not available gpg: /tmp/debsign.I9P72zOS/hdparm_9.48-1.dsc: clearsign failed: secret key not available debsign: gpg error occurred! Aborting debuild: fatal error at line 1295: running debsign failed gbp:error: 'debuild -i -I' failed: it exited with 29 Does your changes require signing them or am I missing something ? Regards Ivan On Wed, Mar 2, 2016 at 12:23 AM, Ivan Gimenez wrote: > Alex > > Impressive upload. I have already checked out and I am starting to > understand how the gpb packager works out. > Thx for the links > > Regards > Ivan > > On Tue, Mar 1, 2016 at 7:57 PM, Alex Mestiashvili > wrote: > >> On 03/01/2016 06:11 PM, Raphael Hertzog wrote: >> > Hello, >> > >> > On Tue, 01 Mar 2016, Alex Mestiashvili wrote: >> >> As there are at least 3 persons ( including me :) ) interesting in the >> >> package, I think it will be a good use case for a collab-maint >> repository. >> >> Further I suggest to use gbp [0] and also switch to debhelper. >> >> >> >> I've played a bit already with the package and ready to push the first >> >> draft. >> >> >> >> Shell I go ahead and create the collab-main/hdparm.git ? ( hope I >> still >> >> have the rights for it ) >> > >> > Sure, go ahead. Feel free to mail/cc me when you have a package ready to >> > upload. I might be able to find the time to review and upload it... >> > >> > Cheers, >> > >> >> Here is the repository for hdparm: >> >> http://anonscm.debian.org/cgit/collab-maint/hdparm.git >> >> It's half baked so far, please feel free to contribute, >> the gpb intro: https://wiki.debian.org/PackagingWithGit >> CollabMaint: https://wiki.debian.org/Teams/CollabMaint >> >> Regards, >> Alex >> >> >> >
Re: hdparm needs a new maintainer
Alex Impressive upload. I have already checked out and I am starting to understand how the gpb packager works out. Thx for the links Regards Ivan On Tue, Mar 1, 2016 at 7:57 PM, Alex Mestiashvili wrote: > On 03/01/2016 06:11 PM, Raphael Hertzog wrote: > > Hello, > > > > On Tue, 01 Mar 2016, Alex Mestiashvili wrote: > >> As there are at least 3 persons ( including me :) ) interesting in the > >> package, I think it will be a good use case for a collab-maint > repository. > >> Further I suggest to use gbp [0] and also switch to debhelper. > >> > >> I've played a bit already with the package and ready to push the first > >> draft. > >> > >> Shell I go ahead and create the collab-main/hdparm.git ? ( hope I still > >> have the rights for it ) > > > > Sure, go ahead. Feel free to mail/cc me when you have a package ready to > > upload. I might be able to find the time to review and upload it... > > > > Cheers, > > > > Here is the repository for hdparm: > > http://anonscm.debian.org/cgit/collab-maint/hdparm.git > > It's half baked so far, please feel free to contribute, > the gpb intro: https://wiki.debian.org/PackagingWithGit > CollabMaint: https://wiki.debian.org/Teams/CollabMaint > > Regards, > Alex > > >
Re: hdparm needs a new maintainer
Hi For me it is ok, I am just a newbie in packaging. I have received help from a debian mentor Anibal Montalve Salazar < ani...@debian.org>, but I got no references for gbp (yet another Debian packaging toolchain ? ) what is exactly a collab-maint repository, a Git repo for the package host somewhere ? I am ok with whatever, Plz go ahead creating the repo (if have permissions). Regards Ivan On Tue, Mar 1, 2016 at 4:48 PM, Alex Mestiashvili wrote: > On 03/01/2016 10:13 AM, Raphael Hertzog wrote: > > Hello, > > > > hdparm is a popular package which has been recently orphaned (see > > #816168). It provides an udeb so it might be needed/useful in the context > > of debian-installer too. There are multiple reverse dependencies too. > > > > There are 4 RC bugs against it and a new upstream release waiting to be > > packaged. > > > > It would be nice if some people could take over the package and bring it > > back to shape. Ccing debian-mentors since new contributors are likely to > > follow that list. > > > > https://tracker.debian.org/pkg/hdparm > > > > The package description is: > > Get/set device parameters for Linux SATA/IDE drives. > > Primary use is for enabling irq-unmasking and IDE multiplemode. > > > > Thank you, > > > > > Hi All, > > As there are at least 3 persons ( including me :) ) interesting in the > package, I think it will be a good use case for a collab-maint repository. > Further I suggest to use gbp [0] and also switch to debhelper. > > I've played a bit already with the package and ready to push the first > draft. > > Shell I go ahead and create the collab-main/hdparm.git ? ( hope I still > have the rights for it ) > > Regards, > Alex > > [0] https://wiki.debian.org/PackagingWithGit > > > >
Re: hdparm needs a new maintainer
Hi I would like to help. I am an experienced software developer (C/C++) but have no experience in packaging. I don't know if hdparm is hard to package for a newbie mantainer, so If someone can mentor me on that part I would gladly adopt the package. Regards Ivan On Tue, Mar 1, 2016 at 10:13 AM, Raphael Hertzog wrote: > Hello, > > hdparm is a popular package which has been recently orphaned (see > #816168). It provides an udeb so it might be needed/useful in the context > of debian-installer too. There are multiple reverse dependencies too. > > There are 4 RC bugs against it and a new upstream release waiting to be > packaged. > > It would be nice if some people could take over the package and bring it > back to shape. Ccing debian-mentors since new contributors are likely to > follow that list. > > https://tracker.debian.org/pkg/hdparm > > The package description is: > Get/set device parameters for Linux SATA/IDE drives. > Primary use is for enabling irq-unmasking and IDE multiplemode. > > Thank you, > -- > Raphaël Hertzog ◈ Debian Developer > > Support Debian LTS: http://www.freexian.com/services/debian-lts.html > Learn to master Debian: http://debian-handbook.info/get/ > >
Re: Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows
> Axel Wagner writes: […] > I don't think Lennart personally would care, no, but I think *we* > should care to paint the Opensource community as better than this. As a member of the said community, I think that, however the presence of either of the packages in Debian paints it, – I could live with that. Regarding the possible enhancement of XBill to allow for using a user-specified set of sprites (whether packaged or not), – it certainly feels like a proper solution to me. I guess the package could then be enhanced to include several such “themes,” including the “classic” one, the newly proposed one, and perhaps a few more, depending on the availability and relevance. > From that point of view, if there was a vote and I'd get a vote I > would also vote against having xbill in the archive as being a poor > taste ad-hominem attack (I mean, for crying out loud, there is an > actually blood-spatter squashing animation in the game, even if it is > a poor one). In my opinion it is certainly not an argument to also > let xlennart in. While not a full-scale ad-hominem attack, I’d say that the two differences I know of between the vrms operation and the official FSF position amount to a misrepresentation at best. Are we going to drop that package, too? […] -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87k30mtown@violet.siamics.net
Re: DE features dependent on Systemd
>>>>> Vincent Bernat writes: >>>>> ❦ 3 décembre 2014 16:47 GMT, Ivan Shmakov : >>> The problem with those groups is that they are not fine grained >>> enough. For example, the video group gives access to the >>> framebuffer device (the user can do a screenshot) or to a webcam >>> (the user can spy another user). By encouraging the use of those >>> groups, we create big security hole. >> Do these security considerations still apply to single-user, >> single-seat systems? > Yes. Namely? > We don't "chmod -R a+rwx /" for a good reason. That makes, like, an order of magnitude difference. The former allows the machine’s owner access to audio devices irrespective of /how/ he or she choose to initiate such access. (Say, I may decide to start ogg123(1) via at(1) to wake me up in the morning.) Using Logind there is akin to only allowing user access to $HOME while being “physically” logged in. (Or do we consider that a valid restriction as well?) On the contrary, the latter would allow for purely accidental damage to the system, with no big obvious advantages I could readily think of. -- FSF associate member #7257 np. Satellite 15… The Final Frontier — Iron Maiden -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87vblso6o5@violet.siamics.net
Re: DE features dependent on Systemd
> Josselin Mouette writes: […] > We are talking about the anti-feature of adding UID=1000 to the audio > group in the installer. This is only relevant for desktop > installations, and all desktop tasks in the same installer bring > logind (formerly consolekit). BTW, what about adding that same user to the ‘sudo’ group (which D-I does; or formerly did, IIRC)? Does Logind also take care of that part nowadays? > If you configure, by hand, a headless machine or a X session started > with startx, I’m pretty sure you can also use adduser on your own. (I guess this means that I should check if the current D-I supports the likes of an Openbox/XDM-based destkop install?…) -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87d280ptrs@violet.siamics.net
Re: DE features dependent on Systemd
> Vincent Bernat writes: > ❦ 3 décembre 2014 13:55 +0100, Adam Borowski : […] >>> This “adduser first-user audio” was already useless in squeeze and >>> it hasn’t changed. >> Only if you run logind or consolekit. Without them (ie, on headless >> boxes or with classic-type WMs) you do need to access the devices >> which are mode 660 root:audio. > A classic-type WM can make use of logind to get the appropriate ACL > setup. > The problem with those groups is that they are not fine grained > enough. For example, the video group gives access to the framebuffer > device (the user can do a screenshot) or to a webcam (the user can > spy another user). By encouraging the use of those groups, we create > big security hole. Do these security considerations still apply to single-user, single-seat systems? […] -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878uioptmy@violet.siamics.net
Re: DE features dependent on Systemd
>>>>> Josselin Mouette writes: >>>>> Le dimanche 30 novembre 2014 à 12:50 +, Ivan Shmakov a écrit : […] >> For home installs, I see no reason for the owner of the device to be >> /denied/ access to the sound card just because of using SSH. Why, >> it’s exactly what I do. (I even did things like $ ssh remote >> ogg123 /dev/stdin < local/file.ogg for various reasons in the past.) > PolicyKit does not control access to devices. The case you pointed > out is already handled correctly by systemd: > * Users needing full access can be added to the audio group. Good to know the support for such groups isn’t going to be dropped anytime soon. (Along with, say, SysVinit support.) > * Other users only have access to audio devices through ACLs when > physically logged on. Unless I be mistaken, ACLs are only applied at the time of open(2). What about the processes (if any) which opened an audio device back when it was possible, but are still running at the time the user logs out? >> OTOH, for “workplace” installs, I see no reason for the user to be >> /granted/ access to the things like network management just because >> he or she happens to be logged in locally, – these privileges should >> rather be granted only to the person(s) responsible for that >> particular host. (And then again, – SSH is a perfectly valid way to >> access to these facilities.) > The nice thing about PolicyKit is that it is configurable. In this > case, you might want to ship laptops to your users and still allow > them to switch wifi networks without giving them root access. Doesn’t “physical access” generally imply “root access”? At the very least, it /used/ to be, and if it still is, I’d rather consider the above a mere inconvenience rather that a security feature. > But in the general case, there are things that make sense to forbid > in a workplace environment. It just takes a PKLA file to do so. You’ve mentioned “the principle of least privilege” below; if I understand your comment there correctly, doesn’t that also mean that access to, say, network configuration should actually be explicitly /granted/ (rather than explicitly forbidden)? >> IIRC, D-I used to add the first non-root user it creates (which more >> or less is bound to happen to be the owner, or the person otherwise >> responsible for the host) to a number of groups (like audio or >> plugdev) to grant access to certain devices. I know of no reason to >> abandon this practice. > This practice is still here, but it is absurd. Actually, I have no strong preference on this issue. I tend to use a full-weight Debian system when installing Debian (that is: # debootstrap … /mnt) whenever possible, which happens to be almost every time. Hence, I use D-I only occasionally. Still, if that’s a bug, could you please provide examples of the categories of users affected? > It makes the first user created special for no reason, I guess the reason is that that user is going to be either the owner for the system, or the person responsible for installing Debian there. Why, I seriously doubt that the D-I user would create an account for some random person at that point. > failing the principle of least privilege. If you need permanent > access to this device or that feature for a given user, you can add > it to the required groups only if needed. Yes. -- FSF associate member #7257 np. Coming Home — Iron Maiden 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r3wkmykq@violet.siamics.net
Re: DE features dependent on Systemd
>>>>> Vincent Bernat writes: >>>>> ❦ 30 novembre 2014 10:10 GMT, Ivan Shmakov : […] >> Or does the above concerns the users of “normally battery-powered” >> devices instead? > Previously, every DE would need to reimplement power management. > Now, this is handled by systemd (and hence not by the DE anymore). > Without any special configuration, closing the lid of a laptop will > put it to sleep except if there is still an active user on an > external display. Just to be clear: I do not use any laptops myself. (Or anything else I’d need to put to sleep by closing its lid, for that matter.) I guess this means that this particular feature is of no use to me, right? (And, as a consequence, that I may safely ignore it when deciding if I should retain my current init.) […] >>> Indirectly through PolicyKit: lots of functionality will be missing >>> if PolicyKit doesn’t have access to a console management interface. >> Specifically? > PolicyKit rely on logind to know if a user is locally connected. A > non-local user won't be allowed things like network management, local > device mounting or sound card access. That looks like a problem to solve, not a feature. For home installs, I see no reason for the owner of the device to be /denied/ access to the sound card just because of using SSH. Why, it’s exactly what I do. (I even did things like $ ssh remote ogg123 /dev/stdin < local/file.ogg for various reasons in the past.) OTOH, for “workplace” installs, I see no reason for the user to be /granted/ access to the things like network management just because he or she happens to be logged in locally, – these privileges should rather be granted only to the person(s) responsible for that particular host. (And then again, – SSH is a perfectly valid way to access to these facilities.) IIRC, D-I used to add the first non-root user it creates (which more or less is bound to happen to be the owner, or the person otherwise responsible for the host) to a number of groups (like audio or plugdev) to grant access to certain devices. I know of no reason to abandon this practice. I agree that the issue gets trickier for multiuser hosts, but I’m pretty sure that there still will be at least one user for whom no such access restrictions should apply, – irrespective of his or her “login locality.” -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/873890onsa@violet.siamics.net
DE features dependent on Systemd
>>>>> Josselin Mouette writes: >>>>> Le samedi 29 novembre 2014 à 16:37 +, Ivan Shmakov a écrit : >>>>> Josselin Mouette writes: […] >>> Desktops (not only GNOME) use a very tiny bit of systemd, >>> interfaces that could be provided elsewhere. >> Is that “use” as in “if available” or is that actually “require and >> be sure to die unless provided”? > Directly: DEs provide more useful features (especially power > management) with systemd but will work correctly without. I see nothing in the ‘apcupsd’ changelog [1] (which is about the only package related to power management I have installed on my systems) to suggest it ever having any Systemd integration. Or does the above concerns the users of “normally battery-powered” devices instead? [1] http://metadata.ftp-master.debian.org/changelogs/main/a/apcupsd/apcupsd_3.14.12-1_changelog > Indirectly through PolicyKit: lots of functionality will be missing > if PolicyKit doesn’t have access to a console management interface. Specifically? -- FSF associate member #7257 np. Tree of Love — Jami Sieber … B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppc5ngm5.fsf...@violet.siamics.net
Re: Technical committee acting in gross violation of the Debian constitution
>>>>> Zbigniew Jędrzejewski-Szmek writes: >>>>> On Sat, Nov 29, 2014 at 06:33:44PM +, Ivan Shmakov wrote: >>>>> Zbigniew Jędrzejewski-Szmek writes: […] >>> The second part, making systemd portable, has already been widely >>> discussed. There are significant technical reasons why systemd is >>> Linux only. And the potential "recepients", like BSD, don't seem >>> to be interested anyway. >> Unless I be mistaken, that also /does/ mean Debian. That is: Debian >> GNU/kFreeBSD and Debian GNU/Hurd. > Yes, the technical reasons apply. The other reasons apply too, I > think: /kFreeBSD and /Hurd ports are interested in staying close to > their upstream projects and certainly don't have the manpower to take > on systemd porting on their own. My point is that Debian is bound to support non-Systemd installs as long as the two statements below remain true: • Debian supports non-Linux installs; • Systemd is Linux-only. And this is about the only thing about Systemd I do care of. (Curiously, from this point of view, being only available for Linux is actually the Systemd feature of most importance to me.) As for Systemd being the default (on Debian GNU/Linux, specifically), – I guess I shouldn’t bother. GNOME is also the default, but I cannot readily recall ever having it running on my Debian installs. […] -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tolpz7z@violet.siamics.net
Re: Technical committee acting in gross violation of the Debian constitution
> Zbigniew Jędrzejewski-Szmek writes: […] > The second part, making systemd portable, has already been widely > discussed. There are significant technical reasons why systemd is > Linux only. And the potential "recepients", like BSD, don't seem to > be interested anyway. Unless I be mistaken, that also /does/ mean Debian. That is: Debian GNU/kFreeBSD and Debian GNU/Hurd. Sorry for jumping into this discussion without any thorough reading, but I have mentioned this point a few times already at (other) mailing lists and on IRC, so if I got it wrong, I’d like to be corrected, so that I won’t spread confusion any further. […] -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/8761dxq2k7@violet.siamics.net
Re: Technical committee acting in gross violation of the Debian constitution
> Josselin Mouette writes: […] > Desktops (not only GNOME) use a very tiny bit of systemd, interfaces > that could be provided elsewhere. Is that “use” as in “if available” or is that actually “require and be sure to die unless provided”? (Please forgive my ignorance here, – my “desktop” runs Openbox ever since I’ve switched off TWM c. 2008, and I’m pretty sure that Openbox does not “use” Systemd or any related services.) > The real purpose of systemd is to provide a modern init system. I believe that the word “init” is misleading at best in this context. The SysVinit-based system traditionally used in Debian was indeed /mostly/ concerned with bringing the system up – that is, “initing” the system. On the contrary, Systemd seems to try to also encompass monitoring, time synchronization, user sessions, and, I presume, a load of other tasks. If anything, it seems to deserve something like Master Control Program for its name, – not something as mundane as an “init system.” -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87a93aotd9@violet.siamics.net
Re: Reintroducing FFmpeg to Debian
On 8/18/14, Moritz Mühlenhoff wrote: > Andreas Cadhalpun schrieb: >> Hi Thomas, >> >> On 18.08.2014 08:36, Thomas Goirand wrote: >>> There's been a very well commented technical reason stated here: the >>> release team don't want to deal with 2 of the same library that are >>> doing (nearly) the same things, with potentially the same security >>> issues that we'd have to fix twice rather than once. >> >> Why is it a security problem to have FFmpeg and Libav, but apparently no >> problem to have MySQL, MariaDB and PerconaDB? > > Raphael Geissert already wrote that mysql/mariadb/percona will be > addressed as well; we haven't come around to since since we need to > deal with a lot of stuf and being dragged into endless discussions > on -devel is certainly not helpful. > > Cheers, > Moritz Excuse my interruption, but I intend to be a little blunt. I think there might be a little bit of miscommunication. You have said that security team cannot handle both FFmpeg and Libav. Since Libav is already in Debian, this statement is assumed to mean that you do not want to deal with FFmpeg. However this mail http://lists.debian.org/debian-devel/2014/08/msg00060.html kind of hints the opposite - Libav security handling is horrible and burden to you, while FFmpeg so far is responsive and responsible. So I would like to get a little bit more details on your priorities and preferences. The options I could think of are: 1. Drop both Libav and FFmpeg. 2. Leave Libav in stable, keep FFmpeg out. 3. Get FFmpeg in stable, drop Libav. 4. Get both Libav and FFmpeg, under the condition that Michael is helping with FFmpeg patching. 5. Get both Libav and FFmpeg, under the condition that Michael is helping with FFmpeg AND Libav patching (only for jessie). 6. Something else... Other people have said that FFmpeg should provide help and resources to the security team. Please elaborate what more can FFmpeg do to please you. Best Regards Ivan Kalvachev iive P.S. I hope ftp masters are not deliberately prolonging the FFmpeg inclusion, thinking they are doing favor to their peers from other teams. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABA=pqfwpzbxagqd-ji4y2ksa_akp+kbiwd6nucw9jbitm2...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 8/16/14, Pau Garcia i Quiles wrote: > On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George wrote: > > >> The only option is to make sure the users do not suffer from the fork, by >> making sure they can easily use the version that is most suited for their >> need without being sucked into the developers' disagreements. >> > > Can we get back on topic? > > With or without libav in Debian, there are solid technical reasons to have > ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although > they parted ways in a civilized way: different library names), and we > certainly have a ton of librarys which provide very similar features. > > Since before the fork, the libav developers have been sabotaging ffmpeg as > much as possible, in every "combat field": library names, library versions, > taking distributions hostage (ffmpeg package that installs libav!?), etc. > This is not the way to fork anything. This is a fact. I don't care whether > Michael Nidermayer was a dictator or not. I don't care whether the > code-review rules in libav are better or worse. I don't care what the Linux > kernel does. The only thing I care about is Debian is shipping a > less-capable (i. e. less multimedia formats supported) distribution due to > this conflict. > > This has to stop. > > ffmpeg is not yet in Debian due to the filename clashing, which will most > certainly cause binary problems. > > If libav and ffmpeg maintainers cannot reach an agreement regarding library > names and it's not possible to simply use either ffmpeg or libav > indistinctly due missing features binary compatibility, etc, the obvious > solution is that BOTH libav and ffmpeg rename their libraries in Debian. E. > g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use > alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done > in the past. AFAIK, Andreas' package uses libavcodec-ffmpeg.so . FFmpeg configure does have option --build-suffix="_ffmpeg" that would append that suffix to library names and pkg-config files. Since applications might have problem finding the ffmpeg libraries, the pkg-config files should be with the old "common" names and this creates a conflict in the -dev packages. Libav and FFmpeg can coexist side by side. There are no conflicts or overlap for binary users. The current goal of FFmpeg is not replacing Libav. The current goal is establishing a native presence in the most popular distribution(s). I'm quite sure the Security team is full of capable people who can handle one more package. FFmpeg takes security seriously. The best scenario for everybody is: 1. Libav stays and all QA tested programs are not touched. 2. FFmpeg is included in a way that does not obstruct the rest of the ecosystem. 3. Optionally, programs that use _only_ FFmpeg could be included back in Debian. Optionally. The inclusion would allow for a real-life estimate to be done of the FFmpeg performance, security, bug and feature wise. Only after assessing real-life data, a final decision could be reached, if there is still demand for such thing. Best Regards Ivan Kalvachev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABA=pqdclh+p4kqx99gmrnu-f24wpxkfnthjwryl5dnyzue...@mail.gmail.com
[OT] config file formats
> Vincent Lefevre writes: > On 2012-12-02 22:04:52 +0100, Wouter Verhelst wrote: > On Sun, Dec 02, 2012 at 12:31:00PM +0100, Vincent Lefevre wrote: […] >>> You may want relations between key-value pair. For instance, if >>> you have a line with a key "foo", then a line with a key "bar" must >>> also exist. Or a line with a key "number" must have a value that >>> is a number (more generally matching some regexp). >> That's not validation of the format, that's validation of the data. > That's validation of the config file. This is what XML validation > does: it checks whether the file is valid according to some schema. That being said, I believe that the reason XML became so widespread (and, conversely, it's ancestor SGML fell into disuse) is precisely because the former decoupled the format (representation, and its inherent semantics) itself from the validation. That way, we were able to forgo DTD and develop such (arguably, much better) XML schema representations such as XML Schema and RELAX NG. (The latter is the one used by Emacs.) I'm not aware of any “standard” schema representations for the (sectioned) key-value file formats, however. >> I've never seen any config file with nested config blocks that >> didn't make the file more complex and less easy to understand. > Wrong. Nested blocks make config files easier to understand. > Otherwise for the same feature (e. g. conditionals), one would need > things like horrible state variables. For instance, think about > redesigning a procmailrc with the ini format... On the second sight, the difference between, e. g.: d f i and, e. g.: [a.b] c = d e = f [a.g] h = i is mostly superficial. -- Advocating the judicious use of XML applications on the Internet at large. -- 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/868v9fy5rm.fsf...@gray.siamics.net
[OT] config file formats
> Игорь Пашев writes: > 2012/12/2 Vincent Lefevre : >> No, that's not sufficient. You may want relations between key-value >> pair. For instance, if you have a line with a key "foo", then a line >> with a key "bar" must also exist. Or a line with a key "number" must >> have a value that is a number (more generally matching some regexp). > For such configs general programming languages are good. > E. g. perl: > $foo = "wtf"; > if ($foo && !$bar) { […] If and only if such “configuration files” will only /ever/ be read by Perl-enabled tools. Which may pose a problem, e. g., should a port of the software in question to a resource-limited, embedded system be considered at some point. The problem with programming languages is that one can't merely read a file in such a language, and extract some kind of result warranted to be sensible. One has to /execute/ it instead. (Some extra care is likely to be required for the “privileges' gate” case as well.) The same applies to *roff and TeX, BTW. -- FSF associate member #7257 -- 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/86hao4xod6.fsf...@gray.siamics.net
Re: Maildir vs. mbox in Debian
> Christoph Anton Mitterer writes: […] > But it also has disadvantages to the mbox formats which may be > crucial for some people: > - wasting a lot of storage, which can be significant even if you use > small file systems block sizes... Only as long as static mbox files are considered. However, removing a message from an mbox requires an amount of free space equal to the size of the mbox in question, sans the message to be removed. OTOH, removing a message from Maildir requires no additional filesystem space. > - full text search will typically be slower, as one has to open/close > many files What are the estimates? And wouldn't it be better to use some kind of a specialized search engine if searching is deemed “crucial”? I guess that it may render the difference between the formats somewhat irrelevant. -- FSF associate member #7257 -- 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/86d2yxyqjj@gray.siamics.net
Maildir vs. mbox in Debian
> Adam Borowski writes: […] > Quoting from that page: > # With the advent and now widespread adoption of the superior Maildir > # format over the past several years, the entire "mbox" family of > # mailbox formats is gradually becoming irrelevant, and of only > # historical interest. > which is no news. And you can't really run a mail server in mbox if > you ever receive mail from business users: for them, sending the text > as an image wrapped in a Word document is the rule rather than an > exception[1]. Unfortunately, it's not just the business users. The so-called “office productivity suites” are seemingly widespread in academia and science, for instance. […] > So, what's the reason mbox is still the default in Debian? That's what I wonder about, too. […] > With current disk sizes, no one should care about a few gigs here, a > few gigs there. Unless you need to read a mbox linearly, that is. Seconded. JFTR: I've switched my mailservers to Maildir c. 2006, for much improved performance and manageability, and never had an issue with that. -- FSF associate member #7257 -- 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/86haoa18tg.fsf...@gray.siamics.net
Re: [OT] XML
>>>>> Jakub Wilk writes: >>>>> * Ivan Shmakov , 2012-11-26, 14:32: >> Seriously, XML takes a lot of concerns off an application >> programmer. It provides quoting, arbitrary hierarchical structure, >> support for different encodings, etc. Why, don't you think that >> $ grep [[:lower:]]' FILE is ever supposed to work? For surely it >> isn't: grep has no way to know the encoding of the input file, and >> relies on the locale instead. On the contrary, XML allows for the >> encoding to be specified explicitly via a processing instruction. >> And then, there's XPath, which takes the input dataset structure >> into account. > How do you search for a lowercase letter in XPath? With fn:matches (WHERE, "\p{Ll}")? Specifically, if you're interested in all ENTRY elements, whose respective KEY's contain a lower-case letter, it may look something like the following: //x:entry[fn:matches (x:key/text (), "\p{Ll}")] For instance, using xqilla(1) (xmlstarlet(1) doesn't seem to support fn:matches ()): $ cat < cf.xml there be an all-lowercase key all-lowercase key's value THERE BE AN ALL-UPPERCASE KEY all-uppercase key's value There be a Mixed-case Key mixed-case key's value $ xqilla -i cf.xml \ <(printf %s\\n '\ declare namespace x="urn:uuid:95364fc4-e68d-492e-a122-7b3b37bdab10";' \ '//x:entry[fn:matches (x:key/text (), "\p{Ll}")]') there be an all-lowercase key all-lowercase key's value There be a Mixed-case Key mixed-case key's value $ -- FSF associate member #7257 -- 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/86mwy34ojh@gray.siamics.net
Bug#694456: ITP: lzma-sdk-4j -- LZMA SDK for Java
Package: wnpp Severity: wishlist Owner: Ivan Fitenko * Package name: lzma-sdk-4j Version : 9.22.0 Upstream Author : Igor Pavlov * URL : https://github.com/b1-pack/lzma-sdk-4j/ * License : Public Domain Programming Lang: Java Description : LZMA SDK for Java LZMA SDK for Java is a data compression library for Java from the LZMA SDK written by Igor Pavlov. -- 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/20121126144624.2795.16300.reportbug@localhost
[OT] XML
> Norbert Preining writes: [...] > Ever heard of grep, sed, awk, all these nice things that make > your life happy. Trash them when you are doing XML. JFTR: there's xmlstarlet(1), which is capable enough to replace awk(1), sed(1), and grep(1) (which is more often than not gets mixed with awk(1) and sed(1), even though its functions are effectively embedded within the former two) on most uses. And then, every other high-level language has libraries for XML processing. Of which Perl is close enough to Awk to hardly ever bother learning the latter at all. Seriously, XML takes a lot of concerns off an application programmer. It provides quoting, arbitrary hierarchical structure, support for different encodings, etc. Why, don't you think that $ grep '[[:lower:]]' FILE is ever supposed to work? For surely it isn't: grep has no way to know the encoding of the input file, and relies on the locale instead. On the contrary, XML allows for the encoding to be specified explicitly via a processing instruction. And then, there's XPath, which takes the input dataset structure into account. (Care to provide an example of grepping out the VALUE for KEY of [SECTION]?) … Oh how I'm glad that there're prominent TeX figures that are actively using XML nowadays! I take the point, however, that the XML toolset is not nearly as mature and complete as that for “plain text.” It /is/ an issue, and I hope it will be resolved. It /is/ reasonable to use the two-level hierarchial [SECTION] KEY = VALUE format for configuration files, for it has better readability (as long as the common tools are considered.) What is /not/ reasonable is to label and shun XML for what it's not. -- Advocating the judicious use of XML applications at the Internet at large. -- 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/86vccs4y6f.fsf...@gray.siamics.net
Re: non-developer packages depending on gettext?
>>>>> Neil Williams writes: >>>>> Ivan Shmakov wrote: >>>>> Neil Williams writes: […] >> To note is that Source: gnunet has contrib/report.sh, which calls >> gettext(1), but it doesn't seem to be propagated to any of the >> binaries currently depending on gettext. > You've misunderstood the gettext packaging. > $ dpkg -S `which gettext` > gettext-base: /usr/bin/gettext > So packages/scripts which call gettext should not depend on gettext > but on gettext-base instead — that's the point. The point is that I haven't checked for gettext(1) the first time I've examined the gnunet source package. So, even though I was sure that the dependency on gettext was unwarranted, I didn't actually rule out gettext-base. […] >>> Could be worth filing a wishlist bug against lintian because it >>> should be quite easy to spot. >> ? I see no easy way to discern between these three cases (the >> dependency is valid, depend on gettext-base instead, drop the >> dependency altogether.) > 0: Manipulating PO files directly should only happen during package > builds, so either the package is itself a build tool (like po4a) or > the dependency goes into Build-Depends. I understand the logic. What I can't understand is how to implement it as a lintian check. (There isn't really a “this package is a build tool” flag. There're Tags:, but they may be misleading; consider, e. g., gnuplot bearing suite::gnu.) > 1: Depend on gettext-base but not gettext when the package calls > /usr/bin/gettext, dgettext and/or ngettext directly (all from > gettext-base) rather than the other executables in the gettext binary > package which do stuff like manipulating or reporting on PO files. I don't see an easy way to check for calls to gettext(1), etc., either. Certainly, we can grep the source, but how reliably (and specific) would that be for a lintian check? > 2: Drop any dependency when no calls to gettext can be found in the > source and it isn't a build tool. Languages other than shell have > in-built ways of using the .mo file prepared through PO and gettext > to output translated text at runtime. This has nothing to do with > running gettext itself. Languages may also have their own packaging > support for this, e. g. liblocale-gettext-perl (which itself uses the > libc support, not gettext-base). So, at least we could safely warn about a dependency on gettext-base for a package containing no Shell scripts. Still, it doesn't seem to rule out a dependency on gettext. -- FSF associate member #7257 -- 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/86sj91z3vg@gray.siamics.net
Re: non-developer packages depending on gettext?
> Neil Williams writes: […] > Check if the package contains a shell script which supports > translated output strings — such packages should Depend: gettext-base > rather than drop the dependency entirely. > I've had a quick look at gnas and it does seem that this is a case > where gettext-base is required, but not gettext. ACK, thanks for the information. To note is that Source: gnunet has contrib/report.sh, which calls gettext(1), but it doesn't seem to be propagated to any of the binaries currently depending on gettext. > gettext should only be necessary for packages or tasks which > *manipulate* PO files directly, rather than use the processed .mo > files to generate translated output. So, Build-Depends: yes, > Depends: probably a bug. gettext-base is only really needed when the > package provides shell scripts with translated output because those > evaluate the gettext process at runtime but that only requires > gettext-base, not gettext. > Could be worth filing a wishlist bug against lintian because it > should be quite easy to spot. ? I see no easy way to discern between these three cases (the dependency is valid, depend on gettext-base instead, drop the dependency altogether.) -- FSF associate member #7257 -- 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/86d30e8mco@gray.siamics.net
non-developer packages depending on gettext?
I find somewhat unusual for the following packages to depend on gettext, given that the latter is a collection of utilities of interest primarily to software developers and maintainers (as stated in its own Description:.) Could someone please clarify on this? TIA. gnacaudio converter for GNOME gosaWeb Based LDAP Administration Program istanbulDesktop session recorder producing Ogg Theora video poker-web Web interface to a poker-network server (I've also filed Bug#690860 against Source: gnunet, which, AIUI, the maintainer intents to fix by dropping the dependency.) -- FSF associate member #7257 -- 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/861ugv9hef@gray.siamics.net
Re: Packages removing alternatives on upgrade
> Russ Allbery writes: […] > It's an improvement. Guillem makes a good argument that you should > drop deconfigure as well, which means that: > if [ "$1" = "remove" ] ; then > update-alternatives --remove > fi > is probably the best thing to use right now. […] > (Note that while common, I've never been fond of that case statement > construction, since it means that we can't introduce new maintainer > script actions without modifying lots of maintainer scripts that may > not need to be modified otherwise.) ? How is the ‘if’ statement above different to, say: case "$1" in (remove) update-alternatives --remove ;; esac -- FSF associate member #7257 -- 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/86wqz1k2nb@gray.siamics.net
Re: where is the DNSSEC root key?
> Philipp Kern writes: > On Thu, Oct 04, 2012 at 03:10:01PM -0400, Chris Knadle wrote: >> Last I looked into this [which has admittedly been a while], Bind 9 >> was the only DNS server that had actually implemented DNSSEC, and >> the others I looked at (PowerDNS, djbdns, tinydns) had stated (IIRC) >> that they were /not/ going to be implementing it. > Obviously there are also recursive resolver implementations, like > unbound. To the client they look like DNS servers, too. (And you > really want to use one of them on your local machine to do the DNSSEC > validation.) > Generally plain servers do not care about the key, it's just the > recursive resolvers that need it. To note is that dig(1) (of dnsutils) implements such a resolver (while not being a DNS server.) With +sigchase and +trusted-key=, it's perfectly capable of DNSSEC validation. >> The problem with this idea is that files installed by Debian >> packages must be unique in order to avoid file conflicts between >> packages. One way around this issue is via 'alternatives'. > Alternatives don't make sense. A dedicated packages might make some. Yes. Such a package should also include the ISC DNSSEC Look-aside Validation [1] trusted key, BTW. [1] https://dlv.isc.org/ -- FSF associate member #7257 -- 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/86pq4xldzz@gray.siamics.net
Bug#689572: nmu: packages linked against libhdf5-7 << 1.8.8-7.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-devel@lists.debian.org, debian-scie...@lists.debian.org There're several packages currently in Debian testing having a versioned dependency on the semi-virtual libhdf5-7 package (apparently as the result of being built prior to Source: hdf5 1.8.8-7.1 propagating to testing on 2012-02-23.) Consequently, these packages cannot be installed along with any of the other libraries providing libhdf5-7 (check, e. g., [1].) I'm therefore suggesting re-building these packages against the now-current libhdf5-7, with binNMU's as specified below. TIA. nmu libcgns_3.1.3.4-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu nexus_4.2.1-svn1614-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu r-cran-hdf5_1.6.10-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu tessa_0.3.1-6 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu udav_0.7.1.2-3 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' The hdf-eos5_5.1.14+dfsg.1-1 currently in Debian unstable fixes the issue (as well as a few others), but unless it's unblocked (and enters Debian testing), it has to be re-built just as well: nmu hdf-eos5_5.1.13.dfsg.1-3 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' [1] http://packages.debian.org/wheezy/libhdf5-7 JFTR, the respective Source: hdf5 Debian changelog [2] entry is: --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- hdf5 (1.8.8-7.1) unstable; urgency=low * Non-maintainer upload. * Stop building the c++ libraries, nothing uses them. And don't version the libhdf5-7 symbols file, so the dependency can also be satisfied by the mpi packages' Provides. * Use DEB_HOST_ARCH instead of DEB_BUILD_ARCH in debian/rules. * Don't require root for debian/rules clean. -- Julien Cristau Sat, 18 Feb 2012 12:25:35 + --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- The PTS entries for the packages affected are as follows. http://packages.qa.debian.org/h/hdf-eos5.html • [2012-02-24] hdf-eos5 5.1.13.dfsg.1-3 MIGRATED to testing (Britney) http://packages.qa.debian.org/libc/libcgns.html • [2012-01-24] Accepted 3.1.3.4-1 in unstable (low) (Sylvestre Ledru) http://packages.qa.debian.org/n/nexus.html • [2011-07-31] Accepted 4.2.1-svn1614-1 in unstable (low) (Tobias Stefan Richter) (Although nexus was re-built once as 4.2.1-svn1614-1+b1, it was on 2012-01-26, thus before hdf5_1.8.8-7.1, and still bearing a possibly unwarranted versioned dependency on libhdf5-7.) http://packages.qa.debian.org/r/r-cran-hdf5.html • [2012-01-18] Accepted 1.6.10-1 in unstable (low) (Dirk Eddelbuettel) http://packages.qa.debian.org/t/tessa.html • [2012-02-20] Accepted 0.3.1-6 in unstable (low) (Josselin Mouette) http://packages.qa.debian.org/u/udav.html • [2012-01-25] Accepted 0.7.1.2-3 in unstable (low) (Salvatore Bonaccorso) -- FSF associate member #7257 -- 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/86txuan2ki.fsf...@gray.siamics.net
Re: mass bug filing about versioned dependency on the libhdf5-7 virtual package
>>>>> Julien Cristau writes: >>>>> On Sun, Sep 30, 2012 at 00:28:15 +0700, Ivan Shmakov wrote: >> I tend to think that a re-build (via binNMU or otherwise) will be >> sufficient for most of the packages affected. >> Unless there'll be objections, I'm going to file the respective bug >> reports regarding the versioned dependency on libhdf5-7 against the >> following packages. (The affected versions and architectures >> [though only amd64 and i386 were tested] are shown, as well as the >> Depends: list items triggering the check.) > NAK. If a binNMU is all that's needed then please don't file bugs > against the packages. See http://wiki.debian.org/binNMU ACK, thanks for the pointer! The problem is that I'm yet unsure whether a binNMU will be sufficient or not. My analysis is below, and unless there'd be objections, I'd be filing a bug against release.debian.org, with the binNMU entries as follows. nmu libcgns_3.1.3.4-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu nexus_4.2.1-svn1614-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu r-cran-hdf5_1.6.10-1 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu tessa_0.3.1-6 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' nmu udav_0.7.1.2-3 . ALL . -m 'Rebuilt against libhdf5-7 >= 1.8.8-7.1' AIUI, the packages affected are exactly those built against pre-1.8.8-7.1 versions of the Source: hdf5 libraries. That may explain the versioned dependency, and may be a good indication for that a binNMU will be sufficient to get the issue fixed. --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- hdf5 (1.8.8-7.1) unstable; urgency=low * Non-maintainer upload. * Stop building the c++ libraries, nothing uses them. And don't version the libhdf5-7 symbols file, so the dependency can also be satisfied by the mpi packages' Provides. * Use DEB_HOST_ARCH instead of DEB_BUILD_ARCH in debian/rules. * Don't require root for debian/rules clean. -- Julien Cristau Sat, 18 Feb 2012 12:25:35 + --cut: http://packages.debian.org/changelogs/pool/main/h/hdf5/hdf5_1.8.8-9/changelog -- As per http://packages.qa.debian.org/, all the packages I've listed before entered unstable prior to 2012-02-18 (except for Source: tessa, which was uploaded a couple of days after.) http://packages.qa.debian.org/libc/libcgns.html • [2012-01-24] Accepted 3.1.3.4-1 in unstable (low) (Sylvestre Ledru) http://packages.qa.debian.org/n/nexus.html • [2011-07-31] Accepted 4.2.1-svn1614-1 in unstable (low) (Tobias Stefan Richter) NB: apparently, nexus was re-built once as 4.2.1-svn1614-1+b1 on 2012-01-26 (before hdf5_1.8.8-7.1, and still bearing a possibly unwarranted versioned dependency on libhdf5-7.) http://packages.qa.debian.org/r/r-cran-hdf5.html • [2012-01-18] Accepted 1.6.10-1 in unstable (low) (Dirk Eddelbuettel) http://packages.qa.debian.org/t/tessa.html • [2012-02-20] Accepted 0.3.1-6 in unstable (low) (Josselin Mouette) http://packages.qa.debian.org/u/udav.html • [2012-01-25] Accepted 0.7.1.2-3 in unstable (low) (Salvatore Bonaccorso) TIA. -- FSF associate member #7257 -- 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/86fw5wp27b@gray.siamics.net
[OT] kernel modules
> Eric Valette writes: […] > I do not want to compile microcode tool as a module because module > loading juts slows down the boot process and contrarilly to many > other package requiring firmware, this one does not enable to load > firmware when not compiled as a module. > So it does not work for people compiling their own kernel and not > using modules (when you tailor your kernel for a given machine, > modules are just slowing the boot process and do not bring anything). Unless under very specific circumstances, the use of a modular kernel brings one the ability to replace the particular hardware the system runs on at will. Say, it's possible to replace a just burned motherboard with an Intel CPU with a different one having an AMD CPU instead. Or one may take the HDD holding the system and put it into a wholly different box, while often retaining the ability to boot. For these reasons, in the majority of cases, compiling a non-modular kernel doesn't worth the effort, and may also be harmful to the system's operation. -- FSF associate member #7257 -- 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/86txuhqk91.fsf...@gray.siamics.net
Re: ${HOME} vs. g_get_home_dir ()
>>>>> Simon McVittie writes: >>>>> On 26/09/12 18:15, Ivan Shmakov wrote: >>>>> Simon McVittie writes: >>> Please research previous discussion to check that you're not >>> missing arguments that have happened in the past, >> Any particular pointers? > Following the git history points to > <https://bugzilla.gnome.org/show_bug.cgi?id=2311>, which raises > interesting issues regarding running GUI applications from under > su/sudo (which is generally a bad idea, but back then there was > little alternative). There's also the analysis at [1]. Unfortunately, it seems that the possibility of the user /intentionally/ changing his or her own HOME was never considered (and neither such concerns are reflected in the documentation.) E. g.: --cut-- It turns out that most of this time, this is irrelevant. login sets $HOME and until you switch users, it will be left unchanged. The case where it becomes an issue is with some "execute a program as another user" commands. There is some difference in behavior here. --cut-- Should the target user be a non-privileged one, my suggestion (to only use HOME if it points to a directory which is both accessible and owned by the “now-current” user) should relieve the concerns listed. On the other hand, when the target user is ‘root’ (UID 0), either of these behaviors may be valid (depending on the exact circumstances, as was noted elsewhere in this thread), so this check shouldn't be done (should we follow the general principle of “root knows what it wants.”) [1] http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00066.html -- FSF associate member #7257 -- 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/86r4pls8w9@gray.siamics.net
Re: Processor microcode update packages
> Henrique de Moraes Holschuh writes: > On Fri, 28 Sep 2012, Eric Valette wrote: >> >> >> >> >> >> Reading the thread about microcode, I wonder why […] > 1. No html, please. And, especially, no /invalid/ HTML, please. […] -- Advocating the judicious use of XML applications at the Internet at large. Stop the use of proprietary formats on the Web and e-mail! -- 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/86vcexsdsv@gray.siamics.net
Bug#688932: g_get_home_dir () should prefer ${HOME} over getpwuid ()->pw_dir
Package: libglib2.0-0 Version: 2.32.3-1 X-Debbugs-Cc: debian-devel@lists.debian.org [Filing bug, as was suggested in the debian-devel@ discussion [1]. I've also started a discussion in gtk-devel-list@ [2].] Currently, it's not possible for the user to specify an arbitrary home directory for most of the Glib-based packages (such as, e. g., Gimp [3].) I therefore suggest to change g_get_home_dir () to follow the usual Unix convention of using ${HOME} as the user's home directory, falling back to getpwuid ()->pw_dir should HOME be non-existent or empty, or, additionally, should it point to a directory not owned by the current user, or on which he or she has no executable permission, unless the current user is ‘root’ (UID 0.) An expanded rationale is at [4]. TIA. [1] http://comments.gmane.org/gmane.linux.debian.devel.general/176973 [2] http://comments.gmane.org/gmane.comp.gnome.gtk+.devel.general/22721 [3] http://bugs.debian.org/453711 [4] http://permalink.gmane.org/gmane.comp.gnome.gtk+.devel.general/22721 -- FSF associate member #7257 -- 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/868vbwuhuj.fsf...@gray.siamics.net
Re: ${HOME} vs. g_get_home_dir ()
>>>>> Simon McVittie writes: >>>>> On 26/09/12 17:12, Ivan Shmakov wrote: >> (Want to use the all-defaults configuration for a program? Just >> start it like: $ HOME="$(mktemp -dt -- foo.)" foo) > Debian's GLib has been patched, and actually has this precedence: > G_HOME > getpwent > HOME. This was originally intended for running > things like regression tests on buildds, where the HOME specified in > /etc/passwd typically doesn't exist or can't be written; so G_HOME > gets set in debian/rules to force the issue. ACK, thanks for the hint! […] >> I believe that this behavior is buggy. There's even a (yet >> unresolved) bug report [2] against Gimp due to this behavior > To be more precise, that bug report is that the man page contradicts > what actually happens. The maintainer appears to think the correct > solution is to fix the man page. If he didn't change his mind over the past four years, that is. >> To address the only concern listed in [1] I deem valid, I'm also >> asking that the value of HOME be disregarded, unless it points to a >> directory, which is readable, writable, and owned, by the user. > That sounds like a good proposal... >> Unless there be objections (or Glib be quickly patched), I'd be >> filing a bug report against libglib2.0-0. > ... but I don't think this is the right way to make it happen. > Please research previous discussion to check that you're not missing > arguments that have happened in the past, Any particular pointers? A scan over the past 2.5 years of gtk-devel-list@ archives revealed nothing, and a brief Web search has only brought more users disappointed by this behavior (e. g., [3]) and more explicit work-arounds (e. g., [4].) [3] http://bugs.irssi.org/index.php?do=details&task_id=532 [4] http://zathura.pwmt.org/projects/girara/doxygen/utils_8c_source.html > then if you still think your proposal is the best option, take it > upstream. > I can see the value in having everything follow the same precedence, > $HOME > getpwent - predictability is good. However, having Debian's > GLib contradict behaviour that is specifically documented upstream > doesn't sound as though it promotes predictability. If your proposal > is good for Debian - which I think it is - then it's equally good for > upstream. Agreed. I guess I should raise this issue on gtk-devel-list@. -- FSF associate member #7257 -- 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/86r4povh7e@gray.siamics.net
${HOME} vs. g_get_home_dir ()
I do remember filing a bug or two against packages that refer to the getent () data to find the user's “home” directory instead of using the HOME environment variable. The environment is the preferred place to check for this kind of things: it's (usually) under the full control of the user, and it's quite possible to run several instances of a single program using different environments (with different executable file search PATH's, locales, time zones, etc.), which occasionally turns to be an immense aid to debugging. (Want to use the all-defaults configuration for a program? Just start it like: $ HOME="$(mktemp -dt -- foo.)" foo) Now, Glib has g_get_home_dir (), whose description reads [1]: --cut-- Gets the current user's home directory as defined in the password database. Note that in contrast to traditional UNIX tools, this function prefers passwd entries over the HOME environment variable. --cut-- I believe that this behavior is buggy. There's even a (yet unresolved) bug report [2] against Gimp due to this behavior, and my guess is that there may be quite a few packages more affected by it. While I understand some of the concerns regarding the “Unix” behavior (also at [1]; quoted below), I'd like to note that the software which both relies on g_get_home_dir () /and/ stores its files under a subdirectory of the home directory returned (which is, arguably, a common practice), is also likely to run into issues should that /subdirectory/ be made non-writable (or non-readable), and the current g_get_home_dir () behavior is not a safeguard against it. Therefore, I'd like to propose for this behavior to be changed to match the usual Unix conventions. To address the only concern listed in [1] I deem valid, I'm also asking that the value of HOME be disregarded, unless it points to a directory, which is readable, writable, and owned, by the user. Unless there be objections (or Glib be quickly patched), I'd be filing a bug report against libglib2.0-0. TIA. --cut-- One of the reasons for this decision is that applications in many cases need special handling to deal with the case where HOME is Not owned by the user Not writeable Not even readable --cut-- [1] http://developer.gnome.org/glib/2.28/glib-Miscellaneous-Utility-Functions.html [2] http://bugs.debian.org/453711 -- FSF associate member #7257 -- 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/861uhowyp3@gray.siamics.net
Re: Bug#688826: ITP: libarchive-rar-perl -- interface for the 'rar' command
> Joenio Costa writes: > Package: wnpp > Severity: wishlist > Owner: Joenio Costa > * Package name: libarchive-rar-perl > Version : 2.02 > Upstream Author : jean-marc boulade > * URL : http://search.cpan.org/dist/Archive-Rar/ > * License : Perl > Programming Lang: Perl > Description : interface for the 'rar' command > This is a module for the handling of rar archives. > .. > Locates the rar command AIUI, the Rar archiver is non-free. Do I understand it correctly that this package is thus intended for contrib? > (from PATH or from regedit for Win32) The W32 platform isn't worth mentioning, as Debian isn't available for one. > and encapsulate it to create, extract and list rar archives. -- FSF associate member #7257 -- 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/86y5jxwh64@gray.siamics.net
Re: Packages removing alternatives on upgrade
> Jakub Wilk writes: [Cross-posting to packages@qa, for elvis is maintained by the QA group.] > Many packages remove alternatives on upgrade, only to re-add them > later, potentially discarding manual choices of the user. > See also bug #71621. […] > Debian QA Group >elvis >elvis-console >elvis-tools >ircii […] BTW, do I understand it correctly that it's just a matter of dropping the ‘upgrade’ case from .prerm? (Possible patch MIME'd.) TIA. -- FSF associate member #7257 --- debian/elvis-console.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis-console.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) for app in editor ex input vi view; do update-alternatives --quiet --remove "$app" /usr/bin/elvis done --- debian/elvis.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) for app in editor ex input vi view; do update-alternatives --quiet --remove "$app" /usr/bin/elvisnox done --- debian/elvis-tools.prerm.~1~ 2012-09-23 13:34:49.0 + +++ debian/elvis-tools.prerm 2012-09-23 15:24:02.0 + @@ -3,7 +3,7 @@ set -e case "$1" in -upgrade|remove|deconfigure) +remove|deconfigure) update-alternatives --quiet --remove ctags /usr/bin/elvtags ;; failed-upgrade)
conffiles
> Thomas Goirand writes: […] > BTW, "conffiles" is a pretty bad name. It's confusing, as you can > see once more. > I thought about calling it "dpkg-conffiles" which has the advantage > of underlying that we leave the handling of the file to the > responsibility of dpkg, keeps the same old "conffiles" name. But > people will continue to use the older short version of it, so... > Anyone with a better idea? umdekfiles, perhaps? (For “User modifies, dpkg keeps [the changes.]”) At the very least, I don't think anyone with half the sane mind will confuse them with “configuration files.” -- FSF associate member #7257 -- 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/86zk4j237k.fsf...@gray.siamics.net
Re: status of eligibility of dug lists on lists.debian.org
> martin f krafft writes: […] > So the solution was to get one or two additional people, and > eventually I was even able to invest in more fail-proof hardware. > … and then you ask yourself what to do with all the spare cycles and > wouldn't other LUGs profit from your setup… And you keep going and > going and the dependence on you grows. Yes. […] > Now there are three ways forward: > 1. take back the mailing list, my infrastructure still exists and >could handle it, but am I willing to give a guarantee for the next >years to come? > 2. work with teams.debian.net to get it back up to speed. > 3. or use the official and professionally maintained infrastructure >on alioth.d.o or lists.d.o, which can probably handle a couple >dozens of additional lists. I can understand that we don't want a >new list for every formation or group in the Debian universe, To be honest, it's the very reason I dislike mailing lists. The groups come and go, while mailing lists have to stay forever, for their archive to be available for posterity. Usenet is better (though still not ideal) in this respect, as newsgroups aren't much more than just “tags”, which a single message may bear an arbitrary number of. Starting a “discussion group” should require no more skill and time than tuning a radio to an agreed frequency. And the archive should persist for as long as there's anyone to care. >but a list for large groups like the Debian users in and around of >Munich should arguably be doable. > My preference is clearly (3.). Maybe one of the sysadmins who could > host their own LUG list would be interested in helping the > listmasters. And should the hardware not be enough, then we can > probably find ways to upgrade it. I'd be fine going (2), either. What exactly needs to be done? -- FSF associate member #7257 -- 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/86mx0l3qrv@gray.siamics.net
versioned dependency on the libhdf5-7 virtual package
This issue was already discussed [1], and I've filed the respective bug report [2] (to which there was no reply so far, though), but now I see that there's a few more packages in Wheezy with a dependency on libhdf5-7. Consider, e. g.: $ bzcat \ < http.debian.net/debian/dists/wheezy/main/binary-amd64/Packages.bz2 \ | gawk '/^Package: / { pkg = $2; } /Version: / { vers = $2; } / libhdf5-7 \(/ { printf("%-23s %s\n", pkg, vers); }' libhe5-hdfeos0 5.1.13.dfsg.1-3 libhdf5-7-dbg 1.8.8-9 libhdf5-dev 1.8.8-9 cgns-convert3.1.3.4-1 libnexus0 4.2.1-svn1614-1+b1 libnexus0-java 4.2.1-svn1614-1+b1 nexus-tools 4.2.1-svn1614-1+b1 r-cran-hdf5 1.6.10-1 tessa 0.3.1-6 tessa-mpi 0.3.1-6 udav0.7.1.2-3 $ Any chance this issue will be rectified? (Or should I file bug reports against these packages?) TIA. [1] news:udlvci28as8@dr-wily.mit.edu http://permalink.gmane.org/gmane.linux.debian.science/5353 [2] http://bugs.debian.org/680400 -- FSF associate member #7257 http://sfd.am-1.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/86a9wu9iky@gray.siamics.net
Re: Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?
> Simon McVittie writes: […] > hicolor-icon-theme is really the infrastructure for a theme, rather > than *being* a theme: it does not contain any icons of its own. It > represents the fallback icon theme for all desktops that use > freedesktop.org themes (GNOME, KDE, XFCE, etc.). The name "hicolor" > is for historical reasons - it was the default icon theme hard-coded > into old versions of one of the major desktop environments (KDE 2 or > 3, I think?) and it stuck. > Its purpose is to be the theme into which applications install their > "theme-neutral" icons: anything that displays a themeable icon should > search for it in the configured theme, and then fall back to hicolor. ACK, thanks for the explanation, and apologies for a “false alarm.” (But why the other “theme” packages depend on it, BTW?) Now, I wonder, could its Description: be amended so to explain its function in more detail? Stating that it's “the default fallback theme” doesn't tell quite much to me, for instance. Consider, e. g. (though the wording is flaky a bit): Description: FreeDesktop.org default fallback theme infrastructure This package contains the necessary infrastructure for the applications to install their theme-neutral icons for the implementations of the Freedesktop.org Icon Theme specification to use. It provides the respective directory layout, an index file, and a script to start gtk-update-icon-cache(1) as necessary. . This package is not an icon theme per se as it contains no icons of its own. The "hicolor" name was hardcoded into an older version of a major desktop environment and is retained for historical reasons. > Its only file outside /usr/share/doc is metadata describing the > directories it provides (index.theme, 24K), and its postinst and dpkg > trigger maintain a Gtk icon cache for icons added to it by > applications. Thus, its function also implies a couple of Shell scripts below /var/lib/dpkg/info/, too. (Which are simple enough to not worry about, though.) […] > I don't think "we could potentially save 24K on those rare systems > that have certain specific X apps, but no GUI menu" is a very > compelling reason to change packages' dependencies? At the very least, it now doesn't bother me much more than having libmysqlclient18 installed on my MX'es running exim4-daemon-heavy (given that I never had to use MySQL with it specifically.) Still, using Depends: to depend on a (otherwise optional) .postinst script doesn't seem quite right to me. (And I'm pretty sure that dependencies of such a kind are generally Recommends: ones in Debian.) -- FSF associate member #7257 http://sf-day.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/86ipcg1yzs@gray.siamics.net
Depends: hicolor-icon-theme: shouldn't it be Recommends: instead?
Abstract The non-data packages currently having an absolute dependency on hicolor-icon-theme should consider downgrading it to Recommends: at the least. The list, and the explanation, are below. Chapter I imagemagick Recently, Depends: hicolor-icon-theme was added to the imagemagick's control file, which triggered my curiosity: does it provide something that wasn't needed (or was missed) by the previous versions of the package, but is strictly necessary to run the newer ones? Indeed, it doesn't. To prove it, I've made a trivial control file for equivs-build(1): --cut: k1o7mjuxokuwghktzugfno8qib.ctl -- Package: k1o7mjuxokuwghktzugfno8qib Provides: hicolor-icon-theme Description: Pretend that hicolor-icon-theme is installed (dummy) A dummy package pretending to provide hicolor-icon-theme. --cut: k1o7mjuxokuwghktzugfno8qib.ctl -- Having hicolor-icon-theme removed and this one installed, I've proceeded to install imagemagick. Unsurprisingly, I've found /no/ issues with either installing or running it. (I've tried display(1), but I'm quite sure that there won't be any issues with convert(1), either.) Chapter II A few packages more Well, I've wondered, is this a singular issue with Depends: hicolor-icon-theme, somehow creeped into Debian Wheezy “just prior” to its scheduled release? Indeed, it isn't. I've examined the reverse dependencies of hicolor-icon-theme: $ apt-cache rdepends --no-suggests --no-recommends \ hicolor-icon-theme hicolor-icon-theme Reverse Depends: viridian tango-icon-theme synaptic rabbitvcs-core perlpanel oxygen-icon-theme openteacher kdelibs5-data imagemagick gnome-phone-manager gnome-icon-theme-symbolic gnome-icon-theme-extras gnome-icon-theme flush d-feet $ Well, it doesn't seem suspicious for anything *-icon-* and *-data to depend on an icon theme, but what about the rest? For a start, I've omitted rabbitvcs-core and viridian, and considered d-feet, flush, openteacher, perlpanel, and synaptic. Unsurprisingly, all of them were able to install and run, but while openteacher is seemingly unaffected by the absence of the data in question, the rest have had obvious issues: almost all of the icons were absent, resulting in blank space on the GUI, missing controls, and warnings to stderr (stdout?) Conclusion Since there're (as it seems) virtually no issues with running imagemagick without a “real” hicolor-icon-theme installed, my suggestion would be to downgrade the dependency to Suggests: (or Recommends:, if there's some point I've missed.) As for the other packages considered, my suggestion would be to downgrade the dependencies to Recommends: (or, for openteacher, to Suggests:, if it's indeed unaffected.) Unless there'd be any objections, I'll consider filing a bug against imagemagick, and perhaps the other aforementioned packages as well. Post Scriptum Curiously enough, the only “application” package having a Recommends: dependency on hicolor-icon-theme is cheese. -- FSF associate member #7257 http://sf-day.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/86ehn551jr@gray.siamics.net
Re: [OT] ifconfig(8)
>>>>> Timo Juhani Lindfors writes: >>>>> Ivan Shmakov writes: >> Curiously enough, ifconfig(8) shows RX/TX byte counts, and, somehow, >> I didn't manage to get a similar output from iproute. Any pointers? >> TIA. > $ ip -s link show lo > 1: lo: mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > RX: bytes packets errors dropped overrun mcast > 1686679058 6901861 0 0 0 0 > TX: bytes packets errors dropped carrier collsns > 1686679058 6901861 0 0 0 0 At last, I can forget about ifconfig(8). Thanks! -- FSF associate member #7257 http://sf-day.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/86fw7xk548@gray.siamics.net
[OT] ifconfig(8)
> Marco d'Itri writes: > On Aug 08, Arno Töll wrote: >> ifconfig and route were around already when everyone insisted on the >> separation of /bin and /sbin. /bin/ip is slightly newer and >> supposed to replace ifconfig/route some day entirely. > Just for the records, iproute entirely replaced ifconfig/route long > ago. Curiously enough, ifconfig(8) shows RX/TX byte counts, and, somehow, I didn't manage to get a similar output from iproute. Any pointers? TIA. > The only reason for keeping around the old programs is compatibility > with other packages not yet updated and to not scare people who do > not know better. > (Does anybody want to try removing net-tools and see what breaks?) I guess that $ apt-cache rdepends may be a safer check, like: $ apt-cache rdepends --no-suggests net-tools However, it made me wonder, why ifupdown Suggests: net-tools? -- FSF associate member #7257 http://sf-day.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/86k3x9k5xn.fsf...@gray.siamics.net
Re: Modified http://wiki.debian.org/DebianDeveloper to mention non-packagers
> The Fungi writes: > On 2012-07-26 14:29:14 +0100 (+0100), Ian Jackson wrote: >> We also need a general word for "someone involved with Debian in a >> positive way". "Participant" is clumsy; "member of the community" >> even more so. "Person" might do but word with a more positive spin >> would be nice. > As a long-time participant and non-DD, I've always liked the term > "contributor" in that context. As (hopefully) one of the affected, I'm fine with “contributor.” -- FSF associate member #7257 http://sf-day.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/86wr1puk4q.fsf...@gray.siamics.net
Re: Bug#637232: Multiarch breaks support for non-multiarch toolchain
> Jonathan Nieder writes: > Goswin von Brederlow wrote: >> What I don't understand is why compilers (which probably means ld >> from binutils in all cases) won't use ld.so.conf to find the libs. >> It only does so to find libs linked into libs you link against. So >> it is used execpt for the verry first level of recursion. > The ld library path and compiler library path represent different > things[*]. Somehow, I guess that “the ld.so(8) library path” and “the ld(1) library path” were actually meant here. […] -- FSF associate member #7257 http://sf-day.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/86pq7my9i5@gray.siamics.net
Re: Recommends for metapackages
> Jonas Smedegaard writes: […] > It is a feature (which each user is free to avoid by not using it!) > for Debian to include a meta-package that pulls in that vil n-m, > not a bug. … And what exactly this “feature” gives to the user? […] -- FSF associate member #7257 http://sf-day.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/86d3430zhm@gray.siamics.net
Re: CD sizes again (and BoF reminder!)
> Ben Hutchings writes: [...] > - twm: no-one should have to suffer this And, exactly, why not? Before I've switched to Openbox, it was one of the two WM's I've used, along with FVWM. And they say [1] that it still can be handy at times. The “obscure” label may fit, though. [...] [1] news:1187451...@ddt.demos.su (in Russian; and is garbled beyond recognition on Google Groups.) -- FSF associate member #7257 -- 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/86sjd13tzn@gray.siamics.net
Re: Bug#675106: ITP: pgbulkload -- A high speed data loading utility for PostgreSQL
> Alexander Kuznetsov writes: […] (Some wording fixes and suggestions.) > Description : A high speed data loading utility for PostgreSQL > pg_bulkload is designed to load huge amount of data to a database. > You can choose whether database constraints are checked and how many errors > are If “You can…” here starts a new paragraph, there's ought to be an empty (“.”) line. And if not, the linebreak here came a bit too early than necessary. > ignored during the loading. For example, you can skip integrity checks for > performance when you copy data from another database to PostgreSQL. On the > other hand, you can enable constraint checks when loading unclean data. > . Are “constraint checks” different to “integrity checks” in the above? Unless they are, it should rather be, e. g.: … For example, you can skip integrity checks for performance when you copy data from another database to PostgreSQL, or have them in place when loading potentially unclean data. > The original goal of pg_bulkload was an faster alternative of COPY command in … was /a/ faster… Or, perhaps: … was to provide a faster… > PostgreSQL, but version 3.0 or later has some ETL features like input data > validation and data transformation with filter functions. > . … but as of version 3.0 some ETL features… were added. And what's ETL, BTW? > In version 3.1, pg_bulkload can convert the load data into the binary file > which can be used as an input file of pg_bulkload. If you check whether Perhaps: As of version 3.1, pg_bulkload can dump the preprocessed data into a binary file, allowing for… (Here, the purpose should be mentioned. Is this for improving the performance of later multiple “bulkloads”, for instance?) > the load data is valid when converting it into the binary file, you can skip > the check when loading it from the binary file to a table. Which would reduce > the load time itself. Also in version 3.1, parallel loading works > more effectively than before. s/effectively/efficiently/. But the whole sentence makes little sense, as the earlier versions weren't packaged for Debian. -- FSF associate member #7257 -- 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/86wr3ujphk@gray.siamics.net
Re: Packaging on GitHub ?
> Thorsten Glaser writes: > Charles Plessy dixit: >> upstream source moved to GitHub, and we would like to try to >> maintain the Debian package there as well. > This is not a good idea: http://mako.cc/writing/hill-free_tools.html That's why I tend to advocate for the use of Gitorious instead. --cut: http://en.wikipedia.org/wiki/Gitorious -- CAPTION: Gitorious Developer(s) Shortcut AS Written inRuby Operating system Cross-platform Available in English Type Project management software License GNU Affero General Public License Website https://gitorious.org/gitorious/ --cut: http://en.wikipedia.org/wiki/Gitorious -- PS. An RFP, perhaps? -- FSF associate member #7257 -- 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/861um2l4w9@gray.siamics.net
/tmp on multi-FS set-ups, or: block users from using /tmp?
> Weldon Goree writes: > On Fri, 2012-05-25 at 10:02 -0400, Nikolaus Rath wrote: >> I think having / and /tmp share the same file system is a bad idea, >> because then writing lots of stuff to /tmp would potentially fill up >> the root file system (that typically also includes /var) and then >> cause a lot of breakage. >> However, if I put /tmp in a separate (on-disk) file system, I have >> to decide how much disk space to I want to permanently allocate for >> temporary data, in addition to the disk space permanently allocated >> for swapping. […] Somehow, I feel that some of the participants of this discussion are missing this very point: having /tmp on disk /doesn't/ mean that /all/ the free disk space will be available for it at any given time. In particular, as Ext2+ filesystems can only be expanded, and not reduced (without unmounting), I've got the habit of having most of the disk space unallocated, and only expanding the filesystems as they grow full. (Unless, of course, considerable amounts of cruft could be identified and removed at that time.) > If only ext*fs supported quotas... … But that makes me recall a solution to both the /tmp and quota issues I've seen somewhere: use ~/tmp/ instead of /tmp. This way, user's temporary files will be subject to exactly the same limits as all the other his or her files. (Still, we may need to identify the software that ignores TMPDIR and tries to write to /tmp unconditionally.) > (Snark aside, does tmpfs support quotas yet/will it ever?) -- FSF associate member #7257 -- 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/86r4u7koc5.fsf...@gray.siamics.net
Bug#664784: ITP: sandbox -- A helper utility to run programs in a sandboxed environment
Package: wnpp Severity: wishlist Owner: Ivan Krylov * Package name: sandbox Version : 2.5 Upstream Author : Gentoo Foundation * URL : http://gentoo.org/ * License : GPL-2.0+ Programming Lang: C Description : A helper utility to run programs in a sandboxed environment Sandbox is a library (and helper utility) to run programs in a "sandboxed" environment. This is used as a QA measure to try and prevent applications from modifying files they should not. . For example, in the Gentoo world it is used for building applications as root and being sure that the build system does not do crazy things outside of its build directory. Such as install files to the live root file system or modify config files on the fly. . For people who are familiar with the Debian "fakeroot" project or the RPM based "InstallWatch", sandbox is in the same vein of projects. -- 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/20120320201143.12461.16661.reportbug@infinitea
Re: Increasing minimum 'i386' processor
> Ben Hutchings writes: > On Sun, 2011-11-20 at 23:44 +0100, Cesare Leonardi wrote: […] >> While i might agree with the exclusion of 486 cpu classes (somewhere >> i have a Winchip C6 200 MHz but i consider it unusable except for >> very limited tasks), i think that excluding 586 could be too >> aggressive. AMD K6-2 processors doesn't have CMOV, because when i >> try to use various rescue CD on some of these machine, they don't >> boot with a messages informing of the missing instruction. These >> processors are about 15 years old but are still useful and usable >> today and maybe still for Wheezy+1. I think that would be a pity if >> Debian will not provide anymore a kernel for this old cpus. > Maybe you think it's a waste to replace old PCs, but in many cases > it's a waste of money to keep them running. Electricity isn't > getting any cheaper and modern systems are much better at > power-saving. I'm not sure about ARM, but one of my K6-based systems apparently has power consumption below or comparable to that of one of my Intel Atom ones. (Though the performance of the former is obviously lower.) One more observation is that the 80386-based systems and the like didn't require any coolers. That being said, I'm now considering moving to ARM-based hardware, such as the Raspberry Pi computer, for the tasks that don't require much CPU cycles. -- FSF associate member #7257 -- 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/86k46soboo@gray.siamics.net
Re: Bug#645656: network-manager in Gnome
> Jon Dowland writes: > On Tue, Nov 01, 2011 at 02:56:53PM +, Ian Jackson wrote: >> We should do it when we judge that the benefits are worth the costs. >> In this particular case the costs seem to be minimal. There isn't >> even a direct patch-carrying cost, since the dependency is expressed >> in our own control files. > What should it be called: gnome-without-network-manager? > I really don't like evolution. Can I have a gnome-without-evolution? > (Only half-joking. I *really* don't like evolution). > Where do you draw the line? > (Of course, any Debian developer can freely create such a dependency > package, it doesn't have to be the GNOME maintainers.) > In case it isn't clear, I don't think it's a good idea. Well, I seem to jump into the discussion without thoroughly reading all the postings (and I've never tried to install the gnome package, BTW), but the issue with network-manager seems to me much easier to solve than the one with evolution, as the former is in Recommends:, while the latter is in Depends:. The difference is that there could be a «negapackage» (marked as manually installed with APT), with the sole purpose of having a Conflicts: network-manager line. (Why, such a package could simply be done with equivs!) Then, it was my understanding that APT will instantly remove network-manager (and its respective dependencies) should the negapackage be installed, and will never try to install the offending package until an explicit user request. Therefore, I'm curious if the Debian metapackages could be switched to primarily use Recommends:, and not Depends:? (So that the users could then have a conflicting package installed, or simply remove the offending package manually.) -- FSF associate member #7257 -- 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/86aa8fg3nn@gray.siamics.net
Re: Advocating the use of RDF for Debian's published metadata
> Matthias Klumpp writes: […] > It would be very nice, if ftpmasters could tell if they would accept > a new format in the archive or if we should stay with RFC822 which is > used for nearly everything else already. >> Note that the same rationale stands for all metadata to be >> eventually published on the Web by Debian servers. >> Hope this helps. > Thank you for the information... I think RDF would be much more > "open" for other people and apps to use, as the data wouldn't be in a > Debian-specific format. (I can't imagine yet what others would do > with this data, but if more people would use RDF, e.g. other > distributors too, having it all in one standardized and extensible > format would be something valuable) Well, having this data aligned with the RDF model will help interoperability, I guess. One application I have in mind is that it becomes possible to query the Debian Packages and Sources databases using the powerful SPARQL language. In particular, one may quickly check if there're any packages that are transitively dependent on A, while also immediately dependent on B. (Yes, grep-dctrl(1) helps, but it's not quite as powerful a language as the recent edition of SPARQL, not to mention that it's yet another query language to learn.) However, I believe that it's infeasible to change the native format the aforementioned databases, as both it isn't going to be easy to implement, and it may bring considerable burden on both the Debian users and maintainers. Thus, my opinion is that there should be a tool performing conversion from the Debian's native database format to some RDF representation. In particular, rdfproc(1) could become such a tool, provided that Raptor will be extended to parse RFC 822. That being said, I don't see such a conversion as a simple and straight-forward process. In particular, should a package stanza be transformed into a named (as per Package:) or blank node (with Package: as an explicit relation)? The Depends: a, b and Depends: a | b may both have an RDF list in the object position, but how to distinguish between them? And how a line such as Depends: a (>> 0.1) should be expressed? Should the package names be encoded as string literals, or should they be transformed into URI's instead? There're quite a few choices to be made by the one volunteering for this. These questions were in my TODO list for some time (filed under Category: nifty hack, as I'm yet to see any serious practical uses for such a thing), but I'm short of spare time these days, and won't probably be able to do much, apart from participation in the discussions on this subject. -- FSF associate member #7257 -- 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/86hb2ng5bt.fsf...@gray.siamics.net
http://www.gnu.org/s/hello/manual/automake/ ?
> Adam Borowski writes: […] > GNU's and the inventor of AM_MAINTAINER_MODE's stance: > http://www.gnu.org/s/hello/manual/automake/maintainer_002dmode.html BTW, this URI seems to me like a thing to be reported to GNU webmasters (Cc:'ed.) The Automake manual should be (and it is) accessible via, e. g.: http://www.gnu.org/s/automake/manual/html_node/ http://www.gnu.org/software/automake/manual/html_node/ I was also surprised to find that the following URI's are also valid (but not, e. g., bash/ or tar/): http://www.gnu.org/s/hello/manual/autoconf/ http://www.gnu.org/s/hello/manual/gettext/ http://www.gnu.org/s/hello/manual/libc/ http://www.gnu.org/s/hello/manual/libtool/ If it was done on purpose, I'd suggest that the respective “parent” page (http://www.gnu.org/s/hello/manual/) should have them hyperlinked. TIA. […] -- FSF associate member #7257 -- 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/86r521mn20.fsf...@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Ben Hutchings writes: >>>>> On Mon, 2011-10-24 at 22:12 +0700, Ivan Shmakov wrote: […] >> BTW, does the root=UUID= variant require udev as well? > Yes, currently the kernel filesystem code does not probe for filesystem > UUIDs. (However, it does support partition UUIDs as used in GPT. You > can use root=PARTUUID= to select from those. ACK, thanks! > But I doubt you're using a GPT.) Actually, I do. CHS addressing (as used in MBR, even if along with LBA) seems to me a bit obsolete (for at least a decade), thus I've moved to use GPT for all the new media almost as soon as I've discovered it. Sometimes, I have to use gptsync(8), though. -- FSF associate member #7257 -- 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/86ty6xoj76@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Marco d'Itri writes: >>>>> On Oct 24, Ivan Shmakov wrote: >> So, the kernel won't try to autoload a module when the corresponding >> device gets accessed? > Not for *hardware* drivers, since it cannot know which driver is > needed. Not even via modprobe.conf(5)? >> I've never heard of that (and Googling for “linux equiv” doesn't >> seem to return anything relevant to the problem.) What's it? > I meant equivs. Somehow, I've totally missed this one. Which, indeed, I've a plenty uses for. Thanks! > Anyway, I think that if you want to learn how udev works then you > should send your questions to an users support mailing > list/newsgroup/forum/etc. Well, seems like there're little specific to Debian in how udev works. Thanks. -- FSF associate member #7257 -- 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/8639eipe2m@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Timo Juhani Lindfors writes: >>>>> Ivan Shmakov writes: >> And what the initramfs-tools package has to do with consistent >> devices' filenames? > Initramfs runs udev. This allows you to use e.g. > root=/dev/disk/by-id/ata-WDC_WD3200AAJS-65B4A0_WD-WMAT13954017-part1 > instead of > root=/dev/sda1 > to specify where your root filesystem is. Indeed, it's a good option to have. But isn't it something that can be, in certain circumstances, however marginal, considered an extra? BTW, does the root=UUID= variant require udev as well? TIA. -- FSF associate member #7257 -- 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/868voapgol@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Marco d'Itri writes: >>>>> On Oct 24, Ivan Shmakov wrote: >> It doesn't seem like a good reason for the aforementioned >> dependency, does it? > There are many other reasons, you can find them in /lib/udev/. ACK, thanks. >> And what the initramfs-tools package has to do with consistent >> devices' filenames? > udev is needed to automatically load all the modules you need, for a > start. So, the kernel won't try to autoload a module when the corresponding device gets accessed? It was my understanding that, e. g., should a 10, 1 character device (/dev/psaux) be accessed, the kernel will spawn modprobe(8) against char-major-10-1, which is then resolved to ‘psmouse’ thanks to modprobe.conf(5). At the least, it was used to do just that something like a decade ago (IOW, as of 2.4.) $ /sbin/modprobe -c | grep -F -- 'char-major-10-1 ' alias char-major-10-1 psmouse $ >> However, I wonder, how often these numbers will change given that >> the system's hardware configuration will essentially be fixed for >> all the foreseeable future? I guess it won't be something like >> “every (other) kernel's release”, right? > Names could change even at every boot. Any reasons for that other than the order in which the modules get loaded? > Anyway, you have equiv. Try to use it and look what happens. I've never heard of that (and Googling for “linux equiv” doesn't seem to return anything relevant to the problem.) What's it? TIA. -- FSF associate member #7257 -- 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/86d3dmpgxr@gray.siamics.net
Re: udev: what does it used for in Debian?
>>>>> Neil Williams writes: >>>>> On Mon, 24 Oct 2011 18:19:08 +0700 Ivan Shmakov wrote: >> I've found that a few packages, contrary to my expectations, have >> Depends: on udev. I'm primarily concerned with alsa-base and >> initramfs-tools, but also wonder about libcomedi0, dkopp, >> python-expeyes, libnjb5, media-player-info, pulseaudio, ukopp, >> xserver-xorg-core, and midisport-firmware. >> The backstory is that I'm about to install Debian (either stable or >> testing) on a tiny Architecture: i386 system, and consider excluding >> udev from the installation, as the hardware in question has >> virtually no support for any pluggable devices whatsoever. > udev isn't just for pluggable devices, packages can provide udev > rules to ensure that devices appear with a consistent name, It doesn't seem like a good reason for the aforementioned dependency, does it? And what the initramfs-tools package has to do with consistent devices' filenames? > e.g. /dev/input/event[0-9] does not include only pluggable or > external devices, it can contain several internal input devices as > HIDs but the actual number is not predictable. To make sure the > package reads from the correct device, it is wiser to provide a udev > rule which gives a particularly identified input device (by > classification / type / interface or even vendor) a known /dev > location as a name or symlink. Indeed, thanks. Somehow, I assume that given a relatively small number of devices per bus, this wasn't a problem, say, a decade or so ago. (Think of, say, 2 IDE or floppy drives per IDE or FDD controller, one keyboard, one PS/2 mouse, two RS-232 ports per UART, etc.) Or was it rather that there was much less variation between different instances Intel-based computers' hardware? However, I wonder, how often these numbers will change given that the system's hardware configuration will essentially be fixed for all the foreseeable future? I guess it won't be something like “every (other) kernel's release”, right? TIA. -- FSF associate member #7257 -- 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/86hb2ypj3i@gray.siamics.net
udev: what does it used for in Debian?
I've found that a few packages, contrary to my expectations, have Depends: on udev. I'm primarily concerned with alsa-base and initramfs-tools, but also wonder about libcomedi0, dkopp, python-expeyes, libnjb5, media-player-info, pulseaudio, ukopp, xserver-xorg-core, and midisport-firmware. The backstory is that I'm about to install Debian (either stable or testing) on a tiny Architecture: i386 system, and consider excluding udev from the installation, as the hardware in question has virtually no support for any pluggable devices whatsoever. -- FSF associate member #7257 -- 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/86lisaprgz@gray.siamics.net
Bug#646131: ITP: pg_comparator -- efficient PostgreSQL table content comparison and synchronization
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: pg_comparator Version: 1.7.0 Upstream Author: Fabien Coelho URL: http://pgfoundry.org/projects/pg-comparator/ License: BSD Description: efficient PostgreSQL table content comparison and synchronization -- 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/20111021163123.ga4...@gmail.com