Re: Naming a 32-bit/64-bit specific Java package
On Tue, 28 Nov 2006, Goswin von Brederlow wrote: libswt-gtk-3.2-java32 libswt-gtk-3.2-java64 libswt-gtk-3.2-java Any other suggestions, or completely different approaches? This seems like a really bad solution. The package is architecture independent except for the register/address size. How come it depends on this and is not architecture-dependent in another way? this seems really strange. If it's all bytecode there should be no dependency, and if there are native libraries it surely needs to be arch-dependent for other things. So i386, m68k, ppc, mips all can use the 32bit version. S390x, amd64, ppc64, mips64 can use the 64bit version. I think having two arch:all packages is better than having 12 arch:any packages where they fall onto two sets of identical apckages. I'd actually go for 12 arch:any packages myself, it's an implementation detail the users don't need to see. Alternatively, is it possible to detect at runtime and load different things on different architectures? Is it possible to upload two different versions of the any package to the different architectures? So that you get the -64 version on 64bit archs and the -32 version on 32 bit archs? It's definitely possible to have different versions in the archive for different architectures. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to cope with patches sanely (Was: State of the project - input needed)
On Sat Jan 26 14:33, Colin Watson wrote: > One major reason many people object to yada is that it's very easy to > think you've fixed something but then discover that the packaging system > in use reverts or otherwise breaks your change, because the files you're > expected to edit are different from other Debian packages and the > differences are not obvious to those unfamiliar with the packaging > system. So, I would go a little further than my understanding of your > comment above and say that, given a reasonable level of general > knowledge about Debian packaging (which might include standard tools not > yet written) and the basic ability to fix a bug in the upstream source, > it should be straightforward to apply that fix to the Debian package and > produce a valid uploadable result. That is, even if a reasonable number > of Debian developers can figure it out, the system should also be > accessible to people with the relevant programming skills with basic > knowledge of Debian packaging. I agree with this, but I don't think this should include using a VCS. As a counter-point to these suggestions here is what I would prefer. Note that I do regularly use DVCSs, and even store my Debian packaging in them, but I'd rather not expose that in the archive. I think we should standardise on some patch system, whether it be quilt or wig&pen or whatever, and people can write tools to take from their VCS of choice and produce a patches dir or take a patch and merge it back to their VCS. In fact, I believe git already has tools to do this. There should be debian/rules targets documented in policy for doing patch/unpatch and a simple method of adding a new patch. Ideally it should be as simple as throwing the output of diff -u around (which rules out dpatch). This means that those who want to use a DVCS can, and they just run git-export-dsc (or whatever) to create a source package with patches. When someone makes an NMU they will have posted a patch to the BTS which can be git-import-quilt (or whatever) into the repo. Those of us who just want to deal with patches dirs can do that too. In either case it should be very simple for another maintainer to patch the software and make a random upload. All you really need to be able to use is diff and the standard Debian packaging tools. dpkg-source could even have an option to test for patch: and apply the patches when it unpacks (I assume the wig&pen format will do essentially that) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to cope with patches sanely
On Thu Jan 31 13:36, Pierre Habouzit wrote: > I only need one tool, $SCM. Which is great, for those people who want that workflow. I definitely think we should come up with improvements to our packaging system which makes this easier. However. Not everyone wants to work like this, and this is also fine. By all means extol the virtues of it, people have done similar things on Planet and other people have said 'wow, that is better, I'll start using it'. But, Debian is sufficiently large and diverse that this workflow will not suit everyone. Certainly we don't want a situation where it is hard for one person to NMU another's packages without learning significant amounts of new tools (and this works both ways, having seen some descriptions of VCS-based packaging in this discussion I would steer away from those as much as I would from CDBS, which I also don't understand. In both cases there are people who say they can't live without it). But, I think it is possible to come up with a solution which fits both ways of working, doesn't add work for those packages which _don't_ have upstream patches and is easily NMU-able by everything. Remember, learning a couple of commands like patch-edit is easier than learning the semantics of merges and branches in a specific VCS. If this all ends up being implemented with .git.gz under the hood, I don't mind, as long I'm still using the same tools, and not having to call any git commands myself. Implementation details are essentially irrelevant. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to cope with patches sanely (Was: State of the project -
On Sun Feb 03 10:38, Pierre Habouzit wrote: > You agree on the fact that a Debian source package isn't (or shouldn't > for big enough packages) be the preferred form of modification. Then > it's that it's an exchange format. As an exchange format quilt is > brilliant, because it holds *EVERYTHING* a SCM need to figure out how to > rebuild meregeable and rebaseable patches from it. So why bother with > anything else ? > > An exchange format *Must* be simple. That's the very reason why Debian > uses rfc822-style flat files everywhere, and that's one of our best > strength: > (1) this format is ubiquitous in Debian ; > (2) it's really easy to parse (in the Debian flavour that doesn't need > the stupid quoted-printeable escapings and so on at least) ; > (3) it's human readable ; > (4) implementing parsers and generators take usually less than a > hundred lines in a high level enough language. > > .git.tar.gz fails in those 4 points. > > What I ask you is just to be consistent. Either we _will_ modify > source packages, either we won't. If we will, adding features to it is a > good idea, if we won't, let's just focus on how to let it be expressive > enough to encode in it all what we use as new features upstream from it. > And as a matter of a fact, quilt is enough for that. Full ACK Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to cope with patches sanely
On Tue Feb 05 00:51, Manoj Srivastava wrote: > > If we can't figure out a good and clean way to keep a large stack of > > long-lived patches in the vcs then I firmly believe we should > > standardize on quilt. > > I think I have indeed solved the issue of long standing feature > sets using feature branches, integration branches, and sloppy branches > while upgrading, and would not want to be forced to regress to a patch > system. > I don't think anyone is talking about forcing DVCS users to regress to a patch system, merely to change the interchange format; which all DVCS-based maintenance methods can easily export to/import from. The only reason which you would have to interact with it would be a more standard interface for NMUs, which can only be a good thing. I am against patch system users being forced to changed to a DVCS system, however, which _has_ been suggested. (It may be technically superior, but let me change when I'm ready by demonstrating the virtues and providing tutorials, don't force me to use it because it's the new source format) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to cope with patches sanely
On Tue Feb 05 22:43, Ben Finney wrote: > Matthew Johnson <[EMAIL PROTECTED]> writes: > > > I am against patch system users being forced to changed to a DVCS > > system, however, which _has_ been suggested. > > I've not seen that suggested in this thread. Can you give a reference, > please? > > What I've seen, that might be confused with the above, is: > > * arguments against patch systems on the basis of forcing others to > use those specific tools; followed by requests; > > * arguments for DVCS workflows on the basis that they provide the > advantages of tracking changes without forcing others to know the > specific tool used; Also: * The package format should be standardised such that the same workflow works for everyone. This implies to me that those who dislike patch systems and like DVCS workflows wish to standardise on the latter. I don't see how someone who wants to deal with patches can do that, whereas I can see how DVCS users can continue their workflow, but still have a patch system in the source format. (I would go through and get references, but it's a long thread, and I should be working. Sorry) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to cope with patches sanely
On Tue Feb 05 14:16, Lars Wirzenius wrote: > On ti, 2008-02-05 at 12:07 +0000, Matthew Johnson wrote: > > Also: * The package format should be standardised such that the same > > workflow works for everyone. > > If that's a reference to my first post to this discussion, it's not > accurate. I don't care about standardizing package formats, but I do > want to have one, simple sequence of operations to work on all packages. > Specifically I want "dpkg-source -x" to unpack a source package so that > it is ready for modification, and "dpkg-source -b" to build a new source > package after it's been edited. Patch systems can and should conform to > that, since it's important for those doing archive-wide QA. I agree with that, however the discussion following that had lots of people (at least to me) saying that this set of operations should be a DVCS workflow. If I've misinterpreted that then I'm sorry to whoever I've inadvertently maligned (-: Standardising NMU/QA workflow is good. I just don't think it should involve invoking any sort of VCS and knowing how the merging works. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to cope with patches sanely
On Tue Feb 05 23:34, Charles Plessy wrote: > Case 1: It is because all the changes were in the diff.gz. > > Case 2: It is because a clean way of applying the contents of > debian/patches has been developped and used. > > In that case, unless "dpkg-source -b" has been similarly engineered to > turn the new changes into a new patch, things will fail when > "debian/rules clean" calls the unpatch rule and the changes overlap an > existing patch. > > Case 3: It is because the sources have been packed patched. > > In that case, "dpkg-source -b" is expected to work. Don't forget: Case 4: Some wig&pen or patches.tar.gz source format which can apply the patches on unpack (maybe this is Case 2.5). It solves the "don't trust debian/rules" problem. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to cope with patches sanely --> Debian New Maintainers'
On Wed Feb 06 12:09, Patrick Schoenfeld wrote: > Hi Pierre, > > On Tue, Feb 05, 2008 at 09:17:12PM +0100, Pierre Habouzit wrote: > > Again, the discussion isn't (for me) about a tool, but an exchange > > format. We are discussing having patches served in a quilt series, and > > okay, this approach is similar but different. So you want a quilt > series, but not quilt. This means every other utility must be able to > generate this and must support every future quilt has, which itself may > not have. So, effectively you don't actively force them to use sth. but > passiveley you do. The difference is small however. I'd have said that it would be more sensible to define a reasonable subset of quilt features. A set of patches with comments at the top and a series file can be manipulated by many tools, isn't really quilt-specific. Allowing obscure quilt-only features wasn't what I'd understood from the discussion. Anyway, given that many VCSen seem to be gaining quilt-compatible interfaces, it doesn't really seem like forcing people to use quilt. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: How to cope with patches sanely
On Thu Feb 07 22:42, Ben Finney wrote: > In the scenario Manoj presents above, the modifications applied to > upstream are easily available all in one place: the foo.diff.gz. But all as one patch, not as your nice separated list of commits and/or branches. > Whereas with a patch bundle system, the security team needs to know > *every* patch bundle system in use and how to use it, just to have a > chance of operating on arbitrary Debian source packages. That's not what is being suggested (although it is the current state). If there is one standard patch _format_ then they need only learn one set of commands (which may be as simple as diff and patch, or may be quilt). This patch format can then be created from DVCSen if you like that, quilt if you like that or diff/patch if you like that. It still has separate, commented patches, but doesn't require the security team to know '*every* patch bundle system' or to know how to deal with a DVCS. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#466694: ITP: trilead-ssh2 -- Java SSH libarary
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: trilead-ssh2 Binary package(s): libtrilead-ssh2-java Version: 211-1 Licence: BSD Author: Trilead AG Homepage: //www.trilead.com/Products/Trilead-SSH-2-Java/ Description: Java SSH libarary Trilead SSH for Java is a freely available open-source library which implements the SSH-2 protocol in pure Java (tested on J2SE 1.4.2 and 5.0). It allows one to connect to SSH servers from within Java programs. It supports SSH sessions (remote command execution and shell access), local and remote port forwarding, local stream forwarding, X11 forwarding, SCP and SFTP. There are no dependencies on any JCE provider, as all crypto functionality is included. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-buildpackage now reorganizing debian/control Depends
On Sat Feb 23 12:02, Kumar Appaiah wrote: > So, I want to build against the reference lapack and blas, and then, > if the user chooses, then I want the alternatives system to enable the > use of atlas. Now, the new dpkg-source reordering installs atlas as > well during build, which causes the "smart" build systems of these > packages to detedct and link against it, which is NOT what I want. Which is something you should probably do anyway to satisfy the 'builds the same in a dirty build environment' goal. Although I do agree that fetching extra build-deps is bad. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#469397: ITP: xbmc -- XBox Media Center Linux Port
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: xbmc Binary package(s): xbmc Version: 0.0~02032008 Licence: GPLv2 Author: Various Homepage: http://xbmc.org/ Description: XBox Media Center Linux Port A media center originally written for the XBox and then ported to linux. I intend to upload this to experimental to start with. The linux port of it is just that. It's also designed for installation to a single directory, not installation on a unix system. I'll need to hack round that first. The version number is a CVS snapshot. I need to improve the long description before uploading. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470623: ITP: nxproxy -- NX X compression proxy
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: nxproxy Binary package(s): nxproxy Version: 3.1.0-2-1 Licence: GPL Author: NoMachine Homepage: http://www.nomachine.com/ Description: NX X compression library NX provides a differential X compression library for X11. . This package provides the X proxy binary. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470621: ITP: nxcl -- NX X compression client library
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: nxcl Binary package(s): libnxcl1 libnxcl-dev libnxcl-bin Version: 0.9-1 Licence: GPL Author: Seb James [EMAIL PROTECTED] Homepage: http://freenx.berlios.de/ Description: NX X compression client library NX provides a differential X compression system for X11. . This package provides the client library. Description: NX X compression client library---headers NX provides a differential X compression system for X11. . This package provides the client library headers. Description: NX X compression client library---runtime NX provides a differential X compression system for X11. . This package provides the runtime binaries for the nx client libraries. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470624: ITP: nxcomp -- NX X compression library
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: nxcomp Binary package(s): libxcomp3 libxcomp-dev Version: 3.1.0-6-1 Licence: GPL Author: NoMachine Homepage: http://www.nomachine.com/ Description: NX X compression library NX provides a differential X compression library for X11. . This package provides the compression library. Description: NX X compression library---headers NX provides a differential X compression library for X11. . This package provides the compression library headers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#470622: ITP: qtnx -- NX client for QT
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: qtnx Binary package(s): qtnx Version: 0.9-1 Licence: GPL Author: Homepage: Description: NX client for QT NX is a differential X compression protocol for X11. . This package provides the QT client. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#470621: ITP: nxcl -- NX X compression client library
On Thu Mar 13 10:20, Roberto C. Sánchez wrote: > On Thu, Mar 13, 2008 at 03:08:39PM +0100, Michael Biebl wrote: > > > > Just curious: > > One of the major complaints about NX (iirc) and the reason why it wasn't > > packaged for Debian yet, is that it basically was a fork of the > > complete Xorg/Xfree86 sources (which understandably didn't make our > > security team happy). > > Is nxcl a reimplementation that solves this problem? > > Does it allow to implement the NX server as an extension for Xorg? > > > Yes. Thay also fork openssh, CUPS and other stuff. The submitter is > advised to check the mailing list archives of the pkg-nx group on > Alioth. I'm aware of this, however, the cups/X fork is only for the server side. On the client side there is normally an SSH fork involved, but I'm working with the freenx people who have a patch to nxproxy so that it doesn't need nxssh. These ITPs are for an NX client with the above patches so that openssh can be used rather than nxssh. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Seeking for advice on packaging reunified upstream source
On Tue Apr 01 14:26, Bastian Blank wrote: > On Tue, Apr 01, 2008 at 12:06:49PM +0200, Francisco Moya wrote: > > Should I provide binaries in main for the Java packages generated with > > gcj (they would run fine with IcedTea)? > > I don't see a reason to not do that. I believe this is still required to be in contrib (certainly I have packages meeting that description), the binaries depend on something outside of main to run... Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: A suggestion
On Thu Apr 03 11:54, Andrea Bolognani wrote: > And stable is not fine for a desktop in general, because it has outdated > packages which are not what a desktop user wants. _you_ may want more up to date packages, but a lot of people are entirely happy with etch on their desktop. For example, both me and my mother. I'd also go as far to say that most corporate Linux desktops, to pick another example, would welcome the lack of change for 18 months. > Testing is fine for a desktop, as long as you know you may have to deal with > breakages from time to time. Not that it happens often, at least from my > experience. Many people don't want breakage. Linux hobbiests may want the constant latest version, and they can cope with testing (or, often, run ubuntu or gentoo for that reason), but most computer users would rather things _didn't_ change regularly, and those people are also our target audience. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Bug#402010: How to deal with #402010?
On Sun Apr 06 17:32, Roland Mas wrote: > sean finney, 2008-04-05 11:59:31 +0200 : > > [...] > > >> RequestHeader set FooPassword very-secret-credentials > > > > i suspect php users will still be able to find that out, in the same > > way that they can read ssl private keys from the webserver's memory > > (you *did* know they can do that, right? :) > > Erm, no, I didn't. Is that supposed to happen (by design), or is it > just a bug in the PHP interpreter? It sounds like a severe security > problem... If you use mod_php then your process is running with the same uid as the web server, ergo, it can read the memory of the apache process. The php interpreter doesn't have much to do with it, as long as system() and friends are enabled. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Wed Apr 16 17:19, Andreas Tille wrote: > Hi, > > it is the third time that I've got this type of rejection. I faced > it two times with package gnumed-client and now with a different package. > > Is anybody able to explain this and how can I avoid the problem. I > just builded the package with an up to date pbuilder. do you have updated devscripts? debsign signs the dsc then updates the md5 hash in the changes before signing that. It needs to update the sha checks as well. The latest devscripts does. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed
On Wed Apr 16 17:47, Andreas Tille wrote: > Do I have to start pdebuild out of an "unstable" system? This > would be a nuisance because I do not want to run unstable on this > machine and regarded pbuilder as a very nice way to maintain a > proper unstable chroot. It depends where you run debsign. I've backported devscripts to the machine I run debsign on, which isn't running unstable, so pbuilder builds in a sid chroot and then I sign outside of it. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: ia32-libs depends on ia32-apt-get ?
On Mon Jun 29 20:18, Raphael Hertzog wrote: > On Mon, 29 Jun 2009, Norbert Preining wrote: > > On Mo, 29 Jun 2009, Mark Brown wrote: > > > > Figure out an acceptable option 4. > > > > > > Multiarch was mentioned in the original thread. > > > > Not that I was happy with the original situation (filing myself a bug), > > but all that "multiarch" blabla and nothing is going forward in this > > direction, so this is not a reasonable solution until nobody steps > > forward and does the work for that. > > There is work going on recently. Steve Langasek drafted a plan that he > wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by > Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a > reality inside Debian but I don't know of any timeframe. > > https://wiki.ubuntu.com/MultiarchSpec I have offered to help with this, if someone can tell me what needs to be done. This is something I'd hoped would be pushed out through Debian to other distributions, not yet another thing which Ubuntu innovates and then we merge back in later. Matt -- Matthew Johnson signature.asc Description: Digital signature
Multiarch (Was: Re: ia32-libs depends on ia32-apt-get)
On Mon Jun 29 21:50, Goswin von Brederlow wrote: > > There is work going on recently. Steve Langasek drafted a plan that he > > wants to bring forward in Ubuntu Karmic Koala and it has been reviewed by > > Guillem Jover, the dpkg maintainer. Guillem also has plans to make it a > > reality inside Debian but I don't know of any timeframe. > > > > https://wiki.ubuntu.com/MultiarchSpec > > > > Cheers, > > Too bad they did that without involving the people already working on > multiarch via the alioth project. > > They messed up some finer details, broke the existing patches, made > the whole thing need a full release cycle for a transition due to > DEBIAN/control format changes and have a broen plan for -dev packages. Ok, For those of us who haven't been following all of the bug reports and threads covering this, perhaps we could have a summary here of what you think needs doing to get multiarch working, what needs changing and what objections people have to changing it. I would love to see this in (or the required changes so that it can be in squeeze+1) in squeeze and now is the time to do it. I've also CC'd Hector and Steve who are listed as owners on that document because whatever we do to get multiarch working (and I have no strong views on the right way to do it) we should definitely not do it differently to Ubuntu. signature.asc Description: Digital signature
Re: Switching /bin/sh to dash (part two)
On Sun Jul 19 18:04, Raphael Geissert wrote: > This is a follow up to my previous thread, with a slightly different proposal. > Sounds like a good plan, I really hope we can go ahead with this for squeeze. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: merge sensible-browser in xdg-open AKA how to select the "best" browser
On Sun Aug 02 09:26, Sandro Tosi wrote: > > All I ask for is that you understand that you are about the change the > > relavant semantics of something security relevant, and act accordingly. > > What? all I'm trying to do is say "hey man, if you need to open a url, > do it with x-o as you've done with x-b". I think that most of these issues could be fixed with the addition of an xdg-browser, which only opens a web browser and nothing else. More integration between desktop environments and other parts of the system is always a good idea, so I'd encourage some integration between the two, whether it's replacing s-b with xdg-something or having s-b call xdg-something in a non-recursive fashion. > - you say x-o is dangerous but then you say it's not that a problem > (no bug report, for example) It's not a bug per-se, it's just that the security model between the two is different, and that's fine. However, to directly use x-o in the place of s-b would be to change the security model under the hood. This is bad because you get a disconnect between what people _expect_ can happen and what can _actually_ happen. Hence why I like the xdg-browser suggestion, which keeps the same semantics. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Bits from the release team and request for discussion
On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote: > Personally I don't think we should do a GR to recommend a freeze or release > date. > We already used the DPL election to push a release, when it was *long* due, > but > I don't think we should push a freeze. Zack has been patching devotee to allow more informal (and not at all binding) polls to be run with the same infrastructure. I think this could be a suitable candidate to run using that. It allows us to have a poll which can only be voted in by DDs and not easily stuffed, but without having to go through the pain of a formal resolution. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: debian/rules "make -f" restriction
On Thu Oct 29 15:58, Michael Banck wrote: > On Thu, Oct 29, 2009 at 11:37:20AM +0100, Tobi wrote: > > Are there any serious objections against just overriding and ignoring > > the Linitan warning about not having "make -f" in the shebang line? > > As long as you don't have an objection against having serious bugs filed > and your packages not be part of a stable Debian release, I guess not. put me in the camp that doesn't think this is necessary. If it behaves precisely the same way as a makefile which does have that shbang line when compiling the standard Debian package I really don't think there is a problem with this. I'm also against the suggestion which reduces debian/rules to: ifeq () include real-debian-rules.mk else include alternate-debian-rules.mk endif At least the VDR solution means that if I just care about fixing the package in normal Debian mode, I can look at Debian rules and see what's going on, not have to go look at some other file which contains the real debian/rules. This is all far nicer than (for example) the packaging for the kernel, which is really scary, but does have the right shbang line. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Lintian based autorejects
On Mon Nov 02 11:40, Luk Claes wrote: > For the actual matter at hand I think it's very wrong to do a MBF > without going through d-devel for several reasons: > Otoh, this is a slightly special case, since they are things which are causing the package to become non-uploadable. In this case the correct place to have the discussion about the scope et al of the bugs is with ftp-master about what constitutes rejection criteria; the bug filing is purely a reflection of that. I certainly don't think that having packages with an upload-critical bug with no bug filed against them is a good idea Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: GDM, getty and VTs
On Mon Nov 16 11:07, Josselin Mouette wrote: > We remove entirely the getty respawning from /etc/inittab. Instead, a > new daemon is started by a regular init script. This daemon does the > following: > * Opens all /dev/tty1 to tty6 and display a d-i-like “press enter > to activate this console” in them. > * Provide a very simple interface to reserve a VT, that can be > queried by the display manager. > * Whenever you press enter on a VT, reserve it and start a getty > process. > * When almost all ttys are allocated, start opening tty7+ and so > on. > * If no display manager is started, always run a getty process in > tty1. How about a hybrid of the two? This daemon ensures that nothing which dynamically selects ttys can allocate on 1--6 and starts a getty on them if you press enter. Thus, If you start X or some *dm you get allocated on the 'next free' tty (but not 1--6), people needing more VTs also get them allocated from 7 and in the 'default' setup (one *dm and no 'extra' ttys) alt-ctrl-f7 still works. I don't really see any reason for users of graphical logins to care which VT it is on most of the time. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#559688: ITP: pescetti -- Bridge Pseudo-duplimate generator
Package: wnpp Severity: wishlist Owner: Matthew Johnson X-Debbugs-CC: debian-devel@lists.debian.org Source package: pescetti Binary package(s): pescetti Version: 0.5-1 Licence: GPL-2 Author: Matthew Johnson Homepage: http://www.matthew.ath.cx/projects/pescetti/ Description: Bridge Pseudo-duplimate generator Generates random bridge hands or hands matching a certain specification with a given probability. Produces hand records and dealing sheets to allow duplication of the hands without a duplimate machine. . Pescetti can interface with the dds double dummy solver to produce analysis for the hand records. . Provides conversion or import from dds-format and pbn files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can quilt delete files?
On Tue Dec 08 17:42, Thomas Koch wrote: > As long as the jar file is the one created by the sourcecode in the tarball, > I > don't see a reason, that it needs to be removed and thus the upstream tarball > repackaged. No, but it is an option still. > Putting the deletion in the clean target could be an option, but I really > hate > to modify my source tree that much while packaging. Why do you think there's a difference between this and at patch time. > So no way to do it with quilt? There's definitely no way to do it with quilt. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Can quilt delete files?
On Tue Dec 08 16:56, Thomas Koch wrote:
> Trying to generate an appropriate quilt patch failed. The only thing I came
> up
> with, was a patch that contains the whole content of the removed files with -
> before every line.
> Anybody more clever then me?
No, you can't do it like that. Generally the source package is repacked
to remove these first and that tarball is uploaded as the orig.tar.gz.
Many Java packages need to be repacked from .zip anyway, so that's not a
big deal. If you do this is customary to append a '.ds' or similar
suffix to the upstream version.
> I know that dpatch allows the execution of shell scripts. This would be
> ideal.
> I'd just do find . -name "*.jar" -exec rm {} \;
You could do this, although if you are going down this route, just doing
it in the clean: target is probably sufficient. In any case they are
still shipped in the upstream tarball and dpkg-source ignores missing
files when creating the diff.gz
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Re: Proposed new release goal: Dependency/file list predictability
> As discussed during DebConf, I'd like to propose a new release goal: > Packages should not only build in clean chroots, but also in non-clean > environments. Specifically, adding extra packages from the archive > into the build environment (that are not in Build-Conflicts) should > not affect the resulting package in any noticeable way. Also, you should consider build systems which switch using the alternatives system. Debian Java policy says that debian/rules must specify the build system to use explicitly, but there are a number of packages which don't. These will build if only their build-depends are installed or if their build system is the current alternative, but not if they were installed in a different order. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Considerations for 'xmms' removal from Debian
Roger Leigh <[EMAIL PROTECTED]> scribbled: > GTK+ 1.2 (and GLib 1.2) were abandoned upstream over *six years* ago. > It's rather probable (nay, doubtless) that there are unidentified and > unfixed security problems with these libraries. > > Given that upstreams have had over five years to port their code, it > is time to drop dead code that is not maintained, IMO. It's not like > there isn't huge amounts of compatibility code in GTK, GDK and GLib to > ease such porting (I've used it myself). A minimal port is often just > a bunch of regex search and replace operations, with some small amount > of rewriting. > > Note that this is irrespective of how good XMMS is or is not. The > libraries it depends on are dead, and they should have upgraded years > back. So, I maintain gbib. It's a gtk1.2 program which hasn't been ported upstream and upstream maintenance is basically dead. Should it be remove from the archive? I think it's really useful, I use it every day, there isn't a suitable replacement available. (kbibtex comes with lots of KDE dependencies and while being slightly more featureful is much less nice to use). Popcon lists 363 installations. If I have the time and inclination maybe I will port it to gtk2, but why should I spend that effort when it's a perfectly good working program. Sure it's not getting new features, but it gets along fine without them. If there were a drop-in replacement for gbib I wouldn't mind, but there isn't. Removing gbib from the archive would deprive any new installations of a suitable tool for doing this, something that existing Debian users also do often (Upgrading is all well and good, but for various reasons I have done numerous clean installations), and in those cases it is made a lot harder for the existing users who suddenly find gbib has disappeared. I'm not arguing against the removal of xmms, but I am arguing against the removal of perfectly good pieces of software just because the are no-longer upstream supported. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#489587: ITP: python-scriptutil -- Python module which provides the functionality of find and grep
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: python-scriptutil Binary package(s): python-scriptutil Version: 1 Licence: BSD Author: Muharem Hrnjadovic Homepage: http://hrnjad.net/src/7/scriptutil.py Description: Python module which provides the functionality of find and grep This package contains a python module which provides a recursive find on the filesystem and searching within those files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Mon Jul 21 14:07, Steve Langasek wrote: > > > > I do feed info upstream (via yet more website logins), I really can't > > > > add yet another one. > > > > I guess OpenID support will come to the rescue here. > > > It will help, if one wants to use the web interface. However, > > Launchpad accepting bug report submission and interaction purely via > > email (like the Debian BTS has done for many years) doesn't seem to be > > up for consideration. > > Launchpad does allow manipulation of bug reports via email, but only by > authenticated users (i.e., registered LP users with known GPG keys). > Given that Ubuntu takes things directly from Debian, and hence all Debian Developers have a vested interest in Ubuntu packages, would it make sense to (provide|ask ubuntu to provide) a way for bug reports to be manipulated by users with keys in the Debian keyring? Obviously this could be created by someone with a LP account and a bouncer that checks the Debian keyring, but it would probably be better to have Ubuntu on board with this. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
On Wed Jul 23 16:13, Reinhard Tartler wrote: > Matthew Johnson <[EMAIL PROTECTED]> writes: > > > Given that Ubuntu takes things directly from Debian, and hence all > > Debian Developers have a vested interest in Ubuntu packages, would it > > make sense to (provide|ask ubuntu to provide) a way for bug reports to > > be manipulated by users with keys in the Debian keyring? > > This would effectivly mean activating the respective LP account [1] and > associating the respective gpg key with that account. This would be of > course doable, but given from this and previous discussions, I do not > have the impression that this is generally desired by all debian > developers. How about activating it the first time they send a gpg-signed mail to the mail interface? Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Packages getting marked not-for-us
On Wed Aug 06 10:42, Steve McIntyre wrote: > Steve Langasek wrote: > >On Wed, Aug 06, 2008 at 12:33:58AM -0400, Michael Casadevall wrote: > >> Correct me if I'm wrong, but it seems like a pretty bad idea to NFU > >> software > >> that can be compiled on an architecture even if it doesn't seem that > >> useful. > >> I have the X11 libraries on my NSLU2, which lacks any graphical output, but > >> I use it as an X11 server. > > > >The argument for not building various packages on s390 is that s390 has *no > >hardware*, so anything that depends on local hardware to be useful has no > >purpose on s390. > > > >That doesn't apply for hpodder, which is not a hardware interface; but > >that's a plausible explanation for why the package was put in NFU, if the > >buildd maintainer thought it was hardware-dependent. > > It would be nice if buildd admins told people they were doing it, of > course, so that maintainers don't have to guess why their packages > mysteriously aren't being built... > Or at least didn't block testing migration. I'm happy if porters decide my package isn't for them, as long as it doesn't stop it being for anyone else either... Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Release Update: freeze guidelines, testing, BSP, rc bug fixes
On Tue Sep 02 09:52, Vincent Danjean wrote: > Cannot you rename NewInLenny to NewInLenny-oldlicense and recreate a > NewInLenny page (with a link to NewInLenny-oldlicense ?) > The new NewInLenny page would have a licence compatible with the > release notes and can be fed up with the content of the current release > notes... Or, ask all the contributors to the NewInLenny page if they could agree to licence their contributions in a compatible fashion (what _are_ the relevant licences anyway?!) -- Matthew Johnson signature.asc Description: Digital signature
Re: Proposal: user-visible list of divergences from upstream
On Tue Sep 09 08:34, Reinhard Tartler wrote: > BTH, I think the maintainer's time is way better spend with > documententing their patches properly. > I concur. patch-tracking.debian.net is the way forward. Integrating it with as many other services as possible is, of course, always good Matt -- Matthew Johnson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#500440: ITP: fcoretools -- Tools for examining and hinting the IO scheduler
Package: wnpp Severity: wishlist Owner: Matthew Johnson <[EMAIL PROTECTED]> X-Debbugs-CC: debian-devel@lists.debian.org Source package: fcoretools Binary package(s): fcoretools Version: 1.0-1 Licence: GPLv2 Author: Dave Plonka <[EMAIL PROTECTED]> Homepage: http://net.doit.wisc.edu/~plonka/packages.html This package provides two tools for manipulating the IO scheduler: fincore is a command that shows which pages (blocks) of a file are in core memory. It is particularly useful for determining the contents of the buffer-cache. fadvise is a command used to give file advisory information to the operating system. Its "--dontneed" option is particularly useful in that it causes the files' pages (blocks) to be evicted from the buffer-cache. -- Matthew Johnson signature.asc Description: Digital signature
Re: RC bugs in lenny, sorted by maintainer
On Thu Oct 23 12:53, Sandro Tosi wrote: > On Thu, Oct 23, 2008 at 12:40, Lucas Nussbaum <[EMAIL PROTECTED]> wrote: > > No: in some cases, the maintainer forgot to send an unblock request to > > -release@, or the fix was inappropriate, and the bug will have to be > > fixed through a testing-proposed-updates upload. > > > > The release team isn't proactively tracking those AFAIK, it's still the > > maintainer's responsibility to take care of this. > > Just to clarify, dato yesterday told me that what's in t-p-u it's > under the release team attention, and the usually take care of it. Yes, but the maintainer has to make the upload to t-p-u (or send the unblock etc) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: I hereby resign as secretary
On Thu Dec 18 08:44, Manoj Srivastava wrote: > > I am hereby resigning as secretary, effective immediately Thank you for your hard work in this post. I'm sorry to see that a few zealots can cause so many hard working folks to consider leaving the project. Personally, if we are to do without anyone it is not the people I see resigning or considering resignation that I would rather see leave. Please ignore those people who are asking for your removal from the project. Whatever their feelings about how you have managed the role of project secretary any suggestion that you should leave the project is completely untenable. It's a ridiculous suggestion and I am shocked that anyone would entertain the thought. Matt -- Matthew Johnson signature.asc Description: Digital signature
Possible MBF due to DBus security issue
In order to fix CVE-2008-4311 the default permissions on the system bus have been tightened up. This has revealed bugs in the configurations shipped with a number of services using the system bus which relied on the broken behaviour and will now break. A fixed version of dbus has been uploaded to experimental. The release team would like this version to go into lenny, but we need to fix any bugs caused by that version. Upstream have already started collating patches to upstreams[0] so for many of the larger packages will already have patches there. Below is the list of all the packages which currently have configuration for the system bus. I've not yet checked them to see whether or not they have problems with their config files but will be doing so soon and filing bugs. It would be great if all the maintainers could check their packages with the dbus from experimental to ensure that they still function properly. All that needs to be done to fix this is to edit the config file which is dropped in /etc/dbus-1/system.d/ to allow all of the incoming method calls and outgoing signals. Method replies/errors and introspection already have exceptions. List of packages which may be affected: Masayuki Hatta (mhatta) cups (U) Moray Allan gpe-bluetooth (U) Michael Biebl consolekit (U) dhcdbd (U) hal (U) knetworkmanager network-manager (U) network-manager-applet (U) policykit (U) powersave Julien BLACHE pommed Phil Blundell gpe-bluetooth (U) Debian Bluetooth Maintainers bluez-utils Debian CUPS Maintainers cups Debian GNOME Maintainers system-config-printer (U) system-tools-backends (U) Debian GPE team gpe-bluetooth (U) Debian Maemo Maintainers libosso osso-gwconnect Debian OLPC sugar Debian VoIP Team mumble Debian/Ubuntu wpasupplicant Maintainers wpasupplicant Sebastian Dröge avahi (U) hal (U) Edd Dumbill bluez-utils (U) Filippo Giunchedi bluez-utils (U) Soren Hansen network-manager-openvpn network-manager-vpnc Mario Iseli bluez-utils (U) Matthew Johnson bluemon Simon Kelley dnsmasq Anand Kumria yum Jonny Lamb libosso (U) odccm osso-gwconnect (U) Roger Leigh cups (U) Jeff Licquia cups (U) Patrick Matthäi mumble (U) Kyle McMartin wpasupplicant (U) Loic Minier avahi (U) libosso (U) osso-gwconnect (U) system-tools-backends (U) Kel Modderman wpasupplicant (U) Josselin Mouette system-config-printer (U) system-tools-backends (U) Kenshi Muto cups (U) Thorvald Natvig mumble (U) Patrick Patterson pathfinder Martin Pitt cups (U) Martin-Éric Racine cups (U) Andres Salomon yum (U) Otavio Salvador system-config-printer system-tools-backends (U) Niv Sardi system-tools-backends (U) Riccardo Setti galago-daemon network-manager (U) Riccardo Setti dhcdbd (U) Sjoerd Simons avahi (U) dhcdbd (U) hal (U) Jonas Smedegaard sugar (U) Jose Carlos Garcia Sogo system-tools-backends Brian Sutherland smart-notifier Philippe De Swert gpe-bluetooth (U) Reinhard Tartler wpasupplicant (U) Enrico Tassi network-manager-pptp Utopia Maintenance Team avahi consolekit dhcdbd hal network-manager network-manager-applet policykit Riku Voipio libosso (U) osso-gwconnect (U) Matthew Wilcox kerneloops Neil Williams gpe-bluetooth 0. https://bugs.freedesktop.org/show_bug.cgi?id=18980 -- Matthew Johnson signature.asc Description: Digital signature
Re: Possible MBF due to DBus security issue
On Sat Jan 03 17:58, Matthew Johnson wrote: > All that needs to be done to fix this is to edit the config file which > is dropped in /etc/dbus-1/system.d/ to allow all of the incoming method > calls and outgoing signals. Method replies/errors and introspection > already have exceptions. OK clarification from dbus upstream. Replies, errors and signals are all allowed by default. Introspection is not. It is recommended that every service has a send_destination rule to allow things to send to the well-known names which that process owns rather than just send_interface so that it applies to introspection as well as other method calls. Matt signature.asc Description: Digital signature
Re: Possible MBF due to DBus security issue
On Sat Jan 03 20:57, Simon McVittie wrote: > > > Michael Biebl > >powersave Definitely needs at least introspection allowing, bug filed > > Debian CUPS Maintainers > >cups > > mjj29 is investigating and thinks it's OK Doesn't allow introspection, but only sends signals so it's not critical. Filed a bug at normal > > > Debian Maemo Maintainers > >libosso > Ships a config file which disables all the security checks on the whole system bus[0]. Filed RC bug > > Matthew Johnson > >bluemon > > Maintainer responding Bug filed, fix uploaded with urgency: high and unblock requested. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Possible MBF due to DBus security issue
On Sat Jan 03 20:57, Simon McVittie wrote: > > Simon Kelley > >dnsmasq > > ??? > > > Anand Kumria > >yum > > ??? > > > Patrick Patterson > >pathfinder > > ??? > > > Matthew Wilcox > >kerneloops All of these have the send_destination policy so look like they should be fine. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Arch:all package depending on package that isn't Arch:any
On Wed Jan 14 19:32, Neil Williams wrote: > > > > How about using (for example) > > > > > > Architecture: all [i386 amd64 ppc] > > I should just note that this was a suggestion by Goswin von Brederlow. > > I'm wondering if the change should be made in the other direction: > > Package: acpi-support-base > Architecture: any > Depends: acpid [i386|amd64] The problem with both of these is that if acpid starts working on ppc as well you have to transition acpi-support-base. Ideally the solution shouldn't require an upload to acpi-support-base when the architectures of its dependencies change. > I'd rather that this is fixed generically for all archive software and > all suites. Also a good idea (if possible). Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Arch:all package depending on package that isn't Arch:any
On Wed Jan 14 19:56, Neil Williams wrote: > > The problem with both of these is that if acpid starts working on ppc as > > well you have to transition acpi-support-base. Ideally the solution > > shouldn't require an upload to acpi-support-base when the architectures > > of its dependencies change. > > Depends whether the Arch:all package is built from the same source as > the Arch:any [restricted] package. If so (as with this specific > example), then the upload problem goes away. > > Sounds like we need some figures and real data on this issue. In some cases it's a non-problem, yes, but it a lot it won't be, so I'd still be in favour of a solution which doesn't transition the other package. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Arch:all package depending on package that isn't Arch:any
On Thu Jan 15 17:49, Adeodato Simó wrote: > An arch:all package should be installable anywhere where its > dependencies can be satisfied. And if they can't be satisfied, dpkg/apt > will refuse to install it already. > > No, the only use for "Architecture: all [i386 amd64]" or > "Install-Architecture: i368 amd64" would be as a hint to dak (and other > tools) that the package is known not to be installable anywhere else, > and hence should not be put in other Packages.gz files. That's *all* > that matters AIUI. Can't dak work that out itself? (assuming that we are only considering archives which are meant to be self-contained). Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Should gnome-libs die for Lenny?
On Wed Jan 21 12:08, Barry deFreese wrote: > There are only 5 packages left that have reverse depends on gnome-libs > packages. They are as follows: > > gbib: Removal was proposed. I mailed upstream and the response was "gbib > is no longer maintained or developed". I'm trying to build it now with > Gtk2 but not having much luck so far. And, it's not in Lenny anyway... Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Why is su preserving the environment?
On Sat Jan 24 11:00, Reinhard Tartler wrote: > Josselin Mouette writes: > > > I think Steve has a point, and as he explains, this is not a big > > security issue; however it is breaking the expectations you have when > > logging as another user. For example, it is not expected that starting > > an application as the other user will re-use the running one, and it is > > not expected that accessing the GNOME keyring will show the passwords of > > the original user. > > Well, then how about gnome-keyring or other applications not expecting > that behaviour should then check the effective user id in addition to > the session cookie in the environment variable? > > In any case, this behaviour should probably be somewhere properly > documented, at least in the developer and/or user documentation of > gnome-keyring (I have to admit that I didn't check it myself, since I > haven't developed an application which uses gnome-keyring yet). Well, if they are using DBUS this should be fine. You cannot connect to a session bus with a uid other than the one it is running as (including root) Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Why is su preserving the environment?
On Sat Jan 24 14:08, Josselin Mouette wrote: > Le samedi 24 janvier 2009 à 10:05 +0000, Matthew Johnson a écrit : > > Well, if they are using DBUS this should be fine. You cannot connect to > > a session bus with a uid other than the one it is running as (including > > root) > > Clearly that’s not the case, since the original issue happens over > D-Bus. In this case, not for authentication, but clearly the application > launched as root can connect to the session bus. Well, clearly something else is going on because root can't connect to the session bus here, this is on Lenny. I'm also part of DBus upstream and AFAIK this part of the security policy has not changed: =0 [mjj29] $ dbus-launch --sh-syntax DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-NcM9i9iZek,guid=c8396b814246d79f7bc863b6497b356d'; export DBUS_SESSION_BUS_ADDRESS; DBUS_SESSION_BUS_PID=12888; =0 [mjj29] $ DBUS_SESSION_BUS_ADDRESS='unix:abstract=/tmp/dbus-NcM9i9iZek,guid=c8396b814246d79f7bc863b6497b356d'; =0 [mjj29] $ export DBUS_SESSION_BUS_ADDRESS; =0 [mjj29] $ DBUS_SESSION_BUS_PID=12888; =0 [mjj29] $ dbus-monitor signal sender=org.freedesktop.DBus -> dest=:1.0 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired string ":1.0" method call sender=:1.0 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='method_call'" method call sender=:1.0 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='method_return'" method call sender=:1.0 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='error'" ^C =130 [mjj29] $ su Password: qadesh:/home/mjj29# echo $DBUS_SESSION_BUS_ADDRESS unix:abstract=/tmp/dbus-NcM9i9iZek,guid=c8396b814246d79f7bc863b6497b356d qadesh:/home/mjj29# dbus-monitor Failed to open connection to session message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. qadesh:/home/mjj29# -- Matthew Johnson signature.asc Description: Digital signature
Re: adding desktop files to misc packages
Eduard Bloch wrote: > * Josselin Mouette [Wed, Jul 18 2007, 07:32:28PM]: > > > > The Debian menu system will generate .desktop files from .menu files > > > if the > > > .desktop file does not exist. This is intended solely > > > as a temporary compatibility measure. > > > > This is a very bad idea. It is going to clutter the freedesktop menu > > with tons of useless entries with ugly icons and make it as useless as > > Make it short, what is your point? Not allowing others to play in your > GNOME sandbox? Surely the correct approach is to say that people who don't want to see it won't have it installed and people who have it installed want to be able to use it from the menu. Programs which you have to have installed and yet don't want to see in the menu probably shouldn't have (visible by default) menu entries and should be dealt with by fixing that program, not by removing all the other entries. Having said that, I do agree with moving to .desktop by default, but that does not address the issue of what should be in the menus, just how. Matt -- Matthew Johnson signature.asc Description: Digital signature
GTK1 Apps (was: Re: Considerations for 'xmms' removal from Debian)
Josselin Mouette wrote: > I don't have any power to remove their packages from Debian, but I > urge every maintainer of a package depending on GTK+ 1.2 to either > start the work on GTK2 porting it or consider its removal. And now is > more than the time to start this. Neil Williams wrote: > If anyone wants *any* packages on > http://wiki.debian.org/GTK+_1%2e2_leftovers to remain in Debian after > Lenny, then do as I have done and take over the upstream maintenance > of the old code and do the port yourself. Nobody else is apparently > willing to do it. I am the gbib maintainer and despite the fact that it is fairly unmaintained upstream I use it regularly and know of no good replacement. I would love to port it it to GTK2, and it is a fairly simple UI, but while I can keep on top of any RC bugs which may arise (there are none at the moment), and do the odd tweak, I certainly don't know enough GTK to be able to port it to GTK2; nor do I have the time to learn right now. Are there any guides, howtos, instructions or anything else useful for porting gtk1 apps to gtk2? I certainly would like to keep this package I use daily in Debian, as I'm sure would many of my 350*(popcon factor) users. Thanks, Matt -- Matthew Johnson Trinity Hall IT Support signature.asc Description: Digital signature
Re: Proposal for reform of the Debian membership process
On Sat Dec 08 16:36, Ondrej Certik wrote: > > The total time it took you to convince the relevant people in Debian > > that you should be a DD was 301 days. Of those 301 days, you spent 4 and > > a half hours working on it (along with five uploads of your packages, > > and apparently a sponsored NMU). > > I thought you spent 4.5 hours working on the application, but > otherwise you were doing regular packaging work in Debian. > So you spent 4.5 hours in total on Debian (plus five uploads and NMU) > for last half a year? I was doing regular packaging work, except it was very hard to find a sponsor. For every sponsored upload I think I had 5 or 6 or more requests for uploads which went completely unanswered. Those figures are time taken to show my AM that I am competent to be a DD, not time spent on Debian while in NM. A quick glance (or search) of the BTS or the wiki page I used in my NM advocacy will show you that I was not inactive in the things that I could do sans sponsorship either... Sure, 300 days isn't a long time from first involvement with Debian to becoming a DD, but I had one package in the archive in 2004 and had been using Debian almost exclusively for 3 years prior to that. I didn't apply to NM until I thought I was ready, and once I got through the queues everyone seems to have agreed with that. > Being DM allows me to upload packages immediatelly, while I am in NM, DM makes it a lot better. I note that the DM proposal hadn't come into effect until after I was approved by the DAM, which sort of felt little pointless applying then. Anyway, I was hoping to discuss my proposal, which you will see suggests having multiple fine grained grants of access rights (such as DM), but in a more structured way and using one as probation for the other. I think this is a good thing, I think waiting in queues for no reason is a bad thing, which I'm trying to help fix. You may disagree with me about how long it should take, but that's not the only thing I'm trying to address. I don't think anyone disagrees that the account creation wait should be shorter; by making access control more fine grained it makes it easier to delegate at least some of the decisions and tasks for those access permissions which aren't as wide ranging. This may assuage the concerns some have over who is sufficiently trustworthy to make those decisions. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Bug#457353: gdome2-xslt: should not be a Debian-native package
On Sun Dec 23 15:26, Roberto C. Sánchez wrote: > On Sun, Dec 23, 2007 at 07:35:12PM +0100, Stefano Zacchiroli wrote: > > > > Sorry, but I disagree with this interpretation. For me a Debian native > > package is a package which contains the official debian packaging stuff > > in the upstream tarball. Since I'm also upstream for gdome2-xslt and the > > software has been used historically always as a Debian package, to me > > that is a native Debian package. > > > One of the packages in whose upstream maintenance I participate has a > -doc package with a ~5MB .orig.tar.gz. Are you suggesting that because > I keep the debian/ directory in the same VCS as upstream development > that I need to make a ~5MB upload everytime I make an upload to fix > something trivial? More to the point, when you fix something trivial under debian/ does that cause a new upstream release to happen? There are lots of reasons why you would want to make debian releases out of sync with upstream releases (in both directions). Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: About new source formats for packages without patches
On Fri Mar 26 10:11, Marc Haber wrote: > On Fri, 26 Mar 2010 09:17:30 +0100, Raphael Hertzog > wrote: > >My goal as dpkg maintainer is that Debian converts the maximum number of > >source packages to the new source formats in the shortest timeframe. (You > >might not share this goal but that's another matter) > > Do you really need a tech ctte decision to step back from that idea at > this point of our release process? I think that's a little harsh, I think that's a perfectly reasonable view. He didn't say 'ignoring the release' or 'by squeeze'. The expected time using the debhelper approach of 'build it and they will come' might be expected to take 5 years and Raphael is trying to actively work towards it so that it happens in 3. There surely must be some extra effort that people can put in to get their system adopted faster than just putting it out there and see what happens. Matt -- Matthew Johnson signature.asc Description: Digital signature
Why does bash make itself unconditionally /bin/sh?
Package: bash Version: 4.0-7 Severity: serious Having just had an argument on IRC about /bin/sh diversions, it appears that the situation in Sid has changed again since I last looked at it. As I understood the discussions at Debconf last year and on this list, dash is now essential and the default /bin/sh. Bash is still essential and the default interactive shell. It can optionally (based on a debconf question at install time, or some other criteria on upgrades) provide /bin/sh should people want the old behaviour. I've been happily using dash for system shell scripts and bash interactively for a while and have been looking forward to that being the default. Having inspected an up-to-date sid chroot, it would appear that both bash and dash are now essential and bash is diverting /bin/sh to itself with /bin/sh.distrib pointing to dash. No amount of dpkg-reconfigure -plow gave me the option to change it. This seems like a regression which kinda makes all the effort on dash and bashims a little pointless.. It looks like this was introduced in 4.0-7 which fixes #546516. Thanks, Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Why does bash make itself unconditionally /bin/sh?
On Fri Apr 09 10:52, Matthew Johnson wrote: > Having just had an argument on IRC about /bin/sh diversions, it appears that > the situation in Sid has changed again since I last looked at it. Hmm, thanks to bwh for pointing out my mistake, sorry for the noise. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: bindv6only again
On Mon Apr 26 18:02, Salvo Tomaselli wrote: > You have a missconception of "broken". > POSIX has a default value, the developers will read the POSIX documentation > and tell you to screw you if you do a bugreport saying that if you > voluntarily > make your system non-compliant then their software doesn't work. Default does not mean "only permittable". If POSIX allows it to be set to either value, then no matter what the _default_ is, not coping with either is a bug. I don't believe that very many people are suggesting that not working with bindv6only=1 is not a bug which should be filed and fix when it occurs in the archive, nor that it should not be configurable to whatever setting we do not choose as the default. I agree - programs which don't work with the current setting are broken and should be fixed - but that does not mean we should go out of our way to exhibit such brokenness to our users. This seems like too much being contrary because it's technically allowed and declaiming the results not to be our problem, even though it breaks a lot of systems. I think we should change the default back _and_ work towards fixing all the applications, without making them instantly RC buggy in the mean time. It smacks of 'uncoordinated transition' to me. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: bindv6only again
On Mon Apr 26 23:21, Salvo Tomaselli wrote: > On Monday 26 April 2010 23:03:22 Don Armstrong wrote: > > It's a system wide default which can be changed by the administrator > > or by Debian. If the code fails when that default is changed, the code > > is buggy. > > > > There's no reason for the code to rely on a particular setting of the > > default when it can easily enforce the particular value that it only > > works with. > Can you indicate me which part of the standard says that? > If POSIX-compliant apps may only work with one setting then the standard would say "only this setting is compliant with POSIX". Since it does not, we must assume that a sysadmin choosing either value results in a POSIX-compliant system. If an application fails to work on such a system it must ipso facto not be POSIX-compliant and hence buggy. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Non-recompilable binaries in source and binary packages (Adobe Flash strikes again)
On Thu Aug 12 11:51, Russ Allbery wrote: > > No. There is no sensible way to do this. The problem is inherent: > > the binary packages in main have to be rebuildable using the source > > package (and supporting binary packages eg compilers) in main. > > > If you have this situation you have to have two separate source > > packages; one in main which builds only the free parts, and one in > > non-free which builds only the non-free parts. > > I don't believe this is correct. Source packages in main can build > binaries in contrib, and I believe the problem with not being able to > rebuild with free tools is more of a contrib thing than a non-free thing. > > But I'm not certain, which is why I was hesitating to reply to the first > message. I think the difference here is between components which require non-(free/debian) components to build and non-(free/debian) components to run. It seems consistent, at least, that if you can build with only free tools then the source package can be in main. If you can run with only free tools then the binary package can be in main (although, of course, if you can build with non-free tools but run with free tools, you still have to be in contrib). If, as is the case here, the building can't be done in main, then it has to be in contrib. Matt signature.asc Description: Digital signature
Re: OMG WTF BBQ balloons
On Mon Aug 16 12:00, Ian Jackson wrote: > I just had to tell NoScript "forbid debian.org" because I wanted to > read a bug report. > > I don't want to be a spoilsport but, honestly! You should read bugs.d.o in IE, they don't show up there Matt signature.asc Description: Digital signature
Re: Is a bug RC relevant if it has an influence on the health of a person
On Thu Sep 09 12:03, Karsten Hilbert wrote: > Here comes the bug: GNUmed will, given appropriate > circumstances, OVERWRITE the first allergy against Sugar. Sounds like "grave: , or causes data loss, ..." to me, which is RC. I was also going to suggest it could be considered a security vulnerability - and hence also be suitable for a DSA upload to stable were this discovered after release. I also wouldn't object to it being filed as serious under " in the package maintainer's ... opinion makes the package unsuitable for release". In any case it clearly should be fixed. Matt signature.asc Description: Digital signature
Re: Is a bug RC relevant if it has an influence on the health of a person
On Thu Sep 09 14:42, Tshepang Lekhonkhobe wrote: > > Rather than RC (which is only about whether the severity of the bug is > > sufficient to delay the release of Debian), what is the severity of the > > bug? > > AFAIK, this is not the sort of package that would delay Debian's > release. At worst it would just get excluded from the release. Indeed, RC is "either we exclude the package or we wait until it's fixed to release", so the comment still applies Matt signature.asc Description: Digital signature
Re: Buildd & binary-indep
On Mon Sep 27 15:18, Russ Allbery wrote: > > Unless I missed it in a previous discussion, I can't see what's wrong > > with simply mandating support with a new Standards-Version as Bernhard > > suggested. Could you elaborate on why Build-Features seems preferable > > since this appears to be a simple and easily implementable solution to > > the problem? > > Using simple version numbers for capabilities is bad protocol design for a > variety of reasons, one of which being that it's not extensible to cases > where you want the feature or capability to remain optional going forward. > Combine that with the problems with repurposing a field that's never had > operational effects in the past and I think this is a bad idea compared to > some way of explicitly stating that specific features are supported. Using the Standards-Version to indicate whether or not we have build-arch and not making it required is clearly wrong. However, that's surely not the suggestion? Assuming that autodetection works with dh7 et al, wouldn't it be sensible to use "Standards-Version >= X means that autodetection works", then require in policy that you make it possible for that to happen. This means that nothing FTBFS (since nothing has a new standards-version yet) and that for the majority of packages (and I believe there are only a few edge cases where it's not true) the Standards-Version can be bumped without any changes. In the few cases where atm the autodetection code will fail, I don't see a problem with fixing that before moving to the latest Standards-Version. Even just requiring the presence of build-arch/indep after a certain Standard-Version wouldn't be the end of the world. > Requiring listing supported features explicitly also makes it much less > likely that someone will claim something is supported accidentally, > without realizing the implications. > > There's significant past experience in this area in IETF protocols, both > negative experience with version numbers and positive experience with > capability labels. There are, of course, other reasons to prefer explicit listing (it's a shame that the target being in the file doesn't count as explicit listing, but...), but I thought it was worth contributing the above. Matt signature.asc Description: Digital signature
Re: Is the FHS dead ?
On Mon Feb 16 13:14, Patrick Schoenfeld wrote: > > Is there a standards body still interested in moving forward with > > filesystem layout discussions? If not, shouldn’t we start our own > > standard? > > I'm not sure if "start our own standard" is a good idea. We already have > our own standards and the FHS is more like a distribution-independent > standard, which it should stay. Defining our own standards wouldn't > neccessarily mean that other distributions adopt it. So if we really > start something on our own we should encourage other distributions to > take a part from the beginning. the FHS should certainly continue to exist and be coordinated between distros though. I agree that if it needs taking over we should do so in cooperation with the other big distros. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Security Issue of .desktop files
On Tue Feb 24 23:44, Yves-Alexis Perez wrote: > On mar, 2009-02-24 at 17:33 -0500, Michael S. Gilbert wrote: > > here is > > a .desktop file that looks like it is iceweasel, but really it > > downloads an essentially random file, but I could have made it do > > pretty much anything. > > Yes, tests may need to be narrowed. That should be part of the spec, > though. Speaking as someone with a PhD in computer security (and my PhD was in this area) I can tell you that trying to use heuristics in order to determine if something is 'bad' does not, and it's fairly widely recognised cannot, work. You are ipso facto providing an oracle to the attacker and he will craft something that looks sufficiently plausible, passes the checks, but is malicious. I firmly agree with Michael that the only good solution is to require explicit marking or .desktop files in some fashion. Owned by root is probably fine (since you've basically already lost if that's the case) as is setting the execute bit (but things should be cautious as always about setting it) Matt -- Dr Matthew Johnson signature.asc Description: Digital signature
Re: LXDE doesnt support Debian Menu
On Thu Feb 26 12:57, David Paleino wrote: > > You will never manage to "force" upstream authors of different environments > > to support freedesktop.org standard because you have no handle to force > > anybody in Free Software. > > Sure you can't, but standards exist for this reason. And sane upstreams would > certainly adhere to standards. Since when are all upstreams sane? Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Upcoming Section changes in the archive
On Fri Feb 27 02:10, Darren Salt wrote:
> > I'd prefer "localization".
>
> Whereas I'd prefer "localisation"...
>
> > - We use en_US in general -> "ize"
>
> ... unless you're localising for en_US. OTOH, given that that section is for
> localisation, "localization" is probably right, being localised...
>
> ("-ize" isn't actually wrong here, but it looks too American to us so we use
> "-ise" even where it *is* wrong; thus it ends up becoming right.)
localization is the spelling given by the OED, so it is correct in all
locales. It doesn't even list localisation as an alternative spelling.
The -ise form here is purely a reaction to American spelling, it's not
actually right.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Re: Upcoming Section changes in the archive
On Fri Feb 27 02:00, Enrico Zini wrote: > Putting java libraries into 'java' instead of 'libs' would just make > it harder for a package manager to hide libraries. Debtags will work > for that, so no big deal, but at the moment 'libs' is nice because it > allows me to auto-tag packages from that section, based on reliable > information provided by the maintainers. Should Java libs be in lib or libdevel (they are both). This is one of the reasons we've wanted a Java section. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon Mar 02 22:36, Bill Unruh wrote: > Are you claiming that he does/did not have the right to release the major > portion of the code under CDDL? (ie those portions that he did release in that > way?) Ie, that he did not have the permission of those other copyright holders > to thus release the code? Merely stating, I believe, that he would _need_ all of those other copyright holders to relicesce their sections of the work in the same manner each time he wants to change the licence and so saying that he is the sole copyright holder is a slight simplification. Speaking as a dbus contributor, which recently tried to relicense, it's really quite hard to get hold of everyone in order to do this (we failed). This is why the FSF insist you grant them the copyright on any patches you submit. >> The problem is fairly clear; the combination of GPLed and CDDLed code >> is not distributable. Whether Joerg will agree with that statement of >> the problem is unlikely, but that's not really our problem anymore. > > This is again far too broad a statement. Debian does distribute a > combination of GPL and many other code licenses which are not GPL-- if > they apply to separate and different programs. I am trying to narrow > down the problem. So again, is the issue the linking of mkisofs with > libscg? The problem is with the linking. Debian is allowed to ship non-linked CDDL (or other) software on the same media as GPL software (the 'mere aggregation' clause) and link GPL fundamental system libraries such as libc to non-GPL software (the 'system libraries' clause), but it is not allowed to link anything against GPL software unless the resulting work as a whole can be distributed under the terms of the GPL. This means that works licensed under the BSD, MIT, expat etc licences can be linked against GPL works because they can be distributed under the terms of the GPL without violating their own terms of distribution. You cannot distribute a CDDL work under the terms of the GPL without violating its licence. As you say, most of cdrecord is pure CDDL and there is no issue with that at all (assuming the above agreement of all copyright holders. As you say, we generally have to trust upstreams about this). The issue is specifically with the combination of a GPL-only mkisofs with a CDDL-only libscg. If Jorg were to dual-license either of them (again, see relicensing) then we could distribute the result under the terms of whichever licence they shared (and it doesn't really matter which). However, I'll repeat the clause that this would merely make it possible for us to distribute. It still requires a maintainer who will work with Jorg, who has been hostile in the past about things like patching his software and working with the Linux kernel rather than insisting everything be done like solaris. Debian routinely patches software it ships for many reasons and this is unlikely to change with cdrecord. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue Mar 03 00:58, Bill Unruh wrote: > I understand this as well. That is a however a different issue than the legal > one. It at least opens the possibility, both for Debian and for the many other > Linux distributions. And relieving the Debian maintainers > from having to try to keep up to date with new and old hardware, which > Schilling has > proven himself to be willing to do, is an attraction which may help make up > for > other detractions. It has been said that Debian is used to working with > ornery writers. > OK, I've been convinced by this thread that it might be useful to have cdrecord in Debian. So, here is a suggestion of compromise. I am willing to sponsor a package of cdrecord into Debian, _providing_ the following conditions are met: - someone who uses it (such as yourself or Michelle) volunteers to be the maintainer and work with Jorg - the packaging meets my (fairly high) standards - Jorg licenses his software in a fashion which is acceptable to Debian (which will certainly require resolving the GPL/CDDL conflict in mkisofs. I'm not the person who can give an authoritative answer on this though, it will require ftp-master being happy with the licence). - the package, maintainer and Jorg work alongside wodim. This means: - it conflicts: with wodim if required - Jorg ceases complaining about wodim and its maintainers in any way, stops telling wodim users they should be using cdrecord, stops posting to debian or other mailing lists or BTSs claiming that it's buggy, violates copyright law or similar and stops threatening anyone with the possibility of legal action who is involved with it. Basically 'play nice'. - Don't complain if frontends are migrated to wodim instead of cdrecord (of course, if wodim continues to ship a compatibility symlink, they could use whichever is installed). - Jorg doesn't complain about our packaging practices. Yes we will patch your software if it needs it. Please do not complain about things filed in _our_ BTS telling people to use the upstream version (for example). - We are not going to do anything about the previous situation to salve Jorg's pride, we won't expel Eduard or recant anything that was said before. I still think Jorg was wrong, but I do think it's potentially useful to have cdrecord in Debian. - (this list is not exhaustive) I don't have the time to package it myself (and I'm happy with wodim, so don't need to use it), however, I'm prepared to sponsor a package if Jorg plays nice (and I will, of course, try to do the same in return), but if not I'll just have it removed again. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue Mar 03 11:07, Joerg Schilling wrote: > The rules of the GPL end at "work" limit and neither libc nor > libschily or libscg are part of the "work" mkisofs. For this reason, > there is no problem with the fact that mkisofs links against libschily > and libscg. The FSF certainly believes (and I think it is supported by at least US copyright law) that the complete work of mkisofs linked against libschily and libscg (i.e. the binary form, rather than the source) is a single work which is a derivative work of all three individual (source) works. Therefore, it must be distributed under terms which are compatible with the licences of all three. You may disagree with this stance, however, it is a view which Debian holds. Maybe that's just us being too cautious, but we are by nature cautious and that isn't going to change. We do a lot of work and distribution in the US. You may also think that it _is_ possible to distribute under terms which satisfy both the CDDL and GPL. There is certainly enough doubt about this that again, we are being conservative in our interpretations. Finally, to address your other point that the above view would make the whole of Debian undistributable: this is where both the system libraries clause comes in (which libscg doesn't meet) and also the fact that libc is LGPL and the kernel is GPLv2+exception come in. Anyway, Debian is not obliged to distribute your software. We have deliberately conservative interpretations of copyright law and licences which is unlikely to change. If you want us to distribute it you'll have to do so under a licence we're happy with. This wouldn't be the first time we've disagreed with people about the freeness of a licence... Matt. -- Matthew Johnson signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue Mar 03 13:38, Joerg Schilling wrote:
> Repeating false claims does not make them correct.
Repeating that correct claims are false does not make them false.
There is enough weight on the side that I have described that I believe
it is in Debian's interest to follow them. After all, if we are wrong
this way round we just miss out on some software. If we are wrong the
other way round we might get sued.
Particularly in the case of cdrecord, I don't believe there is enough of
a case that we absolutely must have it that we should take a risk on the
licensing. If, on the other hand, you want your software in Debian, you
need to take into account our point of view. After all, surely you agree
that there is no problem with dual-licensing libscg? So what does it
cost you? If you are not interested in having it in Debian then I'm
unclear why you are posting to our mailing lists...
> Do you really like to tell us that compiling:
>
> main()
> {
> printf("hello world\n");
> }
>
> makes libc a derived work of the program "hello world"?
No, I am saying that the resulting binary of libc linked with hello
world is a derivative work of both libc and hello world. You seem to
have overlooked that in my previous post. There are three works here:
- the source of libc (licence A)
- the source of hello world (licence B)
- the resulting binary containing both libc and hello world (licence A+B)
This is obviously the case with static linking, the FSF hold that
dynamic linking is equivalent.
Matt
--
Matthew Johnson
signature.asc
Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue Mar 03 14:14, Joerg Schilling wrote: > Attacks from Debian against the cdrtools project caused the license to be > changed. Debian now needs to live with this change. We do live with this change. We don't have cdrtools in the archive, this is how we live with such changes. I've told you what I'll do to help this situation. Whether or not you agree with it, not doing that will not get cdrtools in Debian. If you don't want to do this then we really aren't interested in your software and I don't see why you are posting on our mailing lists! I have nothing else to say on the subject. My offer still stands. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Thu Mar 05 17:23, Russell Coker wrote: > PS What contributions are you making to any free software projects? Please > note that trolling this mailing list doesn't count as a contribution. I think you're being a little harsh Russell, but you're right Bell, I don't think anyone anywhere disagrees that the copyright on program source also applies to the binary form of the program, or to other forms it may be converted into. Otherwise I would be able to pirate Microsoft office without it being illegal. After all, I'm not copying the source. Ditto with other forms of non-text works, I don't think any judge in the world would consider the mp3 of the latest hits any less copyrighted than the original and that's even a lossy transformation. It therefore follows that any binary inherits the copyright of all the source components which went to create it, otherwise I could clearly steal anyone's work merely by adding enough useless code to it. Hence we reach the same conclusion that Debian did some time ago. matt -- Matthew Johnson signature.asc Description: Digital signature
Re: To the aqualung NMUer....
On Tue Mar 10 14:45, Clint Adams wrote: > On Mon, Mar 09, 2009 at 02:22:34PM -0700, Don Armstrong wrote: > > This would definetly be useful, as it would help someone from wasting > > time preparing the NMU in the first place, but it certainly doesn't > > excuse making NMUs without notifying the maintainer beforehand. > > If the maintainer can't be bothered to respond to a bug report, the > maintainer doesn't deserve any kind of notification. Wrong, on so many levels. Ignoring the fact that two wrongs don't make a right... We have individual maintainership and whether that is good or bad it means the maintainer can assume by default that he's the only person working on the package and making uploads. We have exceptions to this, which is good, but they are _exceptions_ and therefore need notification. Yes, the maintainer should respond to the bug report and yes he* should mark the bug as pending, but forgetting this step in no means justifies an NMUer doing the same. NMUs should _always_ be posted to the bug log _before_ upload and ideally before any work is done. That should be an absolute requirement and I will vote against any proposal which doesn't require this. If you want to be nice, you should give the maintainer time to respond before doing this and file patches etc (as suggested in the dev ref...), but for things which are 0day NMUable that's obviously not always practical. Matt * insert pronoun as required -- Matthew Johnson signature.asc Description: Digital signature
Re: How to depend on 32bit libs on amd64? (and what to do with ia32-libs)
On Mon Mar 30 17:20, Roger Leigh wrote: > With multiarch, it's a different story, but we aren't quite there yet. > Multiarch is definitely the right way to handle this and I think we should were possible be putting effort into that and not hacks. I still am not clear what the holdups are with multiarch. What is there that people like myself and the ia32-libs guys can do to get it working? I would really like to see it in squeeze if that's possible. Matt -- Matthew Johnson signature.asc Description: Digital signature
Bug#522616: ITP: live-f1 -- Formula 1 live timing
Package: wnpp Severity: wishlist Owner: Matthew Johnson X-Debbugs-CC: debian-devel@lists.debian.org Source package: live-f1 Binary package(s): live-f1 Version: 0.2.7-1 Licence: GPL-2 Author: Scott James Remnant Homepage: Description: Formula 1 live timing Command line program for monitoring live timing from Formula 1 races. Requires a free account on the Formula 1 website. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: "Team uploads"
On Mon Apr 06 08:18, Lionel Elie Mamane wrote: > On Mon, Apr 06, 2009 at 11:52:54AM +0800, Paul Wise wrote: > > > In Debian we have several teams working on maintaining large numbers > > of packages (pkg-games, pkg-perl, pkg-gnome for example). I > > proposed[1] to silence the lintian NMU warnings in the case of "team > > uploads"; where the person doing the upload is a member of the team > > in Maintainers but is not present in Uploaders. Does anyone think > > this concept of "team uploads" has merit? > > It is a useful concept, but I would like to consider them as "special > case NMUs" rather than "special case MUs". Quite apart from the issue of deciding whether or not something is 'team maintained' in all cases, if you are a member of the team and you are making uploads to the package, then you should just add yourself to uploaders, surely...? That said, the option so far which is least bad is "Team Upload" in the same way as "QA Upload", i.e. no NMU version number, no NMU procedures, no delay, etc, just something to ack the mismatch of changed-by and uploaders/maintainer. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: lilo about to be dropped?
On Mon Apr 06 08:55, Frans Pop wrote: > > This is a heads up mail for the D-I team. > > I'm not sure where the original mail comes from, but IMO this should be > discussed on d-devel, especially since it impacts more than just D-I. I > suspect there are quite a few packages that make some sort of provisions > for lilo. > There are also significant numbers of people still using lilo for, at > least for them, very good reasons. Yes, please do discuss it here. I am one of those users, grub didn't work on one of my machines for some reason. Anyway, isn't grub1 equally unmaintained upstream? I thought they were only working on grub2 (which isn't ready for use yet, or is it?) > > Don't we have some install paths that still depend on LILO? > > Yes: /boot on LVM is the main one. We _certainly_ shouldn't throw it out if there are _known_ situations for which it's required. By all means print large warnings or only make it available in expert mode, or whatever, but please don't break existing functionality. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: lilo about to be dropped?
On Mon Apr 06 11:07, Goswin von Brederlow wrote: > > So lets get grub2 working everywhere. :) A worthy goal. > Sure, but don't remove lilo until we're happy that grub2 does work everywhere. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: "Team uploads"
On Tue Apr 07 10:38, Charles Plessy wrote: > so in the end, can we use the “ * QA upload.” special first line for > non-uploader uploads without breaking the QA infrastructure? That's wrong if the maintainer is not debian...@lists. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: "Team uploads"
On Tue Apr 07 23:21, Gunnar Wolf wrote: > In the pkg-perl group, at least, it is not at all uncommon that a team > member (usually not a DD) works on a package and tags it as ready for > upload. And then a DD just comes along, checks it, builds and uploads > - without having worked with it. It is not precisely a sponsored > upload, but a team activity for both. So, yes, we have usually worked > aroud it by adding both the people who did the work and the DD to > Uploaders: In that case, I'd just treat it as a sponsored upload, since the DD won't be in the changelog trailer. That's certainly what I do with pkg-java. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
On Tue May 05 20:07, Iustin Pop wrote: > Scenarion A, desktop > - / on non-LVM, fixed size, as recovery from a broken LVM setup is way > harder if / is on LVM > - /usr on LVM, as it can grow significantly, and having it on LVM is > much more flexible This is what I do on all of my machines -- Matthew Johnson signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
On Thu May 07 00:38, Stefano Zacchiroli wrote: > > What about the (many) arguments made here about the *other* reasons to > > have /usr a separate filesystem? > > I've nothing against them, I was countering only this precise > argument. FWIW, I haven't seen that many, though the one about > read-only /usr was appropriate. More to the point, has anyone actually presented any real arguments why _not_ to allow it? I've not actually seen anything other than the OP saying "things might need changing to support it" and then refusing to go into detail. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Raising minimum CPU requirement for i386 kernel
On Sun May 24 19:41, Otavio Salvador wrote: > On Sun, May 24, 2009 at 4:07 PM, Bastian Blank wrote: > > Hi folks > > > > I would like to raise the minimum CPU requirement for the shipped Linux > > kernels in the i386 port to i686 (with cmov). For now I will not propose > > a change of the default machine type setting used by the compiler. > > Raise it is non-sense. I know of many people that actively use > machines that will lose support in this case. I concur, I think you are dropping too many CPUs that are actively used. It wasn't that long ago that we dropped 386 support, and non-686 CPUs have been made (relatively) much more recently (due to things like the Via and other cheap alternatives to Intel/AMD). > I'm quite curious to know what is the reason for that? > > I think we could possible change the default kernel available on full > CD set (if we provide an alternative image for usage by those old > machines) and I'd also support it not being available for all > installer flavours but I do think we can't just drop support for those > machines. Can't d-i autodetect CPU features and install a -686 kernel where appropriate? Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Raising minimum CPU requirement for i386 kernel
On Mon May 25 15:03, Goswin von Brederlow wrote: > And how many people with such low power systems do run popcon? How > many use a custom kernel? Oh, I'm sure the numbers aren't very accurate, but I don't think that disproves his point. They're probably not going to be out by a factor of 60... Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Naming convention for Java gluelib ?
On Mon Jun 08 18:12, Mathieu Malaterre wrote: > Hi there, > > I could find the naming convention for C# binding: > > http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning > > I am now looking for a similar page for a library that would be > wrapped in Java. What would be the convention for a foo.jar requiring > a gluelib lib.so ? Hi, this is one of the things I'd like to review at debconf this year since I think this whole area needs reviewing. http://www.debian.org/doc/packaging-manuals/java-policy/ exists, which says: "If a Java library relies on native code, the dynamic libraries containing this compiled native code should be installed into the directory /usr/lib/jni. These dynamic libraries should be shipped in a separate architecture-specific package named libXXX[version]-jni. The package containing the Java bytecode (generally libXXX[version]-java) should depend on this package." which doesn't say much about file naming. A quick sample of the archive shows at least: libfoo-java.so, libjfoo.so, libfoojni-fullversion.so so, at the moment there's not really a standard. I've CC'd debian-java in case anyone there isn't reading debian-devel. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: RFS: kernelcheck
On Sat Jun 20 09:28, David Paleino wrote: > Now that I read Ben's mail again, I see that his concern is also about the > Maintainer field. I suppose that should be a real name too then? Or is it ok > having a pseudonym because it's the sponsor taking responsibility for > the upload? (given that using this pseudonym he won't ever become a DD/DM) Sponsors take responsibility for the upload, so this should be fine. Also, going back to the note about reputation; There's no reason reputation can't be associated with a pseudonym or with a GPG key attached to a pseudonym. Anyway, I have no idea whether my sponsorees who I have never met and haven't gone through ID check are using their real names. If I don't care about that, why should I care about someone who is using a pseudonym that doesn't look like a real name. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: RFS: kernelcheck
On Sat Jun 20 10:19, David Paleino wrote: > > Also, going back to the note about reputation; There's no reason > > reputation can't be associated with a pseudonym or with a GPG key > > attached to a pseudonym. > > How do you sign such a key? You'd break the web of trust, if you don't check > at > least one government-issued document having a photo. And I can't make people > associate my GPG key uid "hanska" with my document saying "David Paleino" -- > even if they know that *I* am hanska (IRC, website, [..]). > > And having a key not signed by anyone seems rather useless :) (/me remembers > his problems getting a GPG signature...) Why would I sign the key, I don't sign the keys of people I sponsor. I'm not saying that I've checked the key belongs to the person it claims to, just that it's probably the same person each time and therefore reputation can build up around it. In the same way that reputation builds up around the people who post under their real name in Debian forums, but aren't DDs and haven't gone through ID check. > > Anyway, I have no idea whether my sponsorees who I have never met and > > haven't > > gone through ID check are using their real names. If I don't care about > > that, > > why should I care about someone who is using a pseudonym that doesn't look > > like a real name. > > That's the point, "haven't gone through ID check". He could well maintain his > package in Debian, just because he's not responsible for the upload. Yeah, that was my point (-: If he's happy to be sponsored all the time, he can be maintainer or upstream. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: libswt and eclipse
On Thu Jun 25 09:55, Adrian Perez wrote: > Hello list. > > I'm almost finished packaging libswt-gtk-3.4.2, since eclipse is > orphaned and I've tried contacting libswt and azureus maintainer > without results, I'm a pretty bit loss in here, since I want the new > version be included in debian. Any tips? (CCing debian-java as well, since that's where java packagers tend to work) He Adrian, that's great news. Even as not a Debian Developer you can maintain packages in Debian, you just need to find a Debian Developer happy to sponsor your package when you need it uploading. debian-mentors or the developers interested in the relevant areas are the best place to start. For Java things I would be happy to sponsor. If you upload the source package (.dsc, .diff.gz and the orig.tar.gz) somewhere and send me a link I should be able to have a look. If you don't have anywhere to upload it I suggest mentors.debian.net. Matt -- Matthew Johnson signature.asc Description: Digital signature
