Re: amd64 as default architecture
On Mon, May 21, 2012 at 02:19:09PM +0800, Chow Loong Jin wrote: > > By the way, are there plans to drop the support of the i386 architecture > > with > > kFreeBSD as well ? > I thought we were discussing amd64 being the default architecture for new > installations, rather than the removal of the i386 architecture. Both. -- WBR, wRAR signature.asc Description: Digital signature
Re: removal of Qt3
On Mon, May 21, 2012 at 2:36 PM, Neil Williams wrote: > Does LSB matter? LSB is irrelevant to me personally since I'm mostly not interested in running proprietary software on Linux systems. I guess LSB must be relevant to Debian since we have it in Debian and even have a mailing list dedicated to it: http://lists.debian.org/debian-lsb/ Apparently LSB 5.0 will drop the Qt3 requirement: http://lists.debian.org/debian-lsb/2012/02/msg9.html -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6Eo8VHiukuziiON90MCefK3=mzx2oygarm7pty2bks...@mail.gmail.com
Re: debuild/dpkg-buildpackage behaves not as expected
Goswin von Brederlow writes: >>> If you need to change a file then that means that file isn't source >>> anymore but generated. Try switching to out-of-tree builds if you have >>> something like that. >> >> What is the advantage of that? From the Debian policy, I don't see a >> need why sources should kept untouched during the build process. > > Less surprises by someone unfamiliar with the source. For example: > > - you (as in some porter, not the maintainer) build the source to > reproduce a FTBS > - it fails as expected > - you edit the broken file > - you build again and it works > - you call clean so you can make a patch > - clean restores the original source file destroying hours of your > work If I would be unfamilar with the source, I would just not expect that the package behaves as I would do it myself. Instead, I would be ready for the case that it does tricky, undocumented things with the source -- and create the debian patch before I am going to build the package. Why should a porter expect more from a package than the requirements specified in the policy? >> It is just the better design: the package was built with a patched >> source, so only the patched version knows for sure how to clean it up. > Note that it only calls clean with unpatched sources if you > specifically unpatched your source before calling it. If you insist so much on this standard: why does debuild (or dpkg-buildpackage) undo the patches if they were not applied before? In this case, it would be up to the (rare) people to unpatch if they need this. One could even provide a debuild/dpkg-buildpackage option for that (like --unpatch-after-build or so), or do it in a hook. > So I think having the clean target make sure patches are applied if > needed is the better design. which again does not behave as expected: if "clean" depends on "patch", then after "debuild clean" the packages is in the "patched" state even if it was unpatched before. I think the best way would be that debuild/dpkg-buildpackage would not automatically unapply the patches (so it would leave the source in the way that is described as "standard" for Debian), with a special option or hook that does this for those who really need it (and know what they are doing). > I was describing the case of having changes commited to the RCS and > generating debian/patches/* automatically (or a single debian-changes > patch). A single debian-changes patch is evil -- even Lintian complains there. Handling a single debian-changes patch is something I would explicitely *not* take as a valid use case. Is there a way to automatically handle a bunch of individual patches trough an RCS? Best regards Ole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ytzzk926l53@news.ole.ath.cx
Bug#673758: ITP: scilab-metanet -- Scilab graphs and networks computations module.
Package: wnpp Severity: wishlist Owner: Sylvestre Ledru * Package name: scilab-metanet Version : 0.4 * URL : http://forge.scilab.org/index.php/p/metanet/ * License : CeCILL Programming Lang: Scilab, fortran, etc Description : Scilab graphs and networks computations module. A number of algorithms solving classical graph problems and minimal cost flow network are provided in this module. This extension is fully integrated in the Scilab environment and provides display and interaction on graphs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521092550.21251.65054.report...@korcula.inria.fr
SV: Moving the target of localization pokes (and eventually NMUs)...
pages doesn't seem to have been updated since may 2 ? bye Joe Danish - Original meddelelse - Fra: Christian PERRIER Til: debian-devel@lists.debian.org; debian-i...@lists.debian.org Cc: Sendt: 7:29 mandag den 21. maj 2012 Emne: Moving the target of localization pokes (and eventually NMUs)... With the final steps of the release of Wheezy approaching, I will, from now on, move the focus of my l10n attention to packages that are blocking some of the localization goals. One of them is 100% completeness for debconf translations in wheezy for seven languages: Czech, Swedish, Spanish, Portuguese, German, Russian and French. As a consequence, I will now be nagging *hardly* the maintainers of packages that are blocking this 100% completeness. These packages are listed on the following pages: http://www.debian.org/international/l10n/po-debconf/cs http://www.debian.org/international/l10n/po-debconf/sv http://www.debian.org/international/l10n/po-debconf/es http://www.debian.org/international/l10n/po-debconf/pt http://www.debian.org/international/l10n/po-debconf/de http://www.debian.org/international/l10n/po-debconf/ru http://www.debian.org/international/l10n/po-debconf/fr ...at the top of each page. For most, if not all, of them, there are pending translations in the BTS. Fortunately, all of these are recent enough, and I hope maintainers will be reactive to my pokes (if they aren't, then NMUs will be on their way..:-)). Packages that have something waiting in the BTS (I don't have info for Portuguese that isn't using the l10n tracking robot): postfixadmin (cs,sv,es,de,ru,fr) glance (cs,sv,es,de,ru,fr) xfonts-traditional (cs,sv,es,de,ru,fr) xsp (sv) auctex (es) lxc (es) gitalist (es) graphite-carbon (es,de,ru,fr) condor (fr) mumble-django (de,fr) dd-list of maintainers: Condor Developers condor Daniel Baumann lxc Davide G. M. Salvetti auctex Debian Mono Group xsp Debian VoIP Team mumble-django Dylan R. E. Moonfire xsp (U) Ghe Rivero glance (U) Ian Jackson xfonts-traditional Jo Shields xsp (U) Jonas Genannt gitalist graphite-carbon lxc (U) Jonathan Yu gitalist (U) Julien Danjou glance (U) Kilian Krause mumble-django (U) Michael Hanke condor (U) Michael Ziegler mumble-django (U) Mirco Bauer xsp (U) Norman Messtorff postfixadmin OHURA Makoto auctex (U) Patrick Matthäi mumble-django (U) PKG OpenStack glance Thomas Goirand glance (U) -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1337606026.91334.yahoomail...@web28415.mail.ukl.yahoo.com
Re: SV: Moving the target of localization pokes (and eventually NMUs)...
Quoting Joe Dalton (joedalt...@yahoo.dk): > pages doesn't seem to have been updated since may 2 ? Yes, I've been notified of this and I'm working on it. signature.asc Description: Digital signature
RE : Re: why do people introduce stup^Wstrange changes to quilt 3.0 format
gitpkg with quilt hook is very nice.
Have a branch with debian change, one for patch queue, one for upstream
Use git cherry pick for porting patch
I use it for imagemagick
Will post my workflow tomorrow I post from my phone, sorry for top post and
brievety
Bastien
Le 21 mai 2012 02:56, "Marco d'Itri" a écrit :
On May 18, Russ Allbery wrote:
> I do this work in cases where keeping the patches...
Some of my packages have 30-60 patches ("mature" software...), and
merging them would make them impossibile to understand.
Is there a VCS workflow which would make such packages easier to manage
than with quilt? (I like quilt, BTW.)
--
ciao,
Marco
Bug#673832: ITP: critcl -- compiled runtime in Tcl
Package: wnpp Severity: wishlist Owner: Andrew Shadura * Package name: critcl Version : 3.0.3 Upstream authors: Andreas Kupries Jean-Claude Wippler * URL : http://jcw.github.com/critcl/ * License : BSD Programming Lang: C, Tcl Description : compiled runtime in Tcl Critcl takes a snippet of C, generates Tcl interface, sends it to the compiler, and then dynamically links the code. Checksums are used to only recompile when needed, so the build overhead really applies only once. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521170420.22434.65795.reportbug@localhost.localdomain
Bug#673893: ITP: pegasus-wms -- Scientific workflow management system for Condor
Package: wnpp Severity: wishlist Owner: Mats Rynge * Package name: pegasus-wms Version : 4.0.0 Upstream Author : Pegasus Dev Team * URL : http://pegasus.isi.edu * License : Apache 2.0 Programming Lang: Java, Python, C Description : Scientific workflow management system for Condor The Pegasus project encompasses a set of technologies the help workflow-based applications execute in a number of different environments including desktops, campus clusters, grids, and now clouds. Scientific workflows allow users to easily express multi-step computations, for example retrieve data from a database, reformat the data, and run an analysis. Once an application is formalized as a workflow the Pegasus Workflow Management Service can map it onto available compute resources and execute the steps in appropriate order. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbaab62.70...@rynge.net
Bug#673906: ITP: pugl -- portable API for OpenGL graphical interfaces
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: pugl Version : 0~svn32 Upstream Author : Dave Robillard * URL : http://drobilla.net/software/pugl/ * License : ISC Programming Lang: C Description : portable API for OpenGL graphical interfaces Pugl is a minimal portable API for OpenGL GUIs which supports embedding and is suitable for use in plugins, but can also be used for programs. Pugl is vaguely similar to GLUT, but with some significant distinctions: * Minimal in scope, providing only what is necessary to draw and receive keyboard and mouse input. * No reliance on static data whatsoever, so the API can be used in plugins or multiple independent parts of a program. * Single implementation, which is small, liberally licensed and suitable for direct inclusion in programs if avoiding a library dependency is desired. * Support for embedding in other windows, so Pugl code can draw to a widget inside a larger GUI. * More complete support for keyboard input, including additional “special” keys, modifiers, and support for detecting individual modifier key presses. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521230111.12325.13813.reportbug@localhost6.localdomain6
Bug#673916: ITP: haskell-options -- Haskell library for parsing command-line options
Package: wnpp Severity: wishlist Owner: John Millikin * Package name: haskell-options Version : 0.1.1 Upstream Author : John Millikin * URL : https://john-millikin.com/software/haskell-options/ * License : Expat Programming Lang: Haskell Description : Haskell library for parsing command-line options The options package lets library and application developers easily work with command-line options. This package provides a library written in the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120522012522.31137.10774.reportbug@vm-debian7-i386
Bug#673920: ITP: python-rsa -- pure Python RSA implementation
Package: wnpp Severity: wishlist Owner: Daniele Tricoli * Package name: python-rsa Version : 3.0.1 Upstream Author : Sybren A. Stuvel * URL : http://stuvel.eu/rsa * License : Apache License 2.0 Programming Lang: Python Description : pure Python RSA implementation Python-RSA is a pure-Python RSA implementation. It supports encryption and decryption, signing and verifying signatures, and key generation according to PKCS#1 version 1.5 so it can also interoperate with OpenSSL. The package will be maintained under the umbrella of the DPMT and it's a dependency for the new version (0.1.3) of python-oauthlib. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120522024102.25715.15901.report...@mornie.home
sticky bit on devices
I've just noticed that a bunch of device nodes on my main system running Unstable now have the sticky bit set. Why is that? crw-rw---T. 1 root lp6, 0 May 18 23:47 lp0 crw-rT. 1 root kmem 1, 1 May 18 23:46 mem crw-rw---T+ 1 root audio14, 0 May 18 23:46 mixer crw-rw---T+ 1 root audio14, 16 May 18 23:46 mixer1 crw-rw---T. 1 root lp 99, 0 May 18 23:47 parport0 crw-rT. 1 root kmem 1, 4 May 18 23:46 port crw--T. 1 root root108, 0 May 18 23:46 ppp brw-rw---T. 1 root disk 8, 0 May 18 23:46 sda brw-rw---T. 1 root disk 8, 1 May 18 23:47 sda1 brw-rw---T. 1 root disk 8, 2 May 22 13:04 sda2 brw-rw---T. 1 root floppy8, 16 May 22 13:01 sdb crw-rw---T. 1 root dialout 4, 64 May 18 23:46 ttyS0 crw-rw---T. 1 root dialout 4, 65 May 18 23:46 ttyS1 crw-rw---T. 1 root dialout 4, 66 May 18 23:46 ttyS2 crw-rw---T. 1 root dialout 4, 67 May 18 23:46 ttyS3 crw--T. 1 root root 10, 223 May 18 23:46 uinput -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205221312.19219.russ...@coker.com.au
Re: sticky bit on devices
On mar., 2012-05-22 at 13:12 +1000, Russell Coker wrote: > I've just noticed that a bunch of device nodes on my main system running > Unstable now have the sticky bit set. > Google search seems to say that the question has already been asked and replied on debian-user http://lists.debian.org/debian-user/2012/02/msg01273.html Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: sticky bit on devices
On Tue, 22 May 2012, "Yves-Alexis Perez" wrote: > On mar., 2012-05-22 at 13:12 +1000, Russell Coker wrote: > > I've just noticed that a bunch of device nodes on my main system running > > Unstable now have the sticky bit set. > > Google search seems to say that the question has already been asked and > replied on debian-user > http://lists.debian.org/debian-user/2012/02/msg01273.html Why are some devices getting it but not others? /dev/ttyS? get the sticky bit even though the serial port driver is linked into the kernel and this issue is thus irrelevant (at least on amd64). /dev/watchdog is from the softdog module which can be unloaded but it doesn't have the sticky bit. Why is /dev/watchdog a good device to remove? /dev/sd* device have the sticky bit set, but they are removed when the hardware is removed (EG unplugging a USB flash device). Why is that? -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201205221614.27750.russ...@coker.com.au
