Re: Embedding jquery.js disaster
Thomas Goirand writes: > I wonder if someone should do a bug mass-filling... > > liblog4tango4-doc: /usr/share/doc/liblog4tango4-doc/html/api/jquery.js doxygen generated, is there an equivalent of dh_sphinxdoc for doxygen ? > python-guidata: /usr/share/doc/python-guidata/html/_static/jquery.js > python-guiqwt: /usr/share/doc/python-guiqwt/html/_static/jquery.js > python-spyderlib: /usr/share/doc/python-spyderlib/html/_static/jquery.js these are only symlink generated by dh_sphinxdoc thanks to Jakub Wilk :) Maybe the lintian warning tag about embeded jquery.js gives a better vue of the real problems. Inddeed this jquery.js multiplication need to be fixed. Cheers Fred -- GPG public key 4096R/4696E015 2011-02-14 fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015 uid Picca Frédéric-Emmanuel GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel -- 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/imwpq01u4ff@ord03037.synchrotron-soleil.fr
Re: Re: RE:RE:Ad-hoc survey of existing Debian git integration tools
Hello > > Yes and it is nice to have meta data (the dgit things) rerpresenting > > the packages which can be shared between derivatives. > I don't understand what you are referring to here. It seems to me but I can be wrong that the dgit informations stored under .git/dgit are sort of meta data which point to git ref corresponding to packages uploaded into Debian. Is it possible for dgit to allow pushing to another derivativ instead of Debian from the same repository ? > Are you saying that your source packages contain things that your git > repositories don't ? This comes up occasionally, and I will say again > what I have said before: I think this is wrong. Yes in my case I consider the configure.ac a source file, but not the configure script generated by autoconf. > You should have a single notion of `source code'. To borrow from the > GPL: the source code is the preferred form for modification. Exactly, the prefer form is the configure.ac and the makefile.am and not the Makefile or the configure script > Either the file (`configure', say) is part of your source code, in > which case it should be in the source package and in the git > repository; or it is not, in which case it should be absent from both. ok, so you just say that the git repository used by dgit-repo contain all the files that we obtain using dpkg-source to extract a usual debian package. We should call this an integration branch right ? > > So we need to agreed on a convention in order to let the upstream do the > > job of integrating their work in the Debian archive. > > Or at least to prepare something which could integrate the Debian archive > > in the end. > I don't understand. In fact I try to understand how we should use dgit at work in order to let developpers do the integration work by themself. We want to put the debian packaging in the upstream git repository and generate and push directly a package from this repository to either a local mini-build (PPA) or the Debian archive. > In git terminology, the tree objects in the dgit view contain the > upstream source code. > dgit should propose a sort of PR (via email) in order for the > upstream to propose the integration of its prepared package into the > repository. something which is done for now via mentors, maybe > I don't understand. I was thinking that an upstream should have work on his own PPA managed with dgit or new ppa tool, prepare internally a package then request for sponsoring this kind of tool should propose a sort of PR generator which should make it trivil to create a RFS RFS and send the email with all the informations necessary for a DD to review the code and uploading with just a dgit push. The way dgit get the proposed pacakge is indeed not clear :) > > does dgit propose to intégrate also the pacakges on mentors > I think you mean `are packages on mentors.d.n visible to dgit'. > The answer to that is `no they currently are not'. > The main part which is missing there is a git server suitable for this > use, but also the mentors workflow is rather unusual, because packages > uploaded to mentors.d.n are not in a suite in the same way as packages > in the archive. but we can apt-get them so they are available in a suite located in the mentors PPA ;) The history is not also linear, becasue you can upload two times the same package version but with different content. > It might be possible to in principle for dgit to present a view of > mentors. But, I wonder if that would be a waste of time. It would be > much simpler for the mentors and mentees to simply exchange git > branches and not bother with source packages at all. Except that I find it more convenient to get the source package and feed directly sbuild with this. this force the menteed to learn how to build a package. > The git branches could easily live on alioth (less of a security > problem than having the dgit repos on alioth, since the sponsor is > going to double-check them anyway). > I don't know what mentors and mentees would think of that. > mentors.d.n would need a way to represent a git-based sponsorship > request. Did we had some document or preliminary tought about how to integrate the packaging into uptream. something we should let them tought that the debian packaging is not something that difficult and can be part of their developpement effort. After all upsteam are integrating by them self into travis, readthedoc etc... It is e pity to see that Debian is not something where developpers thought they could host their code and integrate it into the platform. It seems to me that the debian packaging is something which looks like too complicate We should help upstream create a debian directory and integrate it into their developpement process. (continuous integration, ...) > If you are the maintainer of the package in Debian, and you are using > source format `3.0 (quilt)', then you have implicitly committed to > maintaining your packag
Bug#838742: ITP: haskell-hmatrix-gsl -- Numerical computation
Package: wnpp Severity: wishlist Owner: picca * Package name: haskell-hmatrix-gsl Version : 0.17.0.0 Upstream Author : Alberto Ruiz * URL : https://github.com/albertoruiz/hmatrix * License : GPL Programming Lang: Haskell Description : Numerical computation Purely functional interface to selected numerical computations, internally implemented using GSL.
Bug#843970: ITP: ufo-core -- Library for high-performance, GPU-based computing
Package: wnpp Severity: wishlist Owner: picca * Package name: ufo-core Version : 0.11.0 Upstream Author : matthias.vogelges...@kit.edu * URL : http://ufo.kit.edu/ * License : LGPL-3+ Programming Lang: C, Python Description : Library for high-performance, GPU-based computing The UFO data processing framework is a C library suited to build general purpose streams data processing on heterogeneous architectures such as CPUs, GPUs or clusters. It is extensively used at the Karlsruhe Institute of Technology for Ultra-fast X-ray Imaging (radiography, tomography and laminography). . A gobject-instrospection binding is also provided to write scripts or user interfaces.
Bug#844196: ITP: ufo-filters -- Set of plugins for ufo-core
Package: wnpp Owner: picca Severity: wishlist * Package name: ufo-filters Version : 0.11.0 Upstream Author : matthias.vogelges...@kit.edu * URL or Web page : http://ufo.kit.edu/ * License : LGPL-3+ Description : Set of plugins for ufo-core The UFO data processing framework is a C library suited to build general purpose streams data processing on heterogeneous architectures such as CPUs, GPUs or clusters. It is extensively used at the Karlsruhe Institute of Technology for Ultra-fast X-ray Imaging (radiography, tomography and laminography). . This package contains `average', `backproject', `bin', `blur', `buffer', `calculate', `camera', `clip', `contrast', `crop', `denoise', `duplicate', `fftmult', `fft', `filter', `flatten', `flip', `forwardproject', `gemm', `ifft', `interpolate', `loop', `measure', `merge', `metaballs', `monitor', `null', `opencl', `ordfilt', `pad', `read', `reduce', `refeed', `replicate', `rescale', `ringwriter', `sleep', `slice', `stack', `stdin', `stdout', `subtract', `transpose', `write' and `zeropad' plugins.
Bug#826456: ITP: python-qtconsole -- enhanced interactive Python shell - Qt console
Package: wnpp Severity: wishlist Owner: picca * Package name: python-qtconsole Version : 4.2.1 Upstream Author : Jupyter Development Team * URL : https://github.com/jupyter/qtconsole * License : BSD-3-clause Programming Lang: Python Description : enhanced interactive Python shell - Qt console IPython can be used as a replacement for the standard Python shell, or it can be used as a complete working environment for scientific computing (like Matlab or Mathematica) when paired with the standard Python scientific and numerical tools. It supports dynamic object introspections, numbered input/output prompts, a macro system, session logging, session restoring, complete system shell access, verbose and colored traceback reports, auto-parentheses, auto-quoting, and is embeddable in other Python programs. this packahe will be maintain under the Debian Python Modules Team umbrella It is necessary in order to do the ipython 2.x -> 4.x migration.
Bug#827609: ITP: python-fisx -- Quantitative X-Ray Fluorescence Analysis Support Library
Package: wnpp Severity: wishlist Owner: picca * Package name: python-fisx Version : 1.0.7 Upstream Author : V. Armando Solé * URL : https://github.com/vasole/fisx * License : Expat Programming Lang: C++, Python, Description : Quantitative X-Ray Fluorescence Analysis Support Library This software library implements formulas to calculate, given an experimental setup, the expected x-ray fluorescence intensities. The library accounts for secondary and tertiary excitation, K, L and M shell emission lines and de-excitation cascade effects. The basic implementation is written in C++ and a Python binding is provided. This package is a new dependecy of pymca. I will maintain it under python-modules team.
Bug#379054: ITP: lisaac -- Lisaac is the first object-oriented language base on prototype
Package: wnpp Severity: wishlist Owner: picca frederic <[EMAIL PROTECTED]> * Package name: lisaac Version : 0.84 Upstream Author : Benoit Sonntag <[EMAIL PROTECTED]> * URL : http://isaacos.loria.fr/li.html * License : Cecill (compatible GPL) Programming Lang: (C, Lisaac) Description : Lisaac is the first object-oriented language base on prototype The ideas in Lisaac are mostly inspired by Smalltalk (all values are objects), Self (prototype-based) and Eiffel (design by contract) features: * pure object language * very fast (like C code) * dynamic and multiple inheritance * dynamic definition slot * static typing (invariant) * genericity type * auto-cast type system * programming by contract * interrupt manager * include C code facilities -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#898689: ITP: golang-github-ostreedev-ostree-go -- Golang bindings for httt://github.com/ostreedev/ostree
Package: wnpp Severity: wishlist Owner: Juan Picca * Package name: golang-github-ostreedev-ostree-go Version : 0.0~git20171027.cb6250d-1 Upstream Author : OSTree Project * URL : https://github.com/ostreedev/ostree-go * License : ISC Programming Lang: Go Description : Golang bindings for httt://github.com/ostreedev/ostree OSTree-Go Go bindings for OSTree. Find out more about OSTree here (https://github.com/ostreedev/ostree) This package is a dependency for skopeo (https://github.com/projectatomic/skopeo).
Re: Complex Cameras Micro-conference in LPC and Debian
> It will be very useful if someone from the project could comment on the > stacks: > - Do they follow the Openness requirement/ Debian Social Contract? > - Technical challenges of the stack > - Stack preferences You can find here a stack dedicated to scientific cameras. https://lima1.readthedocs.io/en/latest/index.html and the in developpement next version https://limagroup.gitlab-pages.esrf.fr/lima2/ most european synchrotrons are using this library (which is not yet in Debian). Cheers
Re: Reviving schroot as used by sbuild
> Ah, thank you, I didn't realize that existed. That sounds like a nice > generalization of the file system snapshot approach. I think that this how the sbuild-debian-developer-setup script, setup chroots Fred
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, I like the dgit idea, produce a git repository for people who want to use git and let other use whatever they want. Maybe uploading a paquage to Debian could push automatically into dgit. (maybe this is already the case) Is it possible then to mirror this dgit repository in salsa ? Fred
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
What about dog fooding ? for now we can setup a schroot and sbuild very easily and start to build a local repository in minutes. But when it comes to install gitlab and the CI system it is another story. So we rely on the central salsa instance. It seems to me that a great strength of Debian is to empower the user and provide everything (almost out of the box) in order to de-centralize the build process. I do not know if I am clear but I have the fear that this centralisation will make us forget that de-centralisation is sort of "central" to the Debian way. Frederic
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, > Well, I didn't mean we should *give up* decentralization. I mean we shouldn't > give up *centralization*. These examples are to prove centralization actually > works and is quite common, sometimes necessary. It would be great if we could run the salsa-ci pipeline localy easily, in chroot via sbuild or whatever. Do not get me wrong I like the fact that we have these pipelines in salsa, it is a great plus for Debian. I Just see that the salsa-ci pipelines does not gives somethimes exacly the same result than my current sbuild + autopkgtest run locally. So I need to iterate also on salsa-ci to fix my autopkgtests. It would be great if the "quality-pipeline" could be decouple from salsa and could be run locally / salsa / what ever other infra. We have plenty of quality tools, but it is not easy to run them all in a row during the package preparation. > Besides, *you* are the centralization point when you are the only maintainer. > With a centralized code hosting, you exchange being SPOF with redundancy and > team work :p most of my packages are team maintain and I agreed that this central git repository is valuable when it comes to team works. Fred
Bug#400201: ITP: tango -- TANGO is an object oriented distributed control system using CORBA
Package: wnpp Severity: wishlist Owner: "Frederic-Emmanuel PICCA" <[EMAIL PROTECTED]> * Package name: tango Version : 5.5.2 Upstream Author : The Tango team <[EMAIL PROTECTED]> * URL : http://www.esrf.eu/Infrastructure/Computing/tango * License : (GPL) Programming Lang: (C++) Description : TANGO is an object oriented distributed control system using CORBA TANGO is an object oriented distributed control system using CORBA. . In TANGO all objects are representations of devices. The devices can be on the same computer or distributed over a number of computers interconnected by a network. Communication inter devices is done using CORBA and can be synchronous, asynchronous or event driven. . The object model in TANGO supports methods, attributes and properties. TANGO provides an API which hides all the details of network access and provides object browsing, discovery and security features. . Permanent data is stored in a Mysql database. . TANGO is being actively developed as a collaborative effort between the ESRF (www.esrf.eu), Soleil (synchrotron-soleil.fr), Alba (www.cells.es) and Elettra institutes (www.elettra.trieste.it). -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) (ignored: LC_ALL set to [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#539375: ITP: remotetea -- ONC/RPC for Java package
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org --- Please fill out the fields below. --- Package name: remotetea Version: 1.0.7 Upstream Author: Harald Albrecht URL: http://remotetea.sourceforge.net/ License: LGPL Description: ONC/RPC for Java package This package implements Sun's ONC/RPC Remote Procedure Call specification (see RFC 1831, RFC 1832, RFC 1833). . Functionality currently supported: - RPC calls over TCP/IP as well as UDP/IP. - RPC client functionality. - RPC server functionality org.acplt.oncrpc.server - Querying the ONC/RPC potmapper - jrpcgen-utility for converting x-files into Java classes. - Support for authentication types AUTH_NONE, AUTH_UNIX and AUTH_SHORT on both the client and server side. Hello you can find a first version of almost working package on debian mentors. I did not use pbuild to be sur all the build depenendy are ok. Your upload of the package 'remotetea' to mentors.debian.net was successful. Sponsors can now download it. The URL of your package is: http://mentors.debian.net/debian/pool/main/r/remotetea The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/r/remotetea/remotetea_1.0.7-1.dsc - While checking your package we found these issues: You uploaded files which already exists in the repository: - remotetea_1.0.7-1.dsc - remotetea_1.0.7-1.diff.gz - remotetea_1.0.7.orig.tar.gz We have overwritten the files in the repository by those from your new upload. Please note that this is allowed when uploading to mentors.debian.net. But in the official Debian repository you cannot change the upstream tarball (.orig.tar.gz). Processing your upload took 3.4 seconds. - If you do not yet have a sponsor for your package you may want to go to http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=remotetea and set the "Seeking a sponsor" option to hilight your package on the welcome page. You can also send an RFS (request for sponsorship) to the debian-mentors mailing list. Your package page will give your suggestions on how to send that mail. Good luck finding a sponsor! And thanks for using mentors.debian.net The mentors.debian.net team -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569153: ITP: libhkl -- diffractometer computation control library
Package: wnpp Severity: wishlist Owner: "Picca Frederic-Emmanuel" * Package name: libhkl Version : 4.0.0 Upstream Author : Picca Frédéric-Emmanuel * URL : http://repo.or.cz/w/hkl.git * License : (GPL) Programming Lang: (C) Description : diffractometer computation control library The hkl library is a framework for diffraction computation and diffractometer control, heavily used at the SOLEIL synchrotron. It supports various types of diffractometer geometry: Eulerian 4-circle, Eulerian 6-circle, kappa 4-circle, kappa 6-circle, and z-axis geometry. For each of these it provides several numerically computed modes, such as bisector and constant psi. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
init script verbosity
Hello I am using the /etc/init.d/skeleton (from unstable) file to write my package init scripts. but it seems that the lsb-base default behaviour is to have VERBOSE=no so there is no output. Is it ok with the debian-policy 9.4 Console messages from init.d scripts they say : "This section describes the formats to be used for messages written to standard output by the /etc/init.d scripts." but the next lines says "should" and not "must" when describing the init script output message. so what must I do for my init scripts. VERBOSITY / no VERBOSITY ? thanks Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE : init script verbosity
[PICCA Frédéric-Emmanuel] > I am using the /etc/init.d/skeleton (from unstable) file to write my > package init scripts. > but it seems that the lsb-base default behaviour is to have VERBOSE=no > so there is no output. > I believe this is a good default for the boot, and less good for > package installations and when using init.d scripts on the command > line. See http://bugs.debian.org/505468> for a report about > this. Would be nice with feedback on the patch suggested there, as I > hope to have this implemented for Squeeze. I know nothing about all this except that it would be nice to see the messages when started interactively by the user with the invoke-rc.d command > so what must I do for my init scripts. VERBOSITY / no VERBOSITY ? >Use the VERBOSE to decide when to print informative messages, and >always report errors no matter the verbosity setting. so I need to use VERBOSE=yes in my script to override the vars.sh values. See you Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE : init script verbosity
>> so I need to use VERBOSE=yes in my script to override the vars.sh >> values. > This would lead to messages from the script to show up during boot > even when the 'quiet' boot is requested and no error occured, which I > believe is a bad idea. ok but for now even with quiet I have plenty of init scripts log during the start process... See you Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE : RE : init script verbosity
thanks > Or setting it in /etc/default/rcS, from `man rcS`: > VERBOSE > Setting this option to no (in lower case) will make the > boot process a bit less verbose. Setting this option > to yes will make the boot process a bit more verbose. so plenty of init script do not follow this rcS default... Is it normal ? Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE : RE : init script verbosity
On my system VERBOSE=no and I never touch it. and there is plenty of log even with this default. See you Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE : xulrunner 1.9.2 into sid?
Do you have an entry explaining how to create from scratch a symbol file for a given library ? I could not find this information on the debian wiki. thanks Frederic Message d'origine De: Marco d'Itri [mailto:m...@linux.it] Date: lun. 28/06/2010 12:37 À: debian-devel@lists.debian.org Cc: pkg-mozilla-maintain...@lists.alioth.debian.org Objet : Re: xulrunner 1.9.2 into sid? On Jun 28, Mike Hommey wrote: > Speaking of backports, a way to streamline packages from testing to > backports would be very much helpful for packages like iceweasel, where > basically the package from testing can be installed on a lenny system > provided you already use backports for some other libraries. If that's > not the case anymore, some of its dependencies should be switched to > using symbols files. Please open bugs on all your dependencies which are still not shipping symbol files! I did it (with patches) for some key dependencies of my packages and it helped a lot. -- ciao, Marco -- 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/606cc410b038e34cb97646a32d0ec0bf03888...@venusbis.synchrotron-soleil.fr
upgrading unstable -> nvidia and fglrx installation
Hello I upgraded my computer today. And what a surprise, I got installed the nvidia and fglrx drivers Is it a bug and where can I report this ? x:/home/picca# upgrade-system 1) Updating package lists. 2) Upgrading packages: Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following NEW packages will be installed: cpp-4.3 device3dfx-source dkms fglrx-atieventsd fglrx-driver fglrx-glx fglrx-modules-dkms gcc-4.3 kernel-package libgl1-nvidia-alternatives libglide2 libglx-nvidia-alternatives libvdpau1 linux-headers-2.6-686 linux-headers-2.6.32-5-686 linux-headers-2.6.32-5-common linux-image-2.6.32-5-486 linux-kbuild-2.6.32 nvidia-kernel-2.6.32-5-486 nvidia-kernel-common nvidia-vdpau-driver virtualbox-ose-guest-dkms virtualbox-ose-guest-utils virtualbox-ose-guest-x11 xserver-xorg-video-dummy xserver-xorg-video-geode xserver-xorg-video-glide xserver-xorg-video-glint xserver-xorg-video-ivtv xserver-xorg-video-tga xserver-xorg-video-via The following packages will be upgraded: abiword abiword-plugin-grammar abiword-plugin-mathview apt apt-utils awesome blender bzip2 console-data cpp-4.4 foomatic-filters g++-4.4 gcc-4.4 gcc-4.4-base gdb gdbserver gnumeric gnumeric-common grub h5utils hdf4-tools hdfview icedtea-6-jre-cacao installation-report iso-codes libabiword-2.8 libatlas-dev libatlas3gf-base libavcodec-dev libavcodec52 libavdevice-dev libavdevice52 libavformat-dev libavformat52 libavutil-dev libavutil49 libbz2-1.0 libc-bin libc-dev-bin libc6 libc6-dbg libc6-dev libc6-i686 libdb4.5 libgail18 libgcc1 libgd2-noxpm libgfortran3 libgoffice-0.8-8 libgoffice-0.8-8-common libgomp1 libgtk2.0-0 libgtk2.0-dev libhdf4-0 libimlib2 libjasper1 libjhdf4-java libjhdf4-jni libjhdf5-java libjhdf5-jni liblcms1 libpostproc51 libpsiconv6 libruby1.8 libservlet2.5-java libsimage20 libstdc++6 libstdc++6-4.4-dev libswscale-dev libswscale0 liburi-perl libusb-0.1-4 libusb-dev libwmf0.2-7 libwv-1.2-3 libxmu-dev libxmu-headers libxmu6 libxmuu1 locales openjdk-6-jdk openjdk-6-jre openjdk-6-jre-headless python python-dev python-minimal ruby1.8 ucf x11-common xorg xserver-common xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-video-all yafray yorick-z 97 upgraded, 31 newly installed, 0 to remove and 0 not upgraded. Need to get 212MB of archives. After this operation, 210MB of additional disk space will be used. -- GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel signature.asc Description: PGP signature
Bug#602554: ITP: guidata -- dataset manipulation GUI generator
Package: wnpp Severity: wishlist Owner: "Picca Frederic-Emmanuel" * Package name: guidata Version : 1.2.2 Upstream Author : pierre.rayb...@cea.fr * URL : http://sourceforge.net/projects/guidata/ * License : CeCILLv2 Programming Lang: Python Description : dataset manipulation GUI generator Based on the Qt Python binding module PyQt4, guidata is a Python library generating graphical user interfaces for easy dataset editing and display. It also provides helpers and application development tools for PyQt4. -- 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/20101105205053.3336.49966.report...@mordor
Bug#602555: ITP: guiqwt -- efficient 2D data-plotting library
Package: wnpp Severity: wishlist Owner: "Picca Frederic-Emmanuel" * Package name: guiqwt Version : 2.0.4 Upstream Author : pierre.rayb...@cea.fr * URL : http://sourceforge.net/projects/guiqwt/ * License : CeCILLv2 Programming Lang: Python Description : efficient 2D data-plotting library The guiqwt Python library provides efficient 2D data-plotting features (curve/image visualization and related tools) for signal/image processing application development and interactive computing. It's based on the scientific modules NumPy and SciPy, and the PyQwt plotting widgets for PyQt4 graphical user interfaces. -- 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/20101105210335.3557.63421.report...@mordor
RE : List of FTBFS in Ubuntu
> Many packages (e.g. xfe, xfce-*) fails with > "[LD_ERROR] ...: could not read symbols: Invalid operation" > I know that the Xfe package fails because Ubuntu use: > "-Bsymbolic-functions" by default by the linker. > The reasons for the problems are redefinitions of some library functions > in the package. See: > https://bugs.launchpad.net/ubuntu/+source/xfe/+bug/644645 > Unfortunately I don't know any workaround. All upstreams ought to rewrite > many parts of the source code to work with this default linker config. +1 A package I am working one [1] is also affected by this bug. the only work around I found for now is to remove this flag during the build with this line in the rules file [2]. It would be nice if ubuntu would remove this problematic flag. It is painfull to have user complaining about FTBFS on ubuntu just because of this flag. It took me some time to understand the problem. It there a good reason explaining the presence of this flag ? See you Frederic [1] http://git.debian.org/?p=debian-science/packages/tango.git;a=summary [2] http://git.debian.org/?p=debian-science/packages/tango.git;a=blobdiff;f=debian/rules;h=9aa9ff6811a20efe2f113bccd7a95eddf567155f;hp=de35e4f22d9dc30441395bd8e751fd83e7b3885c;hb=2cdab2a9d1617fd5dd763d8a797d394885040c05;hpb=bfe5c89b57fc3e3a79faa030f3d5e06a97ed1b3f > Have a nice day, Joachim (Germany) -- 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/20101203112744.5d1d1...@jupiter.home -- 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/606cc410b038e34cb97646a32d0ec0bf03888...@venusbis.synchrotron-soleil.fr
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
Le Thu, 13 Jan 2011 13:47:53 +0100, Dominique Dumont a écrit : > Hello Hello Here the messages I got when checking my guidata package (already in the new queue) picca at grisette:~/Debian/guidata/guidata$ config-edit -application dpkg-copyright -ui none You should install Config::Model::TkUI or Config::Model::CursesUI for a more friendly user interface Warning in 'License': key 'CeCILLv2' should match ^(?i:Apache|Artistic|BSD|FreeBSD|ISC|CC-BY|CC-BY-SA|CC-BY-ND|CC-BY-NC|CC-BY-NC-SA|CC-BY-NC-ND|CC0|CDDL|CPL|Eiffel|Expat|GPL|LGPL|GFDL|GFDL-NIV|LPPL|MIT|MPL|Perl|PSF|QPL|W3C-Software|ZLIB|Zope)[\d\.\-]*\+?$ Element 'Format-Specification' of node 'Debian::Dpkg::Copyright' is deprecated In configuration root: (function 'create_element') unknown element 'Upstream-Author' (configuration class 'Debian::Dpkg::Copyright') Expected: 'Format','Upstream-Name','Upstream-Contact','Source','Disclaimer','Comment','Copyright','Files','License','Format-Specification','Name','Maintainer','Upstream-Maintainer','Upstream-Source' or an acceptable parameter matching 'X-.*' So it seems that the CeCILLv2 licence (sort of french GPL licence) [1] is unknown of your software:) Add thoses licences to the licences keys whould be a good things ?. At the end how many licences keys ? See you Frederic [1] http://www.cecill.info/licences.en.html -- GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel signature.asc Description: PGP signature
Re: DEP5 CANDIDATE parser/editor/validator/migrator is released in libconfig-model-perl
Le Thu, 13 Jan 2011 13:47:53 +0100, Dominique Dumont a écrit : hello, another try :) picca@grisette:~/Debian/tango/tango$ config-edit -application dpkg-copyright -ui none You should install Config::Model::TkUI or Config::Model::CursesUI for a more friendly user interface 2011/01/13 16:30:47 Invalid line: Copyright : � 1997-1999 AT&T Laboratories Cambridge 2011/01/13 16:30:47 Invalid line: Copyright : � 2010, The Tango team 2011/01/13 16:30:47 Invalid line: Copyright : � 2010, The Tango team 2011/01/13 16:30:47 Invalid line: Licence LGPL-3+ 2011/01/13 16:30:47 Invalid line: Copyright : � 2010, The Tango team Element 'Format-Specification' of node 'Debian::Dpkg::Copyright' is deprecated In configuration root: (function 'create_element') unknown element 'Upstream-Author' (configuration class 'Debian::Dpkg::Copyright') Expected: 'Format','Upstream-Name','Upstream-Contact','Source','Disclaimer','Comment','Copyright','Files','License','Format-Specification','Name','Maintainer','Upstream-Maintainer','Upstream-Source' or an acceptable parameter matching 'X-.*' I attached the copyright file See you Frederic -- GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel copyright Description: Binary data signature.asc Description: PGP signature
Bug#614245: ITP: pytango -- API for the TANGO control system
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" * Package name: pytango Version : 7.1.3 Upstream Author : Tiago Coutinho * URL : http://packages.python.org/PyTango * License : LGPL3+ Programming Lang: C++, Python Description : API for the TANGO control system TANGO is an object oriented distributed control system using CORBA, mainly developed by the Controls Section of the ALBA Synchrotron. PyTango provides bindings for its client- and server-side C++ APIs. With PyTango, you can write TANGO device servers and TANGO applications (scripts, CLIs, GUIs) that access TANGO device servers in pure Python. -- 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/20110220171023.29991.94839.reportbug@mordor
Bug#614247: ITP: taurus -- framework for TANGO control system client applications
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" * Package name: taurus Version : 2.0.0 Upstream Author : Tiago Coutinho * URL : http://packages.python.org/taurus * License : LGPL3+ Programming Lang: Python Description : framework for TANGO control system client applications TANGO is an object oriented distributed control system using CORBA, mainly developed by the Controls Section of the ALBA Synchrotron. TAURUS is a library for connecting graphical or commandline clients to TANGO device servers, built on top of the PyTango bindings and the graphical library PyQt. It provides an abstraction layer for accessing TANGO in a pythonic, object oriented way. . The goals of this library are to: * provide a simple TANGO API to the end-user application; * speed up development of TANGO-based applications; * provide a standardized look-and-feel. . In many aspects, TAURUS follows the same approach as the TANGO Java Application Tool Kit: Tango ATK. If you know ATK, TAURUS will look familiar. . The TAURUS library is divided into two parts: the core module which handles all interaction with PyTango, and the Qt module which provides a collection of widgets that can be used inside any PyQt GUI. -- 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/20110220171506.30298.49550.reportbug@mordor
RE:python-pyqtgraph -- Scientific Graphics and GUI Library for Python
Thanks a lot for this package. > I would like to maintain inside Debian Python Modules Team, > this package is relevant since is needed by the new binwalk release > (don't know if other packages needs it) I know at least about two package that could be interested by this dependency. pyfai and in the futur python-taurus. Cheers Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1eb5...@sun-dag3.synchrotron-soleil.fr
RE:2 months and no upload for pkg
Hello Charles > Peer review can help, by making sure that the final controllers (the FTP > Master > team) do not waste their time reporting defects that others could have found. > You can find a process for peer review at the URL below. >https://wiki.debian.org/CopyrightReview I like a lot the idea, but don't you think that when entering the New Queues a package should be automatically tag with copyright-review-requested. this way it should be possible to add these bugs in how-can-i-help. even better A script could automaticaly download two random packages, one with no review and one with already one review when you have 20 minutes for Debian during the day. I find that the time spent to find a package for review is a pain. it should be as simple as: how-can-i-help --review ... review reportbug --review to fill the report and tag accordingly. Cheers Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1ed5...@sun-dag3.synchrotron-soleil.fr
RE:daemon user naming scheme
> This has the advantage of being short and downstreams not having lots of > Debian-* > users on their systems possibly confusing users not familiar with > Debian. I'd be nice to standardize on this. I have the same problem in one of my package. #737956 I would like to rename the system user tango -> _tango But I do not know how to do this rename properly :(( cheers Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826101939.gf1...@bogon.m.sigxcpu.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1f01...@sun-dag3.synchrotron-soleil.fr
RE:daemon user naming scheme
> Fake it. > UID=$(id -u tango) > GID=$(id -g tango) > deluser tango > adduser tango --uid $UID --gid $GID I like this fake rename because it cause no troubles to the files already owned by the tango user BÙT in case of an idempotent pre/post scripts. what happend if I delete the tango users before creating the new _tango user. If something goes wrong between this deluser and adduse, I am stuck... another important point in my case is that I need to do some mysql operation to grant right for the new user... Frederic Is it possible to use this thread to define the default snipsets to put in the debhelper scripts to do this rename. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1f01...@sun-dag3.synchrotron-soleil.fr
RE:daemon user naming scheme
> # usermod -l newname oldname > (Other things can also be modified at the same time, see the man page.) thanks a lot Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1f01...@sun-dag3.synchrotron-soleil.fr
Bug#759820: ITP: vispy -- OpenGL interactive scientific visualization
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" * Package name: vispy Version : 0.3.0 Upstream Author : Vispy Development Team * URL : http://vispy.org * License : BSD, MIT/X Programming Lang: Python Description : OpenGL interactive scientific visualization Vispy is an OpenGL-based interactive visualization library in Python. Its goal is to make it easy to create beautiful and fast dynamic visualizations. For example, scientific plotting of tens of millions of points, interacting with complex polygonial models, and (dynamic) volume rendering. All thanks to the graphics card’s hardware acceleration. . Vispy will eventually offer graphical APIs at multiple levels, including a matplotlib-like scientific plotting library. Currently, only the lowest-level API is implemented: it brings an easy-to-use Pythonic object-oriented interface to OpenGL. This layer requires you to have basic knowledge of modern OpenGL (notably the OpenGL shading language, GLSL). . We are currently working on higher level layers. They will hide most OpenGL concepts and let you create beautiful visualizations in a few lines of code. Stay tuned! This package will be maintained under the debian-science team umbrella Vcs-Browser: http://anonscm.debian.org/gitweb/?p=debian-science/packages/vispy.git Vcs-Git: git://anonscm.debian.org/debian-science/packages/vispy.git -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140830173406.27479.57233.reportbug@mordor
Internal compiler error
Hello, I got an FTBFS due to an internal compiler error. should I fill a bug against gcc ? should I fill also an RC bug for my package ? thanks for your help Frederic [1] https://buildd.debian.org/status/fetch.php?pkg=pytango&arch=mipsel&ver=8.1.5-1&stamp=1412309891 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1fab...@sun-dag3.synchrotron-soleil.fr
customization of the kernel command line
Hello, I am preparing a package for a scientific camera andor3. This package contain a kernel module for the video grabber. >From the constructor documentation, I need to add the nopat option to the >linux command line. So I would like to know what is the proper way to customize this command line when installing the package. thanks Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1fcb...@sun-dag3.synchrotron-soleil.fr
Re: Debian Project Leader Elections 2012: Call for votes
D1EQ15GD6Gg3jR1st0PsJif5JA3jkIV1HZo72HePgPsLGVtVJZ9EAlHku+cY > 3doTpGVcKP2f6WfmD0ONalzaHTKvqAPb5N52gX4QTPC1HmDj/p36c7rbt8YRDbg7 > 5wD8HQxCn/vRQRQmQRvaZuBor/KVuTcqoAKesqeeDHZft13s1sGdIgNss26erzPy > jSTdPw48g44ND3BJzwR92G4IWgrnZw/h4O8S17ZmUjCI8nqV4twS6IiSa8POddtf > zjjSpl5YJRimaWtVt7ogABRDfgKZpCfPUn3vH1O05R7yuA6RWegx7chRmhSRSE8F > C4slcmd3hQqzLpELVo/EnQMfao+0qpnRfirGmUwy4hZQGLWOfVuYDoE4v7C/zDQH > /2TJVFDRPjGfT2HFu8tjzKoE7ASoUI1fjd4S3h+Ggd7/3YegMzzFzwx982UEDoDt > YQTiSOM7Qt87qYk6SDRwZQVjL/N13rNLGYZ1g5/s8opi/5A68Pue9gZQuK6FiEYE > ExEKAAYFAk93X9cACgkQQdwckHJElwsVOQCaAhCnPJUMows+HRM0QL+ONsuqV+IA > n3o+LVuTENNqZDqDvIJJFjGo+0twuQINBE93XhgBEADKIk2dg81w+yaQDfJYgO+0 > ImIf1pS8G9pWOoLEOmW7St0yDVWmx/e4m+aUkj7Vq2cgmc4SqXTfTvL8j0ePq3th > viPD8juHscw+KJwQacEoBvqtTZtgWz0UmBNGCmKN7u81LaN6VRJL0M3Gxq7YM1/6 > tsnHfM+ES6KlAHvuOcUurCnvGUYsGRhvmJad09Z0wCLf9Mbu6wBoZJVBTE5VD9J+ > aFJ6fe/Q2U89+kTLLsj5CF+oJiOnFlC9rfmeUThcrpniaZIEuEbVvRzed8EV1CWK > VIkfseuyzzgaMNtYCc8ht4h/Iq+Dty9IqsALN83vzSpVwbAqkG/Eo9e3zYPqXFpI > spINNE4hJN0Py/6oCdnMZbW15e4jz1Xe8rMb6w8tSHQ5Jz91bFmgePsm7c6PHoFq > 2TUTOK/qJgditp5bn4EuqZ3+wKAngqkrpn0GyF/UzslK4Igq4BaoDCMxDHRhDZHH > PQ9MqRVBdqLgrfSBeVsEkWLFOkNEYc+Pmou5q159EMxywILG2UEr5ia3SUfsqTGH > tTs8L/TfS3o2nn7WKAxfaZQwckzVunWAUlWnpeLbab203tXOM65Asgih1fjFRcDH > Qu57uXuWy28aKvnX6zJs47t2vxRzpkTpiPUequ932bUPbQX7IjpIfbcjXni1bqjV > 933ewQ8amK3h/5Zxhqka/wARAQABiQIlBBgBAgAPBQJPd14YAhsMBQkAGl4AAAoJ > EJ0M4QzEI7mhcl8QAJ+y5dmXBGs0BDUodmDvq0kaNJjiUy7zQgvvL4cA2yk3dVQc > Rwmcsc6Pu+xaZQ5t8DabCfum5jsddJZZ6PiAfUitJP+NGr+wLIIAy60ltOuDRdmw > Zva09/QVrp3P9qXx+v5cj4zqD2Xz09b4rbo8WW+lP8e6ahao+X+pvM7dq7axfNbF > CuTL82uTVN14xJqErF/uc8qiHpdWU3FVSkroW7+mSY4A4jKros4eLn1cNuqaRz3U > aL8wtsGLOvB1KLrbQ+QwKxWWwcz80E4F8ZZZEPzYapMMxWZu8Smkgb6QGYHjFFSQ > GVw1PKKmY5YYuKVjHBQBE2HQ6lwpLh7k+NIs0EFjleQO9iAmSoZgRY3zJlfRcm3W > qN62mqesI2X9wLjFq9ivwkhHJ2veoxl5fSlnP+NZGsZgPLgnmi43VpWXD1aERoLt > iG2D5JMzDNdiD/9i8YSDLZT6sUyhh3UBZAaNI6taG9OCtpdGduk6L6xe5XGcZx1H > kTLFEOY3H+C1gU0SqWX5edpcyf8u8SNlyQXZcoFVYqA5i06QUwDU4jSuOYQxOfx/ > 8YZ4jtY4yocvumag/aNIJm3WN4nscoNuO/9wu8kyfu/xN0WHpBoCQWCv1qR3ee3n > qF3xEy5mBndtV7qRLx3ZDrlFh6wuWOvO8gb2Sya/+yqgHKtMq5MG+vq91wDe > =AvZK > -END PGP PUBLIC KEY BLOCK- > -- GPG public key 4096R/4696E015 2011-02-14 fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015 uid Picca Frédéric-Emmanuel GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel signature.asc Description: PGP signature
Bug#717871: ITP: sardana -- sardana control system
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" * Package name: sardana Version : 1.2.0 Upstream Author : Carlos Pascual-Izarra * URL : http://packages.python.org/sardana * License : LGPL3+ Programming Lang: Python Description : sardana control system SARDANA, is a TANGO based control system designed for instrument control and data acquisition, mainly developed by CELLS Alba Synchrotron Controls Section. SARDANA framework is designed to hide the complexity and heterogeneity of the control system (some internal control of a group of devices), while providing a wide, rich, and extensible set of operations that a user may need. -- 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/20130725201350.1706.75958.reportbug@mordor
Bug#721653: ITP: ssm -- macromolecular superposition library
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" * Package name: ssm Version : 1.3 Upstream Author : E. Krissinel * URL : http://www.ccp4.ac.uk/ * License : (LGPL-2.1) Programming Lang: (C++) Description : macromolecular superposition library SSM is a macromolecular coordinate superposition library, written by Eugene Krissinel of the EBI. . The library implements the SSM algorithm of protein structure comparison in three dimensions, which includes an original procedure of matching graphs built on the protein's secondary-structure elements, followed by an iterative three-dimensional alignment of protein backbone Calpha atoms. . The algorithm implemented by the software is described in: E. Krissinel & K. Henrick (2004) Secondary-structure matching (SSM), a new tool for fast protein structure alignment in three dimensions. Acta Crystallogr D Biol Crystallogr. 60, 2256-68. -- 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/20130902185447.6966.82641.reportbug@mordor
RE : mass bug filing of 'deluser/delgroup: command not found' errors detected by piuparts
> We had a conversation (here I think) last year about whether programs > should be trying to automatically remove users in their postrm. IIRC > the conclusion of that discussion the answer was that they should not, > at least in the default case. > We should double check this, before you submit your MBF, so that > nformation about what to do can be included in your bug report. > In particular, I think this is the wrong advice because IMO the > correct fix is not to call any of these tools from postrm purge. In that case you got his kind of piuparts error [1], if you did not remove the homedir of the previously added user. What is the right fice for this ? Cheers, Frederic [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657146 -- 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/a2a20ec3b8560d408356cac2fc148e5325072...@sun-dag1.synchrotron-soleil.fr
RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
> I start to really love the CI thing. I first invested a bit of > time in setting-up everything, do you have a step by step cookbook for your setup. Maybe on the debian wiki ? Cheers Frederic -- 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/a2a20ec3b8560d408356cac2fc148e5358e63...@sun-dag1.synchrotron-soleil.fr
RE : RE : Gerrit, Git requirements, cooperation with others. was: git dangerous operations on alioth
> I love what Michael Prokop did and documented here: > http://jenkins-debian-glue.org/ > Jenkins + Debian packaging using cowbuilder > The code is very clean and easy to hack. Thanks, yes it looks great. Cheers Fred -- 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/a2a20ec3b8560d408356cac2fc148e5358e63...@sun-dag1.synchrotron-soleil.fr
conflict between system user and normal user
Hello, I am the maintainer of the tango package which contain the tango-db binary. This tango-db provide a service called tango-db which connect to a mysql database. I follow the debian-policy to create a dedicated system user for this services. So I used the tango user which is the name of the community in charge of the tango-control system. during the installation I generate a .my.cnf in the system user tango home which I set under /usr/lib/tango in the package now If a non-system user tango exist the home is not /usr/lib/tango but most probably /hom/tango. so the installation process faild because it can not create the /usr/lib/tango/.my.cnf What is the correct way to deal with this kind of problem ? I cannot find in the policy something about conflict between system and non-system user. thanks Frederic -- 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/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr
RE:conflict between system user and normal user
> I don't think there is much that can reall be done to fix the > fundamental problem which is that system users and regular users have to > live in the same namespace causing a risk of conflicts. > There are two things I can see you could do to impreove the situation > with your package. > 1: Fail early, it's better to have preinst fail than it is to start > creating stuff with wrong permissions/ownership. Yes I nedd to faisl with a human comprehensible error explaining that the requested users is already there but that is not a system user. > 2: Choose a less generic name that is less likely to cause conflicts. Do > you plan to use this user only for the db? if so tango-db might make > sense, if not maybe something like tango-control-system. no this user will be used by all tango controls system daemon. tango-db tango-starter tango-accesscontrol ... no my question is should I provide a amigration plan from the current tango user ? this package is already usedin production. -- 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/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr
RE:conflict between system user and normal user
> Just use a generic name and be done with it. sorry, what do you mean by generic ? > The name should not be hardcoded - if it is, patch upstream in each > case and fix it. Don't waste your time and user time on a hacky > workaround - fix the code. no, the name is not hard coded by the upstream. I start "daemon" with start-stop-daemon with this command start-stop-daemon --start --quiet --chuid tango:tango --background \ --make-pidfile --pidfile $PIDFILE --exec $DAEMON -- $DAEMON_ARGS \ || return 2 So it is hardcoded in the package not by the mainstream author. Cheers Fred -- 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/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr
RE:conflict between system user and normal user
Hello, I dig a little bit in the debian documentation, and I found this snipset in the section 9.2 of securing-debian-howto [1] It is interesting to see the code used to create a system user. But the step 4 bother me usermod -c "$SERVER_NAME" \ -d $SERVER_HOME \ -g $SERVER_GROUP \ $SERVER_USER So it seems that this code update silently the user home during the package installation. Is it a good practice ? [1] https://www.debian.org/doc/manuals/securing-debian-howto/ch9.en.html Cheers Fred -- 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/a2a20ec3b8560d408356cac2fc148e53b1dea...@sun-dag3.synchrotron-soleil.fr
Bug#741078: ITP: lmfit-py -- Least-Squares Minimization with Constraints
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" * Package name: lmfit-py Version : 0.7.4 Upstream Author : matt.newvi...@gmail.com * URL : http://lmfit.github.io/lmfit-py/ * License : EXPAT Programming Lang: Python Description : Least-Squares Minimization with Constraints The lmfit Python package provides a simple, flexible interface to non-linear optimization or curve fitting problems. The package extends the optimization capabilities of scipy.optimize by replacing floating pointing values for the variables to be optimized with Parameter objects. These Parameters can be fixed or varied, have upper and/or lower bounds placed on its value, or written as an algebraic expression of other Parameters. . The principal advantage of using Parameters instead of simple variables is that the objective function does not have to be rewritten to reflect every change of what is varied in the fit, or what relationships or constraints are placed on the Parameters. This means a scientific programmer can write a general model that encapsulates the phenomenon to be optimized, and then allow user of that model to change what is varied and fixed, what range of values is acceptable for Parameters, and what constraints are placed on the model. The ease with which the model can be changed also allows one to easily test the significance of certain Parameters in a fitting model. . The lmfit package allows a choice of several optimization methods available from scipy.optimize. The default, and by far best tested optimization method used is the Levenberg-Marquardt algorithm from from MINPACK-1 as implemented in scipy.optimize.leastsq. This method is by far the most tested and best support method in lmfit, and much of this document assumes this algorithm is used unless explicitly stated. An important point for many scientific analysis is that this is only method that automatically estimates uncertainties and correlations between fitted variables from the covariance matrix calculated during the fit. . A few other optimization routines are also supported, including Nelder-Mead simplex downhill, Powell's method, COBYLA, Sequential Least Squares methods as implemented in scipy.optimize.fmin, and several others from scipy.optimize. In their native form, some of these methods setting allow upper or lower bounds on parameter variables, or adding constraints on fitted variables. By using Parameter objects, lmfit allows bounds and constraints for all of these methods, and makes it easy to swap between methods without hanging the objective function or set of Parameters. . Finally, because the approach derived from MINPACK-1 usin the covariance matrix to determine uncertainties is sometimes questioned (and sometimes rightly so), lmfit supports methods to do a brute force search of the confidence intervals and correlations for sets of parameters. This package will be maintained under the debian-science umbrella Vcs-Browser: http://anonscm.debian.org/gitweb/?p=debian-science/packages/lmfit- py.git Vcs-Git: git://anonscm.debian.org/debian-science/packages/lmfit-py.git -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140308082407.6853.62179.reportbug@mordor
RE:About a mass bug report not based on Sid or Jessie.
> It may be that libgc upstream's autogen.sh script is not really 'right' in > some way. But there may well be a lot of upstreams like that, which is > why maintainers need clear guidance on how to deal with this, without > having to become autotools experts. i.e how to determine when they can > just run dh_autoreconf and when they need to do something more > involved. for example in my package hkl (I am also the upstream), the autogen.sh also run gtkdocize #!/bin/sh test -d m4 || mkdir m4 gtkdocize || exit 1 autoreconf -ivf -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1e6e...@sun-dag3.synchrotron-soleil.fr
how to deal with a missed so bump already uploaded ?
Hello, the zeromq upstream forgot to do an so bump when releasing the 4.x series. The breakage was discovers quite late so it is now in testing. the package should be revert to the 3.2.4 version. you can find all the information about this breakage in the bug #743508. So my question is how to deal with this mess ? thanks Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1e96...@sun-dag3.synchrotron-soleil.fr
RE:how to deal with a missed so bump already uploaded ?
> Reverse dependencies are anything but unrelated. Hello julien, from the point of view of the release team. What should be do now ? to my opinion, all we have to do is to upload zeromq3 with this ugly but necessary +really versionnumber 4.0.3+really-3.2.4-1 then the problem should be fixed once migrated into testing. is that all ? thanks for your help Fred -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1e96...@sun-dag3.synchrotron-soleil.fr
gpfs packages for a migration to Debian ?
Hello, I hope that this mailing list is the right one for that kind of questions. I am investigating the availability of packages for de IBM General Parallel File System (GPFS) [1] for Debian. It seems that this kind of distributed filesystem is of 1st importance for an European institut to migrate most for their desktop and serveur to a Debian Solution. So I am asking here, to know if someone already has got experience with this kind of installation, and if some one already packages it. thanks for your help. Frédéric [1] http://www.ibm.com/developerworks/wikis/display/hpccentral/General+Parallel+File+System+%28GPFS%29 -- GPG public key 4096R/4696E015 2011-02-14 fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015 uid Picca Frédéric-Emmanuel GPG public key 1024D/A59B1171 2009-08-11 fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171 uid Picca Frédéric-Emmanuel signature.asc Description: PGP signature
Bug#642586: ITP: mmtk -- The molecular modeling toolkit
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" Dear Maintainer, * Package name: mmtk Version : 2.7.5 Upstream Author : Konrad Hinsen * URL : http://dirac.cnrs-orleans.fr/MMTK/ * License : CeCILL-C Programming Lang: C, Python Description : The molecular modeling toolkit The Molecular Modeling Toolkit (MMTK) is a library for molecular simulation applications. It provides the most common methods in molecular simulations (molecular dynamics, energy minimization, normal mode analysis) and several force fields used for biomolecules (Amber 94, Amber 99, several elastic network models). MMTK also serves as a code basis that can be easily extended and modified to deal with non-standard situations in molecular simulations. this will be a dependency for nMOLDYN http://dirac.cnrs-orleans.fr/plone/software/nmoldyn/ -- 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/20110924080513.16311.23811.reportbug@mordor
RE : Bug#642586: ITP: mmtk -- The molecular modeling toolkit
> Since this second mmtk is written in java, I meant mmtk-gc-java of course. In fact this source package will provide only a python module. So the binary packages will be python-mmtk python-mmtk-doc don't know yet Regards. -- 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/a2a20ec3b8560d408356cac2fc148e5324cf8...@sun-dag1.synchrotron-soleil.fr
RE:Bug#778417: ITP: netcdf-python -- python interface to the netCDF4 (network Common Data Form) library
Hello, I am the maintainer of python-scientific > How does this differ from the existing python-netcdf package? I CC the upstream autor of python-scientific, maybe he can clarify this point but before a question to the netcdf4-python guyes. Does netcdf4-python will support python3 ? @Konrad do you think that this netcdf implementation from scientific python could be replace by this netcdf4-python implementation ? Should we get rid of your implentation and use this one instead (to be clear) It would be nice if at the end only one implementation could be kept and maintain. Cheers Frederic I put here the rest of the message: > That is not an easy question to answer (at least with my limited > knowledge). The Unidata website > (http://www.unidata.ucar.edu/software/netcdf/software.html#Python) lists > 8 different python interfaces to NetCDF. Some are faster, and some offer > writing in reading & writing in other data formats as well as NetCDF. > The netcdf4-python package is the only one described as having > implemented most of the newest features of NetCDF-4. It was actually > modelled on the Scientific.IO.NetCDF module API. > The information about the ScientificPython source package which bundles > python-netcdf (along with many other modules useful for scientific > work), does not contain much easy to digest information about the > implemented interface. I did see in the changelog however, that it is at > least aware of NetCDF-4 data. > Basically, our intention was to package all of the netcdf-* packages > under the Unidata banner on github (https://github.com/Unidata). Regards, Ross -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1feb...@sun-dag3.synchrotron-soleil.fr
RE:Bug#786902: O: ifupdown -- high level tools to configure network interfaces
> I do, it's about time we had a decent scripting language in the base > system. What about haskell as a decent scripting language ? It seems to me that haskell is a clear win when it comes to put things all together. type checking etc... Fred -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2163...@sun-dag3.synchrotron-soleil.fr
RE:Huge data files in Debian
> Hi > Wouldn't a p2p system scale better than any server based solution? Also in > regards to cost... gittorrent[1] would be great for this. [1] http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decentralized-github/ Cheers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b2178...@sun-dag3.synchrotron-soleil.fr
RE:Ad-hoc survey of existing Debian git integration tools
Hello Ian, Since we are speaking about workflow. I work with instituts who want to maintain internaly their own debian packages and repositories. The objectif is to maintain sort of 'PPA' in order to be as reactive as possible when deploying the code internally. Now from time to time it would be great to release officially these packages without too much pain. So I would like to know how you are envisioning this sort of workflow with dgit ? A way to have a dgit 'instance' repository internally to an instituts and the connection with the dgit repository of Debian. These instituts are also upstream developpers and they want to keep the packaging (debian directory) into their upstream git repository. It is time consuming to maintain in parallele a debian package on alioth and a debian (directory) package in the upstream for the internal purpose of the institut. sometimes we need to fix the upstream source and it is a lot easier to commit to the upstream and do the packaging from there instead of generating a .tar.gz, importing this in a separate alioth repository doing the ususal packaging stuffs (copyright, sbuild, lintian piuparts, etc...). This question also the team working when the packaging is not on the debian infrastructure In fine the question is how do we create easy passerelles between upstream repository and the debian infrastructure. It seems to me that Debian should propose a sort of decentralized github which should allow upstream to setup within a minute a 'PPA' which can be naturally connected and beneficiate of the buildd, autopkg-tests depending on the infrastructure shared with other etc... I franckly speaking do not have an idea of how all this should be organize but I would like to share my tought with you. Cheers Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b217a...@sun-dag3.synchrotron-soleil.fr
RE:RE:Ad-hoc survey of existing Debian git integration tools
> dgit is a step in this direction. Yes and it is nice to have meta data (the dgit things) rerpresenting the packages which can be shared between derivatives. > I'm not sure I entirely understand your situation, but: Yes I was a bit laid at this moment :) > If you are a downstream, there is no need at all for you to generate > and work with source packages. Instead, you could keep your source > code entirely in git, and build binaries directly out of git clones. Yes but if peoples are using autotools they do not necessarely put all the autogenerated files in the git repository. so if you want at the end to set up some intégration branch where all the autogenerated files are integrated. or maybe this sort of bootstrapping should be part of the build process, or the job of the get-orig-source make target ? > If want to do this, the dgit view of the Debian archive is a good > starting point, because it is a uniform view of the archive: a git > branch containing an editable, buildable package. So we need to agreed on a convention in order to let the upstream do the job of integrating their work in the Debian archive. Or at least to prepare something which could integrate the Debian archive in the end. > If you find that you want to edit the upstream source, you can make > your changes on an upstream git branch, and then merge or cherry pick > that into your packaging branch. Does it mean that the dgit repo will contain also the upstream repository ? > If you want to feed your changes back to Debian, you need to provide > the maintainer with the format that they are expecting. If the > maintainer is using git, a git branch (with reasonably clean history) > is probably a good bet, but you should ask the maintainer. dgit should propose a sort of PR (via email) in order for the upstream to propose the integration of its prepared package into the repository. something which is done for now via mentors, maybe does dgit propose to intégrate also the pacakges on mentors This way it should be easy to do some packaging review. > If you are the maintainer, then you can simply dgit push into Debian > from your packaging branch. If you have made the git history > complicated (eg, with merges), you may need to either linearise it > somehow yourself, or simply switch away from `3.0 (quilt)'. I do not understand this part why a non linear history is a problem for dgit ? cheers Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b217b...@sun-dag3.synchrotron-soleil.fr
RE:debian queue demon keeps spawning emails for clblas/2.6-2 upload
Ok, I used dcut dcut -k 4696e015 rm clblas_2.6-2_amd64.changes in order to remove the offending file Cheers Fred
Bug#796955: ITP: python-qwt -- Pure Python implementation of Qwt
Package: wnpp Severity: wishlist Owner: "Picca Frédéric-Emmanuel" * Package name: python-qwt Version : 6.1.2a3 Upstream Author : Pierre Raybaut * URL : https://github.com/PierreRaybaut/qwt * License : Expat Programming Lang: Python Description : Pure Python implementation of Qwt The qwt package is a pure Python implementation of Qwt C++ library with the following limitations. . The following `Qwt` classes won't be reimplemented in `qwt` because most powerful features already exist in `guiqwt`: * QwtPlotZoomer * QwtCounter * QwtEventPattern * QwtPicker * QwtPlotPicker . QwtClipper is not implemented yet (and it will probably be very difficult or impossible to implement it in pure Python without performance issues). As a consequence, when zooming in a plot curve, the entire curve is still painted (in other words, when working with large amount of data, there is no performance gain when zooming in). This package will be maintain under the debian-science umbrella. It is a requiered dependency for the new guiqwt package.
RE:Namespace for system users
> Well the point is that the need to create system users can be avoided > entirely by running services using only dynamic UIDs. Except that some services rely on Database granted access ... Cheers Frederic
RE:[Idea] Debian User Repository? (Not simply mimicing AUR)
now we have the salsa pipeline. does it fit your needs ?
RE:RE:[Idea] Debian User Repository? (Not simply mimicing AUR)
After a build, you get this https://salsa.debian.org/science-team/python-xrayutilities/-/jobs/147913/artifacts/browse/debian/output/ Is it enought for you. Mayve you can discuss with the salsa pipeline team and request a target in order to produce a better repo. cheers
RE:Preferred git branch structure when upstream moves from tarballs to git
Hello, I am also the upstream of a bunch of project. what is the right way to use dgit when upstream contain the debian directory. source format etc... thanks Frederic
RE:Bits from /me: A humble draft policy on "deep learning v.s. freedom"
What about ibm power9 with pocl ? it seems that this is better than the latest NVIDIA GPU. Cheers
RE:Difficult Packaging Practices
[...] > packages. While my Perl is a bit rusty, I can propose some "dh_fetch" > helper for this if there is no huge opposition against this approach. why not a dh_uscan ? what is the fundamental difference between dh_fetch and what you can achieve by using uscan from the rules file ? Cheers Frederic
RE:Difficult Packaging Practices (OT)
> This thread reminded me the Debian User Repository thread: > https://lists.debian.org/debian-devel/2019/04/msg00064.html > Such a repository can be a "easy" packaging zone, possibly attracting > more contributing people. Eventually some people will try to improve the > packages and get them into official Debian. Some upstreams maintain there conda recipes, with these nice badges whcih remind them that it doe not work, or that it work. It would be great if we could have this in Debian, in order to let the upstream get use to the Debian packaging and let them target our distributions. so maybe the packaging should be as simple as droping a debian-ci file into the upstream source and our salsa pipeline could start running its pipeline. Cheers Frederic
RE:AMDGPU+OpenCL with Debian?
Same here... with WXX100 cards. what about rocm packaging ? De : Steffen Möller [steffen_moel...@gmx.de] Envoyé : lundi 17 juin 2019 20:14 À : debian-devel@lists.debian.org Objet : AMDGPU+OpenCL with Debian? Hello, Running Debian unstable, I failed to set up OpenCL to work with BOINC and an AMD RX580. The card worked just fine with the monitor, but it was not recognised as an OpenCL device by BOINC. When I then tried to install the 19.10 release of the driver AMD provides on https://www.amd.com/en/support/graphics/radeon-500-series/radeon-rx-500-series/radeon-rx-580 on our distribution, the kernel module did not compile. I then installed Ubuntu and basically did not need to do anything - it just worked upon installing boinc-client-opencl. I could also install the .debs provided by AMD with no difficulty. Are there others on this list with similar experiences under Debian? Is there something we can/want to do to help that situation? Cheers, Steffen
RE:Sorce only uploads with sbuild
> $ origtargz # since I use pristine-tar what is the difference with git deborig > $ dgit --gbp build > $ dgit --gbp push-source or dgit --gbp sbuild to build via sbuild in a clean chroot, everythongs setup via propellor indeed thanks to sean and joeyh :)) > Getting started with dgit felt a bit intimidating, but it basically just > worked once I got sbuild set up (and you've already crossed that hurdle), > and the payoff in reduced mental load was totally worth it. +1, my mental load was reduced a lot with dgit In combination with salsa-ci, the packaging is a lot easier now. I can not wait for this tag2upload thinks :)) then we just missed a nice tool in order to make mass modifications (lintian-brush ?, other project ?) Cheers Frederic
RE:Salsa.d.o: Please support the implementation request for a global config option to change the default for "Custom CI config path" in Gitlab
> the configuration file to debian/gitlab-ci.yml. Therefor some time ago it had it seems that now the name should be debian/salsa-ci.yml Frederic
RE:Generating new IDs for cloning
did you tried this https://codesearch.debian.net/search?q=machine-id&literal=1&perpkg=1
sbuild and trivial local repository
Hello, I try to write a really simple script in perl which allows me to rebuild a bunch of packages using a file with a really simple syntax backport hkl git haskell-hkl https://repo.or.cz/hkl.git contrib/haskell ... I setup a chroot with the sbuild-debian-developer-setup -> ok Now I can build packages with the sbuild command from a checkout package -> ok Now I need to keep the generated packages to build the next one. So I want to setup a local repository own by the user `/home//repository` I use apt-ftparchive in order to maintain the Packages, Sources and Release file between each package build. -> ok My problem is: how can I bind the local repository into the chroot via sbuild. I understand that I can put this configuration in the /etc/schroot/sbuild/fstab configuration. /home/user/repository /tmp/repository none rw,bind 0 0 but the user repository path is a moving target. So my question is how can I do this mount from the sbuild command line thanks Frederic
rejection of binary package based on file timestamp
Hello, I am working on two packages pyfai[4] and python-fabio[3], I have got a rejection based on the file timestamp which seems too old. the bug report is here [1] and [2]. If you lool at python-fabio status page, it seems that they all failed [5], but if you only look at the build log the package build on most buildd.[6]. The upstream did a mistake and all the file in the orig archive have a timestamp close to the 1st january 1070 as explain in the first bug report. So during the build it seems that sphinx keep these timestamp and use it for all the generated documentation. My question is what should I do now..., it seems that dak refuse to upload binary package with old file, but not source packages with old files. The upstream did not plan to do a new upstream relase soon just to set other timestamp... Should I repack it and set an arbitrary timestamp which is closer to the current time just to make dak happy :). thanks for your advices. Frederic [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041443 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041442 [3]https://tracker.debian.org/pkg/python-fabio [4] https://tracker.debian.org/pkg/pyfai [5] https://buildd.debian.org/status/package.php?p=python-fabio [6] https://buildd.debian.org/status/logs.php?pkg=python-fabio
Re: rejection of binary package based on file timestamp
> Touch the generated files in d/rules as Aurelien suggested in the bug report? Yes as a workaround, I can touch all files during the build Nevertheless do we have an explanation of FTPMaster why files with timestamp 1/1/1970 are not allow in the Debian archive (at least for binary package) ? Cheers Fred
Re: rejection of binary package based on file timestamp
thanks for this very precise explanation. Fredric - Le 20 Juil 23, à 15:58, David Kalnischkies da...@kalnischkies.de a écrit : > Hi, > > On Thu, Jul 20, 2023 at 10:01:54AM +0200, PICCA Frederic-Emmanuel wrote: >> I am working on two packages pyfai[4] and python-fabio[3], I have got a >> rejection based on the file timestamp which seems too old. > > Looking at the dak (= Debian Archive Kit; aka the tool(s) handling > the archive) source [0] shows us that this is an explicit check > (BinaryTimestampCheck) against time travel as that "can cause errors > on extraction" (says the source, dating from 2012). > > This check flat out refuses files from before 1975. For the future it > is a lot more restrictive… no more than 24 hours in the future. > > I wonder a bit why this is not applied to sources as well, but I suppose > it could be legit to have unchanged source since then… not that I think > you will encounter a lot of trouble on extraction, but its likely so > untested that something will struggle with it like it does with e.g. the > years 2038 or year 0 (compare also the time_t 32 vs 64bit discussion). > > [0] https://salsa.debian.org/ftp-team/dak/-/blob/master/daklib/checks.py#L461 > ff > > >> If you lool at python-fabio status page, it seems that they all failed [5], >> but >> if you only look at the build log the package build on most buildd.[6]. > > The build was successful on the buildds, so the binary package is > uploaded to the archive – but dak refused to import them. That is > also why it was successfully imported into some ports architectures > as ports is currently not dealt with by dak but by another tool > (dubbed mini-dak) for now (note for time travelers: This might change > in the future). > > >> So during the build it seems that sphinx keep these timestamp and use it for >> all >> the generated documentation. > > Taking the timestamp of the source file is not the worst idea as that is > fixed and fixed is useful e.g. for reproducible-builds. I somewhat doubt > sphinx is doing this as the output usually depends on various input > files, but if that is what you see… > > An alternative is using the value stored in SOURCE_DATE_EPOCH (if it > exists). > >> My question is what should I do now... > > If it is just about a few files each, it might be easiest to `touch` > the binary file in your debian/rules. > > Somewhere at the top place for good measure: > SOURCE_DATE_EPOCH ?= $(shell dpkg-parsechangelog -S Timestamp) > > and a bit later (as I think its the upstream changelogs): > execute_after_dh_installchangelogs: > touch -d"@$(SOURCE_DATE_EPOCH)" path/to/binary/file > > > I haven't actually tried this, so please don't rely on me typing it > correctly into the blue. Test it! Especially look at the timestamps > in the produced deb file. > > > It is a bit iffy to set the timestamp of the changelog (which changes > with every revision), but close enough. At least more realistic than > that this software wasn't changed since the start of the unix epoch… > So please drop this again if its no longer needed. > > > Best regards > > David Kalnischkies > > P.S.: d-devel@ isn't entirely wrong as this is sufficiently esoteric, > but next time start perhaps on d-mentors@.
Re: Can we distribute pre-built locales to speed up image generation?
> Hi Charles, > > On Tue, Aug 01, 2023 at 04:43:59PM +0900, Charles Plessy wrote: >> In the course of generating singularity/apptainer Debian images at work, >> I wanted to make all locales available to the users. I sthere a maliling list where we can speak about these singuarity/apptainer applications ? At work they want us to build these singularity/apptainer, distributed via https://cernvm.cern.ch/fs/ Cheers Fred
Re: Potential MBF: packages failing to build twice in a row
I second this idea, and also the salsa pipeline should check this also. - Le 5 Aoû 23, à 21:07, Timo Röhling roehl...@debian.org a écrit : > Hi Lucas, > > * Lucas Nussbaum [2023-08-05 17:06]: >>An example sbuild invocation to reproduce failures is: > [omitted the command line equivalent of Tolstoy's War and Peace] > > If we decide that this issue is important enough that people should > care and mass bugs be filed, sbuild will need a more concise way to > test this; something like pbuilder's --twice option. > > > > Cheers > Timo > > -- > ⢀⣴⠾⠻⢶⣦⠀ ╭╮ > ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ > ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ > ⠈⠳⣄ ╰╯
Re: DebGPT: how LLM can help debian development? demo available.
> Installation and setup guide can be found in docs/. Is it planed to package transformers in Debian instead of using conda/mamba venv for this installation ? * It would be great to help with the Debian patch workflow. - upstream status - find upstream bug equivalent to a Debian bug report. - prepare bug report for upstream. - propose improved patch description. * doing request on codesearch.net Cheers Frederic
Bug#1065481: ITP: pynx -- Python tools for Nano-structures Crystallography
Package: wnpp Severity: wishlist Owner: Picca Frédéric-Emmanuel X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pan-maintain...@alioth-lists.debian.net, pi...@debian.org * Package name: pynx Version : 2023.1.2-1 Upstream Contact: fa...@esrf.fr * URL : https://gitlab.esrf.fr/favre/PyNX * License : CeCILL-B Programming Lang: (OpenCL, Python) Description : Python tools for Nano-structures Crystallography PyNX stands for *Python tools for Nano-structures Crystallography*. It is a python library with the following main modules: . 1) pynx.scattering: *X-ray scattering computing using graphical processing units*, allowing up to 2.5x10^11 reflections/atoms/seconds (single nVidia Titan X). The sub-module``pynx.scattering.gid`` can be used for *Grazing Incidence Diffraction* calculations, using the Distorted Wave Born Approximation . 2) pynx.ptycho : simulation and analysis of experiments using the *ptychography* technique, using either CPU (deprecated) or GPU using OpenCL. Examples are available in the pynx/Examples directory. Scripts for analysis of raw data from beamlines are also available, as well as using or producing ptychography data sets in CXI (Coherent X-ray Imaging) format. . 3) pynx.wavefront: *X-ray wavefront propagation* in the near, far field, or continuous (examples available at the end of ``wavefront.py``). Also provided are sub-modules for Fresnel propagation and simulation of the illumination from a Fresnel Zone Plate, both using OpenCL for high performance computing. . 4) pynx.cdi: *Coherent Diffraction Imaging* reconstruction algorithms using GPU. . In addition, it includes :doc:`scripts ` for command-line processing of ptychography data from generic CXI data (pynx-ptycho-cxi) or specific to beamlines (pynx-ptycho-id01, pynx-ptycho-id13,...). This package will be naintain in the Debian-Science repository by the Debian-PAN team
Re: Validating tarballs against git repositories
One missing piece for me in order to migrate to meson is the integration between flymake and the autotools. https://www.emacswiki.org/emacs/FlyMake#h5o-7
Re: Any volunteers for lintian co-maintenance?
I tried it on one of my package silx warning: File: ./debian/tests/control:22:14:22:19: It is possible that the value is a typo of "i386". [Correctable via --auto-fix] 22: Architecture: !i386 It seems wrong to me, the test control file allow !i386 Cheers Frederic
Re: Documenting packaging workflows (was: finally end single-person maintainership)
My standard workflow I use gbp and dgit gbp import-orig --pristine-tar --uscan gbp dch lintian-brush dgit --gbp sbuild (build and autopkgtest) ...work until it is ok on my computer gbp dch ... hand edit the changelog gbp push git push (to push the UNRELEASE master branch) ... wait for salsa result if everythings is ok ... if not work and push commits to salsa ... then relase with dch -r dgit --gbp build-source dgit --gbp push-source gbp push I like the way dgit help for the upload. Cheers
RE:deduplicating jquery/
What about doing something similar to sphinx. Create a package with the doxygen jquery and link to files of this package for all documentations generated via doxygen. provide a dh_doxygen to do this link like dh_sphinxdoc Cheers Fred
RE:Possible DEP proposal - contribution preferences
cme should not use wrap-and-sort instead of implementing its own logic ?
Bug#985100: server suspended after installation
Package: general Severity: normal X-Debbugs-Cc: pi...@debian.org Hello, I just wanted to report an issue I am facing with my servers. I used the bullseye beta3 of the installer, but If I remember correctly it was already the same with buster. after installation and the final reboot, the server is suspended around 20 minutes later. it seems that I need to request no suspend, no sleep and no hybernate following the instruction of this wiki page https://wiki.debian.org/Suspend Indeed, I forgot to apply this configuration before leaving the data center. when I arrived to my office the server was down... It seems to me that the default behaviour is not adapted to servers. So I would like you to reconsider the default configuration of these target. thanks for considering Frederic
RE:Bug#996203: ITP: ifeffit -- Interactive XAFS analysis program
https://en.wikipedia.org/wiki/X-ray_absorption_fine_structure See you
where can I find the binNUM informations ?
Hello, I am trying to understand a problem in matplotlib on the mips64el arch https://buildd.debian.org/status/logs.php?pkg=matplotlib&ver=3.3.4-2%2Bb1&suite=sid between 3.3.4-2 and 3.3.4-2+b1 the tests started to failed. So I would like to know why this package was binNMU and the difference between both enviropnment during the build. thanks for your help Frederic
Re: where can I find the binNUM informations ?
thanks a lot. cheers Fred
Re: Porter roll call for Debian Bookworm
> > In case #1000435 (matplotlib crashes on mips64el) is not already on > > your radar, would you please take a look? > > > > Thank you. I will work on it right now. Hello, I just added some information about this problem on this bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001168#72 it seems to me that this is something related to gcc-11. If I build matplotlib with gcc-10 there is no more crash. I think that I reach my peter principe with this last effort :)) Cheers Frederic
RE:devscripts uninstallable in Debian Sid due to unmet dependencies
perle 5.30 transition whcih was announced here https://lists.debian.org/debian-devel-announce/2019/10/msg0.html
RE:source only upload with git-buildpackage
And what about dgit --gbp push-source ?
RE:GPU-ready (with free driver) buildd/CI/porterbox?
Hello > Debian has from time to time funded hardware for people doing important > work. > I'd definitely be happy to receive a reimbursement request for such > hardware from Debian developrs. For non DDs, I would want a DD involved > in our GPU ecosystem (like yourself) to confirm the people doing the > work have the necessary skills. > We'd ask that people write regular status reports to let us know how our > money is helping Debian. > See https://wiki.debian.org/Teams/DPL/AskingForMoney for initial > instructions on such requests. > That links to a reimbursements page with the formal process. What about AMD sponsoring Debian via providing GPU to the Debian community, whcih should be added to the buildd or in a porterbox ? Frederic
RE:GPU-ready (with free driver) buildd/CI/porterbox?
It would be nice also to be able to test the OpenCL icd implementations and work with real hardware.
RE:GPU-ready (with free driver) buildd/CI/porterbox?
> That is mostly upstream's job -- ICD packagers should just verify that the > package still runs "Hello World" on their hardware, i.e. the ICD > integration works, and then we assume that it works. ok, so in that case it would be nice to provide a computer with a GPU as porterbox to test this hello world. Since we are using a lot of autopkgtest, this should be available for these integrations tests. Fred
RE:Salsa update: no more "-guest" and more
do we have some documentation explaining how to use a nitrokey PRO in order to do 2FA authentication for salsa ? It seesm that ybikey is suppoprted out of the box, but inevertheless is it possible to use a nitrokey pro 2 for the same purpose ?
RE:Salsa update: no more "-guest" and more
Is it possible to use it's ssh key in order to have acces to the salsa api ? I mean instead of the token, which looks to me quite fragile compare to ssh via a gpg card and the gpg agent. cheers Frederic
RE:Salsa update: no more "-guest" and more
> If you use ssh, you can create an own account for the ssh key and give > it very special permissions, if you need it for automatic pushes or > similar things. In fact I would like to use the salsa command from devscripts but without the token. My private ssh key was generated from my private gpg key inside my nitrokey pro card. Is it possible ?
