Re: adduser claims existing diretory in postinst when running piuparts for shiny-server
Hi, On Fri, 2022-05-20 at 09:37 +0200, Andreas Tille wrote: > the Debian Science team has packaged node-shiny-server[1]. > It creates a system user in its postinst script. I've added > some debug output to this script[2] since I wanted to debug > a piuparts issue which you can see here in salsa CI[3]. > > This log shows two ways to verify that the home directory > of the user does not exist, but adduser fails with > > Stopped: Couldn't create home directory `/home/shiny': File > exists. > > anyway. > > Any idea what's going on here and how to fix this? It seems wrong for a system user to use a directory below /home. Ansgar
Re: RFS: source-only upload of opm-{grid,simulators,upscaling}/2021.10-2
Hi Markus, On Mon, 2022-02-21 at 15:55 +0100, Markus Blatt wrote: > > > opm-upscaling build-depends on missing: > > > - libsuperlu3-dev:amd64 (>= 3.0) > > > > Can you check+fix this? > > [...] > > No need to list it again and I removed the offending entry: > > Build-Depends: ..., libsuperlu3-dev (>= 3.0) | libsuperlu-dev (>= > 4.3), ... > > Maybe buildd is different and does not allow packages that do not > exist? To get reliable build results, the buildd network removes alternative build dependencies when building for unstable; only the first alternative is used. They are only used for the *-backports and experimental suites (I admit I'm not sure about stable uploads, but they should *not* be used there). As usual there is a small exception: if you have Build-Depends: a [i386] | b | c then the `a [i386]` is discarded on non-i386 earlier, that is, one would get "a" on i386 and "b" everywhere else. See the `RESOLVE_ALTERNATIVES` option in man:sbuild.conf(5) for more details. Ansgar
Re: RFS: opm-common/2021.10-1 [QA] -- Tools for Eclipse reservoir simulation files
Hi, On Fri, 2022-01-21 at 21:10 +0100, Markus Blatt wrote: > Fix the issue with libfmt8 and the package builds find on salsa-ci > (except for puiparts, > which fails) and my chroot. Furthermore I can successfully build opm- > material with it on > salsa-ci (only piuparts fails). I uploaded the package. > Do I need to do something for opm-material or will that get resolved > automatically? The build service should automatically note when the dependency gets installable. However, the package will need a source-only upload (no changes) to be allowed to migrate to testing. Ansgar
Re: dropping python2 [was Re: scientific python stack transitions]
Thomas Goirand writes: > On 7/7/19 5:31 PM, Matthias Klose wrote: >> you can start dropping it now, however please don't drop anything yet with >> reverse dependencies. So leaf packages first. > > I'm sorry, but I think I need to contest this. Doing things in order, > first leaf, then go all the way back, will take too long, and this is > IMO unnecessary effort. Older binary packages will anyway stay in the > archive as long as they are needed, and no FTP hint is added (please > correct me if I'm wrong here... but that's what I saw in the past). Packages usually don't migrate to testing if they cause packages to be uninstallable which will happen if you start breaking reverse dependencies. Will that be the case here? > You've done some pretty destructive transitions yourself for other > stuff, so why should we bother on this simple case? Removing an entire language isn't a simple case, even less so when doesn't mean we just remove all packages written in said language (as the source packages all build for a different language as well). Ansgar
Re: @salsa-pipeline-guest Developer access for Debian science.
PICCA Frederic-Emmanuel writes: > I would like to know if you are ok, if I grant a Developer acces to > salsa-pipeline-guest for the science-team. > I would like to use this [1], for my packages. > [1] https://salsa.debian.org/salsa-ci-team/pipeline Why does a CI system need to push branches and open merge requests? Ansgar
Re: New GitLab-Salsa service and Debian-Science Team
Hi, Anton Gladky writes: > thanks for an excellent tip! I have updated my migration-script > to create these pre-receive-hook. > > I will then start to migrate projects now to escape mixing migration > state between salsa and alioth. This is non-invasive, so if somebody > is against of it - it can easily be reverted. There are a few entries in /git/debian-science/packages that are symlinks. Please don't import them twice on salsa. Ansgar
Re: Upcoming new round of R package rebuilds [FWD: [Rd] R-devel object header changes that require reinstalling packages]
On Wed, 2017-09-20 at 11:34 +0200, Sébastien Villemot wrote:
> It consists in bumping the "r-api-3" value to "r-api-3.4", or "r-api-
> 3a" (or basically whatever you want, as long as it is different from
> previous values).
>
> This takes less than 5 minutes of your time, is clean and robust, and
> solves the whole issue.
I agree that this seems to be the best solution. That was also
suggested by the release team, but for some (unexplained) reason was
not done.
> I know you don’t consider this issue as an ABI break, but this is a
> rather theoretical debate. In practice this proposed change does the
> job.
>
> Then the Release Team will schedule binNMUs for all R reverse
> dependencies, and everything will migrate to testing. Of course this
> means more rebuilds than strictly necessary, but who cares?…
> computing resources are cheap.
That is also the case for most other ABI changes: most often only a few
functions are affected, but everything has to be rebuilt when the
soname of a library changes (or the r-api-${x} here), even when not
using the interface that actually changed.
Ansgar
Re: failure uploading new version of dijitso
Hi,
Drew Parsons writes:
> Johannes Ring is the upstream author and a Debian Maintainer (but not
> full DDeveloper). We're lucky to have him so closely involved in the
> Debian maintenance of dijitso and the other FEniCS packages.
>
> Lately Johannes tried to upload dijitso 2017.1 to experimental but the
> system blocked him, citing insufficient permissions. Certainly I could
> do the upload but we wanted to understand what the block was.
Debian Maintainers can only upload packages they have been explicitly
granted permission to upload. Nobody has allowed Johannes to upload
dijitso (see the current permissions at [1]), so the upload gets
rejected.
To grant DMs upload permissions, any DD can either use `dcut` from
`dput-ng` or manually write a *.dak-commands file[2] and upload it.
dak will then update the ACL and send a confirmation message by mail.
The .dak-commands file should look something like this:
+---
| Archive: ftp.debian.org
| Uploader: Drew Parsons <dpars...@debian.org>
|
| Action: dm
| Fingerprint: ${40 hexdigits fingerprint of the DMs PGP key}
| Allow: dijitso
+---[ dparsons-20170808-2227.dak-commands ]
Ansgar
[1] <https://ftp-master.debian.org/dm.txt>
[2] <https://lists.debian.org/debian-devel-announce/2012/09/msg8.html>
Re: RFS: gpaw/0.10.0.11364 ITP -- DFT and beyond within the projector-augmented wave method
On 07/22/2015 04:11 PM, Andreas Tille wrote: Moreover I'm afraid ftpmaster will not accept this package since there is a policy to refuse new Python 2 only packages. Huh? Since when should there be such a policy? Ansgar -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/55afb633.60...@debian.org
Re: Mpich 1/2/3
Anton Gladky gl...@debian.org writes: 2013/7/4 Torquil Macdonald Sørensen torq...@gmail.com: However, I have a question concerning multiarch and update-alternatives: In libmpich-dev.postinst, update-alternatives requires the library file paths as arguments. These paths include DEB_HOST_MULTIARCH, so the command dpkg-architecture is needed. So it seems that libmpich-dev must depend on dpkg-dev to solve this problem? Is this acceptable, or is there some another solution? I had never yet such situation. But I think it is OK to add dpkg-dev into Depends-section if it is necessary. You can determine the architecture at build time and generate a postinst using this information. Binary packages shouldn't have to use dpkg-architecture. Ansgar -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obaegy0q@deep-thought.43-1.org
Re: Stupid fumble with bug numbers
Sylvestre Ledru sylves...@debian.org writes: On 17/03/2013 09:56, Julien Puydt wrote: That is what I did to reopen the bug ; but for closing the real one, is it the best course of action? you can do: 702898-d...@bugs.debian.org Ideally with a Version: version header at the beginning of the message so the BTS knows in which version the bug was fixed. or mail cont...@bugs.debian.org with fixed 702898 version thanks Marking a bug as fixed alone in a version doesn't close the bug. Ansgar -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjy2gzo4@deep-thought.43-1.org
Re: Mathgl upload
Anton Gladky gladky.an...@gmail.com writes: no, I did not tried an uploading of an existing package, which should go to a NEW queue due to a new binary packages in it. I just heard[1], that this new DM-interface should allow such action. = ... Any DD may use this to grant/revoke upload permissions to existing packages (ie. at least in NEW); ... = DDs can grant upload permission starting when a new package is in the NEW queue (ie. as soon as dak knows about the package), but the rules for DM uploads still do not allow uploads to NEW. Ansgar -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/857gpmg0ql@tsukuyomi.43-1.org
Re: yorick_2.2.02+dfsg-3_i386.changes REJECTED
Hi, Andreas Tille andr...@an3as.eu writes: could you please explain? It was me Andreas Tille ti...@debian.org who did the actual upload as sponsor. You signed -2 which landed in NEW. Thibaut Paumard signed -3 which was still NEW (as -2 was not accepted yet) and thus the upload was rejected. As yorick-full is now in unstable, Thibaut should now be able to upload the updated package. Ansgar -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fw9pcbe4@deep-thought.43-1.org
Re: Please check whether your package is mentioned in tasks files
Hi, [ Cc'ed admin@ as they were Cc'ed in a later mail in the thread. ] Picca Frédéric-Emmanuel writes: picca@ORD03037:~/Debian/main/debian-science/debian-science$ git svn dcommit --username picca Committing to svn://svn.debian.org/blends/projects/science/trunk/debian-science ... ^ Autorisation refusée: Authorization failed at /usr/lib/git-core/git-svn line 4970 what is wrong ? You can only commit via svn+ssh://. The svn:// scheme is read-only (for Alioth). Ansgar -- To UNSUBSCRIBE, email to debian-science-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txyfhciv@deep-thought.43-1.org
