Bug#903617: ITP: equinox-framework -- Implementation of the OSGi Core Framework R4 specification
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: equinox-framework Version : 4.7.3 Upstream Author : Eclipse Foundation, Inc. * URL : http://www.eclipse.org/equinox/framework/ * License : EPL-1.0, Apache-2.0 Programming Lang: Java Description : Implementation of the OSGi Core Framework R4 specification The Equinox Framework component is tasked with being a full implementation of the OSGi Core Framework R4 specification. In addition, the Framework component produces launchers, bootstrap infrastructure and application models that facilitate the use of Equinox OSGi in end-user product scenarios. This package will be maintained by the Java Team. It's required to update the Eclipse ecosystem in Debian and complete the transition to Java 11.
Bug#903590: marked as done (general: REBOOT command shuts system off Pi3B+ without rebooting. Even kills the power, i.e. the red light on the Pi goes out)
Your message dated Wed, 11 Jul 2018 20:17:48 +0100 with message-id <20180711191748.gb20...@espresso.pseudorandom.co.uk> and subject line Re: Bug#903590: general: REBOOT command shuts system off Pi3B+ without rebooting. Even kills the power, i.e. the red light on the Pi goes out has caused the Debian Bug report #903590, regarding general: REBOOT command shuts system off Pi3B+ without rebooting. Even kills the power, i.e. the red light on the Pi goes out to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 903590: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903590 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: general Severity: grave Tags: d-i Justification: renders package unusable Dear Maintainer, * What led up to the situation? Updated to the late June 2018 release of Rasbian from March 2018 release * What exactly did you do (or not do) that was effective (or ineffective)? Reboot. * What was the outcome of this action? Shutdown my Pi 3B+, and corrupted my USB Boot HDD * What outcome did you expect instead? normal re-boot -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 9.4 (stretch) Release:9.4 Codename: stretch Architecture: armv7l Kernel: Linux 4.14.52-v7+ (SMP w/4 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_ZA.UTF-8), LANGUAGE=en_ZA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_ZA.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- On Wed, 11 Jul 2018 at 20:05:24 +0400, Jack wrote: > Distributor ID: Raspbian > Description: Raspbian GNU/Linux 9.4 (stretch) Raspbian is based on Debian, but it is not the same thing as Debian. Please contact Raspbian support channels for assistance with running Raspbian or to report bugs. Thanks, smcv--- End Message ---
Bug#903602: ITP: yaha -- find split-read mappings on single-end queries
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: yaha * URL : https://github.com/GregoryFaust/yaha * License : MIT Programming Lang: C/C++ Description : find split-read mappings on single-end queries Team-maintained on https://salsa.debian.org/med-team/yaha
Re: Research survey: Impact of Microsoft Acquisition of GitHub
Hi Wouter et al., > This questionnaire contains an error: Whilst I certainly appreciate your usual attention to detail and preciseness note that these questionnaires — whilst they appear to be quite free-software oriented or specific to us — are typically sent to 100s of different lists and communities at once. They, frankly, should probably be just ignored or be (loosely) categorised as spam. I get at least three or four a week these days.. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#903590: general: REBOOT command shuts system off Pi3B+ without rebooting. Even kills the power, i.e. the red light on the Pi goes out
Package: general Severity: grave Tags: d-i Justification: renders package unusable Dear Maintainer, * What led up to the situation? Updated to the late June 2018 release of Rasbian from March 2018 release * What exactly did you do (or not do) that was effective (or ineffective)? Reboot. * What was the outcome of this action? Shutdown my Pi 3B+, and corrupted my USB Boot HDD * What outcome did you expect instead? normal re-boot -- System Information: Distributor ID: Raspbian Description:Raspbian GNU/Linux 9.4 (stretch) Release:9.4 Codename: stretch Architecture: armv7l Kernel: Linux 4.14.52-v7+ (SMP w/4 CPU cores) Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_ZA.UTF-8), LANGUAGE=en_ZA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_ZA.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
Hi Julien, On Wed, Jul 11, 2018 at 05:18:18PM +0200, Julien Cristau wrote: > > Is there any smart way to obtain the latest activity time stamp? > > I don't know about smart, but each project has a last_activity_at > attribute which I'm assuming is an overapproximation of repository activity. Thanks, thats probably very helpful. I'll compare with Ian's hint. > > I'm happy that I explicitly mentioned this since it seems to help > > avoiding misinterpretations of my mails. > > > Does it? I still don't get why this is here. I think it turns out that not Salsa but my code is broken. So why should I bother Salsa admins with my broken code if I can get proper help here as well from people who are not known as Salsa admins to me? Kind regards Andreas. -- http://fam-tille.de
Re: Research survey: Impact of Microsoft Acquisition of GitHub
Hi, On Mon, Jul 09, 2018 at 02:13:13PM +0900, Asavaseri Natnaree wrote: > Dear Debian developers, > > I am Natnaree Asavaseri and currently undertaking a research internship at > Nara Institute of Science and Technology, Japan. Note that we are not biased > to either GitHub or Microsoft, and this is purely from an empirical research > perspective. > > As a part of my research in the field of Software Engineering (SE), my > professors and I are analyzing the impact of Microsoft's acquisition of > GitHub. The main purpose of my survey is understanding how developers > perceive the Microsoft's acquisition of GitHub, especially from contributors > to Linux distributions and BSD families. If the survey is successful, we will > publish our findings at SE academic venues (journals or conference). > > So please consider voicing your opinion by allowing us up to 5 minutes to > complete my short survey. > > https://goo.gl/forms/lbIL5qsinDRQyTaK2 This questionnaire contains an error: --- Which statement best describes your current situation with any of your contributed projects? * * The projects that I contribute to the most is currently using GitHub (currently using GitHub) * One of the projects that have made contributions has already left GitHub (used before but not now) * All projects that I contribute to have never used GitHub (none of the above) --- None of these options apply to me: - Debian does not use GitHub and has never done so (so the first option is not correct) - None of the projects that I contribute to have left github (so that is also not correct) - I do contribute to some projects that use github and continue to do so (so the last option is also not correct). Since it's marked as "none of the above" I suspect you really meant something else for that last option. Since it's also marked as a required option, I can't skip it, so I've chosen the last one -- but I suspect your answers on that question may be for some people. -- Could you people please use IRC like normal people?!? -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008 Hacklab
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On 07/11/2018 04:51 PM, Andreas Tille wrote: > On Wed, Jul 11, 2018 at 01:34:29PM +0200, Julien Cristau wrote: >> >> You could probably save yourself some trouble by not polling repos that >> have had no activity since you last looked at them. > > Is there any smart way to obtain the latest activity time stamp? I don't know about smart, but each project has a last_activity_at attribute which I'm assuming is an overapproximation of repository activity. >> You're also right that salsa support issues don't really belong on this >> list. > > I'm happy that I explicitly mentioned this since it seems to help > avoiding misinterpretations of my mails. > Does it? I still don't get why this is here. Cheers, Julien
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
Andreas Tille writes ("Re: Is Access to Salsa restricted to a certain number of
queries per time and host?"):
> on Alioth. But this does not work for remote repositories. May be
> I'm missing something but how can I do this by using
> git ls-remote
> ? I have not found out how to get the said files.
git-ls-remote does not get you the files. It can just tell you if the
ref you are interested in (HEAD, I guess) has been updated.
So your algorithm would be:
sleep 5
read https://salsa/blah HEAD`
if [ "x$current" = "x$last" ]; then exit 0; fi
... do stuff you currently do to fetch the individual files ...
printf >last-$package.new "%s\n" "$current"
mv last-$package.new last-$package
Ian.
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
Andreas Tille writes ("Re: Is Access to Salsa restricted to a certain number of
queries per time and host?"):
> On Wed, Jul 11, 2018 at 11:55:11AM +, Peter Palfrader wrote:
> > Or keeping a local clone and git pulling each of them over the course of
> > a week.
>
> Unfortunately I do not have access to a host that could store full
> clones of all those repositories which are potentially very large just
> to fetch 5-7 very small text files.
You could, however, cache the git revision, and then use git-ls-remote
to see if it had updated.
If you do that, and ratelimit your queries, you should not cause
operational difficulties for salsa, and I would guess you'll also not
get auto-blocked.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On Wed, Jul 11, 2018 at 07:55:57AM -0400, James McCoy wrote: > > You could probably save yourself some trouble by not polling repos that > > have had no activity since you last looked at them. > > Or by setting up a webhook[0] so the relevant repos can notify you when > there's a commit that changes the files you care about. I have no idea how I can organise that those webhooks are set on all those repositories which I do not necessarily have commit permissions myself. Teaching all members of those teams to add such web hooks does not seem a practical approach. Thanks for the tip anyway Andreas. > [0]: https://salsa.debian.org/help/user/project/integrations/webhooks.md -- http://fam-tille.de
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On Wed, Jul 11, 2018 at 11:55:11AM +, Peter Palfrader wrote: > > > > This could be done with gis-ls-remote, which is probably a lot more > > lightweight than Gitlab API calls. > > Or keeping a local clone and git pulling each of them over the course of > a week. Unfortunately I do not have access to a host that could store full clones of all those repositories which are potentially very large just to fetch 5-7 very small text files. Kind regards Andreas. -- http://fam-tille.de
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
Hi Ian,
On Wed, Jul 11, 2018 at 12:48:04PM +0100, Ian Jackson wrote:
> Julien Cristau writes ("Re: Is Access to Salsa restricted to a certain number
> of queries per time and host?"):
> > You could probably save yourself some trouble by not polling repos that
> > have had no activity since you last looked at them.
>
> This could be done with gis-ls-remote, which is probably a lot more
> lightweight than Gitlab API calls.
I admit I used
git ls-tree -r HEAD debian/
on Alioth. But this does not work for remote repositories. May be
I'm missing something but how can I do this by using
git ls-remote
? I have not found out how to get the said files.
Kind regards
Andreas.
--
http://fam-tille.de
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On Wed, Jul 11, 2018 at 01:34:29PM +0200, Julien Cristau wrote: > > You could probably save yourself some trouble by not polling repos that > have had no activity since you last looked at them. Is there any smart way to obtain the latest activity time stamp? > You're also right that salsa support issues don't really belong on this > list. I'm happy that I explicitly mentioned this since it seems to help avoiding misinterpretations of my mails. Kind regards Andreas. -- http://fam-tille.de
Bug#903582: ITP: mirtop -- annotate miRNAs with a standard mirna/isomir naming
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: mirtop * URL : https://github.com/miRTop/mirtop * License : MIT Programming Lang: Python Description : annotate miRNAs with a standard mirna/isomir naming Team-maintained on https://salsa.debian.org/med-team/mirtop
Re: SALSA migration of XML/SGML packages (sgml-data for me)
On 11/07/18 15:38, Osamu Aoki wrote: > Hi, > > On Sun, Jul 08, 2018 at 07:51:53PM +0300, Adrian Bunk wrote: >> On Sun, Jul 08, 2018 at 11:20:57PM +0900, Osamu Aoki wrote: > ... >> All this gives sgml-base impressive popcon numbers, but the actual usage >> is likely pretty limited. I'm sure we have users who still need tooling >> for SGML, but all this is now more a fringe area of the archive. > > You missed my point. I don't care about popcon. Problem is "Reverse > Build-depends in main". Try: > > --- > $ build-rdeps sgml-data > > Found a total of 1336 reverse build-depend(s) for sgml-data. wow, I get an entirely different number: $ build-rdeps sgml-data WARNING: dose-extra >= 4.0 is not installed. Falling back to old unreliable behaviour. Reverse Build-depends in main: -- qmtest python-ethtool Found a total of 2 reverse build-depend(s) for sgml-data. That says the results are unreliable, but manually checking dists/sid/main/Sources gives me the same thing. Cheers, Emilio
Re: SALSA migration of XML/SGML packages (sgml-data for me)
Hi, On Sun, Jul 08, 2018 at 07:51:53PM +0300, Adrian Bunk wrote: > On Sun, Jul 08, 2018 at 11:20:57PM +0900, Osamu Aoki wrote: ... > All this gives sgml-base impressive popcon numbers, but the actual usage > is likely pretty limited. I'm sure we have users who still need tooling > for SGML, but all this is now more a fringe area of the archive. You missed my point. I don't care about popcon. Problem is "Reverse Build-depends in main". Try: --- $ build-rdeps sgml-data Found a total of 1336 reverse build-depend(s) for sgml-data. ... --- This is the concern. I was wondering to place this package into simple Orphan state or assigning to a group ML address which seems to have almost no reader. This is what I was wondering. FYI: I have been lontime subscriber of debian-s...@lists.debian.org. Osamu
Bug#903575: ITP: equinox-bundles -- Implementation of add-on services defined in the OSGi specifications
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: equinox-bundles Version : 4.7.3 Upstream Author : Eclipse Foundation, Inc. * URL : http://www.eclipse.org/equinox/bundles/ * License : EPL-1.0 Programming Lang: Java Description : Implementation of add-on services defined in the OSGi specifications The Equinox Bundles project is tasked with implementing all add-on services detailed in the OSGi specifications including the output of the various OSGi Expert groups. For example, the Core Platform, Enterprise and Mobile Expert Groups. In addition, the bundles component team defines and produces bundles and services that are of general utility to OSGi systems and programmers. For example, the Bundles team is responsible for the Extenstion registry used throughout Eclipse. This package will be maintained by the Java Team. It's required to update the Eclipse ecosystem in Debian and complete the transition to Java 11.
Re: A message from CMake upstream: announcing dh-cmake
On Wed, 2018-07-11 at 08:57 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > But no, my real fear here was a tool more in the cpack kind. Years > ago we had packagers trying to get their stuff in by using cpack. > While it might be of some help for non official packages it was not > really fit for official ones. Yes, the idea here is to make something that is fit for official Debian packaging. > Kyle has made it really clear that they intend to support the various > realities they will probably face if people start using it everywhere > to create good quality packaging, so yes, I also applaud the > effort... now ;-) Thank you Lisandro! I'm glad I was able to address your concerns, and I think this has been a really good discussion. Ian, thanks for the feedback, and if you have minor technical questions please feel free to ask them, either on- or off-list :) I think it makes sense for dh-cmake to live primarily in VTK for now, and then, as we work out the issues, hopefully we will see other packages start to adopt it as well. I will keep everyone updated as both dh-cmake and the VTK packaging are developed. We are hoping for an official Debian release of both packages towards the end of the year. Kyle
Bug#903569: ITP: libbio-tools-run-alignment-clustalw-perl -- Bioperl interface to Clustalw
Package: wnpp Severity: wishlist Owner: David Miguel Susano Pinto * Package name: libbio-tools-run-alignment-clustalw-perl Version : 1.7.3 Upstream Author : bioperl * URL : https://metacpan.org/release/Bio-Tools-Run-Alignment-Clustalw * License : perl 5 Programming Lang: perl Description : Bioperl interface to Clustal W Bio::Tools::Run::Alignment::Clustalw provides a Perl interface to Clustal W, a program for alignment of multiple nucleotide or peptide sequences. This module distribution is part of the Bioperl project.
Re: A message from CMake upstream: announcing dh-cmake
El mié., 11 de jul. de 2018 07:33, Ian Jackson < ijack...@chiark.greenend.org.uk> escribió: > [snip] I really don't agree with the thrust of Lisandro's comments. AFAICT > what Lisandro is saying is this: because the upstream components may > not always be perfect; and even may be totally inappropriate; they are > useless or harmful for packaging for Debian. Now that you mention it I reckon it can be read that way, indeed. But no, my real fear here was a tool more in the cpack kind. Years ago we had packagers trying to get their stuff in by using cpack. While it might be of some help for non official packages it was not really fit for official ones. Kyle has made it really clear that they intend to support the various realities they will probably face if people start using it everywhere to create good quality packaging, so yes, I also applaud the effort... now ;-) Cheers, Lisandro.
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On Wed, Jul 11, 2018 at 01:34:29PM +0200, Julien Cristau wrote: > On 07/11/2018 10:18 AM, Andreas Tille wrote: > > Hi, > > > > I'm running a daily cron job on host blends.debian.net to gather machine > > readable data from all blends packages. The cron job fetches only the > > following files > > > > debian/changelog > > debian/control > > debian/copyright > > debian/README.Debian > > debian/upstream/edam > > debian/upstream/metadata > > > > (if the latter two exist) from about 2000 repositories. These data are > > consumed in UDD from where they are used in the Blends web sentinel. The > > script which is running can be found in Git[1]. > > > > Unfortunately the cron job seems to stop with > > > > Traceback (most recent call last): > > File "/usr/lib/python3/dist-packages/gitlab/exceptions.py", line 251, in > > wrapped_f > > return f(*args, **kwargs) > > File "/usr/lib/python3/dist-packages/gitlab/mixins.py", line 48, in get > > server_data = self.gitlab.http_get(path, **kwargs) > > File "/usr/lib/python3/dist-packages/gitlab/__init__.py", line 728, in > > http_get > > streamed=streamed, **kwargs) > > File "/usr/lib/python3/dist-packages/gitlab/__init__.py", line 706, in > > http_request > > response_body=result.content) > > gitlab.exceptions.GitlabHttpError: 429: b'Retry later\n' > > > > During handling of the above exception, another exception occurred: > > > > Traceback (most recent call last): > > File > > "/srv/blends.debian.org/misc/machine_readable/fetch-machine-readable_salsa.py", > > line 106, in > > project = gl.projects.get(pr.attributes['id']) # without this extra get > > repository_tree() fails > > File "/usr/lib/python3/dist-packages/gitlab/exceptions.py", line 253, in > > wrapped_f > > raise error(e.error_message, e.response_code, e.response_body) > > gitlab.exceptions.GitlabGetError: 429: b'Retry later\n' > > > You could probably save yourself some trouble by not polling repos that > have had no activity since you last looked at them. Or by setting up a webhook[0] so the relevant repos can notify you when there's a commit that changes the files you care about. [0]: https://salsa.debian.org/help/user/project/integrations/webhooks.md Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On Wed, 11 Jul 2018, Ian Jackson wrote:
> Julien Cristau writes ("Re: Is Access to Salsa restricted to a certain number
> of queries per time and host?"):
> > You could probably save yourself some trouble by not polling repos that
> > have had no activity since you last looked at them.
>
> This could be done with gis-ls-remote, which is probably a lot more
> lightweight than Gitlab API calls.
Or keeping a local clone and git pulling each of them over the course of
a week. Tens of thousands of requests at an instant, as you are doing,
is not just ..unsmart, it's abusive.
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `-https://www.debian.org/
Re: A message from CMake upstream: announcing dh-cmake
El mar., 10 de jul. de 2018 15:46, Kyle Edwards escribió: > On Tue, 2018-07-10 at 12:52 -0300, Lisandro Damián Nicanor Pérez Meyer > wrote: > > Well, there are cases when upstream is doing things the right way > > with respect to Debian but... what about derivatives (distributions > > which base themselves in Debian)? Sometimes they need something > > different, and even if the package fits perfectly well in Debian it > > might not be true for them. So they need to either patch CMake files > > or re do the whole packaging using traditional tools. > > I understand what you're saying. As a concrete example, we all know > that Debian requires *.so library symlinks to live in the -dev package. > But let's say there's a hypothetical Debian derivative that requires > them to live in the library binary package instead. > > If upstream has both the headers and the symlink in the "Development" > component, then this would certainly be a problem. Perhaps the solution > is for upstream to make this more flexible, through one of several > options: > [Snip] > > To sum it up: I *do* think there is a *huge* potential for this > > helper, just not for Debian proper. Of course I would *love* to see > > it packaged in Debian because it will help projects trying to create > > their own Debian packages, but I would expect a very clear > > explanation that this is not a suitable way to maintain packages in > > Debian proper. > > In fact, CPack already provides its own method for maintaining 3rd > party Debian packages - it has its own .deb generator. But dh-cmake is > our attempt to make something that fits better into the Debian > workflow, so that it *can* be used to maintain packages in Debian > proper. > > We want CMake packaging to be as easy as Python packaging, where you > just activate dh-python. The end goal of dh-cmake is to make CMake > packaging as easy as writing a few configuration files, and then > declaring "dh $@ --buildsystem=cmake --with cmake --with ctest --with > cpack". > > In our case, our goal is to maintain an official VTK package in both > Debian proper and Ubuntu proper. VTK is a huge project which has proven > to be difficult to package, and dh-cmake is being created to solve this > problem. We've also made changes to both VTK and CMake itself to > support the VTK packaging effort, and we can and will make more. > > > Except we can find smart work arounds for this cases, of course. > > I think making the component names configurable and/or standardized, as > I described above, would help tremendously with this. > I really applaud your effort. It's now clear to me that you are not trying to add just some logic around cpack but really are wanting to create a nice tool. I would say just keep on with vtk packaging and tackle other cases as they appear. Regards, Lisandro. >
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
Julien Cristau writes ("Re: Is Access to Salsa restricted to a certain number
of queries per time and host?"):
> You could probably save yourself some trouble by not polling repos that
> have had no activity since you last looked at them.
This could be done with gis-ls-remote, which is probably a lot more
lightweight than Gitlab API calls.
Ian.
Re: Is Access to Salsa restricted to a certain number of queries per time and host?
On 07/11/2018 10:18 AM, Andreas Tille wrote: > Hi, > > I'm running a daily cron job on host blends.debian.net to gather machine > readable data from all blends packages. The cron job fetches only the > following files > > debian/changelog > debian/control > debian/copyright > debian/README.Debian > debian/upstream/edam > debian/upstream/metadata > > (if the latter two exist) from about 2000 repositories. These data are > consumed in UDD from where they are used in the Blends web sentinel. The > script which is running can be found in Git[1]. > > Unfortunately the cron job seems to stop with > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/gitlab/exceptions.py", line 251, in > wrapped_f > return f(*args, **kwargs) > File "/usr/lib/python3/dist-packages/gitlab/mixins.py", line 48, in get > server_data = self.gitlab.http_get(path, **kwargs) > File "/usr/lib/python3/dist-packages/gitlab/__init__.py", line 728, in > http_get > streamed=streamed, **kwargs) > File "/usr/lib/python3/dist-packages/gitlab/__init__.py", line 706, in > http_request > response_body=result.content) > gitlab.exceptions.GitlabHttpError: 429: b'Retry later\n' > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File > "/srv/blends.debian.org/misc/machine_readable/fetch-machine-readable_salsa.py", > line 106, in > project = gl.projects.get(pr.attributes['id']) # without this extra get > repository_tree() fails > File "/usr/lib/python3/dist-packages/gitlab/exceptions.py", line 253, in > wrapped_f > raise error(e.error_message, e.response_code, e.response_body) > gitlab.exceptions.GitlabGetError: 429: b'Retry later\n' > You could probably save yourself some trouble by not polling repos that have had no activity since you last looked at them. You're also right that salsa support issues don't really belong on this list. Cheers, Julien
Bug#903559: ITP: eclipse-debian-helper -- Helper tools for building Eclipse related packages
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg * Package name: eclipse-debian-helper Version : 1.0 Upstream Author : Emmanuel Bourg * URL : https://salsa.debian.org/java-team/eclipse-debian-helper * License : Apache-2.0 Programming Lang: Perl Description : Helper tools for building Eclipse related packages This project contains helper tools to ease the packaging of Eclipse related projects. These projects often consist in a collection of bundles built with Tycho. Since Tycho isn't fully usable in Debian yet this package provides an alternative way of building the bundles using Ant. Eclipse Debian Helper provides an Ant macro designed to build a bundle and a debhelper buildsystem class to reduce the boilerplate in debian/rules. By convention we assume a one to one mapping between bundles and Debian packages. The package name is automatically derived from the bundle name. For example the org.eclipse.foo.bar bundle is packaged as libeclipse-foo-bar-java. Equinox packages are handled slightly differently, org.eclipse.equinox.foo is mapped to libequinox-foo-java. The binary packages carry the version of the bundle packaged. For example if the project eclipse-platform-foo 4.9.2 contains the version 1.2.3 of the bundle org.eclipse.foo, the version of the libeclipse-foo-java package will be 1.2.3+eclipse4.9.2-1. This package will be maintained by the Java Team.
Re: A message from CMake upstream: announcing dh-cmake
Kyle Edwards writes ("Re: A message from CMake upstream: announcing dh-cmake"):
> I understand what you're saying. As a concrete example, we all know
> that Debian requires *.so library symlinks to live in the -dev package.
> But let's say there's a hypothetical Debian derivative that requires
> them to live in the library binary package instead.
>
> If upstream has both the headers and the symlink in the "Development"
> component, then this would certainly be a problem. Perhaps the solution
> is for upstream to make this more flexible, through one of several
> options:
You have missed an option, which is for that derivative to use the
existing upstream components, and dh-cmake, etc., which put the
symlink in the wrong package for them, *and then to fix up that
wrinkle afterwards*.
This kind of thing is entirely normal in packaging.
I really don't agree with the thrust of Lisandro's comments. AFAICT
what Lisandro is saying is this: because the upstream components may
not always be perfect; and even may be totally inappropriate; they are
useless or harmful for packaging for Debian.
The usual case is that the upstream components are mostly right.
If they are slightly wrong, then the right thing to do is to fix them
(carrying the patch in Debian until it makes it through into the
appropriate upstream release), or if upstream don't want the fix for
any reason, to carry that patch forever, or to write a workaround
which fixes it up and carry that forever in debian/rules.
If there is a systematic mismatch, it is normally possible to invent a
systematic fixup. That is an alternative to adding a feature to the
upstream component system to do things differently.
We have taken all of these approaches in various packages. Which to
choose is a matter of judgement, and of course any one of them may be
inappropriate in particular circumstances. But that does not mean
that upstream component systems are harmful or dangerous or that they
should be discouraged or ignored. The usual case will be that it is
easiest to use the upstream component system and deal with any
problems with it in any one of the usual ways we deal with problems
with upstream functionality.
Given that upstream component systems will often be useful, especially
if they are done with a bit of care, it is a very good thing to have a
build tool which can use them automatically.
So, in summary, if I were packaging one of the pieces of software
which dh-cmake is aimed at, I would probably want to use it. Thanks,
Kyle (and your colleagues) for this work. This work sounds excellent
to me. Please do not be discouraged.
I did have some minor technical question when I read the original
posting. But it's not important. It is more important to applaud
what you are doing.
Thanks,
Ian.
Is Access to Salsa restricted to a certain number of queries per time and host?
Hi, I'm running a daily cron job on host blends.debian.net to gather machine readable data from all blends packages. The cron job fetches only the following files debian/changelog debian/control debian/copyright debian/README.Debian debian/upstream/edam debian/upstream/metadata (if the latter two exist) from about 2000 repositories. These data are consumed in UDD from where they are used in the Blends web sentinel. The script which is running can be found in Git[1]. Unfortunately the cron job seems to stop with Traceback (most recent call last): File "/usr/lib/python3/dist-packages/gitlab/exceptions.py", line 251, in wrapped_f return f(*args, **kwargs) File "/usr/lib/python3/dist-packages/gitlab/mixins.py", line 48, in get server_data = self.gitlab.http_get(path, **kwargs) File "/usr/lib/python3/dist-packages/gitlab/__init__.py", line 728, in http_get streamed=streamed, **kwargs) File "/usr/lib/python3/dist-packages/gitlab/__init__.py", line 706, in http_request response_body=result.content) gitlab.exceptions.GitlabHttpError: 429: b'Retry later\n' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/srv/blends.debian.org/misc/machine_readable/fetch-machine-readable_salsa.py", line 106, in project = gl.projects.get(pr.attributes['id']) # without this extra get repository_tree() fails File "/usr/lib/python3/dist-packages/gitlab/exceptions.py", line 253, in wrapped_f raise error(e.error_message, e.response_code, e.response_body) gitlab.exceptions.GitlabGetError: 429: b'Retry later\n' Once this has happened Git access to salsa seems to be completely blocked from this host since I can not even tille@blends:/tmp$ git clone https://salsa.debian.org/blends-team/website.git Cloning into 'website'... remote: Retry later fatal: unable to access 'https://salsa.debian.org/blends-team/website.git/': The requested URL returned error: 429 (similar with git pull). This problem seems to exist since 2018-05-27 (when the last complete set of data was created. I wonder whether some setting on Salsa was changed to prevent to frequent access to Salsa from some specific IP address (I can perfectly access that repository from other hosts) and what I can do to fetch these data instead. Kind regards Andreas. PS: Yes, I'm aware that this might be a question for Salsa support tracker and I'll open a ticket there in case it turns out that there is no better way to fetch this data. My motivation to post it on Debian devel is to get hints how to perform that query better and also give a hint to the problem for others who also might try to fetch data from Salsa (in replacement of other jobs running formerly on Alioth). [1] https://salsa.debian.org/blends-team/website/blob/master/misc/machine_readable/fetch-machine-readable_salsa.py -- http://fam-tille.de
Bug#903542: ITP: r-cran-xfun -- miscellaneous GNU R functions by 'Yihui Xie'
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-cran-xfun Version : 0.3 Upstream Author : Yihui Xie, Daijiang Li * URL : https://cran.r-project.org/package=xfun * License : MIT Programming Lang: GNU R Description : miscellaneous GNU R functions by 'Yihui Xie' This package provides miscellaneous functions for GNU R commonly used in other packages maintained by 'Yihui Xie'. For instance it is needed in r-cran-tinytex. Remark: This package is maintained by Debian R Packages Maintainers at https://salsa.debian.org/r-pkg-team/r-cran-xfun This package is needed to upgrade r-cran-tinytex to its lates upstream version.
