Re: Re: time_t progress report
Wondering about the current state of this transition. Is there a tracker of
any kind for this? Or would someone be willing to post an email here
periodically? Weekly maybe?
I looked at the release goals wiki and at the "brain dump" page but failed to
find anything dated more precisely than "***The t64 transition is ongoing
(March 2024) in Debian***".
There are five milestones listed on the release goal page. I would hazard that
the first three are done but I'm not sure whether the last two are complete?
The Milestones are:
1. Make a complete list of libraries with changed public ABI changes that must
transition together.
2. Change gcc-* to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 by default.
3. Change dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64 on
all 32-bit arches except i386 and hurd-i386 (filter this out for 100-odd
packages which are sensitive to LFS but not time_t).
4. NMU all libraries with binaries renamed from libfoo to libfoot64, removing
old suffixes (c102, c2, ldbl, g…) if present, and emit a Provides/Replaces/
Breaks libfoo on 64-bit arches + i386 and hurd-i386.
5. Do unchanged source rebuilds (binNMUs on all architectures) of 5000-6000
packages which depend on those. By the magic of transitions this just works.
I'm guessing that we're somewhere in the midst of Milestone 5?
In looking at packages I maintain, I find things like "blocked by ${pkg}". But
when I go to the blocker, there's often no upload for 2-3 weeks and no other
visible sign of progress. What's holding things up? Are we waiting for folks
to identify the 5-6k packages that need binNMU?
Can we help? I tried filing a binNmu bug for a package, but then found out the
package was nmu'd later -- without closing my bug. So clearly someone is
looking at things. Where are we in the process?
Appreciate all the good work going into this. Just wondering whether there's
something constructive I could pitch in on? If there is nothing for me but to
wait, that is useful information, too.
Thanks,
-Steve
signature.asc
Description: This is a digitally signed message part.
what's up with python3.11 on arm?
This recent transition has really illuminated how little I know of the dark corners of Debian infrastructure... Some packages (e.g. libcdk5/experimental) aren't buildable on the armel/armhf because the build-deps don't install, and in particular: The following packages have unmet dependencies: libpython3.11 : Depends: libpython3.11-stdlib (= 3.11.8-1) but 3.11.8-3+b1 is to be installed What I can't figure out is: the same python3.11 sources build both libpython3.11 and libpython3.11-stdlib - so where does this version skew come from? The python build logs for armel/armhf are mysterious in that no buildd nor logs are listed. I presume that's a signal these were manually built somehow? Do they just need rebuilding with the dependency version numbers fixed up? Who needs to be notified to fix this? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Package marked for autoremoval due to closed bug?
According to the "action needed" section for nifticlib [1], it is: Marked for autoremoval on 31 March: #1063178 But that bug is fixed for the version in unstable. Why does that cause the package to be removed? [1] https://tracker.debian.org/pkg/nifticlib Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Re: 64-bit time_t transition: cargo needs manual intervention
On Tuesday, March 12, 2024 1:24:25 A.M. CDT Steve Langasek wrote: > The quickest fix for this based on what we've done in Ubuntu is: > > - unpack cargo and libstd-rust debs to the root via dpkg-deb -x > - use equivs to mock up packages by these names with no dependencies and > install those > - bootstrap > - enjoy Thanks! I checked the build logs for cargo and noticed that most architectures have been built on the buildds. All release arches except armel & armhf. How is it that these two have build dep installability problems but others do not? -Steve signature.asc Description: This is a digitally signed message part.
64-bit time_t transition: cargo needs manual intervention
Peter convincingly argues (details in bug) that manual intervention is needed for package "cargo": On Sun, 10 Mar 2024 00:48:32 + Peter Michael Green wrote: > This will require manual intervention to resolve, either through > cross-building or through building manually in a hacked-up build > environment. > > I've certainly seen mention of rustc on #debian-devel recently, > so I think the people handling the time_t transition are already > aware of this. I'm wondering if the time_t people or the rust people could comment on this? This build failure has a surprisingly (to me) long chain of casualties. Is this an easy thing to fix or is going to take weeks? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Re: Bits from the Release Team: Cambridge sprint update
On Saturday, December 16, 2023 12:23:46 P.M. CST Paul Gevers wrote: > Another topic we covered is the volume and purpose of our mail list > (debian-devel@lists.debian.org). We recognize that that list mostly just > mirrors BTS traffic. The BTS already archives all information, and there are > multiple ways anyone can subscribe to the Release Team bugs, so this > mirroring seems unnecessary. More importantly it inhibits the list from > being a more useful discussion channel that we like it to be. Hence, we'll > try to work with the BTS maintainers to direct the traffic away Does that mean ceasing the "ITP" messages in debian-devel? I'd certainly welcome that! -Steve signature.asc Description: This is a digitally signed message part.
Bug#1051939: ITP: ubpm - Universal Blood Pressure Manager
Package: wnpp Severity: wishlist Owner: "Steve M. Robbins" X-Debbugs-Cc: debian-devel@lists.debian.org, debian-...@lists.debian.org * Package name: ubpm Version : 1.9.0 Upstream Contact: Thomas Löwe * URL : https://codeberg.org/LazyT/ubpm * License : GPL v3 Programming Lang: C++ Description : Universal Blood Pressure Manager The UBPM manages blood pressure readings, imported directly from supported devices, from files (CSV, JSON, XML, SQL), or entered manually. Readings may be viewed, printed, or mailed as a chart, table, or statistics. Features: * export data to CSV, JSON, XML, SQL or PDF format * migrate data from vendor software * analyze data via SQL queries * plugin interface for blood pressure monitors with a computer interface (USB, Bluetooth) My intention is to maintain this under the Debian-med umbrella https://salsa.debian.org/med-team signature.asc Description: This is a digitally signed message part.
Googletest 1.13 requires at least C++14
Hi, Please CC me in any reply. A new googletest package for 1.13.0 just hit unstable and I now realise it requires at least C++14. From autopkgtests, I noted at least one build failure because of this. I'm hoping most code can simply opt to build at C++14 or later. However, I'm willing to re-introduce a googletest 1.12 if need be. Please get in touch if you have a package that cannot be made to build with googletest 1.13. Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Un-plug/re-plug second monitor messes up video config (regression)
Hello, I have two monitors connected to my linux desktop. One of them is sitting on an HDMI switch as it is shared with a laptop. For months, this worked just fine: when I switched the monitor to the laptop, linux would notice that only one monitor was connected and adjust; when I later switched the monitor back to the linux machine, it would notice that there are two monitors and adjust back to the original two-monitor configuration. Recently -- since maybe 2-3 weeks ago (hard to pin down because I run "sid" and update frequently) -- the switch from one to two monitors has stopped working. This forces me to open the KDE "System Settings" application and fix the "Display Configuration". The second monitor is detected OK, but the "Enabled" checkbox remains off. I need to click it back on. The reason for this email rather than a bug report is that I don't know where this functionality is located -- in the xorg server? NVIDIA drivers? KDE? Something else?? Thanks! -Steve signature.asc Description: This is a digitally signed message part.
Re: Bug email is not getting to me
Thanks to all who responded. I have learned a lot! On Sunday, September 25, 2022 4:57:19 P.M. CDT Russ Allbery wrote: > Steven Robbins writes: > > To re-iterate: mail sent today to my debian address from outside debian > > came through OK. Mail sent from bugs.debian.org apparently does not. I > > think if there were any issue with the incoming email server (e.g. the > > DMARC thing that Andrea Pappacoda referenced) that would affect all > > email to me at debian, wouldn't it? > > No, the annoying thing about the DMARC problem is that its effect depends > on the configuration settings of the person sending the email. Oh! OK. So Adam Barratt found a log somewhere that confirms my ISP is blocking the sender. > If someone sends mail from a domain that says all mail from that domain > will always have good DKIM signatures, and if the signature isn't present > or doesn't validate the mail should be rejected, and that message is > forwarded through bugs.debian.org to someone whose mail server honors > DMARC settings, the mail will be rejected. That's because the process of > modifying the message in the way that bugs.debian.org needs to do (adding > the bug number to the Subject header, for instance) usually breaks the > signature. So are you effectively confirming this is indeed the DMARC bug [1] filed in 2014? [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809 > If you send mail from a domain that has a more relaxed (or no) DMARC > configuration, then your mail will go through fine and you'll not see the > problem. Well, OK. But I'm the recipient not the sender so this advice is hard to implement :-) -Steve signature.asc Description: This is a digitally signed message part.
Re: Bug email is not getting to me
On Sunday, September 25, 2022 3:49:37 P.M. CDT Geert Stappers wrote: > On Sun, Sep 25, 2022 at 03:42:40PM -0500, Steven Robbins wrote: > > I just noticed today that this applies even to responses that apparently > > directly CC my debian address; e.g. https://bugs.debian.org/cgi-bin/ > > bugreport.cgi?bug=1020397;msg=10 > > > > I literally searched my mail logs for the Message-ID in question and it is > > not reported. So it appears to have been hung up somewhere. How can I > > debug this? > > > > I have sent a test email to my debian address and it came through. So I > > think email is normally being delivered. Just not from bug reports. > > Who is running the incoming mail server? The mail server is run by my ISP (shaw.ca). Using fetchmail, I pick up the email via IMAP and send it into my local server. So in my original message when I said I had checked the logs -- it was my local server logs. To re-iterate: mail sent today to my debian address from outside debian came through OK. Mail sent from bugs.debian.org apparently does not. I think if there were any issue with the incoming email server (e.g. the DMARC thing that Andrea Pappacoda referenced) that would affect all email to me at debian, wouldn't it? -Steve signature.asc Description: This is a digitally signed message part.
Bug email is not getting to me
Hi, When I first started with Debian many many years ago, I would routinely see email for bug reports submitted against packages I maintain, and responses to said bugs. Nowadays I get essentially none of that. The only way I see such responses is by perusing bugs via the web interface -- which I do infrequently so messages languish. I may have missed when something changed over the years. Is there something I must do to get bugs.debian.org to reliably send me email? I just noticed today that this applies even to responses that apparently directly CC my debian address; e.g. https://bugs.debian.org/cgi-bin/ bugreport.cgi?bug=1020397;msg=10 I literally searched my mail logs for the Message-ID in question and it is not reported. So it appears to have been hung up somewhere. How can I debug this? I have sent a test email to my debian address and it came through. So I think email is normally being delivered. Just not from bug reports. Thanks, -Steve P.S. This has been happening for months if not years. It's just that I haven't been motivated to ask the question until now. P.P.S. I don't subscribe to any debian lists, so it is appreciated to directly cc me in replies. signature.asc Description: This is a digitally signed message part.
Half the world being removed
Suddenly half the packages are marked AUTOREMOVE; many due to gcc-12 and zlib. The related two bugs are months-old. Why are things suddenly being removed?? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Re: Re: Need a buildd build after trip through NEW -- best practice?
Paul Said: > On Sun, 2022-08-28 at 17:54 -0500, Steven Robbins wrote: > > Specficially: in the case of a NEW binary upload, could a manual request > > be > > implemented (pick a different name if "give back" is not suitable) such > > that it is thrown away and replaced by a buildd build? > > If you are suggesting the ability for dak to replace binaries already > in the archive with different content without a new source version, > then I don't think that should be implemented for Debian at least, > since our archive is meant to only contain immutable package files. OK, so let's call it "bin nmu", then. And add the "+bN" version suffix. > The dak software already has an option to enable throwing away all the > binary packages from NEW before they reach the archive, but this option > is not yet enabled on the Debian ftp-master server unfortunately. This would clearly be optimal. I'm just asking about an additional / alternative mechanism. -Steve signature.asc Description: This is a digitally signed message part.
Re: Need a buildd build after trip through NEW -- best practice?
On Tuesday, August 23, 2022 6:56:32 P.M. CDT Nilesh Patra wrote: > On 24 August 2022 3:29:10 am IST, Steven Robbins wrote: > >The binary upload cannot transition to testing -- a buildd binary build is > >required. So far as I know -- assuming [1] is still up-to-date, this means > >a nuisance upload just bumping the debian revision from -1 to -2. Is this > >still the recommended practice? > >I've also been wondering about the "Give Back" action button on the buildd > >log page. It doesn't work in this case because "Package in state > >Installed, cannot give back. ✗". > >Wondering if the logic can be modified to also check > >whether the build was done on a buildd -- e.g. check whether the logs > >column contains "no log". If it wasn't a buildd build, can the giveback > >be allowed? > It was probably intentional. In any case, you might want to CC the > wanna-build team ML as well I understand that the current state is that one can only "give back" a failed build. I'm asking whether this must necessarily be the case. Specficially: in the case of a NEW binary upload, could a manual request be implemented (pick a different name if "give back" is not suitable) such that it is thrown away and replaced by a buildd build? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Need a buildd build after trip through NEW -- best practice?
Commonly, I update a package that provides a shared library. Due to the package naming convention, a new SOVERSION necessitates a trip through NEW, which in turn means a binary upload. The binary upload cannot transition to testing -- a buildd binary build is required. So far as I know -- assuming [1] is still up-to-date, this means a nuisance upload just bumping the debian revision from -1 to -2. Is this still the recommended practice? I've also been wondering about the "Give Back" action button on the buildd log page. It doesn't work in this case because "Package in state Installed, cannot give back. ✗". Wondering if the logic can be modified to also check whether the build was done on a buildd -- e.g. check whether the logs column contains "no log". If it wasn't a buildd build, can the giveback be allowed? Thanks, -Steve [1] https://wiki.debian.org/SourceOnlyUpload signature.asc Description: This is a digitally signed message part.
How to debug mips64el buildd failure unreproducible on porterbox?
Hi, After the recent spate of rebuilds for the new glibc, I had a couple packages fail in their respective post-build test suite. For one package, the buildd failure went away after a rebuild. The second package, libminc, however failed on the buildd as recently as yesterday. https://buildd.debian.org/status/logs.php?pkg=libminc=mips64el I used the sid_mips64el-dchroot chroot on eller for a test build and it works there. Is there something I need to do to make it more identical to the buildd machine? How does one debug this? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Suggestion for db.debian.org/machines.cgi page
On Monday, August 22, 2022 1:29:13 A.M. CDT Nilesh Patra wrote: > On Mon, Aug 22, 2022 at 08:08:30AM +0200, Sebastiaan Couwenberg wrote: > > On 8/22/22 07:15, Steve Robbins wrote: > > > Oh. I did use Eller -- but the architecture is listed as mipsel. I need > > > mips64el> > > eller has mips64el chroots too, Ah, thank you. NOTE for whoever is maintaining the very nice db.debian.org/machines.cgi page: The way I use this page is to search the Architecture column for the architecture I want. It would help me (and, I expect, others) if there were a few sentences preamble alerting one to the presence of dual-chroot machines. I guess that one should really be searching in the Description field rather than Architecture. On the topic of eller architecture: when I put mips64el in the architecture search field, eller does not appear. I am puzzled by this because "uname -a" on eller apparently is a 64-bit machine so it can't be "mipsel", can it? What does "Architecture" represent if not the base machine architecture? Regards, -Steve signature.asc Description: This is a digitally signed message part.
Is there a mip64el machine available for debugging?
The list at https://db.debian.org/machines.cgi suggests all available machines are "buildd" and restricted. I need to debug a build problem that appears only on mips64el. And only since the new glibc. Is there any known issues with the new glibc on mips64el? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Re: Re: Firmware - what are we going to do about it
Luca Boccassi wrote: > Personally, I'd even go for option 4, so that other drivers are covered > too (the general advice that can be found on the internet for users > with nvidia hardware seems to be: "avoid Debian, go Ubuntu/Mint/etc", > which is just a sad state of affairs). But option 5 is already a great > improvement upon the status quo. Agree! The original post did mention video cards, but I'm left unsure whether the non-free stuff in the NVidia case, for example, would fall into "firmware" (hence included) or "drivers". If the latter, my sense is that Option 5 was intended to be narrowly focused and exclude such drivers. I'd rather support a wider focus that would include drivers -- basically any "non-free hardware support package". So if Option 5 is narrow and Option 4 is wide-open "non- free" maybe there's room for an option in between? -Steve signature.asc Description: This is a digitally signed message part.
Re: Re: Re: How to do 32-bit build in AMD64 chroot -- problem with SSE instructions?
Thanks for the pointer to https://wiki.debian.org/ ArchitectureSpecificsMemo#Architecture_baselines. I read there that "Each Debian architecture has a baseline indicating the oldest or least capable CPU on which the architecture can be used. The baseline can change between Debian releases. The baseline is mostly defined by the gcc-N package, which is configured to produce baseline binaries when options like -march= are not used." Is the choice of baseline a Debian-specific configuration of GCC? Or might another OS vendor configure differently such that "gcc" running on an i386 class machine actually targets something newer than i686? -Steve signature.asc Description: This is a digitally signed message part.
Re: Re: How to do 32-bit build in AMD64 chroot -- problem with SSE instructions?
Thank you Andrey! > For example, in this case it's not about compilation flags because the > relevant code uses SSE2 explictly when USE_SSE2_32IMPL is set. I haven't > checked how is it set but the configure step output suggests it checks the > hardware support on the build machine, which must not be done in Debian > packages. So the first step would be finding how to disable this. There > may be other steps needed. I've found it -- the flag is conditional on "defined(__i386__)." The code builds once I remove that so I've at least got the beginning of a workaround. Can you (or anyone) confirm whether the Debian i386 build SHOULD or SHOULD NOT enable SSE of any flavour? I've googled numerous times but can't seem to find this kind of detailed port information. Thanks again, -Steve
How to do 32-bit build in AMD64 chroot -- problem with SSE instructions?
Hi, I've built the ITK package on my AMD64 machine without trouble, but the 32-bit build is failing with the error below. The errors seem to point to using SSE instructions. Is there a recommended set of flags to use when building for x86? I tried "-march=i686" but it gives the same error. Below is the first warning and error -- there are several more similar errors. Thanks! -Steve In file included from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkMath.h:32, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkVector.hxx:21, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkVector.h:332, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkPoint.h:23, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkContinuousIndex.h:21, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkImageRegion.h:34, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkImageRegionSplitterBase.h: 21, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/ itkImageRegionSplitterSlowDimension.h:21, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/src/ itkImageRegionSplitterSlowDimension.cxx:19: /home/steve/Packages/insighttoolkit/build-area/InsightToolkit-5.2.1/Modules/ Core/Common/include/itkMathDetail.h: In function ‘itk::int32_t itk::Math::Detail::RoundHalfIntegerToEven_32(double)’: /home/steve/Packages/insighttoolkit/build-area/InsightToolkit-5.2.1/Modules/ Core/Common/include/itkMathDetail.h:151:24: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi] 151 | return _mm_cvtsd_si32(_mm_set_sd(x)); | ~~^~~ In file included from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkMathDetail.h:37, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkMath.h:32, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkVector.hxx:21, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkVector.h:332, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkPoint.h:23, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkContinuousIndex.h:21, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkImageRegion.h:34, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/itkImageRegionSplitterBase.h: 21, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/include/ itkImageRegionSplitterSlowDimension.h:21, from /home/steve/Packages/insighttoolkit/build-area/ InsightToolkit-5.2.1/Modules/Core/Common/src/ itkImageRegionSplitterSlowDimension.cxx:19: /usr/lib/gcc/i686-linux-gnu/11/include/emmintrin.h:867:1: error: inlining failed in call to ‘always_inline’ ‘int _mm_cvtsd_si32(__m128d)’: target specific option mismatch signature.asc Description: This is a digitally signed message part.
Why doesn't nifticlib migrate?
The excuses page says it is good to go, but it hasn't migrated despite being 7 days past the required 5 days. What's up? Excuse for nifticlib Migration status for nifticlib (2.0.0+git186-g84740c2-1 to 3.0.1-4): Will attempt migration (Any information below is purely informational) Additional info: Piuparts tested OK - https://piuparts.debian.org/sid/source/n/nifticlib.html 12 days old (needed 5 days) Excuses generated Sun Dec 20 18:08:20 2020 signature.asc Description: This is a digitally signed message part.
Re: How much data load is acceptable in debian/ dir and upstream (Was: edtsurf_0.2009-7_amd64.changes REJECTED)
On Thursday, September 17, 2020 3:07:23 P.M. CDT Thomas Goirand wrote:
> On 9/16/20 2:55 PM, Steven Robbins wrote:
> > Since you're soliciting opinions, here's mine. In the absence of a
> > documented consensus, ftpmaster should respect the packager's judgement
> > rather than reject on their own personal opinion.
>
> Reviewing the packaging is also part of the FTP master job.
The debate is over the desirable _extent_ of such a review.
I would also say that a review that offers suggestions for improvement is
totally welcome. On the other hand, an opinion masquerading as an unstated
requirement to pass the gate is an irritant.
I like this discussion on the Tone of the Review
https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/
> On 9/16/20 2:55 PM, Steven Robbins wrote:
> > Thorsten's observation ("... is much too large") is completely
> > arbitrary. Also, why does size matter? If the files are necessary,
> > they will show up somewhere. Why do we care which tarball they are
> > part of?
>
> The above shows you haven't understood what the problem is.
That is certainly possible!
> I replied already to Andreas, though here's my thinking, hopefully that
> was the one of TA as well.
>
> With a separate source package holding the data, the data set,
> typically, will be uploaded *once*, then we may see new revision of a
> tiny debian tarball. I also don't think such a package will need so many
> revisions anyways.
>
> On the other hand, the package which needs to be tested with this
> dataset may need to be often upgraded to the latest upstream revision.
> Uploading a huge debian tarball each time isn't optimized.
You are right. I don't understand the problem. If the size of upload is a
concern, surely the uploader is the most invested in such optimization and
would be a good judge of that. Why do we need ftpmaster to second-guess it?
Now, I'm a disinterested observer and have not looked at either the data or
the code in question. It may well be true in this case that the test data
rarely changes. However, my experience at work is that we update test data
not infrequently so I think I'd be careful of drawing conclusions on what is
"typical".
Regards,
-Steve
signature.asc
Description: This is a digitally signed message part.
Re: How much data load is acceptable in debian/ dir and upstream (Was: edtsurf_0.2009-7_amd64.changes REJECTED)
On Tuesday, September 15, 2020 11:18:28 P.M. CDT Andreas Tille wrote:
> Hi Paul,
>
> On Tue, Sep 15, 2020 at 10:00:45PM +0200, Paul Gevers wrote:
> > On 14-09-2020 21:04, Andreas Tille wrote:
> > > In the case of larger data sets it seems to be natural to provide the
> > > data in a separate binary architecture all package to not bloat the
> > > machines of users who do not want this and also save bandwidt of our
> > > mirroring network. New binary packages require new processing and my
> > > question is here about a set of rejection mails we received ( .
> >
> > I assume you realized, but just in case you didn't: the data doesn't
> > need to go into any binary package for autopkgtests to find it. While
> > running autopkgtests, the SOURCE is unpackaged and available. (You
> > mentioned other reasons why you want it, though.)
>
> Yes, that fact is perfectly known. However, in the current discussion
> this would only "help" us since without an extra binary package we would
> "avoid" the ftpmaster review of the source package. My intention is
> not to avoid the review but to clarify the situation.
>
> If I understood ftpmaster correctly the amount of data in the source
> package is the problem. It would be great to hear other developers
> opinion about the size of data needed for proper testing and where to
> put these.
Since you're soliciting opinions, here's mine. In the absence of a documented
consensus, ftpmaster should respect the packager's judgement rather than
reject on their own personal opinion.
>From your original set of questions:
> On Sun, Sep 13, 2020 at 12:00:08PM +, Thorsten Alteholz wrote:[1]
>
> > your debian tar file is much too large.
> > Please put all data in a separate source package and don't forget to add
the copyright information.
>
> I admit the debian/ dir (2.7MB) exceeds the real code (300kB) by far.
> However can we please fix somewhere in our packaging documentation
> what size of the debian/ dir is acceptable or not.
Thorsten's observation ("... is much too large") is completely arbitrary.
Also, why does size matter? If the files are necessary, they will show up
somewhere. Why do we care which tarball they are part of?
> On Sun Sep 13 13:00:09 BST 2020, Thorsten Alteholz wrote:[2]
>
> > please explain why you need such a huge amount of test data in this
> > package.
This is, to me, also a completely arbitrary opinion ("huge amount").
Ftpmaster should give the packager the benefit of the doubt. They have
presumably also noticed the amount of data and deemed it acceptable. This
should not be a barrier to acceptance.
Demanding an explanation up front is also an arbitrary request. Allow the
package and have a conversation afterwards.
> On Sun Sep 13 18:00:08 BST 2020, Thorsten Alteholz wrote:[3]
>
> > please don't hide data under debian/*.
There shouldn't be a need for language ("hide data") that suggests possible
malfeasance on the part of the packager. If the file placement is against
documented consensus, then simply point to the relevant policy section.
Otherwise, accept the package without editorializing.
-Steve
signature.asc
Description: This is a digitally signed message part.
Re: Bug email to Maintainer, not Uploader?
On Saturday, February 22, 2020 10:15:28 A.M. CST Steven Robbins wrote: > I'm not receiving messages concerning bugs for most of the packages I > maintain. Most of my packages are team-maintained, so my email appears only > as the Uploader, not the Maintainer. I am beginning to suspect this is > the cause of missing emails. Is it? Is there a global method to inform > bts to send me email even when only an uploader? Thanks to Mattia for confirming my suspicions. Neither of the two options presented, however, are appealing to me. 1. Subscribe to the Maintainer ML would produce an enormous amount of spam. The maintainer is Debian-Science, which is listed in 790 packages, of which I care about maybe 10. 2. Subscribe through the PTS requires manual work for a few dozen packages and remembering to sub/unsub each time I add/drop a package. I would prefer, instead, to suggest a mechanism to email uploaders. Would that be best suggested to the bts software or the pts software? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
Bug email to Maintainer, not Uploader?
I'm not receiving messages concerning bugs for most of the packages I maintain. Most of my packages are team-maintained, so my email appears only as the Uploader, not the Maintainer. I am beginning to suspect this is the cause of missing emails. Is it? Is there a global method to inform bts to send me email even when only an uploader? Thanks, -Steve signature.asc Description: This is a digitally signed message part.
