On 03/09/24 at 16:56 -0400, Louis-Philippe Véronneau wrote:
> On 2024-09-03 14:05, Lucas Nussbaum wrote:
> > On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:
> >> FYI, I opened an RT ticket asking DSA for a VM to host all of this.
> >
> > Hi,
> >
&
On 03/09/24 at 20:49 +0200, Fabio Fantoni wrote:
> Il 03/09/2024 20:05, Lucas Nussbaum ha scritto:
> > On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:
> > > FYI, I opened an RT ticket asking DSA for a VM to host all of this.
> > Hi,
> >
> > I
On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:
> FYI, I opened an RT ticket asking DSA for a VM to host all of this.
Hi,
I still don't understand the long term strategy here.
UDD provides the same information. I recently did the work so that it is
properly indexed by search engines,
Hi,
On 20/08/24 at 07:28 +0200, Helmut Grohne wrote:
> There are various QA-related teams looking at packages from other
> maintainers. When it trips a check, that often incurs time from some QA
> person investigating a report or failure. Examples:
> * Lucas Nussbaum, Santiago Vi
On 09/08/24 at 07:54 +, Bastien Roucariès wrote:
> Le vendredi 9 août 2024, 06:39:04 UTC Lucas Nussbaum a écrit :
> > On 08/08/24 at 18:40 +, Bastien Roucariès wrote:
> > > > > It is not meant to replace the corresponding UDD link, in fact I
> > > >
On 09/08/24 at 13:12 +0200, Nicolas Peugnet wrote:
> You proposed to fix it by adding the description of the tag on UDD, but I
> don't think this is an optimal solution.
>
> 1. The page is very slow to load, around 6 to 10 seconds. This is a problem
> both for the user, and for the server that nee
On 07/08/24 at 19:05 +0200, Nicolas Peugnet wrote:
> Hi all,
>
> Pierre-Elliott Bécue on Wed, 27 Sep 2023 14:19:20:
> > Otto Kekäläinen wrote on 27/09/2023 at 06:35:07+0200:
> >
> > > Hi!
> > >
> > > Thanks for the context - so there is no need technical incompatibility
> > > at play, but most
On 08/08/24 at 18:40 +, Bastien Roucariès wrote:
> > > It is not meant to replace the corresponding UDD link, in fact I added a
> > > link to it in the page of each tag, to see all the affected packages. But
> > > I think it is better to first arrive on a very fast to load page that
> > > si
On 09/05/24 at 13:57 -0700, Soren Stoutner wrote:
> First, I should say that I am painfully aware of how long it takes to run
> lintian on large
> packages. When working on qtwebengine-opensource-src it takes my system
> (Ryzen 7
> 5700G) about 2 hours to build the package and about half an ho
On 29/03/24 at 23:29 -0700, Russ Allbery wrote:
> Antonio Russo writes:
> > But, I will definitely concede that, had I seen a commit that changed
> > that line in the m4, there's a good chance my eyes would have glazed
> > over it.
>
> This is why I am somewhat skeptical that forcing everything i
On 29/03/24 at 23:29 -0700, Russ Allbery wrote:
> The sad irony here is that the xz maintainer tried to do exactly what we
> advise people in this situation to do: try to add a comaintainer to share
> the work, and don't block work because you don't have time to personally
> vet everything in detai
Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: parsyncfp2
Version : 2.59+git20240305.b2ef136
Upstream Contact: Harry Mangalam
* URL : https://github.com/hjmangalam/parsyncfp2/
* License
Hi,
I finally got time to perform those archive rebuilds.
Results are available at http://qa-logs.debian.net/2024/01/11/
I did a first archive rebuild (all packages on arm64, armhf, armel), and
then did a second one, restricted to packages that failed at on at least
one architecture.
Results in
On 22/11/23 at 09:09 +0100, Aurélien COUDERC wrote:
> Any chance to get back a front page with the complete list of tags, linking
> to the individual tag pages ?
>
> The best I could find for now is [1] but it's not very practical.
>
>
> [1] https://salsa.debian.org/lintian/lintian/-/tree/maste
On 28/11/23 at 13:00 -0700, Otto Kekäläinen wrote:
> > >> I finally fixed this. Sorry for the delay.
> > >>
> > >> https://udd.debian.org/lintian?packages=entr has a link for each lintian
> > >> tag, that points to (e.g.)
> > >> https://udd.debian.org/lintian-tag.cgi?tag=superfluous-file-pattern
>
On 19/11/23 at 23:49 -0700, Otto Kekäläinen wrote:
> > > This issue still exists. I would now have the need to send the url
> > > https://lintian.debian.org/tags/service-file-is-not-a-file to upstream
> > > developers to learn about this Lintian issue, but the URL does not
> > > serve any contents
Hi,
On 17/11/23 at 15:11 +0800, Otto Kekäläinen wrote:
> Hi!
>
> On Wed, 27 Sept 2023 at 13:27, Lucas Nussbaum wrote:
> >
> > Hi,
> >
> > #1042428 is the bug for "no explanation for lintian tags on UDD"
> >
> > On 26/09/23 at 21:35 -0700,
On 14/08/23 at 14:53 +0200, Emanuele Rocca wrote:
> Hi Lucas,
>
> On 2023-08-12 08:18, Lucas Nussbaum wrote:
> > Results:
> > http://qa-logs.debian.net/2023/08/11.stackclash-arm/
> >
> > I only included logs for builds that succeeded in a vanilla build,
>
Hi,
#1042428 is the bug for "no explanation for lintian tags on UDD"
On 26/09/23 at 21:35 -0700, Otto Kekäläinen wrote:
> I know Lintian tag info is available via command line, but I
> frequently need to educate upstreams about Lintian rules, and thus
> really also need a URL to share to them. Pe
On 26/09/23 at 21:35 -0700, Otto Kekäläinen wrote:
> Hi!
>
> Thanks for the context - so there is no need technical incompatibility
> at play, but mostly a matter of having resources and time to do it.
I think it's worth adding that the new implementation (as part of UDD)
is less ambitious on the
On 24/09/23 at 12:16 -0700, Otto Kekäläinen wrote:
> > I don't know if it is just me, but even udd gives me a 500
> > when I try to check lintian output for any (existing) package.
> >
> > For example: https://udd.debian.org/lintian/?packages=nim
>
> I also just get error 500 when trying to look u
On 15/08/23 at 01:29 -0400, Michael Stone wrote:
> On Mon, Aug 14, 2023 at 09:40:52PM +0100, Wookey wrote:
> > Yes. You are right. I (and most of the others who expressed an
> > interest in having this working) mostly care about doing a binary
> > build repeatedly. But doesn't this amount to much t
On 14/08/23 at 22:09 +0200, Michael Biebl wrote:
> Could maybe dh_clean automatically clean up such __pycache__ directories or
> do we really expect that each individual package does such a clean up
> manually?
> Or is there maybe a way to avoid the creation of the __pycache__ directories
> altoget
On 10/08/23 at 14:38 +0200, Lucas Nussbaum wrote:
> On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> > Are we ready to call for consensus on dropping the requirement that
> > `debian/rules clean; dpkg-source -b` shall work or is anyone interested
> > in sending lots of patc
Hi Emanuele,
On 10/08/23 at 16:57 +0200, Emanuele Rocca wrote:
> Hi,
>
> On 2023-08-10 02:43, Lucas Nussbaum wrote:
> > What I would need is a script that customizes a chroot.
>
> This is what I'm passing to sbuild --chroot-setup-commands for my
> builds:
>
Hi,
On 08/08/23 at 01:25 +0200, Guillem Jover wrote:
> Hi!
>
> Lately I've been updating metadata in patches in packages I maintain and
> noticed several issues with the Patch Tagging Guidelines, and after Lucas
> created the new great patches UDD service [P] and we discussed some
> other issues
On 10/08/23 at 10:49 +0200, Emanuele Rocca wrote:
> Hi,
>
> On 2023-08-06 11:25, Moritz Mühlenhoff wrote:
> > I worked with Lucas a while back and he made an archive rebuild on amd64,
> > only a minimal list of packages will need to be adapted:
> > http://qa-logs.debian.net/2023/05/24/
>
> Can we
On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> Are we ready to call for consensus on dropping the requirement that
> `debian/rules clean; dpkg-source -b` shall work or is anyone interested
> in sending lots of patches for this?
My reading of the discussion is that there's sufficient interest f
Hi,
On 05/08/23 at 21:01 +0200, Sven Joachim wrote:
> On 2023-08-05 19:31 +0100, Wookey wrote:
>
> > On 2023-08-05 17:06 +0200, Lucas Nussbaum wrote:
> >>
> >> I wonder what we should do, because 5000+ failing packages is a lot...
> >>
> >> Shou
On 05/08/23 at 21:29 +0200, Andrey Rakhmatullin wrote:
> On Sat, Aug 05, 2023 at 07:20:19PM +0300, Adrian Bunk wrote:
> > What packages are failing, and why?
> >
> > I would expect some debhelper machinery being responsible for most of
> > these, e.g. perhaps some dh-whatever helper might be crea
On 05/08/23 at 19:20 +0300, Adrian Bunk wrote:
> On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
> >...
> > Packages tested: 29883 (I filtered out those that take a very long time to
> > build)
> > .. building OK all times: 24835 (83%)
>
Hi,
Debian Policy section 4.9 says:
clean (required)
This must undo any effects that the build and binary targets may
have had, except that it should leave alone any output files
created in the parent directory by a run of a binary target.
I looked at what happens when doing 'dpk
On 02/10/22 at 22:21 +0200, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Lucas Nussbaum (2022-10-02 21:51:52)
> > On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> > > Nǐmen hǎo!
> > > I did another _source_ rebuild of the archive -- checking if
On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> Nǐmen hǎo!
> I did another _source_ rebuild of the archive -- checking if every package
> is capable of repacking its source. Ie, if you can unpack it, (possibly
> modify), and pack again.
>
> Putting aside packages that are broken in other ways
On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> Nǐmen hǎo!
> I did another _source_ rebuild of the archive -- checking if every package
> is capable of repacking its source. Ie, if you can unpack it, (possibly
> modify), and pack again.
>
> Putting aside packages that are broken in other ways
On 29/06/22 at 15:49 +0200, Axel Beckert wrote:
> Correct, except that it happened for quite a while (7 months at least)
> and was (and maybe still is — see below) a continuous transition. It
> is present since at least 2.114.0 from November 2021. According to the
> git history, the implementation
On 28/03/22 at 16:03 -0700, Sean Whitton wrote:
> Hello,
>
> On Tue 15 Mar 2022 at 06:26PM +01, Lucas Nussbaum wrote:
>
> > On 15/03/22 at 15:36 +, Ian Jackson wrote:
> >> At least the following packages of which I am the maintainer or
> >> sponsor wer
Hi,
On 15/03/22 at 09:29 -0700, Sean Whitton wrote:
> > What the are the packages for which you are surprised that bugs were
> > filed? I wonder which part of the criteria was too loose.
>
> It looks like the query didn't do quite what was intended, indeed:
> src:userv-utils is maintained in git
Hi,
On 15/03/22 at 15:36 +, Ian Jackson wrote:
> At least the following packages of which I am the maintainer or
> sponsor were includined in the MBF, despite the fact that they are 1.0
> native packages with Debian revision:
>
>its-playback-time
>spigot
>vm
>vtwm
>chroma
On 15/03/22 at 10:36 +, Ian Jackson wrote:
> Answers were given, including by a former DPL (whom you may observe
> is not someone I am on speaking terms with).
>
> But I see now that the MBF has gone ahead anyway.
>
> I spent some time trying to help by setting out the factual
> background, b
On 10/03/22 at 23:23 +0200, Adrian Bunk wrote:
> On Thu, Mar 10, 2022 at 09:49:50PM +0100, Lucas Nussbaum wrote:
> >...
> > For packages in (1.1) and (1.2), I propose to file Severity: wishlist
> > bugs using the following template:
> >
> > ---
On 10/03/22 at 21:49 +0100, Lucas Nussbaum wrote:
> https://udd.debian.org/cgi-bin/format10.cgi provides the list of
> packages for each category. The packages count is currently:
> (1.1): 53 packages
> (1.2): 424 packages
> (2): 149 packages
Actually it's:
(1.1): 60 packages
Hi,
Based on the discussion, I propose the following:
Let's split the 626 packages in bookworm that use source format 1.0 into
three categories (1.1), (1.2), (2):
(1) packages with are very unlikely to use a VCS-based workflow (not
maintained by Debian X; not using a VCS; or referring to a broken
On 09/03/22 at 08:52 -0700, Sean Whitton wrote:
> On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
> > Also, how would that work with packages that combine direct changes to
> > upstream, and quilt for Debian-created patches?
>
> Could you expand? I didn't thin
On 08/03/22 at 17:33 -0700, Sean Whitton wrote:
> Lucas, as I've had a lot to do with these git workflows and have
> probably done the most work documenting them, I can help with any
> specific follow-up questions you might have.
Thanks!
So the main question I think I have is:
can we find a midd
On 08/03/22 at 17:10 +0100, Johannes Schauer Marin Rodrigues wrote:
> I did exactly that and rebuilt all the packages found by Lucas with the
> following changes:
>
> $ mkdir -p debian/source
> $ echo '3.0 (quilt)' >debian/source/format
>
> 141 source packages produce bit-by-bit reproduci
On 08/03/22 at 16:11 +0200, Adrian Bunk wrote:
> On Tue, Mar 08, 2022 at 11:39:04AM +0100, Andreas Tille wrote:
> > Hi Adrian,
>
> Hi Andreas,
>
> > Am Mon, Mar 07, 2022 at 11:42:42PM +0200 schrieb Adrian Bunk:
> >...
> > > lintian already warns or has info tags that should be upgraded to warning
Hi,
On 06/03/22 at 22:24 +, Holger Levsen wrote:
> So I'd rather propose to file these bugs with severity 'normal' and then wait
> and then get policy updated, and then raise the severity further.
For reference, there's a debian-policy bug about deprecating 1.0 +
dpatch/quilt: #850157 (no act
On 06/03/22 at 22:25 +0100, Marco d'Itri wrote:
> On Mar 06, Lucas Nussbaum wrote:
>
> > I think that we should reduce the number of packages using the 1.0 format,
> > as
> > (1) format 3.0 has many advantages, as documented in
> > https://wiki.debia
Hi,
There are 629 packages in bookworm that use source format 1.0. That's 1.9% of
bookworm packages.
I think that we should reduce the number of packages using the 1.0 format, as
(1) format 3.0 has many advantages, as documented in
https://wiki.debian.org/Projects/DebSrc3.0 ; (2) this contributes
Hi,
On 05/11/21 at 21:22 +0100, Lucas Nussbaum wrote:
> Hi,
>
> I'd like to propose a MBF with severity:serious for the above issue.
> build-arch and build-indep are required targets according to Debian
> Policy section 4.9. This rule was introduced in Policy version 3.9.4
Hi,
I'd like to propose a MBF with severity:serious for the above issue.
build-arch and build-indep are required targets according to Debian
Policy section 4.9. This rule was introduced in Policy version 3.9.4,
released in 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-buildin
On 27/08/21 at 12:54 +, Holger Levsen wrote:
> On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote:
> > There's probably a large number of packages that just require a
> > rebuild (+ test with autopkgtest) to be backported.
>
> uploading to -backports a
Hi,
I'm really amazed by all the great work done around the Debian Janitor
project. It's great to see how it focuses the maintainer's work on where
there's some actual value with having humans in the loop.
Watching the talk[0] on automatically providing packages for new
upstream releases and new
On 23/08/21 at 13:45 +0200, Gard Spreemann wrote:
>
> Mattia Rizzolo writes:
>
> > On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
> >> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
> >> on purpose? Perhaps a consequence of the recent release?
> >
> > Th
Hi,
I would like to propose a mass bug filing on source packages that miss
support for build-arch or build-indep targets in debian/rules.
Those targets were made mandatory in Debian Policy 3.9.4 (released in
August 2012). From the changelog:
* build-arch and build-indep are now mandatory target
On 13/04/21 at 11:18 +0200, Bastian Blank wrote:
> Hi Lucas
>
> I would like to add:
>
> - Removing Berkeley DB.
To clarify, I was focusing on stuff that is already tracked via Trends.
Lucas
[ M-F-T set to -qa@ ]
Hi,
I just updated Debian Trends: https://trends.debian.net/
I wonder if we should use the start of the next release cycle to decide
that we no longer want to accept some packaging practices, such as:
- debhelper compat level << 9
- source format 1.0 with direct changes in
Hi,
On 17/01/21 at 22:00 +0900, Norbert Preining wrote:
> On the infrastructure side, you mentioned on #debian-qa that in your
> opinion, lintian is best run in a CI pipeline instead of on the
> lintian.d.o service. While this is certainly true, do you plan to keep
> the functionality on your rewo
Hi,
FYI:
I'm able to run archive rebuilds on a quite regular basis. I do that to
find (and file) FTBFS bugs, but it's also possible to test candidate
changes in Debian (for example, new versions of compilers, interpreters,
or other packages that are common build-depends).
If that's useful for you
Hi,
On 04/07/20 at 13:24 +0200, Steffen Möller wrote:
> Hello,
>
> I just skimmed through https://trends.debian.net/ and am impressed. Many
> thanks for these figures.
Thanks
> Do you accept wishes for additional graphs?
Sure
> Mine would be on the number of build dependencies as a scale for
Hi,
I just updated https://trends.debian.net/
Debian Trends provides historical graphs about Debian packaging
practices. It is built by running lintian on the data from
snapshot.debian.org.
Lucas
On 28/06/20 at 23:38 +0200, Bernd Zeimetz wrote:
>
>
> On 6/28/20 10:58 PM, Lucas Nussbaum wrote:
> > Well, I think that it would a good thing for Debian to enforce some
> > consistency on Debian images for clouds and software that require
> > VM images, at least abou
On 28/06/20 at 10:54 -0700, Ross Vandegrift wrote:
> [removing serpent@d.o from CC, he's resigned as delegate]
>
> Hi Lucas,
>
> On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote:
> > One could argue that the Cloud team delegation does not cover Docker
&
thank them for that.
However ...
On 26/03/19 at 12:25 +0100, Lucas Nussbaum wrote:
> On https://hub.docker.com/_/debian, there's:
>
> > Where to file issues:
> > https://github.com/debuerreotype/docker-debian-artifacts/issues
This hasn't changed. The Debian official im
On 25/05/20 at 09:57 +0100, Rebecca N. Palmer wrote:
> Control: retitle -1 UDD/dmd: fails to load when debci data is missing
>
> The problem isn't the number of packages, but some specific packages that
> can't be displayed even when they are the only package requested:
> https://udd.debian.org/dm
On 14/04/20 at 19:40 +0200, Adam Borowski wrote:
> > I think we should be rebuilding everything at least once per release
> > cycle, so we don't have a nasty surprise when these "mature" packages
> > need bug fixes.
>
> There's enough automated testing to spot FTBFS, thus rebuilding would only
> r
On 04/04/20 at 08:09 +0200, Paul Gevers wrote:
> Hi Lucas
>
> On 03-04-2020 22:41, Lucas Nussbaum wrote:
> > There are a few things that strike me:
> >
> > - first, one can see how the number of package in testing decreases
> > slowly during freezes, as bro
Hi,
https://trends.debian.net/ was just updated (with data until April 1st).
The main change is that graphs are now displayed by default for Debian
'testing' (thus hiding broken packages in unstable only). Graphs for
'unstable' are still available.
There are a few things that strike me:
- first
On 22/03/20 at 20:32 +0100, Adam Borowski wrote:
> Hi!
> There's a bunch of packages that fail to repack their sources. That is,
> "dpkg-buildpackage -S" fails in a clean environment.
>
> I've tested the entire archive, invoking:
> sbuild -s --source-only-changes --no-arch-all --no-arch-any
>
Hi,
I just updated https://trends.debian.net with recent data and some more
graphs. Thanks go to Peter Wienemann and Niels Thykier for patches and
ideas.
Lucas
signature.asc
Description: PGP signature
On 08/11/19 at 16:39 +, Holger Levsen wrote:
> On Fri, Nov 08, 2019 at 05:29:33PM +0100, Lucas Nussbaum wrote:
> > How often do packages get test-built thanks to that? (It looks like the
> > answer is: "once per month"?)
>
> it depends - see the
On 03/11/19 at 15:24 +, Holger Levsen wrote:
> On Sun, Nov 03, 2019 at 03:14:38PM +0100, Matthias Klose wrote:
> > As part of general QA we did some test rebuilds during the last release
> > cycle, and filing the ftbfs reports as RC issues. Afaics there were no such
> > test rebuilds and RC fi
Hi,
On 02/10/19 at 23:23 +0200, Bernd Zeimetz wrote:
> > Given that backports are a no-go, I hope that
> > http://fasttrack.debian.net/ will make quick progress and turn into an
> > official service soon.
>
> basically a good idea, but
> - what are your requirements for packages that are being up
Hi,
Back in the beginning of September, because I needed to run VirtualBox
on Debian 10, I created an unofficial backport of the Debian unstable,
published it[1], and mentioned it on [2] (I don't think it was
advertised elsewhere).
[1] https://people.debian.org/~lucas/virtualbox-buster/
[2] https
Hi,
I updated https://trends.debian.net .
Main changes:
* Refreshed data (up to July 2019)
* Added data about DEP5 copyright format adoption
* Added data about autopkgtest adoption
* Various minor changes
Now is probably a good time to go through smells in your packages and
update them to newer
Hi,
On 14/05/19 at 14:30 -0400, Sam Hartman wrote:
> I think there's a fairly clear consensus emerging that it's worth having
> things to check when making a build system conversion. Looking at
> debdiff, ditherscope and reproducibility of the build all appear to be
> important things to consider
On 16/04/19 at 15:55 +0200, Enrico Weigelt, metux IT consult wrote:
> On 13.04.19 10:20, Lucas Nussbaum wrote:
> > TL;DR: see https://trends.debian.net and
> > https://trends.debian.net/#smells
> >
> > Hi,
> >
> > Following this blog post[1] I did some wo
On 16/04/19 at 08:52 +0200, Andreas Tille wrote:
> On Mon, Apr 15, 2019 at 05:35:40PM +0200, Bastian Blank wrote:
> > On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote:
> > > biococoa (U) does not use Debhelper (no compat level found)
> > > (source version: 2.2.2-4)
> > >
On 15/04/19 at 16:55 +0200, Andreas Tille wrote:
> Are you sure that you are not tricked by false positives from lintian?
I might be, but if lintian reports something incorrectly about your
package, it's probably worth fixing in lintian.
Lucas
On 13/04/19 at 09:28 +, Holger Levsen wrote:
> Hi Lucas,
>
> On Sat, Apr 13, 2019 at 10:20:53AM +0200, Lucas Nussbaum wrote:
> > TL;DR: see https://trends.debian.net and
> > https://trends.debian.net/#smells
>
> that's beautiful! thank you!
>
> >
On 13/04/19 at 10:24 +0200, Sebastiaan Couwenberg wrote:
> On 4/13/19 10:20 AM, Lucas Nussbaum wrote:
> > Additionally (and much more controversially I guess :-) ) I also added
> > an analysis of "package smells"[3], such as "not using dh", "not using a
TL;DR: see https://trends.debian.net and
https://trends.debian.net/#smells
Hi,
Following this blog post[1] I did some work on setting up a proper
framework to graph historical trends about Debian packaging practices.
The result is now available at [2], and I'm confident that I will be
able to upd
On 08/01/19 at 13:25 +0100, Andreas Tille wrote:
> Hi,
>
> I was seeking for remaining references to anonscm in packages in UDD.
> I've found the following strange hit:
>
> udd=> select source, version, maintainer, vcs_browser, release from sources
> where source = 'r-bioc-deseq2' and release =
Hi,
On 16/04/18 at 08:28 +0800, Rolf Leggewie wrote:
> Lucas and Atheros hijacked my package [...]
I know I'm late to the thread, but I wanted to make another point.
You write "my package". I think that as Debian maintainers, we should
try to avoid talking about "*my* package", but rather use e.
On 15/11/17 at 16:43 +0100, Steffen Möller wrote:
> Hello,
>
> my QA page or our blend's task page (like
> https://blends.debian.org/med/tasks/bio-ngs) regularly informs me about
> updates that should be performed to packages I alone maintain or (more
> likely) with the help of my blend. The updat
Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum
* Package name: vmtouch
Version : 1.3.0
Upstream Author : Doug Hoyte
* URL : https://hoytech.com/vmtouch/
* License : BSD-3-clause
Programming Lang: C
Description : Portable file system cache
On 21/04/17 at 14:15 +0200, Paul Gevers wrote:
> Hi,
>
> On 21-04-17 14:10, Holger Levsen wrote:
> > On Fri, Apr 21, 2017 at 01:44:40PM +0200, Paul Gevers wrote:
> >> I don't think this number is bad per-se (assuming this extra_source_only
> >> just meant it has "Build-Using"). The bad thing in my
On 07/12/16 at 20:27 +, Niels Thykier wrote:
> Lucas Nussbaum:
> > Hi,
> >
> > On 28/11/16 at 12:04 +, Ian Jackson wrote:
> >> [...]
> >
> > No.
> >
> > I think that we should rather push for using tools such as Vagrant or
&g
Hi,
On 28/11/16 at 12:04 +, Ian Jackson wrote:
> We are running a multitude of services.
>
> Our usual approach to these services is that we fix things when they
> break, test our client code against the live instance (with perhaps a
> special area of the database - eg the `experimental' suit
On 17/11/16 at 08:31 -0200, Henrique de Moraes Holschuh wrote:
> The deal with *current* Debian stable is that, if the breakage is too
> widespread, we simply might not be able to do the right thing (fix the
> real bugs).
Based on the number of bugs uncovered by my archive rebuild, I'm really
not
On 12/11/16 at 18:51 -0200, Henrique de Moraes Holschuh wrote:
> Lucas,
>
> Thanks for trying a build run with TSX enabled.
>
> On Sat, 12 Nov 2016, Lucas Nussbaum wrote:
> > I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that
> > use a CPU
On 07/11/16 at 21:52 +0100, Lucas Nussbaum wrote:
> Hi,
>
> On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > > It's worth noting that TSX is broken in 'Haswell' processors and is
> > >
On 08/11/16 at 16:01 -0200, Henrique de Moraes Holschuh wrote:
> I fear it might be bad, but
> I would love to be pleasantly surprised that people did get libpthreads
> locking right most of the time...
I wonder if it has been considered to "fix" glibc so that the misuses
that are tolerated withou
On 07/11/16 at 21:52 +0100, Lucas Nussbaum wrote:
> Hi,
>
> On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > > It's worth noting that TSX is broken in 'Haswell' processors and is
> > >
Hi,
On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > It's worth noting that TSX is broken in 'Haswell' processors and is
> > supposed to be disabled via a microcode update. I don't know whether
> > glibc avoids using it on these proces
ect too many surprises either, since other distributions
> already tested enabling bindnow and probably they found
> most issues.
>
> >
> > From dpkg PoV enabling both, would at least require a full-archive
> > rebuild, for bindnow ideally also a full autopkgtest run
On 08/02/16 at 21:53 +1100, Stuart Prescott wrote:
>
> An impressive achievement indeed.
>
> I started collecting some data on source packages vs time a few years ago.
> It also shows some of the rhythm of the development cycle:
>
> http://ircbots.debian.net/stats/
You could use snapsho
On 11/01/16 at 10:49 +0100, Stefano Zacchiroli wrote:
> On Mon, Jan 11, 2016 at 05:43:45PM +0800, Paul Wise wrote:
> > On Mon, Jan 11, 2016 at 5:23 PM, Ansgar Burchardt wrote:
> > > So you don't want another component, but something that looks like a
> > > component in some places only? I.e. it be
On 28/12/15 at 14:24 +0100, Bastien ROUCARIES wrote:
> > qa-vcs_but_not_git_or_svn.txt (290 packages)
> >
> >The package is maintained using a VCS, which is not either Git or SVN.
>
> This one is really bellow pedantic...
I agree. And this could also apply to "still using classic debhelper"
a
1 - 100 of 581 matches
Mail list logo
