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: 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
Offre de strage au Synchrotron-Soleil: autopkgtest
Bonjour, le synchrotron-Soleil propose un stage[1] de 3 à 6 rémunéré, afin de mettre en place des tests unitaires et d’intégration sur un ensemble de logiciels [2] considérés comme prioritaires pour l’exploitation des données scientifiques. Bonne journée Frédéric [1] https://www.synchrotron-soleil.fr/fr/emplois/stage-informatique-scientifique [2] https://salsa.debian.org/pan-team/soleil-packaging-overview
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: 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: 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: 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
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: 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: 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: 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
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
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
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: where can I find the binNUM informations ?
thanks a lot. cheers Fred
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=3.3.4-2%2Bb1=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:Bug#996203: ITP: ifeffit -- Interactive XAFS analysis program
https://en.wikipedia.org/wiki/X-ray_absorption_fine_structure See you
RE:Possible DEP proposal - contribution preferences
cme should not use wrap-and-sort instead of implementing its own logic ?
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:How does one package a multirepo project?
what about the git mode of uscan then you would have all the tags ?
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 ?
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
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: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: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?
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:source only upload with git-buildpackage
And what about dgit --gbp push-source ?
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:Generating new IDs for cloning
did you tried this https://codesearch.debian.net/search?q=machine-id=1=1
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: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: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: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: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: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: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: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:[Idea] Debian User Repository? (Not simply mimicing AUR)
now we have the salsa pipeline. does it fit your needs ?
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:Salsa token and privacy
> You can still use SSH to do repository operation. But I don't know what > kind of automation you are doing. I just want to configure CI parameters especially the .gitlab.yaml location used by the CI. for a bunch of packages. > You talked about automation. Such tasks usualy run on a pre-defined > system. So I don't know why you need to have the credentials for this > task on many computers. At my work, I need to used different public computer located at different locations. I do notwork only fromon computer. this is why I like a lot the GPG key solution. > You can always use the encryption key functionality to decrypt the > token. ok, so now i just need to store the encrypted token :). I already do this via propellor in order to checkout private repository on another gitlab instance. But my question was more about using the API to do configuration, not only retrieving public informations. Cheers Frederic
Salsa token and privacy
Hello, I was using a nitrokey pro + gpg-agent in order to connect via ssh to the debian infrastructure. Now that we have salsa, it seems that the way to go is to use salsa token in order to automake a bunch of tasks. So now I need to put somewhere on a disk my salsa token, in fact on every computer where I want to use this token. And it means a lot. I would like to have something like the previous setup where all my private information are stores on the nitrokey. do you know if the salsa api (in fact gitlab api) can be access more securely than via a token which is copied multiple times everywhere. and if not how are you dealing with this ? Frederic PS: Nothing polemic here please, I have just this concern about the token privacy.
RE:unstable -> testing migration and arch
> from the maintainer. Please request your package to be removed from the > arch it doesn't build for anymore (bug against ftp.debian.org, use > reportbug) in unstable and britney will migrate that. done https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905348 thanks for your feedback Fred
unstable -> testing migration and arch
Hello, I hope that I use the right mailing list for this. Here my problem: I just updated the pymca package and this new version dependes on the python[3]-silx modules. silx depends on pyopenCL which is only available on a limited amount of architecture. So now the migration of pymca is blocked because it doe not build on arch it previously built. I am wondering if britney could not take this into account when evaluating a package, and could automatically reduce the list of arch for the pymca package due to this new build dependency. right ? or I am missing something ? cheers Frédéric
RE:Feedback request about the Alba Upstream to Debian packaging effort
>> It just comes to my mind that Maybe it does not fit well with my convention >> for exeprimental numbering whcih is >> blablab_x.y.z-t~exp1 >> so maybe the best way would be to use >> blalbla_x.y.z-t~~alba+1 >So, you would not use the "bpo9" part for the packages built for stretch? Not at all, I would use the bpo, this is just that sometimes we use experimental in order to prepare transitions. And I use ~expN which is > ~alba+N So I am wondering if you want to create blabla_x.y.z-t~exp1~alba+1 just wondering. Cheers Fred
RE:Feedback request about the Alba Upstream to Debian packaging effort
Hello Ian > I didn't have a massive amount of time to review this in detail, but > it sounds cool. I looked at the slides in the pdf [5] above. > (Shame there isn't a technical report...) the technical part is in the gitlab-ci.yml file :). > I reviewed the version number proposal and it seems sound to me. It just comes to my mind that Maybe it does not fit well with my convention for exeprimental numbering whcih is blablab_x.y.z-t~exp1 so maybe the best way would be to use blalbla_x.y.z-t~~alba+1 > I have some observations: > You probably want to keep the delta between the upstream and the > debianised branch as small as possible. Yes you are right this should be kept as small as possible. > On build systems and debian/ruless: if (i) you can get as much of your > upstream build system looking as standard as possible (ii) you can get > as much of the rest supported by dh as possible, then your > debian/rules files could possibly be very small indeed. Yes > debian/changelog is a bit of a pain and you will have to write code to > generate it. [gbp-]dch can be helpful. gbp allows to generate this automatically, but this is true that the quality of the changelog is not necessary good. Most of the time because the commit are not that great either... > Ideally you would treat debian/control as an output file: generate it > entirely from upstream stuff, using some tool, and commit the result > as a committed-artefact to the debianised branch. I agreed with you that it would be great to have a way to generate a debian package from the upstream git repository and some minimalist metadata purely descriptive. > Your debianisation tool becomes part of the source code for your > packages. You need to publish it in your repository, track the > version used, etc. So it probably needs to be debianised. I think > you need to mention it in Built-Using or something similar. good point, but for now this is just the gitlab file. Do you think that the guix way can be modified in order to generate Debian packages instead of guix binaries ? I like a lot the idea to maintain only the metadata in a repository. Indeed in our case scientific software are most of the time not that standard and need lot's of tweak in order to be packages. > Finally, and VERY CONTROVERSIALLY: consider whether you want to bother > with source packages. You could just use git branches instead. > Source packages are a pain. Just use dgit ;) > Good luck and have fun! thanks Frederic
Feedback request about the Alba Upstream to Debian packaging effort
Hello, the Alba[1] synchrotron radiation facilities, recently switch to Debian for their OS. They are part of the Tango[2] control system community which contain most of the European Synchrotron Radiation Facilities and others[3]. At least three instituts have already choosen Debian (partially Soleil, ESRF, petraIII, and Alba). The next meeting of this community will be held in Prague[4] next week. During this meeting, Alba will present their plan about packaging "Collaborative and automated Packaging"[5]. The idea is to propose a pipeline via a .gitlab-ci.yml[6] file which should be added to the upstream repository and/or in a repository dedicated to packaging, in order to generate debian packages ready to install software on their facility or ready to upload into Debian. Since I am not at all a specialist of gitlab-ci, I would like your advice on the pipeline, and also on the numbering scheme propose by Alba. In fact all feedback which should smooth the upstream to debian flow. Thanks for considering. Frederic Ps: Please keep the CC, they are not yet subscribers of debian-devel [1] https://www.cells.es/en [2] http://www.tango-controls.org/ [3] http://www.tango-controls.org/partners/institutions/ [4] https://indico.eli-beams.eu/event/310/other-view?view=standard#20180605.detailed [5] https://people.debian.org/~picca/CollabPkg-v3.pdf [6] https://people.debian.org/~picca/gitlab-ci.yml
RE:Auto-update for sid? Auto-backport?
> If an upstream author knows their code will go straight into an active > Debian suite when they push a git tag to GitHub, the trust dynamic is > changed, I think for the worse. this is the model of travis no ?, the upstream could become also the debian maintainer. And check that his package build properly on Debian. They are doing the work for travis, appveyor, gitlab-ci etc.. and why not Debian ? Cheers Frederic
RE:How to start a new packaging team now?
> Now that Alioth is beginning to close down and its replacement is not > yet ready, how would I start this team now? What is the status of this migration ? which solution was selected ? thanks Frederic
RE:Keysafe dynamic UID
> Also renaming a user is actually trivial: > usermod -l _something Debian-something In my case (tango-db package), We need also to take care of the user database access privilege. granted by dbconfig-common. So when moving from tango -> _tango users, they should be availalbe a sort of hook available for other packages in order to deal with theses user renames Cheers Frederic
RE:EOL of fglrx-driver
Hello, first thanks for your hard work. I am using fglrx-driver for OpenCL on my W5100 and W7100 amd GPUs. Do you know if there will be a plan in order to support OpenCL on amd for strech ? Cheers Frederic
Is there a problem with the build all infra of experimental ?
Hello, I did a source upload yesterday of the 9.2.2-1~exp1 into experimental and since then the all part of the package do not build with a strange error [1]. This package contain a Build-Depends-Indep part. I tested it with sbuild and and it was ok last week. (unstable sbuild not experimental) but now. The following packages have unmet dependencies: apt : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed aspcud : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.9) but it is not going to be installed clasp : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed cpp : Depends: cpp-5 (>= 5.3.1-3~) but it is not going to be installed doxygen : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 4.4.0) but it is not going to be installed g++ : Depends: g++-5 (>= 5.3.1-3~) but it is not going to be installed Depends: gcc-5 (>= 5.3.1-3~) but it is not going to be installed gcc : Depends: gcc-5 (>= 5.3.1-3~) but it is not going to be installed gettext : Depends: libgomp1 (>= 4.9) but it is not going to be installed gringo : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed groff-base : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libapt-pkg5.0 : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed libaspell15 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.6) but it is not going to be installed libboost-regex1.58.0 : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed libboost-signals1.58.0 : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed libc6 : Depends: libgcc1 but it is not going to be installed libclang1-3.6 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed Depends: libstdc++-5-dev but it is not going to be installed Depends: libgcc-5-dev but it is not going to be installed libcos4-1 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libenchant1c2a : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libharfbuzz-icu0 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libhunspell-1.3-0 : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed libicu55 : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed libllvm3.6v5 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 5.2) but it is not going to be installed liblua5.2-0 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libmysqlclient18 : Depends: libgcc1 (>= 1:3.0) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libmythes-1.2-0 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libobjc-5-dev : Depends: gcc-5-base (= 5.3.1-12) but it is not going to be installed Depends: libgcc-5-dev (= 5.3.1-12) but it is not going to be installed libobjc4 : Depends: gcc-5-base (= 5.3.1-12) but it is not going to be installed Depends: libgcc1 (>= 1:3.3.1) but it is not going to be installed libomniorb4-1 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libomnithread3c2 : Depends: libgcc1 (>= 1:4.1.1) but it is not going to be installed Depends: libstdc++6 (>= 4.1.1) but it is not going to be installed libpoppler57 : Depends: libstdc++6 (>= 4.9) but it is not going to be installed libqtcore4 : Depends: libgcc1 (>= 1:3.0)
RE:Creating directory /sbuild-nonexistent/.lyx/
> please file bugs if you find other packages which try to access $HOME during > the build process. ok,I will do a bug report. Cheers Fred
Creating directory /sbuild-nonexistent/.lyx/
Hello, I am preparing the next tango package, so I need to build the doc with lyx. But then I get this error message. make[5]: Entering directory '/<>/tango-9.2.0~a+dfsg/build/doc/src' cd ../../../doc/src; /usr/bin/lyx --export pdf2 tango.lyx LyX: Creating directory /sbuild-nonexistent/.lyx/ Failed to create directory. Exiting. it seems that lyx try to create a default config directory but It can not. I know how to prevent this with the -userdir parameter of lyx, but I would like to now if this is not a bug in sbuild ? what is the expected behavious from sbuild when something try to create a config file in the home of sbuild. I suspect that lyx is not the only software which create this kind of files. cheers Frederic
RE:dbconfig-common: near future change in dependency stack
Hello Paul > Can you please point me to the relevant discussion? I speak about this [1] > Actually, I don't think that is in scope of dbconfig-common. I would > rather expect that MariaDB would provide that functionality. It is > required for more packages and situations than just those supported by > dbconfig-common. I understand. > There must be a misunderstanding here (and I would like to learn where > it comes from). dbconfig-no-thanks does NOTHING to get in the way of any > database. The ONLY thing that it does it prevent dbconfig-common from > managing the database for the package that depends on the > dbconfig-common framework. As the description reads now: > """ ok thanks for the clarification, now I understand better what this no-thanks package is meant for. > If a package relies on the dbconfig-common framework for database setup > and maintenance, installing dbconfig-no-thanks instead of one of > dbconfig's database-specific packages will block this function. It is > intended for cases where the system administrator desires or requires > full control of the database or where dbconfig-common makes bad choices, > and typically leaves the depending packages non-functional until > manually configured. > """ If the no-thanks package is installed, what could be expected from the package maintainer in order to deal with the system administrator database mis configuration. We just need to let the package un-configure in order to explain that the database is wrongly configure. Do we have something in dbconfig-common whcih could say, here ok I do not manage the database but with this sysadmin database configuration, the package is not working. > I am not sure what exactly you want, but you CAN'T use the > dbconfig-common framework to prevent installation of MySQL, it is not > intended for that. With dbconfig-no-thanks installed ANY package that > relies on the dbconfig-common framework will not configure its database. > Without installing dbconfig-no-thanks, you can still (as has always been > the case) opt-out of dbconfig-common support per package, but this > requires either preseeding or responding to the corresponding debconf > question. ok, it is clearer Frederic [1] https://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2016-January/008605.html
RE:dbconfig-common: near future change in dependency stack
Hello thanks a lot for your work on dbconfig-common. I am the maintainer of tango-db which use dbconfig-common and a mysql database. It seems that there is currently a discussion about he support of mysql and mariadb for Debian 9 Do you know if dbconfig-common will integrate a way to switch from mysql to mariadb in the near futur. something whcih can help do the migration database from mysql to mariadb. Also, I have the feeling that the new dbconfig-no-thanks is too coarse. It mean no database of any kind supported by dbconfig-common could be install on this machine. But I would like to express, no mysql on my computer, but I could allow postgresql for other packages. Is it possible to have this use case and how should we instrument our package for this? once again thanks for your work Frederic
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
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: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: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: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: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
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
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=pytangoarch=mipselver=8.1.5-1stamp=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
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
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 download 2 packages ... 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: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: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
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: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
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
problem with source format 3.0 (quilt) and binary files
Bonjour, Je suis en train de travailler sur le paquet spyder. Pour l'ajout du support python3, j'ai crée un patch qui contient un fichier binaire (une icone). L'idée pour moi est de préparer un patch contenant tout le necessaire pour que je puisse ensuite l'envoyer à l'upstream. J'utilise git-buildpackage pour gérer ma patch queues. une fois les modifications faites, j'ai ce type d'erreur à la construction du package. Est-ce un problème dans dpkg ? si non qu'elle est la bonne façon de procéder merci Frédéric dpkg-source: info: utilisation du format source « 3.0 (quilt) » diff: standard output: Broken pipe diff: standard output: Broken pipe diff: standard output: Broken pipe diff: standard output: Broken pipe diff: standard output: Broken pipe diff: standard output: Broken pipe dpkg-source: erreur: fichier binaire non souhaité : debian/patches/0002-forwarded-upstream-deal-with-python3-file-installati.patch dpkg-source: erreur: 1 fichier binaire non souhaité a été détecté (il est nécessaire de l'ajouter dans debian/source/include-binaries pour autoriser son inclusion). dpkg-buildpackage: erreur: dpkg-source -i -b spyder a produit une erreur de sortie de type 29 debuild: fatal error at line 1364: dpkg-buildpackage -rfakeroot -D -us -uc -i failed -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a2a20ec3b8560d408356cac2fc148e53b1de4...@sun-dag3.synchrotron-soleil.fr
Bug#602554: ITP: guidata -- dataset manipulation GUI generator
Package: wnpp Severity: wishlist Owner: Picca Frederic-Emmanuel pi...@synchrotron-soleil.fr * Package name: guidata Version : 1.2.2 Upstream Author : pierre.rayb...@cea.fr 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 pi...@synchrotron-soleil.fr * Package name: guiqwt Version : 2.0.4 Upstream Author : pierre.rayb...@cea.fr 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
Bug#569153: ITP: libhkl -- diffractometer computation control library
Package: wnpp Severity: wishlist Owner: Picca Frederic-Emmanuel pi...@synchrotron-soleil.fr * Package name: libhkl Version : 4.0.0 Upstream Author : Picca Frédéric-Emmanuel pi...@synchrotorn-soleil.fr * 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
