Re: RFS: ipset
On Fri, Jan 27, 2012 at 9:31 PM, Paul Wise p...@debian.org wrote: On Sat, Jan 28, 2012 at 7:24 AM, Joseph R. Justice wrote: wouldn't it be more reasonable to use 3.0.y as the next Debian stable release's kernel? I mean, sure, if many of the other major Linux distributions, the ones which can be considered as peers to Debian in terms of importance, collectively decide to use a different, later kernel version for their next stable release, it would make sense to use that kernel for Debian's next stable release of course, since it allows the effort of maintaining the kernel to be shared between distributions (at least to some extent). But, failing that, why not use the one that has the imprimatur of the existing defacto stable kernel maintainer? Please refer to this thread: http://lists.debian.org/debian-kernel/2011/12/msg6.html http://lists.debian.org/debian-kernel/2012/01/msg00254.html If you have more questions about that, please ask the Debian Linux kernel team. I read those threads. I see they're considering the points I'd raised (and others I hadn't, as well). Fair enough; can't ask for more than that. Thanks for the pointer! (I don't currently receive that list, d-kernel.) Joseph -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC58tq-__OY1aLBM6ys2DP=wkffbqjrntcmzc3pyzbjjerq...@mail.gmail.com
Re: RFS: ipset
On Fri, Jan 27, 2012 at 2:06 PM, Henrique de Moraes Holschuh h...@debian.org wrote: On Fri, 27 Jan 2012, Nikolai Lusan wrote: I guess the major issue at this point would be the kernel that will ship with the next release, if it is set to be a 3.0 or newer kernel then it shouldn't be an issue (similar to things like iptables itself or tools like vlan). For the next Debian stable (wheezy) it will be either 3.2 or an even newer kernel than that. Given Greg K-H's blog post Stable kernel tree status, January 9, 2012 (http://www.kroah.com/log/linux/stable-status-01-2012.html) where he writes: Here's the different active kernel versions that I am maintaining at the moment: [...] 3.0.y - this is the new longterm kernel release, it will be maintained for 2 years at the minimum by me. wouldn't it be more reasonable to use 3.0.y as the next Debian stable release's kernel? I mean, sure, if many of the other major Linux distributions, the ones which can be considered as peers to Debian in terms of importance, collectively decide to use a different, later kernel version for their next stable release, it would make sense to use that kernel for Debian's next stable release of course, since it allows the effort of maintaining the kernel to be shared between distributions (at least to some extent). But, failing that, why not use the one that has the imprimatur of the existing defacto stable kernel maintainer? Hope this is of some use, interest. Thanks for your time. Be well. Joseph -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC58tq-ejO0r75_g6y6uajApF6WRKnVXWijiKP5=yoxfdlg...@mail.gmail.com
Re: RFS: tk-table
[I am not a DD, a DM, an experienced packager of any sort, or able to provide any review of this package at all. I'm just following the debian-mentors list. -- J] On Fri, Jan 20, 2012 at 4:42 AM, Ole Streicher debian-de...@liska.ath.cx wrote: I am looking for a sponsor for my package tk-table. * Package name : tk-table Version : 2.10-1 Upstream Author : Jeffrey Hobbs j...@hobbs.org * URL : http://tktable.sourceforge.net * License : BSD Section : interpreters It builds those binary packages: tk-table - Table extension for Tcl/Tk This is a kind of adoption of the package tktable2.9 (binary package libtktable2.9) which was orphaned since 2008 and removed from unstable in Feb 2011. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465957. It is needed in order to bring the astronomical package saods9 back into Debian (ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655648). I put tk-table under the maintenance of Debian-Science. I would be glad if someone uploaded this package for me. I would also very appreciate a review without an upload since I am not familar with tcl/tk and therefore I am unsure about whether the package fits into the Debian tcl/tk subsystem. I would suggest that a more obvious and natural fit for a maintenance home for this package would be: Debian Tcl/Tk Packagers - mailto:pkg-tcltk-de...@lists.alioth.debian.org QA Page - http://qa.debian.org/developer.php?login=pkg-tcltk-devel%40lists.alioth.debian.org Mail Archive - http://lists.alioth.debian.org/pipermail/pkg-tcltk-devel/ Just from the short description, it sounds to me like tk-table is more of a general purpose and utility sort of Tk package, and not something of interest uniquely to someone doing science type work; just from their name, Debian Tcl/Tk Packagers sound like the sort of group interested in general purpose and utility Tk packages. Also, the Tcl/Tk Packagers would be the obvious source of information on how to fit this package into the already existing Tcl/Tk ecosystem within Debian. (They might even have a language-specific policy and packaging guide; I haven't looked.) FWIW, I found this by searching the Debian package archive (http://www.debian.org/distrib/packages) for package names including tk, and seeing who the maintainers of those packages were, in case you wanted to know how I found this. I had not previously known about this group within Debian. Thanks for your time. Hope this is of some use, interest. Good luck with getting this package and the one depending on it into Debian. Be well. Joseph -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC58tq-PZ2aYdHvLfr0gKgB19Vj1TeZRF23XcmEZ1mre...@mail.gmail.com
Re: RFS: mobile-broadband-provider-info (updated package)
On 11/23/11, Paul Wise p...@debian.org wrote: On Sun, Nov 13, 2011 at 9:55 PM, Bhavani Shankar R wrote: Regarding watch file I'm a bit skeptical as its a package which has regular commits upstream and requires frequent updation of the package in the archives I think personally and using the ftp site for the tarball location in watch file could lead to confusions with the versions in the archive. And if the watch file is removed lintian throws up error. So Antii (marked in CC) can pitch in I guess. This is why I think packaging it at all is possibly a bad idea since people running Debian stable/oldstable will always have old information. It would be better if the software that uses it were to be responsible for downloading it periodically. [Kerrect speeling note: Instead of updation of, I probably would have written updates [of/to].] Wouldn't this combination of factoids [(1) that the package has regular commits upstream of important data contained within the package, (2) that the package therefore needs to be frequently updated to get the new data from upstream incorporated into the package, and (3) that these updates need to be made available to people running Debian stable and oldstable without requiring those people to install a version of this package from testing or unstable] therefore suggest that this package is a candidate for debian-volatile (or whatever that is called these days)? I've been subscribing to the applicable Debian announcement mailing list (debian-volatile-announce@lists.d.o) for a little while now, and I see mention of updates to tzdata and clamav. Looking at http://lists.debian.org/debian-volatile-announce/2011/msg0.html , I guess it's now called squeeze-updates, not debian-volatile. However, the point still stands: This suite will contain updates that satisfy one of the following criteria: [...] * The package in question is a data package and the data must be updated in a timely manner (e.g. tzdata). As for if there should be a watch file, or what the watch file should be if there should be one at all, that I do not know. (Is there a facility / capability yet for watching for changes to a git / bzr / hg / svn / cvs / etc archive, and should that facility be used instead for this package instead of watching a (relatively) static tarball file if the facility is available for use?) Thanks for your time. Hope this is of some use, interest. Joseph -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cac58tq8d1wk_zwfc562jbdlpzgvh1wyjsjlhxrmuccq1lty...@mail.gmail.com
Re: RFS: mobile-broadband-provider-info (updated package)
On 11/24/11, Bhavani Shankar R bh...@ubuntu.com wrote: On Thu, Nov 24, 2011 at 9:06 PM, Joseph R. Justice jayare...@gmail.com wrote: On 11/23/11, Paul Wise p...@debian.org wrote: On Sun, Nov 13, 2011 at 9:55 PM, Bhavani Shankar R wrote: Regarding watch file I'm a bit skeptical as its a package which has regular commits upstream and requires frequent updation of the package in the archives I think personally and using the ftp site for the tarball location in watch file could lead to confusions with the versions in the archive. And if the watch file is removed lintian throws up error. So Antii (marked in CC) can pitch in I guess. This is why I think packaging it at all is possibly a bad idea since people running Debian stable/oldstable will always have old information. It would be better if the software that uses it were to be responsible for downloading it periodically. Wouldn't this combination of factoids [(1) that the package has regular commits upstream of important data contained within the package, (2) that the package therefore needs to be frequently updated to get the new data from upstream incorporated into the package, and (3) that these updates need to be made available to people running Debian stable and oldstable without requiring those people to install a version of this package from testing or unstable] therefore suggest that this package is a candidate for debian-volatile (or whatever that is called these days)? I've been subscribing to the applicable Debian announcement mailing list (debian-volatile-announce@lists.d.o) for a little while now, and I see mention of updates to tzdata and clamav. Looking at http://lists.debian.org/debian-volatile-announce/2011/msg0.html , I guess it's now called squeeze-updates, not debian-volatile. However, the point still stands: This suite will contain updates that satisfy one of the following criteria: [...] * The package in question is a data package and the data must be updated in a timely manner (e.g. tzdata). I was thinking of uploading regular stable release updates both in debian and ubuntu. I'll work on this regard coming weekend. Thanks for all inputs and support. Cool. I don't know the process for getting a package qualified to be considered under the squeeze-updates policy, but that sounds like what you (and/or the DD who sponsors your uploads of this package) want to look into, at least down the road. As for if there should be a watch file, or what the watch file should be if there should be one at all, that I do not know. (Is there a facility / capability yet for watching for changes to a git / bzr / hg / svn / cvs / etc archive, and should that facility be used instead for this package instead of watching a (relatively) static tarball file if the facility is available for use?) Yes the package does have a git handle: http://git.gnome.org/browse/mobile-broadband-provider-info/ but there is nothing as such as a static tarball on the site. Need more clarity on this. Well, I'm not involved in packaging for Debian at all, just standing on the sidelines, so I could be All Wrong about the following. But... I have the impression that the watch files being talked about elsewhere in this discussion _typically_ refer to a distinct file or files of some sort, which can be obtained via anonymous ftp / http / etc, and which have a distinct version of some sort, be it something embedded in the file name, or a file time stamp, or whatever. And, watching that file, changes to its file name, changes to its time stamp, etc is what's used to determine if a Debian package is up-to-date in terms of its version with respect to the version of the original source the Debian package is derived from. If what you are packaging here does not have a distinct file of some sort that can be used to determine the version of the original source, but a worthwhile version of some sort can be derived from the source version's Git handle, and if that Git handle can be used by the Debian watch file mechanisms to automatically determine when the Debian package's version is out of date with respect to the original source file, then it seems to me that this is what should be done. Now, _if_ one can do this, and if how _how_ one does this, I do not know. But, that seems to be the question that needs to be answered. Thanks for your time. Hope this is of some use, interest. Joseph -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC58tq_R3LH1zP7O8cQ772zdtcKjSM7WfU=dxhfenunbp9i...@mail.gmail.com
Re: RFS: open-axiom
On 8/29/11, Игорь Пашев pashev.i...@gmail.com wrote: 2011/8/29 Joseph R. Justice jayare...@gmail.com interpsys would be a Build-Depends of some sort for OpenAxiom then, No, interpsys is a part of OA sources and used only for building. As I said before, one can think of it as of libtool or similar. OK. I wondered, because in ... mail from David Bremner brem...@debian.org dated Sun, 28 Aug 2011 12:00:38 -0300, message-id 87k49xy415.fsf@zancas.localnet, he claimed interpsys isn't included in the open-axiom source package (assuming I read his message correctly). That's why I wondered where interpsys was coming from. Perhaps Mr. Bremner was mistaken, however. (Talking about my concerns about SBCL core being included within OpenAxiom, without OpenAxiom run-depending on SBCL): Might this cause a problem for someone down the line? I'm thinking of something along the lines of, a bug (possibly a security-related bug) is found in SBCL (possibly by SBCL upstream), in the portion that is duplicated inside of OpenAxiom, and is fixed in the SBCL package itself within Debian. AFAIK this is how most lisp compilers work: include its core into resulting binaries. OK, I think I understand. I saw (IIRC) that OpenAxiom Build-Depends on SBCL. Without having previously done Debian packaging... I presume that means that if SBCL has a security-fix of a sort that would affect the portion of SBCL that is incorporated into stand-alone binaries created using SBCL (e.g. OpenAxiom), that when SBCL is patched and rebuilt, this will automagically force the rebuilding of all packages that Build-Depends on SBCL (e.g. OpenAxiom) without further human intervention, so that those packages will eventually incorporate the fix made to SBCL? Or, is this incorrect, and if so what needs to be done and/or who needs to be aware of this connection between OpenAxiom and SBCL such that if if there *is* a fix to SBCL that needs to be incorporated into OpenAxiom also, it will be duly incorporated into OpenAxiom either automatically and/or through manual actions being taken by whomever needs to take them? As an aside, I wonder if it would make some sense down the line to figure out how to library-ize this portion of SBCL core that is incorporated in OpenAxiom (and presumably also other stand-alone applications built using SBCL) so that it can be encapsulated and somehow packaged as an independent entity of its own that the various stand-alone applications depend on. Please note, I am _NOT_, in _ANY_ way, suggesting that this is something that *you* need to do for *this* package! That's fully out of scope for anything you should need to do, I'd think; I'm sure it's something that needs to be taken up by the upstream developers of SBCL and the various independent applications that are built using SBCL, and by the various major distributions as a whole (e.g. Debian, Ubuntu, Fedora/Red Hat, SUSE, maybe some of the others like Gentoo and Slackware, and by the non-Debians such as the various BSDs, OpenSolaris, etc), and possibly by the other major Lisps out there that are peers of SBCL (and which the independent applications might make use of instead of using SBCL). Again, thanks for your time. Hope this is of some use, interest. Joseph -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAC58tq-JSLMNyjmVRHwQFddSTXPzD=srh11g_sfevkjt3tp...@mail.gmail.com
Re: RFS: open-axiom
On 8/28/11, Igor Pashev pashev.i...@gmail.com wrote: 28.08.2011 19:00, David Bremner пишет: Without having looked at all at your package (and, note, I am purely a random bystander, not a mentor or packager or anything): I'm not sure if open-axiom uses this feature (and I notice sbcl itself also has broken #! lines in it's fasl files. In your case, I suspect the upstream build process is putting the wrong path into the #! lines. interpsys isn't installed by debian sbcl and it isn't included in the open-axiom source package. interpsys is a main tool to build OpenAxiom, it is not requred to run OA. One can think of it as of libtool or similar. interpsys would be a Build-Depends of some sort for OpenAxiom then, I assume? I do not see it mentioned in open-axiom_1.4.1+svn~2299-1.dsc. (I peeked.) Is it packaged and/or available in Debian, then? (AO includes SBCL core, so SBCL itself is not required to run AO. And there is no problem to upgrade system SBCL :-) Might this cause a problem for someone down the line? I'm thinking of something along the lines of, a bug (possibly a security-related bug) is found in SBCL (possibly by SBCL upstream), in the portion that is duplicated inside of OpenAxiom, and is fixed in the SBCL package itself within Debian. Who is going to know, and how are they going to know, that the same bug (at least potentially) exists within OpenAxiom and needs to be found and fixed there, too? I realize this may not be feasible to address within the Debian package, it may have to be resolved by OpenAxiom upstream (assuming they are willing to do so). But, I read of problems various distributions (Debian, Fedora, etc) have with applications like Google Chromium (the open source version of the Google Chrome browser), where Google has chosen to include its own copy of many different software libraries within the source distribution for Chromium rather than use the distribution- / system-supplied version of these libraries, and each distribution has to decide how to address this decision by Google. What you describe above for OpenAxiom sounds like the same sort of thing, albeit on a much smaller scale. So... Thanks for your time. Hope this is of some use, interest. Joseph -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cac58tq90digthzrvkoacxrq0up+wiadspwdwmmqpc3qm4hx...@mail.gmail.com
