Re: Look for keysign
I remember you! I can't help with signing (wrong country) but good luck! -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Request for IkiWiki NMU (FTBFS #1074727)
Hi, intrigeri's patch at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074727#22> looks good to me (eyeball test only) I would be very grateful if someone would be prepared to Debian-ize it and NMU IkiWiki (due to be removed from testing this week); I am not able to do any Debian work at the moment. Best, -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: RFC: packages that can be installed by the user but not used as build dependencies
On Tue Aug 20, 2024 at 12:17 AM BST, Lisandro Damián Nicanor Pérez Meyer wrote: > But users would love to have something like 'qt6-full-dev'. And the > reason we never provided them with this meta-package is that package > maintainers would use it almost everywhere, dragging the whole Qt > installation on each package depending on it... This is a _huge_ waste > of resources and buildd time (or is it not??) I think it would be better to use social methods to prevent maintainers from doing this, rather than technical ones. > At one point I thought of adding a Lintian test checking for this kind > of usage, but first and foremost I would like to know if you think > this is a viable/acceptable idea, maybe even adding a special section > in our policy. I like the idea of a Lintian check, assuming Lintian accepts checks which don't correspond to Policy. I'm not sure it makes sense to try and encode this restriction in Policy itself. Best wishes, -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Thanks for working on this. I finally had a read over it today.
I've found the split in discussion between this list and the Merge Request
comments
hard to manage. It would help a lot, I think, if some of the MR threads were
marked
resolved, assuming the issues they describe are resolved. That would reduce the
amount of stuff to read.
I got random errors from Gitlab whilst trying to add comments myself
("Error dismissing suggestion popover. Please try again.") but perhaps they're
irrelevant (or perhaps nobody will see my comments).
My overall impression is that this is a bold attempt, but the document could do
with some copy-editing to whittle it down, make it more focussed, and possibly
narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be
done further down the line in a follow-up DEP?
There are a few references to DEP-14, which Bastian points out has been in
"candidate" state since 2020. Your proposal is not strictly depending on
DEP-14, but I wonder if someone invested should try and get that one over
the line as well (if not before). It would give me (and I wager others) more
confidence in the whole DEP process if more of the proposals made it into a
"final" state than are now.
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sun Sep 1, 2024 at 6:14 PM BST, Otto Kekäläinen wrote: > The discussion was summarized in a separate "Summay" email by me on this > list, and a comment in the MR (which merges the two discussions) and it > just happened that the next day it was also covered in > https://lwn.net/Articles/986480/ > > I am currently writing revision 2 of the proposal. I will notify when > published. Thanks. I look forward to it. It would be great if this was iterative on top of your first, in distinct commits, such that you/we/someone can mark conversation threads on GitLab as "resolved" (if they are by your second draft). Best, -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: Debian Birthday in Netcraft
On Thu, Aug 21, 2003 at 02:03:50PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: > I'm not even sure how they derive that information, Debian's Apache might > provide it in the banner information (Since when? BTW, has this always been > the case?) but many other web servers in Debian won't. This might not be > completely relevant however (since the web server market is dominated by > two products at the moment). > > But, of course, you (can?) always lie with statistics [1] netcraft have some very clever means of discovering such information, from what I've heard (which isn't much). I used to know someone who worked there but he was very tight-lipped. I would imagine its far more sophisticated than looking at the web server's banner info. -- Jon Dowland http://jon.dowland.name/
debian menu system and capital letters
Hi all, A small annoyance I have with debian's menu system is an inconsistency in the naming of programs on the menus: Apps/Tools ASclock EditRes Oclock ... bbpager docker ... The ordering of the menu is dictated by the menu system rather than my window manager. I would like the menu to be alphabetical, but the existing ordering (alphanumerical I presume) would suffice if the packages all agreed on starting either with a capital or a lower-case letter. Do you think that there should be a menu policy as to the capitalisation (or general presentation) of entries? Where should the responsibility for ordering menus lie, in the menu system, or the program which exhibits a menu (E.g., the window manager)? If anyone could point me at an existing discussion of this topic I would be very grateful. -- Jon Dowland http://jon.dowland.name/
Re: debian menu system and capital letters
On Mon, Sep 08, 2003 at 04:10:20PM +0100, Jason Chambers wrote: > > You can get the case ignored when ordering by adding the following > to /etc/menu-methods/menu.h. > > sort=tolower($title) > > Then run update-menus to regenerate them. I've had a play around with this, and found that putting a custom menu.h in ~/.menu-methods works for a user. However, I then need to keep up-to-date copies of anything from /etc/menu-methods/ in this directory too, if I want a menu generated. Is it currently impossible to override some, but not all of the /etc/menu-methods folder, on a user-by-user basis? Thanks for your help, -- Jon Dowland http://jon.dowland.name/
Re: Debian should not modify the kernels!
On Sun, Sep 21, 2003 at 12:00:05PM -0700, Erik Steffl wrote: > if I get kernel 2.4.22 as a debian package I expect kernel 2.4.22 as > a debian package, not something else... any debian specific changes > should result in kernel name change, that's what's expected in kernel > world (when I get ac kernel I get 2.4.22-ac3) Me too - if we have to have significantly modified kernels, they should be labelled as being such. If the issue here is the grsec patch distributed as a debian package cannot cleanly apply to the debian kernel sources because they have been significantly modified; why aren't those modifications distributed as seperate kernel patches / debian packages in the same way grsec is? -- Jon Dowland http://jon.dowland.name/
Re: [debian-devel] Re: A case study of a new user turned off debian
On Tue, Nov 04, 2003 at 06:48:09AM +, Magos?nyi ?rp?d wrote: > I guess having kernel-image-vanilla and/or > kernel-image-onlybugfix in debian would not hurt. Or kernel-image-hx ... what caught me out was believing kernel-image-2.4.xx or whatever was relatively pristine. However naive that makes me I know I am not alone. > I think the same about the rest, however I understand that > Herbert does the best kernel debs you can apt-get install, > and he does a very importand job no one else is willing to > do, and he does it well (but with a different approach I or > you do not do). I definitely appreciate Herbert's work, regardless of my differences of opinion on how it should be done :-) -- Jon Dowland http://jon.dowland.name/
Re: A case study of a new user turned off debian
On Mon, Nov 03, 2003 at 08:12:38PM +, Steve Kemp wrote: > On Mon, Nov 03, 2003 at 03:05:56PM -0500, Greg Stark wrote: > > > All he had to do was install an older version of libc6 and every other > > package > > would have been happy. All the infrastructure is there to do this, the old > > packages are all on the ftp/http sites, the package may even be sitting in > > apt's cache. But there's no interface for it. > > Sure there is, 'dpkg --install $foo.deb'. Doesn't that do exactly the > correct thing, even at the expense of downgrading? So its possible.. it isn't easy, intuitive or flexible. I suppose he could grab the pristine tarball too. -- Jon Dowland http://jon.dowland.name/
Re: Package libc6-dev depends on linux-kernel-headers
On Mon, Nov 03, 2003 at 08:23:14PM +0100, Andreas Metzler wrote: > Jonathan Dowland <[EMAIL PROTECTED]> wrote: > > I don't know whether this package needs to match the kernel version or > > not, but if not I think the name is poorly chosen. > > So your "substantive reason" is: "The name of the new package is > poorly chosen."? - I don't think so, it describes the contents rather > well, doesn't it? Well, the package contains the header files appropriate to libc. It has been mentioned that these headers are mostly 'private' to libc, that is, applications should rarely include them. The headers do not need to match the kernel version - but calling the package 'linux-kernel-headers' gives a strong association between itself and the linux kernel. In what situation would the linux-kernel-headers package be needed seperate from libc? -- Jon Dowland http://jon.dowland.name/
Re: Package libc6-dev depends on linux-kernel-headers
On Wed, Nov 05, 2003 at 05:23:30PM -0500, Andrew Pimlott wrote: > On Mon, Nov 03, 2003 at 01:20:49PM -0500, Daniel Jacobowitz wrote: > > It does not need to. Feel free to propose a patch to document this > > more clearly (I don't really want to rename it again...) > > Add something like this to the description: > > These headers are not used to compile kernel modules, and need > not match the running kernel or any installed kernel source > tree. > > Andrew I understand that renaming the package is less than easy and that making the description include this warning is fairly straightforward, but if we acknowledge that there is a problem here, then in the long-run this will come up again and again based soley on the package name, as people won't read the descriptions before complaining. Renaming the package will save trouble later. -- Jon Dowland http://jon.dowland.name/
kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)
On Wed, Nov 05, 2003 at 11:13:28AM -0600, Ryan Underwood wrote: > Before that realization, it seemed like the type of random cruft that > sometimes gets pulled in on dist-upgrade; a name change would help > alleviate that initial perception, IMO. Why not libc6-linux-headers? I'm in two minds whether or not to ask this, but I've been wondering about the naming scheme for linux packages - kernel-*. Why not linux-kernel-* or linux-* ? If alternative kernels in debian become more popular, is there a potential for confusion in the future? Thanks, -- Jon Dowland http://jon.dowland.name/
Re: Package libc6-dev depends on linux-kernel-headers
On Wed, Nov 05, 2003 at 11:21:11AM -0500, Daniel Jacobowitz wrote: > On Wed, Nov 05, 2003 at 10:37:24PM +1100, Herbert Xu wrote: > > Jonathan Dowland <[EMAIL PROTECTED]> wrote: > > > > > > In what situation would the linux-kernel-headers package be needed > > > seperate from libc? > > > > Ths issue is not whether it is needed separately from libc-dev, the > > issue is that it comes from a different upstream source and thus is > > best handled in a separate source package. This requires it to be > > in a different binary package too. > > Precisely. > > The original reason it was separated was because I wanted to maintain > a separate set of .patch files for the Debian-local changes to the > kernel headers. This way was most convenient. Also, most fixes to the > kernel headers do not require glibc to be rebuilt. Thank you both, that is then a perfectly reasonable and rational reason to have seperate packages. -- Jon Dowland http://jon.dowland.name/
Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)
On Thu, Nov 06, 2003 at 01:14:31PM -0600, Steve Greenland wrote: > On 05-Nov-03, 19:14 (CST), Jonathan Dowland <[EMAIL PROTECTED]> wrote: > > I'm in two minds whether or not to ask this, but I've been wondering > > about the naming scheme for linux packages - kernel-*. Why not > > linux-kernel-* or linux-* ? If alternative kernels in debian become > > more popular, is there a potential for confusion in the future? > > Surely these won't all show up in the same Packages file...if you're > running GNU/KFreeBSD, it will be a FreeBSD kernel, right? Why would the > Linux and Hurd kernels even be in the list? The image file for kernel A may not be of much use when you are running kernel B, but I wouldn't suggest that nobody would have a need for it. Sources and headers would be more useful as you may want to examine the code of one kernel if you are working on another, and use sections etc. -- Jon Dowland http://jon.dowland.name/
Re: kernel package names (was Re: Package libc6-dev depends on linux-kernel-headers)
On Wed, Nov 05, 2003 at 08:43:52PM -0500, Greg Folkert wrote: > On Wed, 2003-11-05 at 20:14, Jonathan Dowland wrote: > > I'm in two minds whether or not to ask this, but I've been wondering > > about the naming scheme for linux packages - kernel-*. Why not > > linux-kernel-* or linux-* ? If alternative kernels in debian become > > more popular, is there a potential for confusion in the future? > > Here we GO again... > > Martin Kraaft? Herbert Xu? among others... Ready for another "heated" > debate. Sorry! I'm not out to cause a flamewar. I'll search the archives for the arguments... -- Jon Dowland http://jon.dowland.name/
Re: rename linux-kernel-headers to system-headers
On Thu, Nov 06, 2003 at 07:55:03PM +0100, Eduard Bloch wrote: > What not rename linux-kernel-headers to simple system-headers-linux? > This will prevent confused users (or: lazy to read the description users) > from asking this again and again. system-headers-linux is a bit vague and without knowing could be associated with the kernel just as strongly as with libc. How about libc-linux-headers? -- Jon Dowland http://jon.dowland.name/
Re: rename linux-kernel-headers to system-headers
On Fri, Nov 07, 2003 at 10:45:24PM -0600, Graham Wilson wrote: > On Fri, Nov 07, 2003 at 09:37:16PM +0100, Otto Wyss wrote: > > > On Fri, Nov 07, 2003 at 10:45:32AM +0000, Jonathan Dowland wrote: > > > > On Thu, Nov 06, 2003 at 07:55:03PM +0100, Eduard Bloch wrote: > > > > > > > > > What not rename linux-kernel-headers to simple system-headers-linux? > > > > > This will prevent confused users (or: lazy to read the description > > > > > users) > > > > > from asking this again and again. > > > > > > > > system-headers-linux is a bit vague and without knowing could be > > > > associated with the kernel just as strongly as with libc. > > > > > > > > How about libc-linux-headers? > > > > > > I second that, or perhaps libc6-linux-headers. > > > > If the package would have been named "libc6-linux-headers" to show its > > strong relationship with libc6 I had never started this thread. I'm not > > a fan of renaming but in this case IMO it seems to be appropriate. > > But then the package would have to be changed for a new SONAME. And I > don't see any benefits of using libc6-linux-headers, as opposed to > libc-linux-headers. Would the package libc6 not have to be changed in the same way? So the work would have to be done for part of the system. libc6-* would be more consistent with libc6 (although I have little objection to libc-*, as it is still a great deal clearer than the present situation) -- Jon Dowland http://jon.dowland.name/
Re: Is vrms really still a Virtual Richard M. Stallman?
On Mon, Nov 17, 2003 at 12:04:00PM +0100, Roland Stigge wrote: > Andrew Lau wrote: > > So is vrms now up for a name change before the real RMS decides to sue > > us for misrepresenting him! = ) > > > > Nominations are now open. > debian-legalint I think this one, or a variation, has good prospects.. -- Jon Dowland http://jon.dowland.name/
Re: Programming first steps.
On Sun, Nov 16, 2003 at 08:45:51PM +0800, David Palmer wrote: > Hello, > > I thought that I might make a beginning at learning. > I've searched the web, found information that goes beyond the definition > of plethora, so I thought that I'd ask here. > > (1) What is the best language to start with? Learn more than one (breadth first search rather than depth first) :) Pick a procedural, pick an object-oriented, pick a functional, pick a 'glue' language. I'd recommend C, Perl, Java, Haskell. I would possibly recommend Python over Java if I had any experience with it. I think learning vi(m) is a good idea but grab emacs, kate and (insert someone else's recommendation here) and give them at least a cursory glance. Diversity is the key - as a user and a developer. -- Jon Dowland http://jon.dowland.name/
Re: Tabs v.s. spaces (was Re: Programming first steps.)
On Mon, Nov 17, 2003 at 02:19:02PM -0500, H. S. Teoh wrote: > For personal pet projects, I use 2 spaces per nesting level. Some people > think that's Pure Evil(tm), Most noteably perhaps, Linus Torvalds, although... >although I fully agree with you about wasting > screen real estate in 80 columns (yes, I am one of those freaks who insist > that all code must not have lines longer than 79 characters). ...he agrees with you on that point! Torvalds' position is that code that cannot be expressed using 8-spaces-per-indent and wrap at 79 characters needs to be rewritten. -- Jon Dowland http://jon.dowland.name/
Re: Debian communication and attitude [was: Re: Example of really nasty DD behavior]
On Sun, Nov 16, 2003 at 12:44:03PM +0100, Henning Makholm wrote: > No, but if you don't do it, you forfeit your right to whine about > duplicate work when it turns out that you're not the only one who has > been doing work without telling anybody about it. So, _both_ people involved should have ITPd, early. -- Jon Dowland http://jon.dowland.name/
Re: apt-rpm article -- the features we don't have
On Mon, Dec 01, 2003 at 11:17:26PM -0800, A.J. Rossini wrote: > > Andrew Pollock <[EMAIL PROTECTED]> writes: > > > On Mon, Dec 01, 2003 at 07:50:29PM -0800, A.J. Rossini wrote: > >> > >> Joey Hess <[EMAIL PROTECTED]> writes: > >> > >> > > >> > To install a package directly, with apt downloading any necessary > >> > dependencies: > >> > apt-get install rpmver-2.0-13498cl.i386.rpm > >> > >> couldn't this just refer to dpkg --install ? > > > > But that won't satisfy any dependencies that the package you're installing > > has. > > Got it -- a bit more than just parsing out... but suprisingly little > (other than someone's time, which is always worth a great deal...) This would be a useful feature indeed. (assembling this message was a nightmare, please read http://www.river.com/users/share/etiquette/#inline) -- Jon Dowland http://jon.dowland.name/
Re: apt-rpm article -- the features we don't have
On Mon, Dec 01, 2003 at 07:06:41PM -0500, Joey Hess wrote: > Similarly, to check the build depends of a source package file: > apt-get build-dep apt-listchanges-1.49-11104cl.src.rpm Should this be the job of apt-get? Fetching a list of build-depends is a similar job to that performed by apt-cache for other fields. I always associate apt-get with installing and removing packages. (now that I think about it, apt-get remove reads a bit like 'click on start to shut down your computer'). -- Jon Dowland http://jon.dowland.name/
Re: Backport of the integer overflow in the brk system call
On Tue, Dec 02, 2003 at 12:08:17PM +0100, Andreas Metzler wrote: > Afaik: 2.4.23 contains literally 100s of changes, one of these was a > small change to do_brk(), which looked like a normal non-critical > bugfix to everybody involved. Some time later Debian was hacked and > backtracing how the intruder got superuser privileges revealed that > that the do_brk() without the "small change" was guilty, it had been > no simple bug but a local privilege escalation issue. Thanks Andreas! My understanding is that the do_brk vulnerability allowed access to kernel address space. It seems a lot of work is needed to move from that freedoom to spawning a root shell. I'd be interested in seeing a worked example. -- Jon Dowland http://jon.dowland.name/
Re: Debian packages and freedesktop.org (Gnome, KDE, etc) menu entries
On Thu, Dec 04, 2003 at 03:53:54PM +0900, Miles Bader wrote: > Sebastien Bacher <[EMAIL PROTECTED]> writes: > > I'm not sure that's a good idea. I'm using Gnome and I'd like to keep a > > simple applications' menu, not having hundred entries like in my > > debian's menu. Having too many entries in a menu is an usability problem > > imho Does turning on menu hints help? > I think dropping the current `auto add' behavior of menus would be a > _serious_ mistake. Agreed. The debian menu system is imperfect, but has some good features. The .desktop system is not a direct competitor either, as I understand it. '.desktop' is also a fairly bad name for a menu convention imho :-) It has been bashed around a lot but I think the menu system needs to be discussed thoroughly, as everyone seems to have reserved opinions on how it should be developed. I would very much like to be involved in an all-encompassing discussion of how it could be improved. Does anyone else feel this is a good idea? -- Jon Dowland http://jon.dowland.name/
Re: apt-rpm article -- the features we don't have
On Wed, Dec 03, 2003 at 08:19:24AM +0100, Goswin von Brederlow wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: > > > ... apt-get build-dep somesourcepackage" ... > > apt-get build-deb ... Just to clarify, build-dep is the proposed action rather than build-deb? -- Jon Dowland http://jon.dowland.name/
Re: apt-rpm article -- the features we don't have
On Wed, Dec 03, 2003 at 06:10:27PM +1100, Hamish Moffatt wrote: > On Tue, Dec 02, 2003 at 02:10:56PM +0000, Jonathan Dowland wrote: > > Should this be the job of apt-get? Fetching a list of build-depends is a > > similar job to that performed by apt-cache for other fields. I always > > associate apt-get with installing and removing packages. > > Yes, and "apt-get build-dep somesourcepackage" does install the > necessary build-deps, so this fits right in. Ah yes, of course. I was thinking of an action which would return build dependencies, not install them. For the latter case apt-get would be the logical tool. -- Jon Dowland http://jon.dowland.name/
Re: improving downloader packages (was: Re: holes in secure apt)
On Thu, Jun 12, 2014 at 07:31:14PM +0200, Thijs Kinkhorst wrote: > I think a better way than to create such a policy would be to create a simple > framework that does in-package downloading "right" and that downloader > packages can depend on and call from their scripts (a bit like dbconfig- > common). An existing technical solution will probably be more quickly adopted > by the various packages than a set of requirements, and improvements need to > be made in only one place. This kind-of exists in "game-data-packager": except it isn't structured so that you call it from another package. Instead, the 3rd party stuff to be packaged are handled within gdp itself. I wonder whether it would be possible to extend gdp to provide such a framework, however I have a lot of reservations about the notion of running download code in postinst stages etc. at all. I once planned to rename gdp to just "data-packager", coinciding with the first non-game thing to be supported. I idly considered the flash plugin or Oracle's Java as such targets. But I never did it. -- 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/20140616123322.ga12...@bryant.redmars.org
Re: Bug#753704: Aw: Re: Bug#753704: ITP: amap -- Next-generation scanning tool for pentesters
On Mon, Jul 07, 2014 at 11:12:23PM -0700, Vincent Cheng wrote: > On Mon, Jul 7, 2014 at 9:48 AM, costamagnagianfra...@yahoo.it > wrote: > > > > Hi Steffen and all, > > > > today while talking with a backbox project administrator I discovered that > > popular tools such as openvas directly calls the amap binary. > > > > I never talked with them, but I don't think it is feasible to ask to every > > security tool provider to patch their code for the only debian benefit. > > > > I think I'm then changing again my opinion: the conflict field might be the > > only proper way to be sure such popular tools (not packaged in debian and > > some of them not even free) continue to work. > > > > Is this one a good reason for a conflict? > > Again, according to Policy 10.1, as well as precedent that was established by > the CTTE decision regarding the namespace collision between ax25-node vs. > nodejs, no, it isn't; your argument is no different from that of the nodejs > maintainers, arguing that /usr/bin/node should be taken over by nodejs simply > because it's already widely used by the nodejs community. > > If you feel strongly enough about this issue, I'd suggest filing a bug > against debian-policy, going through the process and gathering consensus to > change 10.1 (e.g. perhaps by weakening it to a "should" instead of a "must", > or by proposing a carefully-worded exception to existing policy). But just to be clear, the odds of changing policy are vanishingly small. Rename the binary in Debian, do whatever foo is necessary to provide a PATH that doesn't rename the binary that can be injected in the right place for callers/environments that won't accept a renamed binary, or give up on packaging it in Debian. -- Jonathan Dowland -- 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/20140708125908.gb30...@bryant.redmars.org
Re: let missing-debian-source-format lintian tag be a warning!
On Tue, Jul 15, 2014 at 10:43:05AM +0200, Raphael Hertzog wrote: > Can we have a reasonable discussion based on real arguments and not on > personal feelings? I haven't read any personal feelings yet, apart from personal preferences about how to handle patches. It *is* a shame that the patch-handling aspect of 3.0 (Quilt) is offputting enough to folks that some are avoiding 3.0 altogether and not benefitting from the other improvements. However the single-debian-patch workaround is a pretty good compromise, IMHO, and perhaps just needs wider awareness. -- Jonathan Dowland -- 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/20140715142628.ga9...@bryant.redmars.org
Re: How Debian should handle users requests?
On Sun, Jul 20, 2014 at 07:50:17AM +0800, Paul Wise wrote: > I think that would probably just add more noise to debian-devel. Maybe "general" bugs should go to debian-user instead? -- 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/20140720102928.ga28...@bryant.redmars.org
Re: How Debian should handle users requests?
On Mon, Jul 21, 2014 at 08:36:09AM +0800, Paul Wise wrote: > That would be change in meaning of the pseudo-package, it isn't > supposed to be for user support. Personally I don't think that we need > the general/base/cdrom/project pseudo-packages any more. At minimum we > should update reportbug to discourage their use. Or a pseudo-package which *is* meant for user support, to which bugs are re-assigned, and for which debian-user is the "maintainer". Making d-u (more) useful as well as solving this issue sounds quite attractive to me. (Not sure how things would actually get closed, mind you.) -- 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/20140721160217.ga3...@bryant.redmars.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Jul 27, 2014 at 08:05:22PM -0400, Reinhard Tartler wrote: > I think it would be best if ftp-master left the ffmpeg package in NEW > until an answer to this problem has been found. That would leave people who are eagerly awaiting ffmpeg(1) stranded in limbo whilst the tangential library issue is fought over. -- 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/20140728103951.ga23...@bryant.redmars.org
Re: Standardizing the layout of git packaging repositories
On Fri, Aug 15, 2014 at 04:16:01PM +0200, Raphael Hertzog wrote: > - encoding (due to git restrictions): > ":" -> "%" > "~" -> "_" I think I'd prefer to see something like X -> _Y where chr(Y) = X and hex(ord(X)) = Y, e.g. "_" -> "_5f" ":" -> "_3a" "~" -> "_7e" There is probably a more sensible choice of escape character than '_', something not commonly used in native git tag names, yet legal. -- 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/20140817161510.ga25...@bryant.redmars.org
Re: Standardizing the layout of git packaging repositories
On Sat, Aug 16, 2014 at 02:03:18PM +0200, Raphael Hertzog wrote: > The vast majority (all?) of git packaging repositories have the upstream > sources. > > I think this point is not really contentious. Others have demonstrated that this is not the case. However, I believe the majority of git packaging repositories do not break out the upstream source. I also believe that doing so is painful for new contributors: people seem to have varied reasons for doing it and that's fine, but they should be aware of the cost. I see no problem in the DEP standardising on having upstream and ./debian in the repository, those who don't want to follow it aren't mandated to, but having a lot more consistency of vcs-packaging for the majority of packages will make a huge difference for new contributors and I think that's something we should encourage. -- Jonathan Dowland -- 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/20140818061837.ga20...@bryant.redmars.org
Re: Standardizing the layout of git packaging repositories
On Mon, Aug 18, 2014 at 02:27:15PM +0200, Thorsten Glaser wrote: > I’d rather have something that sorts like Debian versions > in “git tag” output… If that proves too hard to achieve with a mapping scheme, it would be trivial to write a filter to implement it. It does sound useful. > Yikes! > > tags/foo_3a4b5c-6d You really have a tags/foo:4b5c-6d? Or assuming you mis-read my email, a tags/foo:K\-m? Can we please use realistic counter-examples? -- 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/20140818163537.ga32...@bryant.redmars.org
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
On Tue, Sep 02, 2014 at 01:45:30PM +0200, Adam Borowski wrote: > For any standardish font, taking any extra memory is a no-no. You might be > running in a chroot on a 256MB RAM phone, etc. > > On the other hand, for a 400MB game, not using -z9 is a pure waste of space. They're all arch: all though, right, so in practice no buildds are actually building these packages? -- 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/20140902130655.ga4...@bryant.redmars.org
Re: Possible abuse of dpkg-deb -z9 for xz compressed binary packages
On Wed, Sep 03, 2014 at 10:59:44AM +0200, Thorsten Glaser wrote: > Not on avr32, and it hurts sh4, m68k and others as well. I suppose we should always be sympathetic towards such architectures, but at the end of the day we should primarily concern ourselves with release architectures. -- 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/20140903194506.ga22...@bryant.redmars.org
Re: systemd, again (Re: Cinnamon environment now available in testing)
On Sat, Sep 06, 2014 at 02:33:04PM +0200, Adam Borowski wrote: > Ok, so let's quantify the view of sysadmins somehow. This is a complete waste of time and I expect better of you in particular. -- 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/20140908161425.ga24...@bryant.redmars.org
Re: ok to ship vaporware in Debian?
>From reading the bug it's not clear to me whether or not libjs-mediaelement does anything, but IMHO your tone towards the uploader seems unnecessarily bullish and confrontational. In particular [1] strikes me as sacrificing any moral high ground when it comes to BTS ping-pong. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=78;bug=760297 -- 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/20140908205221.ga...@bryant.redmars.org
Re: Trimming priority:standard
On Fri, Sep 12, 2014 at 03:44:46AM +0200, Adam Borowski wrote: > You want 'nc myserver 25', as 'telnet myserver 25' will misbehave on 0xff > bytes. A malicious server can do pretty surprising things to you, too. You're both wrong; you want swaks(1). -- 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/20140915133648.ga22...@bryant.redmars.org
Re: Trimming priority:standard
On Fri, Sep 12, 2014 at 06:27:38PM +0100, Simon McVittie wrote:
> On 12/09/14 18:19, Theodore Ts'o wrote:
> > One thought... there will probably be trademark concerns with "unix".[1]
> > So we might have to choose a name for the tasksel task to be someting
> > like "unix-like".
>
> Perhaps
>
> task-traditional -- Traditional Unix utilities
I quite like that. My main objection with task 'unix' is it'll be confusing for
users who are not really sure what it is, but think that it must be important.
My less important objection is I have a hobby source package 'unix' which is
the v7 UNIX sources (so far only ed/sed have been made to work on modern
systems; the work was all done by David Jones and not me). I will almost
certainly never upload this package, but I do occasionally daydream about
/usr/lib/unix/{sed,ed,cat} etc.
--
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/20140915134207.gb22...@bryant.redmars.org
Re: Trimming priority:standard
On Fri, Sep 12, 2014 at 03:49:11PM +0200, Thorsten Glaser wrote: > bc is the standard Unix calculator, normally a dc frontend, > and used in *a lot* of scripts. Is there any way of verifying or even reasonably estimating how common it is used? *Within* debian, sadly it's hard to ascertain via codesearch as 'bc' is too short, but /bc => http://codesearch.debian.net/search?q=%2Fbc I must admit I've never seen it used in 3rd party scripts in my entire career as a sysadmin. > And yes, bc is also the primary interactive calculator, > for things beyond what $((…)) can do. We've got python in priority:standard. -- 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/20140915135328.gc22...@bryant.redmars.org
Re: Trimming priority:standard
> On 17 Sep 2014, at 07:58, Ansgar Burchardt wrote: > > That's why *both* should be installed by default. Then everybody will be > happy. To keep the (bad) joke going, I was going to suggest gnu zile be made standard, but even *that* is pretty big. -- 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/9281c8a0-c119-4a9e-a2ca-0cb9bc31e...@debian.org
Re: Trimming priority:standard
> On 17 Sep 2014, at 08:24, envite wrote: > > Having one easy text editor in command line is necessary. Both nano or joe > will make that target. None of emacs nor vi does: they are not as easy. I really think *some* vi implementation should be in standard. It's true, those who don't know vi find it unusable, but sadly the reverse is also true. I'd be genuinely shocked (and somewhat hamstrung) to ever log into a Linux machine of any type and not find a vi. Looking at package sizes I'm surprised to see nvi is larger than gnu zile (karma for my previous bad joke). There's also a vi in busybox I believe, similar size. -- 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/9898e31e-34d6-48d8-bb21-e2003c2a8...@debian.org
Re: bash without importing shell functions from the environment
On Thu, Sep 25, 2014 at 04:29:05PM +0100, Ian Jackson wrote: > I have prepared bash packages which do not honour any shell functions > they find in the environment. IMO that is a crazy feature, which > ought to be disabled. (I'm running this on chiark now and nothing has > visibly broken yet.) Thank you very much for doing this. I would love to see Debian transition to having this facility disabled by default at some point in the future. > A codesearch [1] shows that this change will break very few things. Of course that won't help indicate which external scripts will be affected. To get something like this in the archive, we will probably need a runtime switch to re-enable the old behaviour, if your patches don't already (I haven't looked yet). > Arguably we (Debian) should apply this in sid (hence this bug report). > Doing it in security updates to stable releases is sadly too risky. > But people who want to take that risk themselves are welcome to > install my packages. I'm definitely going to try this in a few places to test to see how widespread the impact might be. -- 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/20140926130844.GA7563@debian
Re: binary data file and endianness and multiarch
> On 27 Sep 2014, at 10:36, Adam Borowski wrote: > > Except that the endianness war has been won by little-endian And yet, network byte order remains big. It's less important which endian they pick, but that they pick one and use it consistently across arches. -- 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/c44c80e0-6812-43e1-a584-3c0da7891...@debian.org
Re: bash without importing shell functions from the environment
On Tue, Sep 30, 2014 at 07:58:38PM +0200, Matthias Klose wrote: > so maybe as a non-native speaker I am unaware of some joke here, or are you > just > trolling about something fixed for jessie/unstable? I was curious to see what Ian was complaining about, and what has changed up to the jessie version. I can see that the rules file is a little bit simpler. I guess that's because you've moved to the 3.0 (quilt) package type? I couldn't find the changelog entry documenting when you did this. -- 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/20140930201939.GA8221@debian
Re: piece of mind (Re: Moderated posts?)
On Tue, Oct 14, 2014 at 11:11:35AM +0100, Ian Jackson wrote: > I think in future we should probably make a habit of posting something > to d-d-a when there is a GR proposal. Yep, liw made the same point on -project in response to a thread I started there on this subject. I still feel we don't adequately document where GRs should be announced. As things stand, we should probably amend [1], assuming there is no strenuous objection. I'll at least raise the bug. [1] https://www.debian.org/vote/howto_proposal -- 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/20141014124109.ga28...@chew.redmars.org
Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
There are a number of mechanisms for proposing and tracking distro-wide changes, such as release goals and DEPs in some cases. But this is not what the general bug is for. Please choose something and then kindly close this bug. -- 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/20141015192521.gb...@chew.redmars.org
Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
On Wed, Oct 15, 2014 at 09:44:43PM +0200, Christoph Anton Mitterer wrote: > Well a bug is at least something, where one has a central log of all > discussions... and where one can really keep track of... Only if people remember to copy it. And that's less likely to happen when you start getting down to the nitty-gritty of changes to actual packages. Those discussions are more likely to happen on more specific bugs. It's also a lousy way of keeping track of the current state of affairs. Just consider the recent mammoth tech-ctte bugs. It must have been a herculean effort for the tech-ctte to keep track of what had been considered and what had not. A wiki page would be a much better way of keeping a summary in place. Something like https://wiki.debian.org/ReproducibleBuilds or https://wiki.debian.org/DebianEdu/Status/Jessie for good examples. > The problem with release goals / DEP is, that there is a lot of talking > but in the end nothing might really happen. The DEP process, at least, has had some thought put into the design to address that issue. > Also, I think that supporting broken algorithms actually *is* a bug :) Well, it's a meta-bug, of sorts; really it isn't a bug itself. There are others, that could be theoretically filed and blocking information between this one and those filed in the BTS. Without that, how would you otherwise consider when this bug is "fixed"? You can't really leverage the excellent versioning features of the BTS with the general package. Another problem with the "general" package is, who is responsible? Are you prepared to take responsibility to close this bug yourself? If it isn't a release goal, there's no push to have it resolved in any particular time frame. It could languish forever. -- Jonathan Dowland -- 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/20141015203321.gb1...@chew.redmars.org
Re: Bug#765512: general: distrust old crypto algos and protocols perdefault
On Thu, Oct 16, 2014 at 05:42:23AM +0200, Christoph Anton Mitterer wrote: > On Wed, 2014-10-15 at 18:31 -0700, Russ Allbery wrote: > > It feels to me like you're spending lots of time telling other people > > they're wrong and telling other people what they should be spending time > > on, and then arguing with anyone who tells you that how you're going about > > this isn't effective. > Well isn't that somehow the point of discussion and defending one's > opinions? Don't you just do the same? There's no point having an argument unless you are prepared to have *your* opinion changed. I work for a University Computing Science department which has a research group dedicated to Security research. They have a fair amount of success and there are some very bright people in the group. My former boss, the Head of School, originally set up the security group. We discuss these issues from time to time. He told me that one of the biggest problems they have with new researchers is getting them to understand that security in the real world is a matter of compromise. A lot of researchers come in with an attitude quite like yours: absolutist. This is either insecure and must not be used in any circumstances ever, or it's secure. The problem is this simply doesn't work, for many reasons including the ones that Russ has done an excellent job of explaining. The clients of the research group, including some large companies and government departments with acronyms for names, know this. The good science that comes out recognises this. >From one of your other posts you make it quite clear that you appreciate the practical difficulties of trying to get any distro-wide change made in Debian: buy-in. If you want to see security in Debian improved; that's where your efforts need to go, towards seeking buy-in. Read and carefully consider the advice people have given you here regarding your approach, using things like release goals, gaining consensus, altering your argument style, etc., if you want any hope of achieving your ultimate goals. -- 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/20141016065249.gc10...@chew.redmars.org
Re: Built-Using, again…
On Thu, Oct 16, 2014 at 10:10:46AM +0200, Andreas Barth wrote: > You didn't ask a wider audience, you whined to one, and that on > something totally unrelated to the thing you really wanted. The mails to the @buildd addresses are of course private to those behind the list, so the peanut gallery on -devel can't see what tg wrote nor judge for ourselves whether it was whiny or not, but characterising it as such here is not helpful. TG's mail to -devel, at least, was polite, and I was sad to see passive aggressive responses from you and others. > > But it’s now resolved, thanks Philipp! > > Wrong again, I dist-upgraded the chroots and gave back the package. > But as before, facts are difficult. Likewise, you could have pointed this out without being quite so condecending. -- Jonathan Dowland -- 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/20141016082322.ga13...@chew.redmars.org
Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
Show me the patches.
Re: so long and thanks for all the fish
Sad news. I wish you all the best for your future endeavours. I hope to cross paths with you from time to time (maybe I should tidy up my half finished ikiwiki patches!) The coincidental timing of Colin leaving the tech-ctte did make me wonder how different things would be if we could have coerced you into joining. Great for Debian but perhaps not so much for you... -- Jonathan Dowland -- 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/20141109094140.ga29...@chew.redmars.org
Re: Please more fish
On Sat, Nov 08, 2014 at 08:20:29PM -0800, Russ Allbery wrote: > I thought Zlatan's message was beautiful, and it really touched me, and I > wanted to say that. It may have been better if I'd said that in private. No, such public appreciation messages are a pleasure to read. Please do not refrain in future. -- 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/20141109195523.ge29...@chew.redmars.org
Re: Bug#768329: grub-common: Please enable splash for jessie
On Thu, Nov 06, 2014 at 05:19:40PM +0100, Christian Hofstaedtler wrote: > Nothing in a default install currently Depends or Recommends > plymouth, so don't worry about getting a graphical splash screen or > anything. Anyway, if you were to install plymouth, the default > "theme" is *text*. In other words, plymouth installed but no 'splash' argument to the boot results in no change; adding 'splash' results in plymouth being activated albeit in text mode (so no modechange?) > Plymouth is a terminal multiplexer. Without it, if, f.e., there is > prompting for an encrypted disk passphrase, you'll end up with other > messages writing over the password prompt and so on. [1] With plymouth > installed you'll get a nice standalone prompt for the passphrase. > I imagine this being the same for systemd and upstart and any other > event-based inits. > http://web.dodds.net/~vorlon/wiki/blog/Plymouth_is_not_a_bootsplash/ > has some additional background. I'm reminded that the plymouth package short and long descriptions need adjusting to reflect this as they are presently quite misleading (but I'm as guilty as anyone else for not filing a wishlist bug for this yet, let alone supplying suggested text) > Why's there a new boot parameter? > > I don't know, but currently at least Ubuntu, Tanglu (both via > grub-common), and Fedora do it this way. > It's certainly nice to have the parameter so the recovery boot > option can skip plymouth (esp. if you were to enable a graphical > theme). I presume the option is interpreted by systemd or plymouth, rather than the kernel. (raises an interesting question, where is this handled, and is it handled differently for different init systems?) I see no reason why Debian couldn't default to the opposite (plymouth installed? plymouth runs - some 'nosplash' command line argument passed? plymouth doesn't run) if that was determined to be preferential. IMHO on-by-default is a good idea, especially if boot-time password prompts are likely useless without it (at least with systemd, but this is functionally a regression from wheezy). -- Jonathan Dowland -- 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/20141109200345.gf29...@chew.redmars.org
Re: A concerned user -- debian Guidelines
Dear Nathael, This is off-topic for -devel. Please consider debian-user or the offtopic list. On Mon, Nov 10, 2014 at 09:57:50AM +0100, Nathael Pajani wrote: > You certainly heard about "debianfork" (http://debianfork.org/) and from a > user point of view this is a tragedy. snip > When a (big ?) pool of users is not happy to the point of suggesting to fork > because of a decision taken (or about to be taken) by the project developers, > then (I think) that the Debian developers are not doing their job right. There's no way of knowing how big or not the set of people who are unhappy is, and there is no public list of people behind 'debianfork', which IMHO is complete hot-air. Debian welcomes forks. They're healthy and result in improvements to Debian. Just look at Ubuntu. Spreading free software to more people is entirely compatible with Debian's goals. The fact "debianfork" is presented - anonymously - as a sort-of threat says all you need to know about the motivations of the people behind it. Show me the code. > You'll notice that the fork has not been started yet, as (I think) many still > hope this can end the right way, with USERS taken into account. All of them. It's an idle threat, designed to help spread FUD and not an actual effort to create a forked operating system. > Other distributions may have chosen the easy single init way, but Debian is > not other distributions. And uniformity is not an option. Debian has decided to support multiple init systems. Do you not know this? Have you been misled by the FUD? That's exactly what we're working on! -- Jonathan Dowland -- 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/20141110093747.ga30...@chew.redmars.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 01:13:39AM +0100, Matthias Urlichs wrote: > Please discourage the use of pristine-tar. The format is fragile and can > suffer from bit rot. I am not personally interested in pristine-tar, but I don't think this is the right place to take a stance on its use. -- 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/20141112080255.ga22...@chew.redmars.org
Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On Wed, Nov 12, 2014 at 03:38:59PM +0800, Paul Wise wrote: > Personally I wouldn't use anything other than debian-only repos, at > least for those where I have a choice. I also actively avoid > contributing to packages that don't use such repos. And I'm the exact opposite. -- 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/20141112080511.gb22...@chew.redmars.org
Re: Being part of a community and behaving
On Thu, Nov 13, 2014 at 01:58:23PM +0100, Bálint Réczey wrote: > > acceptance for ironic, sarcastic humor. > I love irony and sarcasm, but I don't think planet.debian.org is the > right place for the mentioned content. I'm afraid you misunderstand the purpose of planet Debian. If you want an aggregator with more rules about content, please set one up. -- 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/20141113200927.ga3...@chew.redmars.org
Re: parsable copyright format 1.0 (jessie release goals)
On Sun, May 12, 2013 at 07:52:25PM +0800, Thomas Goirand wrote: > Being able to write tools to extract the license of any given package. Well, extract what the maintainer thought the license was when they wrote debian/copyright. What correlation that has with reality is an open question. -- 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/20130514111930.GA3761@debian
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 06:26:40PM +, Thorsten Glaser wrote: > Oh, sorry, I forgot, you work for Canonical (which totally explains some > of your writings in the other eMail too, which I’m not going to comment > on). Of course, for *buntu people it’s not about choice. I think you are totally out of order, here. You could equally be criticised of having your judgement clouded by your involvement with MirOS. That would be just as absurd. Steve has been contributing to Debian much longer than you, or I have, or Ubuntu has existed. -- 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/20130515091755.GC22791@debian
Re: Bug#709237: ITP: meta-suckless-tools -- meta-package installs simple commands for minimalistic window managers
On Wed, May 22, 2013 at 07:17:34AM +0400, Dmitry Papchenkoff wrote: > Maybe there should not be a separate package for each tool, but at > least st and dmenu should be packaged separately. Why? > Moreover, there IS a package named stterm in unstable which ships st > separately (I've found it then published ITP for my version of st). It > lacks Breaks/Conflicts with suckless-tools 38, but will overwrite it > files. It predates suckless-tools in the archive. Therefore, suckless-tools should have renamed its st binary. Conflicts is not appropriate here. -- 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/20130522133146.GA20887@debian
Re: Debian systemd survey
On Fri, May 24, 2013 at 03:22:12AM +0200, Matthias Klumpp wrote: > 2013/5/24 brian m. carlson : Gentlemen, This is well-worn territory on -devel. Please bear in mind the OP's wish not to open this can of worms again. -- 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/20130524080744.GA20095@debian
Re: Debian systemd survey
On Fri, May 24, 2013 at 04:07:06AM +0800, Thomas Goirand wrote: > On 05/23/2013 03:55 PM, John Paul Adrian Glaubitz wrote: > > How on earth does that contradict with the fact that 40%, i.e. > > the minority of all contributions are done by the original > > author. 40% still means that 60% of the code comes from other > > people and those are 145 contributors according to ohloh [1]. > > It's not this way. Last time I checked, there was another upstream doing > about 30% of the work. You keep moving the goal posts! I don't see why this even matters. I guess you don't think systemd's development community is healthy, whereas John does. I doubt either of you is going to convince the other, so why not respect the OP and leave it there? -- 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/20130524081525.GB20095@debian
Re: Debian systemd survey
If On Thu, May 23, 2013 at 12:50:00PM -0700, Steve Langasek wrote: > A large number of contributors to an *init system* is not > something that should be a goal in and of itself Then > Furthermore, the statistics for systemd are themselves a distortion isn't really relevant here, let's please not open a can of worms counting contributors and contributions every which way. -- 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/20130524081825.GC20095@debian
Re: default MTA
On Tue, May 28, 2013 at 03:02:22AM +0200, Marco d'Itri wrote: > Now that we are done with systemd for the time being, can we have the > flame war about replacing Exim with Postfix as the default MTA? > > Are there any objections other than "but I like it this way!"? As things stand, for the vast majority of users the actual MTA that is deployed is irrelevant, as their only interface to it is via the debconf stuff which has been engineered on top. (one might ask: why bother switching?) Personally I've settled on using exim as an MTA everywhere, as a consequence of it being the default MTA, however I have no objection with it being replaced by default. (In fact I find the debconf engineering hinders rather than helps as soon as you want to do anything complicated. Perhaps the need for some much structure would go if it were not the default MTA.) There is an impedence mismatch between packages which consider an MTA and the sendmail interface to be standard and those desktop components that make no such assumption. If we are going to keep ensuring a local MTA/sendmail interface going forward, I'd love to see it better integrated into the desktop stack. (In fact I still battle debconf-stuff-on-top-of-exim from time to time, when I have a system where I don't want any local mail.) I'd be interested in reading the arguments for switching: can you point my at some relevant historic threads? Thanks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130528093430.GA16477@debian
Re: Bug#706078: ITP: base91 -- base91 encoder/decoder
On Tue, May 28, 2013 at 09:42:20AM +0200, Franck Routier (perso) wrote: > this description is from the upstream readme. I have submited a bug > report to ask for a correction. > Should I patch the readme inbetween ? If you mean the package description, then yes: it should be tailored to Debian. When one can reuse upstream text in a package description, great, but if it isn't correct it should be fixed. If you mean patch an upstream documentation file shipped in the Debian package, that's less important (IMHO), and could wait for an upstream correction. -- 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/20130528093633.GB16477@debian
Re: optimizing PNGs
Hi Adam, On Sun, May 26, 2013 at 05:56:06PM +0200, Adam Borowski wrote: > A while ago, someone raised the possibility of recompressing PNG files. From my brief experience of working on games-thumbnails, I can appreciate that the space savings may well be worth it at scale, but performing compression/optimisation at package build stage is a major PITA. For lossless-compression, there's no reason for the compressed PNGs to not be integrated upstream (esp. in the case of local packages like games-thumbnails). > This massive number of files seems to be concentrated mostly in a limited > number of packages: What isn't clear here is whether these packages full of PNGs are already efficiently compressed or not. > So here are the results: How did you decide on which packages to sample from the above list? > fonts-mathjax-extra 4 94.6% 90.0% This (at least) didn't appear in the above list. I think an ideal solution would be a central/separate PNG recompression service that could alert maintainers if their PNGs were not optimal (bug perhaps? "Dear maintainer, foo.png in your package could be more optimal! Perhaps replace it with pngcrush.debian.net/v1/srcpackage/path/foo.png"?) rather than maintainers/buildds paying the compression cost. If compressed PNGs could be annotated with some metadata indicating that they were recompressed (or checked for recompression), then that might help to avoid costly recompression attempts. (foo.png is marked up that pngcrush.debian.net compressed it with version 1 of it's preferred compression solution; bar.png with version 2¸ current is version 3, recompress both… or perhaps pngcrush.debian.net could maintain checksums for files it has already checked.) -- 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/20130528130106.GB20013@debian
Re: optimizing PNGs
On 28 May 2013, at 14:04, Paul Tagliamonte wrote: > Some plugins for photoshop etc store data in the fields that get removed > by pngcrush and friends. In a sense, doing this is removing source data. This is a bug that should be fixed in the optimiser(s). However, it could easily be worked around by a service such as the one I outlined. > I've been debating writing dh_pngcrush / dh_jpegoptim. I think it's a > good idea. Just don't expect graphic designers to want the result. For the reasons already outlined, I for one wouldn't use it and would object to it being part of default debhelper or dh rules. -- 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/888155df-e06e-47f7-809c-fe51508a7...@debian.org
Re: default MTA
Hi Simon, On Tue, May 28, 2013 at 01:05:24PM +0100, Simon McVittie wrote: > The participants in this thread are debian-devel subscribers: the sort > of people who know that Debian is a Unix system, know what a Unix system > is, and have some idea of what a "btrfs scrub cron job", or indeed an > MTA, means. That's a pretty limiting audience for an operating system. > The Universal Operating System should also be usable by people who don't > meet those criteria, and I think Joss is right to speak up on their behalf. I think the problem is that Aunt Tilly will stumble across packages which expect a working sendmail whether or not they are ready for them: they'll read advice suggesting they should have smartd/smartmontools running; or they'll install some other semi-random Debian package after performing a search for a tool to solve a specific task, which supposes that mail works. We were all Aunt Tillys, once, and I certainly had this experience (although in my day everyone faced the exim3 configuration stuff on a fresh install. Not that I'm advocating that for a minute.) Such novices may well have no idea what cron or at are, but once they begin reading around to try and solve problems like scheduling things, they'll soon stumble across them. To address this problem, I think we have to either adjust all packages which expect a working sendmail to use some other universal local messaging system or better configure the system (including the desktop) to handle local mail, as Adam suggests. I don't think the former solution is viable, not least because there is no alternative, universal local messaging system to switch to. -- 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/20130528202633.GA30037@debian
Re: systemd .service file conversion
On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote: > Do you have any reason at all to believe that these were problems with > systemd, rather than problems in Debian configuration or mostly > independent bugs in other software that happened to trigger under > systemd? Whether or not systemd is responsible is not important if we are considering systemd as a default init: even if it is not responsible, if it exposes important bugs, those bugs need to be addressed before we could make a switch. What we need to make sure works is "systemd in Debian", that is, integration is where all the work is going to be. -- 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/20130530141451.GA2864@debian
Re: question about build a package
Hi Pol, Your question is more on-topic for the debian-mentors list. You might get more help there. Thanks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130603161422.GB20767@debian
Re: default MTA
On Thu, May 30, 2013 at 06:38:52PM +0200, Marc Haber wrote: > On Thu, 30 May 2013 16:53:56 +0200, m...@linux.it (Marco d'Itri) wrote: > >I think that ease of configurability is a major plus for Postfix when > >compared to Exim, since a common configurations is just a few lines long. > > How many lines does an average update-exim4.conf.conf have? You're right, in that the "interface" that a user has to exim-on-debian is update-exim4.conf.conf, rather than exim4's configuration directly; however, length aside, I don't see this as a strength, but a serious source of confusion. -- 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/20130606130738.GA22156@debian
Re: default MTA
On Thu, Jun 06, 2013 at 11:36:21PM +0800, Thomas Goirand wrote: > Well, in that case, it failed to be as simple to configure as qmail. Is ease of configuration an important criteria for default MTA? More important than sensible-default? -- 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/20130607084341.GB6619@debian
Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2
We'll need binaries for sdl 1 and 2 coexisting from two different source packages I believe. -- 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/0d0aca7b-918f-4ba1-80e1-f1f54c8df...@debian.org
Re: Bug severity and private data disclosure
It's amazing how much simpler Debian life becomes if one simply ignores bug severities entirely. Of course harder to do nearer to release, but we live in a time of relative luxury right now… -- 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/20130610140505.GB30122@debian
Re: Bug#711570: ITP: libsdl2-mixer -- Mixer library for SDL2
At some point in the recent past the SDL team was effectively dead and the games team took over maintenance. ISTR sponsoring at least one upload of an SDL component during that time. However, it's possible that the SDL time was revived since. -- 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/20130611162945.GA10618@debian
Re: Bug severity and private data disclosure
On Mon, Jun 10, 2013 at 08:10:22PM +0600, Andrey Rahmatullin wrote: > Life for the maintainer or for the user? Well, the severity of a bug, from a user POV, makes no guarantee on how serious the maintainer takes it, nor whether they will actually fix it. Admittely some users get comfort from being able to set a priority, in much the same way that some maintainers do. It still takes separate effort to turn severity into "dealt with promptly" or "considered important" or "I'll fix this one". -- 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/20130611163540.GA10760@debian
Re: default MTA
On Fri, Jun 07, 2013 at 12:45:07PM +0200, Marc Haber wrote: > Sendmail has just one more layer of indirection by virtue of the m4 > macros. Postfix has most of its behavior hard coded in the C sources, > while exim's behavior can be controlled by run-time configuration if > an advanced user wants to do things that Debian's abstraction layer > was not designed to handle. There are a class of users between beginner and exim expert for which the current state of affairs is not optimal. I don't know how big that class is but I've been in it for ten years. -- 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/20130611163701.GB10760@debian
Re: systemd .service file conversion
On Sun, Jun 02, 2013 at 11:10:38AM +0200, Tollef Fog Heen wrote: > Since you repeat this claim: over the last year and a bit, systemd has > seen 21 releases. I agree this is quite a lot, but it's hardly twice a > week. The number of Linux releases over the samer period is only about half that, which I think is quite close. -- 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/20130611164022.GC10760@debian
Re: default MTA
On Wed, Jun 12, 2013 at 08:00:17AM +0200, Wouter Verhelst wrote: > To this exim expert, configuring exim is done as follows: > > zcat /usr/share/doc/exim4/examples/example.conf.gz > /etc/exim4/exim4.conf Absolutely. At some point in the last few years I was recommended this course of action by a friend in the Debian community and it has greatly improved my experiences. I got the impression that this is quite commonly done. -- 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/20130612123828.GA24063@debian
Re: default MTA
On Tue, Jun 11, 2013 at 11:05:24PM +0200, Bernhard R. Link wrote: > The only class of users I can imagine the current situation not optional > is someone being used to postfix[1]. Well, that's not me… > When I remember learning exim I found it quite nice that the config is quite > self-explaining what it is actually doing. The exim config — once I started to actually use it — is indeed, very comfortable to understand and manipulate, in my experience to. The point I'm making is the current arrangement gets in the way of doing that. -- 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/20130612123928.GB24063@debian
Re: default MTA
On Wed, Jun 12, 2013 at 08:08:17AM +0200, Daniel Pocock wrote: > OpenPGP and S/MIME don't guarantee anonymity as they don't (and can't > really) encrypt the headers/envelope Erm, they also identify the recipients, as it's the recipients key to which the messages are encrypted. (and typically the sender is listed as a recipient for convenience). > That is the type of `metadata' that allows a hostile party to start > building a social graph of who knows who. Even if they can't see the > contents of the communications, those social graphs are undesirable and > an ideal solution would prevent that. Indeed, there are court cases where this has been key. -- 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/20130612124123.GC24063@debian
Re: default MTA
On Wed, Jun 12, 2013 at 09:41:27PM +0200, Daniel Pocock wrote: > DFSG #4: Our priorities are our users and free software > > A court prosecuting/persecuting one of our users is not in scope I'm now struggling to understand which side of the argument you are arguing. -- 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/20130613105956.GB3956@debian
Re: RFH: two base wheezy bugs
On Sun, Jun 16, 2013 at 11:22:50AM +0200, Daniel Pocock wrote: > Being able to systematically link bugs to hardware would be useful, then > other owners of the same hardware would (a) be able to check for outstanding > bugs before upgrading (b) try to reproduce and confirm bugs And if one uses more than one computer, then it's easy as a submitter to forget on which machine you experienced the bug, later on down the line. I did try to address this once using a usertags scheme as part of work on 'debgtd' which I've since abandoned (or at least parked for a long time.) -- 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/20130617160805.GC28337@debian
Re: Anybody using quilt?
On Mon, Aug 26, 2013 at 05:59:41PM +0400, Игорь Пашев wrote: > https://wiki.debian.org/Projects/DebSrc3.0 > > Anything other looks bad :-) I think guilt attempts to address something that 3.0 leaves unresolved. -- 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/20130918134718.GB32614@debian
Re: packaging data that can't be distributed as part of a Debian package
On Thu, Sep 19, 2013 at 08:10:07PM -0300, Henrique de Moraes Holschuh wrote: > On Fri, 20 Sep 2013, Faheem Mitha wrote: > > So, I suppose anyone using the software needs to download it. I'll > > provide a script to download the data, but if I want to build a > > Debian package containing that data, how should I do it? > > Maybe studying other download-and-package packages, like "java-package", can > help. In your case, apparently you can automate the "get the data file" > part, which java-package is forbidden to do. I'd also recommend java-package, which when last I looked (prior to the opening up and subsequent closing of the Java licenses, though, caveat) was well put together. It was an inspiration for "game-data-packager" which might also be worth a look (disclaimer: I wrote a lot of it) -- 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/20130920134515.GA17441@debian
Re: packaging Postgres binary dump files
On Fri, Sep 20, 2013 at 12:20:38PM +0200, Paul Wise wrote: > It is also impossible to patch the binary format unlike SQL. Interesting. For the first time, I've realised there can be a clash between "preferred form for modification" and "preferred form for use". -- 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/20130920134739.GB17441@debian
Re: packaging Postgres binary dump files
Please don't CC me, I'm subscribed to the list. -- 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/e3a10ec6-e8d6-4c82-8c0e-523f2931a...@debian.org
Re: packaging Postgres binary dump files
> On 20 Sep 2013, at 14:49, Paul Tagliamonte wrote: > > I mean, not really, right? I wouldn't write it if I didn't think so. > > If I want to use a .so, I want the ELF, but I want to modify it in C The classic case we all know well which doesn't map to this situation. > This just means we ship the prefered form for use (this binary kruft) > but ship the preferred form for modification in the source When the preferred form for modification can be trivially generated from that of use, as in this case; paired with the difficulty of going the other way, what is gained? Larger source packages, and either the risk of the two versions going out of sync, or a build dependency on an available Postgres server. -- 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/a33d1abb-02f4-4693-b4b4-a5a2b0042...@debian.org
Re: packaging Postgres binary dump files
Please don't CC me, I'm subscribed to the list. -- 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/108274b5-05b0-4a9b-8ee4-54bd1b353...@debian.org
Re: Replacing unrar-free with unar wrapper
On Mon, Sep 23, 2013 at 04:30:59PM +0200, Dominik George wrote: > My proposal is to remove unrar-free from Debian, for the reasons > mentioned above, and add a patch to src:unar that include a wrapper > script that provides a command-line wrapper compatible to both > unrar-free and unrar-nonfree, so unar can become a drop-in replacement > for both. This all sounds like a great idea, but I would suggest that rather than attempt to be command-line compatible with the existing tool, you clearly define a set of command line arguments and their corresponding semantics that you *do* support, ensuring that it is an accurate and correct subset of the behaviour of the original tool, and implement that. Ensure this covers the behaviour that is relied upon by the things that you are aware of already (e.g. calibre). Otherwise 90% of your effort will be on re-implementing esoteric or awkward features or behaviours that are not practically required. -- 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/20130925133252.GA5412@debian
Re: qmake and "make dist"
On Wed, Sep 25, 2013 at 07:06:04PM +, Sune Vuorela wrote: > For all my qmake and cmake based projects, neither that has a make dist, > I've asked my VCS for a tarball of the tag and blessed that one as 'the > release'. +1 Anecdotally, one of my upstreams has a broken tarball which is a git export on a windows machine, with +x everywhere and CRLF line-endings, which isn't an issue if you're treating the VCS as your "orig". -- 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/20130925211919.GA14727@debian
Re: pdksh transitional package going away...
On Thu, Sep 26, 2013 at 08:41:15AM +, Thorsten Glaser wrote: > In Debian, there are only two packages depending, recommending, > suggesting or build-depending on pdksh right now: … >graphviz (U) >shunit2 These surprised me, so I took a peek. In shunit2's case, ksh is optionally used as part of the test suite. Removing the dependency did not cause FTBFS. In graphviz's case, it seems there's three implementations of /usr/bin/dotty and lneato in the source; a sh, a ksh and a bash. None are run (afaics) in the build phase and the sh ones are installed in the binary. (graphviz seems to FTBFS in a clean pbuilder sid chroot atm, as as aside) > I would like to ask the aforementioned maintainers to transition > to depending/build-depending on mksh instead It seems simply dropping pdksh as a build-dependency is sufficient. -- 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/20130926094756.GA21716@debian
Re: Bug#724980: ITP: trove -- Database as a Service for OpenStack
On Tue, Oct 01, 2013 at 01:31:20AM +0800, Thomas Goirand wrote: > Here's my current long description: A few suggestions, take them or leave them ☺ > Trove is Database as a Service for Openstack. It's designed to run I'd quote Database as a Service, otherwise the first sentence doesn't scan: > Trove is "Database as a Service for" Openstack. The second sentence could be abbreviated a bit, from > It's designed to run entirely on OpenStack, with the goal of allowing > users to quickly and easily utilize the features of a relational > database without the burden of handling complex administrative tasks. To > It's designed to allow users to quickly and easily utilize the > features of a relational database without the burden of handling > complex administrative tasks. The following sentence describes what the tool/package will do in the future, rather than the present: > Initially, the service will focus on providing resource … I'd remove the second reference to "complex administrative tasks", like so, from > resource isolation at high performance while automating complex > administrative tasks including deployment, configuration, patching, > backups, restores, and monitoring. to > resource isolation at high performance while automating deployment, > configuration, patching, backups, restores, and monitoring. The rest reads OK to me but I think it would be nice if it was a bit more concise (whilst still describing key terms that someone not immersed in the area will understand. Quite a challenge.) -- Jonathan Dowland -- 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/2013093019.GA16565@debian
Re: Bug#724980: ITP: trove -- Database as a Service for OpenStack
On Tue, Oct 01, 2013 at 01:31:20AM +0800, Thomas Goirand wrote: > P.S: Even if I'm spending the most of my days on packaging OpenStack for > Debian, it's still too big for me alone, and I would accept some help... May I make a suggestion? Instead of filing ITPs for every Openstack component, file RFPs. When you file an ITP you send a signal that you are working on it, which will dissuade others from interfering. You currently have 36 open ITPs. -- 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/20131001131139.GC23743@debian
