Re: Reviving schroot as used by sbuild

2024-06-25 Thread PICCA Frederic-Emmanuel
> 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

2024-06-19 Thread PICCA Frederic-Emmanuel
> 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

2024-05-27 Thread PICCA Frederic-Emmanuel
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)

2024-05-22 Thread PICCA Frederic-Emmanuel
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?

2024-05-21 Thread PICCA Frederic-Emmanuel
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

2024-04-02 Thread PICCA Frederic-Emmanuel
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.

2024-01-03 Thread PICCA Frederic-Emmanuel
> 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

2023-08-05 Thread PICCA Frederic-Emmanuel
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?

2023-08-01 Thread PICCA Frederic-Emmanuel
> 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

2023-07-20 Thread PICCA Frederic-Emmanuel
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

2023-07-20 Thread PICCA Frederic-Emmanuel
> 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

2023-07-20 Thread PICCA Frederic-Emmanuel
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

2023-07-13 Thread PICCA Frederic-Emmanuel
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

2022-01-04 Thread PICCA Frederic-emmanuel


> > 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 ?

2021-12-24 Thread PICCA Frederic-emmanuel
thanks a lot.

cheers 

Fred



where can I find the binNUM informations ?

2021-12-24 Thread PICCA Frederic-emmanuel
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

2021-10-12 Thread PICCA Frederic-Emmanuel
https://en.wikipedia.org/wiki/X-ray_absorption_fine_structure

See you


RE:Possible DEP proposal - contribution preferences

2021-02-09 Thread PICCA Frederic-Emmanuel
cme should not use wrap-and-sort instead of implementing its own logic ?


RE:deduplicating jquery/

2020-12-01 Thread PICCA Frederic-Emmanuel
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?

2020-10-19 Thread PICCA Frederic-Emmanuel
what about the git mode of uscan

then you would have all the tags ?



RE:Salsa update: no more "-guest" and more

2020-04-28 Thread PICCA Frederic-Emmanuel
> 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

2020-04-28 Thread PICCA Frederic-Emmanuel
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

2020-04-26 Thread PICCA Frederic-Emmanuel
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?

2019-11-19 Thread PICCA Frederic-Emmanuel
> 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?

2019-11-19 Thread PICCA Frederic-Emmanuel
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?

2019-11-19 Thread PICCA Frederic-Emmanuel
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

2019-10-06 Thread PICCA Frederic-Emmanuel
And what about

dgit --gbp push-source ?


RE:devscripts uninstallable in Debian Sid due to unmet dependencies

2019-10-06 Thread PICCA Frederic-Emmanuel
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

2019-08-08 Thread PICCA Frederic-Emmanuel
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

2019-07-25 Thread PICCA Frederic-Emmanuel
> 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

2019-07-23 Thread PICCA Frederic-Emmanuel
> $ 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?

2019-06-17 Thread PICCA Frederic-Emmanuel
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)

2019-05-28 Thread PICCA Frederic-Emmanuel
> 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

2019-05-28 Thread PICCA Frederic-Emmanuel
[...]
> 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"

2019-05-24 Thread PICCA Frederic-Emmanuel
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

2019-05-07 Thread PICCA Frederic-Emmanuel
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)

2019-04-08 Thread PICCA Frederic-Emmanuel
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)

2019-04-08 Thread PICCA Frederic-Emmanuel
now we have the salsa pipeline.

does it fit your needs ?



RE:Namespace for system users

2019-02-10 Thread PICCA Frederic-Emmanuel
> 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

2018-08-07 Thread PICCA Frederic-Emmanuel
> 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

2018-08-06 Thread PICCA Frederic-Emmanuel
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

2018-08-03 Thread PICCA Frederic-Emmanuel
> 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

2018-08-03 Thread PICCA Frederic-Emmanuel
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

2018-06-04 Thread PICCA Frederic-Emmanuel
>> 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

2018-06-03 Thread PICCA Frederic-Emmanuel
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

2018-06-02 Thread PICCA Frederic-Emmanuel
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?

2017-11-15 Thread PICCA Frederic-Emmanuel
> 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?

2017-09-15 Thread PICCA Frederic-Emmanuel
> 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

2016-10-23 Thread PICCA Frederic-Emmanuel
> 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

2016-05-04 Thread PICCA Frederic-Emmanuel
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 ?

2016-03-19 Thread PICCA Frederic-Emmanuel
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/

2016-02-28 Thread PICCA Frederic-Emmanuel
> 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/

2016-02-28 Thread PICCA Frederic-Emmanuel
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

2016-01-30 Thread PICCA Frederic-Emmanuel
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

2016-01-30 Thread PICCA Frederic-Emmanuel
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

2015-08-19 Thread PICCA Frederic-Emmanuel
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

2015-07-29 Thread PICCA Frederic-Emmanuel
 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

2015-07-24 Thread PICCA Frederic-Emmanuel
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

2015-07-18 Thread PICCA Frederic-Emmanuel
 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

2015-05-26 Thread PICCA Frederic-Emmanuel
 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

2015-02-18 Thread PICCA Frederic-Emmanuel
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

2014-11-07 Thread PICCA Frederic-Emmanuel
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

2014-10-04 Thread PICCA Frederic-Emmanuel
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

2014-08-26 Thread PICCA Frederic-Emmanuel
 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

2014-08-26 Thread PICCA Frederic-Emmanuel
 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

2014-08-26 Thread PICCA Frederic-Emmanuel
 # 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

2014-08-13 Thread PICCA Frederic-Emmanuel
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

2014-07-03 Thread PICCA Frederic-Emmanuel
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 ?

2014-05-17 Thread PICCA Frederic-Emmanuel
 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 ?

2014-05-16 Thread PICCA Frederic-Emmanuel
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.

2014-04-19 Thread PICCA Frederic-Emmanuel
 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

2014-02-07 Thread PICCA Frederic-Emmanuel
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

2014-02-07 Thread PICCA Frederic-Emmanuel
 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

2014-02-07 Thread PICCA Frederic-Emmanuel
 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

2014-02-07 Thread PICCA Frederic-Emmanuel
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

2014-02-02 Thread PICCA Frederic-Emmanuel
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

2010-11-05 Thread Picca Frederic-Emmanuel
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

2010-11-05 Thread Picca Frederic-Emmanuel
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

2010-02-10 Thread Picca Frederic-Emmanuel
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