Re: Uploading patch to unstable
Hi Hilmar, Thanks very much, I have submitted a bug report. Aaron On Mon, Mar 20, 2023 at 11:43 AM Preuße, Hilmar wrote: > On 20.03.2023 16:38, Aaron Boxer wrote: > > Hi Aaron, > > are you subscribed to debian-devel-annou...@lists.debian.org ? > > > Thanks, Santiago. How do I contact the release team to ask about unblock > ? > > > "According to schedule, we have frozen bookworm a bit more > (2023-03-12). This means that we are one step closer to the release of > bookworm. Like mentioned before we expect everyone to follow the > freeze policy [1]. This means that from now on key packages [2] and > packages without significant autopkgtest coverage need to be unblocked > by the release team to be able to migrate from unstable to testing. If > you need to request an unblock, check that your request is in line > with the freeze policy and use $(reportbug release.debian.org) in > order to get the meta data correct and get the template that helps us > get the right information." > > Hilmar > > [1] https://release.debian.org/bookworm/freeze_policy.html#hard > [2] https://release.debian.org/key-packages.html >
Re: Uploading patch to unstable
Thanks, Santiago. How do I contact the release team to ask about unblock ? On Mon, Mar 20, 2023 at 11:17 AM Santiago Ruano Rincón < santiag...@riseup.net> wrote: > El 20/03/23 a las 11:08, Aaron Boxer escribió: > > Hi Folks, > > > > I have successfully created a patched version of libgrokj2k to fix a > serious > > encoder bug. > > > > https://mentors.debian.net/package/libgrokj2k/ > > Without looking at the bug itself, I'd file an RC bug to keep a record > about why you are targeting this change to testing. (And include that in > debian/changelog) > > Since your package doesn't have any autopkgtest, in this stage of the > freeze, it requires an unblock from the release team, AFAIU: > https://release.debian.org/testing/freeze_policy.html#hard > So, before uploading, you need to get the ACK from them. > > Cheers, > > -- Santiago >
Re: Need to push a patch to a package in testing
Thanks, Thomas. I have it on mentors now, but yes, I will need to get special intervention to unblock it once it gets into unstable. On Mon, Mar 20, 2023 at 9:23 AM Thomas Ward wrote: > Firstly, testing is I believe under a freeze. > > Secondly, version 10.0.5.1 would need an orig.tar.gz file that *has* > version 10.0.5.1. If you are attempting to patch an issue you may want to > do it via quilt packaging if the package is a quilt format package and then > upload the package incrementing the version string at the end by 1 (so if > it's 10.0.5-1 in Debian packaging, then 10.0.5-2 becomes your version > string). > > Not sure if this will get migrated though due to testing freeze - might > need special intervention to get in. > > > Thomas > > > On 3/20/23 09:12, Aaron Boxer wrote: > > Hello, > > My package libgrokj2k is currently in bookworm testing. I have a small > patch that fixes a serious bug in the encoder. How may I get this into > bookworm testing before release ? > > The current version in testing is v10.0.5. I have created a patch branch > v10.0.5.1 > with the library version still set to 10.0.5. When I tried to upload a new > package, > it was rejected because > > > Dsc is invalid Source package origin file differs from the official > archive: Origin file : libgrokj2k_10.0.5.orig.tar.gz > Any advice would be much appreciated! > > Thanks, > Aaron > >
Uploading patch to unstable
Hi Folks, I have successfully created a patched version of libgrokj2k to fix a serious encoder bug. https://mentors.debian.net/package/libgrokj2k/ Help uploading this to unstable would be greatly appreciated ! Thanks, Aaron
Need to push a patch to a package in testing
Hello, My package libgrokj2k is currently in bookworm testing. I have a small patch that fixes a serious bug in the encoder. How may I get this into bookworm testing before release ? The current version in testing is v10.0.5. I have created a patch branch v10.0.5.1 with the library version still set to 10.0.5. When I tried to upload a new package, it was rejected because Dsc is invalid Source package origin file differs from the official archive: Origin file : libgrokj2k_10.0.5.orig.tar.gz Any advice would be much appreciated! Thanks, Aaron
libgrokj2k 10.0.5
Hi Folks, I've just updated libgrokj2k on the mentors site - if someone could please upload it to unstable, I would greatly appreciate it! https://mentors.debian.net/package/libgrokj2k/ Thanks, Aaron
Re: Need some help understanding compiler-flags-hidden lintian warning
On Mon, Sep 19, 2022 at 5:07 PM Aaron Boxer wrote: > > > On Mon, Sep 19, 2022 at 3:10 PM Jeremy Sowden wrote: > >> On 2022-09-18, at 20:35:37 -0400, Aaron Boxer wrote: >> > https://qa.debian.org/bls/packages/l/libgrokj2k.html >> > >> > >From the build logs, I am unable to find which compiler flags are >> hidden. >> > What's the best way of getting more information about the warning ? >> >> Running blhc on a couple of the build-logs yields this warning: >> >> LDFLAGS missing (-Wl,-z,now): /usr/bin/c++ -fPIC -g -O2 >> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat >> -Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 >> -Wl,-z,relro -shared -Wl,-soname,libgrokj2k_plugin.so.1 -o >> ../../../bin/libgrokj2k_plugin.so.10.0.2 >> CMakeFiles/grokj2k_plugin.dir/Plugin.cpp.o >> >> J. >> > > Thanks, Jeremy. That was indeed one of the warnings. The others I fixed by > configuring cmake for verbose builds. > Now that I have fixed these warnings, (and the package should be lintian clean), I have uploaded another version to mentors; would greatly appreciate help uploading it to unstable. Thanks, Aaron
Re: Need some help understanding compiler-flags-hidden lintian warning
On Mon, Sep 19, 2022 at 3:10 PM Jeremy Sowden wrote: > On 2022-09-18, at 20:35:37 -0400, Aaron Boxer wrote: > > https://qa.debian.org/bls/packages/l/libgrokj2k.html > > > > >From the build logs, I am unable to find which compiler flags are > hidden. > > What's the best way of getting more information about the warning ? > > Running blhc on a couple of the build-logs yields this warning: > > LDFLAGS missing (-Wl,-z,now): /usr/bin/c++ -fPIC -g -O2 > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -fvisibility=hidden -Wdate-time -D_FORTIFY_SOURCE=2 > -Wl,-z,relro -shared -Wl,-soname,libgrokj2k_plugin.so.1 -o > ../../../bin/libgrokj2k_plugin.so.10.0.2 > CMakeFiles/grokj2k_plugin.dir/Plugin.cpp.o > > J. > Thanks, Jeremy. That was indeed one of the warnings. The others I fixed by configuring cmake for verbose builds.
Need some help understanding compiler-flags-hidden lintian warning
https://qa.debian.org/bls/packages/l/libgrokj2k.html >From the build logs, I am unable to find which compiler flags are hidden. What's the best way of getting more information about the warning ? Thanks!
Re: libgrokj2k - v10.0.2
On Fri, Sep 16, 2022 at 3:10 PM Aaron Boxer wrote: > > > On Fri, Sep 16, 2022 at 2:18 PM Adam Borowski wrote: > >> On Fri, Sep 16, 2022 at 12:10:57PM -0400, Aaron Boxer wrote: >> > I have just pushed a new version to mentors that fixes the build on >> armel >> > and mipsel. >> > >> > https://mentors.debian.net/package/libgrokj2k/ >> > >> > If this could be uploaded it would be greatly appreciated ! >> >> Alas, it fails at least on riscv64, and possibly on other architectures as >> well. >> >> While the proper way to fix these errors is -pthread, cmake doesn't handle >> it right on new glibc. Your build system looks complex, thus I'd propose >> just trying to link with -latomic unconditionally. Because of --as-needed >> which is the default these days, the library won't be added on archs where >> it is not required. >> > > Thanks. I actually found that I had inadvertently deleted these lines from > my rules file > > ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mips mipsel powerpc sh4 > riscv64)) > export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic > -Wl,--as-needed > endif > > > which were added last year for exactly this issue - build failure do to > lack of libatomic. (riscv64 wasn't there last year though) > > let me re-submit with these lines restored. > Alrighty, the new version is now uploaded to the mentors site. Thanks for looking into this. Aaron > > > >> >> >> Meow! >> -- >> ⢀⣴⠾⠻⢶⣦⠀ >> ⣾⠁⢠⠒⠀⣿⡁ Seems that the Russian Army is no longer organized crime... >> ⢿⡄⠘⠷⠚⠋⠀ >> ⠈⠳⣄ >> >
Re: libgrokj2k - v10.0.2
On Fri, Sep 16, 2022 at 2:18 PM Adam Borowski wrote: > On Fri, Sep 16, 2022 at 12:10:57PM -0400, Aaron Boxer wrote: > > I have just pushed a new version to mentors that fixes the build on armel > > and mipsel. > > > > https://mentors.debian.net/package/libgrokj2k/ > > > > If this could be uploaded it would be greatly appreciated ! > > Alas, it fails at least on riscv64, and possibly on other architectures as > well. > > While the proper way to fix these errors is -pthread, cmake doesn't handle > it right on new glibc. Your build system looks complex, thus I'd propose > just trying to link with -latomic unconditionally. Because of --as-needed > which is the default these days, the library won't be added on archs where > it is not required. > Thanks. I actually found that I had inadvertently deleted these lines from my rules file ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mips mipsel powerpc sh4 riscv64)) export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic -Wl,--as-needed endif which were added last year for exactly this issue - build failure do to lack of libatomic. (riscv64 wasn't there last year though) let me re-submit with these lines restored. > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ Seems that the Russian Army is no longer organized crime... > ⢿⡄⠘⠷⠚⠋⠀ > ⠈⠳⣄ >
libgrokj2k - v10.0.2
Hello, I have just pushed a new version to mentors that fixes the build on armel and mipsel. https://mentors.debian.net/package/libgrokj2k/ If this could be uploaded it would be greatly appreciated ! Aaron
Re: Testing package on mipsel and armel
On Wed, Sep 14, 2022 at 10:32 AM Bo YU wrote: > Hi, > On Wed, Sep 14, 2022 at 09:45:45AM -0400, Aaron Boxer wrote: > >Hello, > >I currently have failed builds on mipsel and armel archs. > >For these systems, it appears that I need to link explicitly > >to libatomic. I've added the link flag, but the failures persist. > > > >Any suggestions on setting up VMs for these architectures so > >I can directly debug my builds ? > > I just setup they some day ago on x86 pc: > (maybe it need binfmt-support or qemu-binfmt) > > ``` > sudo sbuild-createchroot --debootstrap=mmdebstrap --arch=mipsel \ > --make-sbuild-tarball=/srv/sid-mipsel-sbuild.tgz \ > sid /tmp/chroots/sid-mipsel-sbuild/ \ > http://ftp.debian.org/debian/ > > # and > sudo sbuild-createchroot --debootstrap=mmdebstrap --arch=armel \ > --make-sbuild-tarball=/srv/sid-armel-sbuild.tgz \ > sid /tmp/chroots/sid-armel-sbuild/ \ > http://ftp.debian.org/debian/ > > ``` > They will setup their arch chroot then can use sbuild to build the > package. > > `sbuild --arch=mipsel -c sid-mipsel-sbuild ` > Thanks, I wasn't able to get that working, but I did find away following these instructions https://www.antixforum.com/forums/topic/use-sbuild-to-automate-deb-package-building/ This helped me create the chroot for mipsel, run the chroot, and build the package. > > > > >Thanks, > >Aaron > > -- > Regards, > -- >Bo YU > >
Testing package on mipsel and armel
Hello, I currently have failed builds on mipsel and armel archs. For these systems, it appears that I need to link explicitly to libatomic. I've added the link flag, but the failures persist. Any suggestions on setting up VMs for these architectures so I can directly debug my builds ? Thanks, Aaron
Re: how to manage packages that require native acceleration code
On Mon, Sep 12, 2022 at 11:45 PM Paul Wise wrote: > On Mon, 2022-09-12 at 10:05 -0400, Aaron Boxer wrote: > > > My codec project uses SIMD code for x86 and AArch64 architectures. > > Also, as there are different versions of SIMD i.e. SSE vs AVX vs > > AVX2, the project uses a library that builds multiple versions of the > > accelerated code and chooses which version to use at runtime. > > Runtime selection of instructions is the best solution indeed. > > Other solutions include automatic porting between SIMD instructions, > emulating atomic instructions, manual runtime code path selection, > manual runtime function selection, compiler function multi-versioning, > glibc hwcaps library selection, runtime binary selection, blocking > installation and blocking running binaries. All are summarised here: > > https://wiki.debian.org/InstructionSelection Very interesting, thanks! > > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise >
Re: how to manage packages that require native acceleration code
On Tue, Sep 13, 2022 at 2:58 AM Andrey Rahmatullin wrote: > On Mon, Sep 12, 2022 at 05:25:27PM -0400, Aaron Boxer wrote: > > Thanks, Andrey. I have fixed this problem. v10.0,0 has just been uploaded > > to unstable - would you > > recommend releasing a new version 10.0.1 with these fixes, or is there a > > way of updating v10.0.0 ? > You can upload 10.0.0-2. > Thanks. As code in master has changed, I decided to make a new point release, now uploaded to mentors https://mentors.debian.net/package/libgrokj2k/ If this could be uploaded to unstable, it would be much appreciated! Aaron > > -- > WBR, wRAR >
Re: how to manage packages that require native acceleration code
On Mon, Sep 12, 2022 at 10:37 AM Andrey Rahmatullin wrote: > On Mon, Sep 12, 2022 at 10:05:36AM -0400, Aaron Boxer wrote: > > My codec project uses SIMD code for x86 and AArch64 architectures. Also, > as > > there are different versions of SIMD i.e. SSE vs AVX vs AVX2, the project > > uses a library that builds multiple versions of the accelerated code and > > chooses which version to use at runtime. > This sounds good. > > > My package currently has a `march-native` error logged for certain > > architectures. > -march=native is not compatible with the approach you just described. And > you indeed must not use it when building packages. > Thanks, Andrey. I have fixed this problem. v10.0,0 has just been uploaded to unstable - would you recommend releasing a new version 10.0.1 with these fixes, or is there a way of updating v10.0.0 ? > > -- > WBR, wRAR >
how to manage packages that require native acceleration code
Hello, My codec project uses SIMD code for x86 and AArch64 architectures. Also, as there are different versions of SIMD i.e. SSE vs AVX vs AVX2, the project uses a library that builds multiple versions of the accelerated code and chooses which version to use at runtime. https://github.com/google/highway My package currently has a `march-native` error logged for certain architectures. https://qa.debian.org/bls/packages/l/libgrokj2k.html What would be the best approach for packaging such a project and avoiding this error ? Thanks very much, Aaron
Re: lintian warning on libgrokj2k: executable-stack-in-shared-library
On Mon, Sep 12, 2022 at 8:59 AM Andrey Rahmatullin wrote: > On Mon, Sep 12, 2022 at 08:49:53AM -0400, Aaron Boxer wrote: > > mips66el is not a target platform > What do you mean? > by that, I mean I don't have access to this platform for my own testing, and I doubt there are any users currently running the codec on mips64el. > > -- > WBR, wRAR >
Re: lintian warning on libgrokj2k: executable-stack-in-shared-library
Thanks, not a big deal then :) On Mon, Sep 12, 2022 at 8:50 AM David Bürgin wrote: > Aaron Boxer: > > Here is the warning report > > > > https://udd.debian.org/lintian/?packages=libgrokj2k > > > > and explanation of the warning > > > > https://lintian.debian.org/tags/executable-stack-in-shared-library > > > > I ran `readelf -l` on the .so, and I noticed that there is no E flag > > on the GNU_STACK entry. So, it looks like this is a false positive. > > > > Is this a fair assumption ? > > I have noticed this, too, in the packages that I maintain. However, note > that this concerns only the mips* architectures, so you would only find > this on such a machine. > >
Re: lintian warning on libgrokj2k: executable-stack-in-shared-library
a, I missed that. mips66el is not a target platform, so I suppose I can ignore this warning. On Mon, Sep 12, 2022 at 8:47 AM Andrey Rahmatullin wrote: > On Mon, Sep 12, 2022 at 08:37:34AM -0400, Aaron Boxer wrote: > > Here is the warning report > > > > https://udd.debian.org/lintian/?packages=libgrokj2k > It happens on mips* in other packages too. > > > I ran `readelf -l` on the .so, and I noticed that there is no E flag > > on the GNU_STACK entry. So, it looks like this is a false positive. > On the .so from mips64el? > > -- > WBR, wRAR >
lintian warning on libgrokj2k: executable-stack-in-shared-library
Here is the warning report https://udd.debian.org/lintian/?packages=libgrokj2k and explanation of the warning https://lintian.debian.org/tags/executable-stack-in-shared-library I ran `readelf -l` on the .so, and I noticed that there is no E flag on the GNU_STACK entry. So, it looks like this is a false positive. Is this a fair assumption ? Thanks, Aaron
Re: libgrokj2k version 10.0.0 : uploading to unstable
On Thu, Sep 8, 2022 at 11:00 AM Adam Borowski wrote: > On Thu, Sep 08, 2022 at 10:11:45AM -0400, Aaron Boxer wrote: > > I just uploaded a new package for version 10.0 of this library. > > Would someone be so kind as to upload the new package to unstable ? > > > > https://mentors.debian.net/package/libgrokj2k/ > > --- libgrokj2k-9.7.5/debian/changelog 2022-04-10 11:10:00.0 +0200 > +++ libgrokj2k-10.0.0/debian/changelog 2022-09-04 11:10:00.0 +0200 > @@ -1,8 +1,8 @@ > -libgrokj2k (9.7.5-1) unstable; urgency=medium > +libgrokj2k (10.0.0-1) unstable; urgency=medium > > -* Maintenance bug fix release > +* Majour release > > - -- Aaron Boxer Sun, 10 Apr 2022 11:10:00 +0200 > + -- Aaron Boxer Sun, 4 Sep 2022 11:10:00 +0200 > > Could you please re-add the changelog entry for the previous release? > > Thanks, done ! > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. > ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. > ⠈⠳⣄ A master species delegates. > >
libgrokj2k version 10.0.0 : uploading to unstable
Hi Folk, I just uploaded a new package for version 10.0 of this library. Would someone be so kind as to upload the new package to unstable ? https://mentors.debian.net/package/libgrokj2k/ Many Thanks, Aaron
Updated package for libgrokj2k - 9.7.5
Hello!, I have just updated the latest 9.7.5 version of my JPEG 2000 codec to mentors. Could someone be so kind as to transfer it over to Debian ? https://mentors.debian.net/package/libgrokj2k/ Thanks so much, Aaron
libgrokj2k removed from Debian - updated package available
Hello! The libgrokj2k was removed from Debian due to build issues with gcc 11. I have fixed this problem, and a host of other bugs. I would be much obliged if my package at https://mentors.debian.net/package/libgrokj2k/ could be uploaded. Thanks very much, Aaron
Re: libgrokj2k: version 9.2 uploaded
oops, never mind - I see Bullseye is in freeze. On Wed, Jul 7, 2021 at 10:00 AM Aaron Boxer wrote: > Hello Again, > I've upgraded this package priority to high as it fixes a CVE > present in previous version. > It would be great if we can get this migrated. > Thanks, > Aaron > > On Tue, Jun 8, 2021 at 12:11 PM Aaron Boxer wrote: > >> Hi Guys, >> Just a polite ping about my recently uploaded new package for >> a majour release of my library. >> Thanks, >> Aaron >> >
Re: libgrokj2k: version 9.2 uploaded
Hello Again, I've upgraded this package priority to high as it fixes a CVE present in previous version. It would be great if we can get this migrated. Thanks, Aaron On Tue, Jun 8, 2021 at 12:11 PM Aaron Boxer wrote: > Hi Guys, > Just a polite ping about my recently uploaded new package for > a majour release of my library. > Thanks, > Aaron >
libgrokj2k: version 9.2 uploaded
Hi Guys, Just a polite ping about my recently uploaded new package for a majour release of my library. Thanks, Aaron
Re: libgrokj2k: fix for bug 985116
On Wed, Mar 17, 2021 at 5:43 PM Andrey Rahmatullin wrote: > On Tue, Mar 16, 2021 at 06:13:43PM -0400, Aaron Boxer wrote: > > > > Hello, > > > > I have what I hope is a fix for the build failure on i386. > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985116 > > > > > > > > Version 7.6.6-3 is uploaded to the mentors site, > > > > and should be available shortly. Could someone please > > > > push this to testing when they have time ? > > > The version builds fine (both on amd64 and i386) but can you please fix > > > the patch? Its name should end with .patch and you should fix or remove > > > the boilerplate in its header. > > > Also, if you want this package to be included in bullseye, please read > and > > > be prepared to follow > > > https://release.debian.org/bullseye/freeze_policy.html#appropriate > after > > > this version arrives in sid and builds. > > > > > > > Updated patch is now on mentors site. > Now you have two patches: > gcc-poisont-fix-bug-985116.patch > gcc-poison-fix-bug-985116.patch > > Please always review files that you upload, especially for RC bug fixes. > My apologies, and thanks again for taking the time to review and help upload. I have put a new package with a patch to fix the i386 bug, on the mentors site. Aaron > > > > -- > WBR, wRAR >
Re: libgrokj2k: fix for bug 985116
On Tue, Mar 16, 2021 at 3:18 PM Andrey Rahmatullin wrote: > On Tue, Mar 16, 2021 at 01:05:11PM -0400, Aaron Boxer wrote: > > Hello, > > I have what I hope is a fix for the build failure on i386. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985116 > > > > Version 7.6.6-3 is uploaded to the mentors site, > > and should be available shortly. Could someone please > > push this to testing when they have time ? > The version builds fine (both on amd64 and i386) but can you please fix > the patch? Its name should end with .patch and you should fix or remove > the boilerplate in its header. > Also, if you want this package to be included in bullseye, please read and > be prepared to follow > https://release.debian.org/bullseye/freeze_policy.html#appropriate after > this version arrives in sid and builds. > Updated patch is now on mentors site. > > -- > WBR, wRAR >
Re: libgrokj2k: fix for bug 985116
On Tue, Mar 16, 2021 at 3:18 PM Andrey Rahmatullin wrote: > On Tue, Mar 16, 2021 at 01:05:11PM -0400, Aaron Boxer wrote: > > Hello, > > I have what I hope is a fix for the build failure on i386. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985116 > > > > Version 7.6.6-3 is uploaded to the mentors site, > > and should be available shortly. Could someone please > > push this to testing when they have time ? > The version builds fine (both on amd64 and i386) but can you please fix > the patch? Its name should end with .patch and you should fix or remove > the boilerplate in its header. > Also, if you want this package to be included in bullseye, please read and > be prepared to follow > https://release.debian.org/bullseye/freeze_policy.html#appropriate after > this version arrives in sid and builds. > Thanks, for testing, I will fix the patch.
Re: libgrokj2k: fix for bug 985116
On Tue, Mar 16, 2021 at 1:32 PM Andrey Rahmatullin wrote: > On Tue, Mar 16, 2021 at 01:05:11PM -0400, Aaron Boxer wrote: > > Hello, > > I have what I hope is a fix for the build failure on i386. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985116 > > > > Version 7.6.6-3 is uploaded to the mentors site, > > and should be available shortly. > It's still not. > Yes, I had some issues with the patch. It's up now. Thanks, Aaron > > > -- > WBR, wRAR >
libgrokj2k: fix for bug 985116
Hello, I have what I hope is a fix for the build failure on i386. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985116 Version 7.6.6-3 is uploaded to the mentors site, and should be available shortly. Could someone please push this to testing when they have time ? Thanks! Aaron
Re: package slated for auto-removal from testing
On Wed, Mar 10, 2021 at 8:13 PM Adam Borowski wrote: > On Wed, Mar 10, 2021 at 08:49:52AM -0500, Aaron Boxer wrote: > > Hi Guys, > > My package is slated for auto removal for bug > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983775 > > > > I have just uploaded a patch for this bug to the mentors site, > > can this please be pushed to testing ? > > Works for me: > * compiles on armel (on arm64 hardware) > * grk_compress|grk_decompress works on AVX-less amd64 (Phenom 2) > > On the other hand, could you please say what you're actually fixing in the > changelog, and also close the bugs? > > +libgrokj2k (7.6.6-3) unstable; urgency=high > + > +* Fix testing bug > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983773 > + > + -- Aaron Boxer Wed, 10 Mar 2021 12:10:00 +0200 > + > +libgrokj2k (7.6.6-2) unstable; urgency=high > + > +* Fix testing bug > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983775 > + > + -- Aaron Boxer Wed, 10 Mar 2021 11:10:00 +0200 > > These entries don't bring any information. What about: > > * Add -latomic to fix FTBFS on armel/mipsel (Closes: #983773) > * Drop -mavx2 -mbmi2 to avoid baseline violation on x86 (Closes: #983775) > > Also, please squash these revisions into one -- -2 was never released, thus > including such a spurious entry would be misleading to readers. > Thanks, I've made these changes and uploaded 7.6.6-2 to the site. Aaron
package slated for auto-removal from testing
Hi Guys, My package is slated for auto removal for bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983775 I have just uploaded a patch for this bug to the mentors site, can this please be pushed to testing ? Thanks! Aaron
Re: fix severe bug in my package
never mind :) as there are no packages at the moment, there is no link. sorry for the noise, Aaron On Tue, Feb 2, 2021 at 6:53 PM Aaron Boxer wrote: > > On Tue, Feb 2, 2021 at 3:22 PM Aaron Boxer wrote: > >> I've uploaded a new 7.6.6 version to the mentors site with a fix for this >> issue >> >> https://mentors.debian.net/package/libgrokj2k/ >> >> I see there isn't a soft freeze until Feb 12, so hopefully this can be >> migrated before that deadline. >> >> Thanks! >> Aaron >> > > Thanks a lot for uploading! One odd thing: it looks like > > https://mentors.debian.net/package/libgrokj2k/ > > is no more: I can no longer view the page. > > Cheers, > Aaron > > > >> >> On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: >> >>> Dear Mentors, >>> Last night I discovered a severe bug in my encoder. The bug affects lossy >>> compression of monochrome images, a very large class of images. The bug >>> causes the output pixels to be set to 0, which is pretty serious. >>> >>> I realize there is a freeze on new packages leading up to Bullseye >>> release, but >>> is there a way of getting a new version in somehow? I wouldn't want the >>> current >>> version to be released. >>> >>> Thanks very much, >>> Aaron >>> >>
Re: fix severe bug in my package
On Tue, Feb 2, 2021 at 3:22 PM Aaron Boxer wrote: > I've uploaded a new 7.6.6 version to the mentors site with a fix for this > issue > > https://mentors.debian.net/package/libgrokj2k/ > > I see there isn't a soft freeze until Feb 12, so hopefully this can be > migrated before that deadline. > > Thanks! > Aaron > Thanks a lot for uploading! One odd thing: it looks like https://mentors.debian.net/package/libgrokj2k/ is no more: I can no longer view the page. Cheers, Aaron > > On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: > >> Dear Mentors, >> Last night I discovered a severe bug in my encoder. The bug affects lossy >> compression of monochrome images, a very large class of images. The bug >> causes the output pixels to be set to 0, which is pretty serious. >> >> I realize there is a freeze on new packages leading up to Bullseye >> release, but >> is there a way of getting a new version in somehow? I wouldn't want the >> current >> version to be released. >> >> Thanks very much, >> Aaron >> >
Re: fix severe bug in my package
I've uploaded a new 7.6.6 version to the mentors site with a fix for this issue https://mentors.debian.net/package/libgrokj2k/ I see there isn't a soft freeze until Feb 12, so hopefully this can be migrated before that deadline. Thanks! Aaron On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: > Dear Mentors, > Last night I discovered a severe bug in my encoder. The bug affects lossy > compression of monochrome images, a very large class of images. The bug > causes the output pixels to be set to 0, which is pretty serious. > > I realize there is a freeze on new packages leading up to Bullseye > release, but > is there a way of getting a new version in somehow? I wouldn't want the > current > version to be released. > > Thanks very much, > Aaron >
Re: fix severe bug in my package
Forgot to mention: this is the package in question: https://tracker.debian.org/pkg/libgrokj2k On Tue, Feb 2, 2021 at 9:03 AM Aaron Boxer wrote: > Dear Mentors, > Last night I discovered a severe bug in my encoder. The bug affects lossy > compression of monochrome images, a very large class of images. The bug > causes the output pixels to be set to 0, which is pretty serious. > > I realize there is a freeze on new packages leading up to Bullseye > release, but > is there a way of getting a new version in somehow? I wouldn't want the > current > version to be released. > > Thanks very much, > Aaron >
fix severe bug in my package
Dear Mentors, Last night I discovered a severe bug in my encoder. The bug affects lossy compression of monochrome images, a very large class of images. The bug causes the output pixels to be set to 0, which is pretty serious. I realize there is a freeze on new packages leading up to Bullseye release, but is there a way of getting a new version in somehow? I wouldn't want the current version to be released. Thanks very much, Aaron
Re: Interested in status of libgrokj2k package
On Wed, Jan 27, 2021 at 7:55 PM Jeremy Stanley wrote: > On 2021-01-27 16:31:14 -0500 (-0500), Aaron Boxer wrote: > > Is there a way of expediting my package's passage into Debian? It > > has been at least 7 months since I first submitted. I currently > > maintain my own local .deb builds on github , so that other > > projects can use them. According to the Debian Package Tracker, > > the latest package version has been in Testing as of January 7th. > > It's in Debian. Are you asking when it will appear in a stable > release of Debian? If so, not until the next stable release, > Bullseye, for which a schedule exists only up through the "hard > freeze" projected to begin 2021-03-12. After that comes the "full > freeze" followed by the release, but as of the last update[*] from > the release team there is no projected date for those yet. Keep in > mind that newly introduced packages don't generally get added to > prior stable release series, and Debian makes a new stable release > something like every 2-2.5 years. > > [*] https://lists.debian.org/debian-devel-announce/2021/01/msg2.html Thanks, Jeremy, that makes sense. I just checked on my sid schroot, and I can install the package . Aaron
Re: Interested in status of libgrokj2k package
Hello again, Is there a way of expediting my package's passage into Debian? It has been at least 7 months since I first submitted. I currently maintain my own local .deb builds on github , so that other projects can use them. According to the Debian Package Tracker, the latest package version has been in Testing as of January 7th. Thanks very much, Aaron On Wed, Dec 23, 2020 at 9:44 AM Aaron Boxer wrote: > Dear Mentors. > I submitted the libgrokj2k package over 6 months ago, and I am not clear > on its current status. > It has been accepted into the NEW repo, and has been released to UNSTABLE. > Are there any other steps needed before it is fully upstream ? > I have had questions from one user about when this package will be > available. > > For more info, my latest update v7.6.2 is here: > https://mentors.debian.net/package/libgrokj2k/ > > Thanks very much, > Aaron >
Re: Interested in status of libgrokj2k package
> > I have had questions from one user about when this package will be >> > available. >> >> As Andrey just mentioned, a new upload was needed. You've just gave us >> 7.6.2-1, which I've sponsored. So that's done, and it should migrate to >> testing shortly. >> > >> > For more info, my latest update v7.6.2 is here: >> > https://mentors.debian.net/package/libgrokj2k/ >> >> I've noticed no problems over what lintian says. >> >> It would be nice if you could solve them in your next upload. >> > I have uploaded version 7.6.3 with all lintian issues fixed (except one info and one pedantic) Also, there is a source-only version uploaded for testing.
Re: Question about lintian bad-whatis-entry warning
On Wed, Dec 23, 2020 at 1:36 PM Robin Gustafsson wrote: > Hi Aaron, > > > How can I get more insight into the problem? > > Lintian's explanation for bad-whatis-entry [1] mentions that it's > "lexgrog" that fails to parse your header. (Looking at Lintian source > [2], it's indeed just running lexgrog on your file and checking the > exit code.) > > The lexgrog man page contains more info about how specifically the > NAME section is parsed and some requirements for it to work. Perhaps > that could help. The part about "\-" might be of particular interest. > It also mentions a "--debug" option that could perhaps provide you > with some leads if you try running lexgrog on your file manually. > > [1] https://lintian.debian.org/tags/bad-whatis-entry.html > [2] > https://salsa.debian.org/lintian/lintian/-/blob/c9601fc5/lib/Lintian/Check/Documentation/Manual.pm#L241 Thanks! I did look deeper into lexgrog, turned out it doesn't like fancy en-dash and em-dash characters that pandoc was generating.
Re: Question about lintian bad-whatis-entry warning
On Wed, Dec 23, 2020 at 1:36 PM The Wanderer wrote: > On 2020-12-23 at 13:04, Aaron Boxer wrote: > > > On Wed, Dec 23, 2020 at 11:42 AM The Wanderer > > wrote: > > > >> On 2020-12-23 at 11:25, Aaron Boxer wrote: > >> > >>> Hi, > >>> I have some questions about a lintian warning I am getting from my > package. > >>> It complains that the NAME section of the man page can't be parsed. > >>> Here is how the section appears in my man page: > >>> > >>> NAME > >>>grk_compress — compresses images to JPEG 2000 format > >>> > >>> Note: I generate the man page from markdown files via pandoc. > >>> > >>> How can I get more insight into the problem? > >> > >> I have no particular relevant expertise, but one thing I notice > >> instantly is that that doesn't quite look like a standard hyphen. > >> > >> Indeed, copying it into a text file and examining it with a hex viewer > >> shows that — is apparently 0x8094, whereas - is 0x2d. > > (Correction: that's 0xe28094, which in UTF-8 is > https://www.fileformat.info/info/unicode/char/2014/index.htm.) > > >> It might be worth checking whether that one character is the cause of > >> this. > > > > Unfortunately, switching to en dash does not fix the problem > > What's the hex value of the generated character? > > Again, I could be barking up a completely wrong tree. However, as I > understand matters there are Unicode emdash and endash characters > (U+2014 and U+2013 respectively), both of which are distinct from the > ASCII hyphen (U+002D). It's not impossible that the system involved may > understand the latter but not the two former. > Yes, correct, thanks. I switched to good old ASCII hyphen and the warning is now gone! > > -- >The Wanderer > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. -- George Bernard Shaw > >
Re: Question about lintian bad-whatis-entry warning
On Wed, Dec 23, 2020 at 12:56 PM Aaron Boxer wrote: > > > On Wed, Dec 23, 2020 at 11:42 AM The Wanderer > wrote: > >> On 2020-12-23 at 11:25, Aaron Boxer wrote: >> >> > Hi, >> > I have some questions about a lintian warning I am getting from my >> package. >> > It complains that the NAME section of the man page can't be parsed. >> > Here is how the section appears in my man page: >> > >> > NAME >> >grk_compress — compresses images to JPEG 2000 format >> > >> > Note: I generate the man page from markdown files via pandoc. >> > >> > How can I get more insight into the problem? >> >> I have no particular relevant expertise, but one thing I notice >> instantly is that that doesn't quite look like a standard hyphen. >> >> Indeed, copying it into a text file and examining it with a hex viewer >> shows that — is apparently 0x8094, whereas - is 0x2d. >> >> It might be worth checking whether that one character is the cause of >> this. >> > Unfortunately, switching to en dash does not fix the problem > > > Thanks! Yes, this is an em dash > > https://www.thesaurus.com/e/grammar/em-dash/ > > troff symbol is > > \[em] > > > >> -- >>The Wanderer >> >> The reasonable man adapts himself to the world; the unreasonable one >> persists in trying to adapt the world to himself. Therefore all >> progress depends on the unreasonable man. -- George Bernard Shaw >> >>
Re: Question about lintian bad-whatis-entry warning
On Wed, Dec 23, 2020 at 11:42 AM The Wanderer wrote: > On 2020-12-23 at 11:25, Aaron Boxer wrote: > > > Hi, > > I have some questions about a lintian warning I am getting from my > package. > > It complains that the NAME section of the man page can't be parsed. > > Here is how the section appears in my man page: > > > > NAME > >grk_compress — compresses images to JPEG 2000 format > > > > Note: I generate the man page from markdown files via pandoc. > > > > How can I get more insight into the problem? > > I have no particular relevant expertise, but one thing I notice > instantly is that that doesn't quite look like a standard hyphen. > > Indeed, copying it into a text file and examining it with a hex viewer > shows that — is apparently 0x8094, whereas - is 0x2d. > > It might be worth checking whether that one character is the cause of this. > Thanks! Yes, this is an em dash https://www.thesaurus.com/e/grammar/em-dash/ troff symbol is \[em] > -- >The Wanderer > > The reasonable man adapts himself to the world; the unreasonable one > persists in trying to adapt the world to himself. Therefore all > progress depends on the unreasonable man. -- George Bernard Shaw > >
Question about lintian bad-whatis-entry warning
Hi, I have some questions about a lintian warning I am getting from my package. It complains that the NAME section of the man page can't be parsed. Here is how the section appears in my man page: NAME grk_compress — compresses images to JPEG 2000 format Note: I generate the man page from markdown files via pandoc. How can I get more insight into the problem? Thanks, Aaron
Re: Interested in status of libgrokj2k package
Thanks, guys! On Wed, Dec 23, 2020 at 9:57 AM Adam Borowski wrote: > On Wed, Dec 23, 2020 at 09:44:18AM -0500, Aaron Boxer wrote: > > Dear Mentors. > > I submitted the libgrokj2k package over 6 months ago, and I am not clear > on > > its current status. > > It has been accepted into the NEW repo, and has been released to > UNSTABLE. > > Are there any other steps needed before it is fully upstream ? > > By "upstream", do you mean Debian? > > Yes. > > I have had questions from one user about when this package will be > > available. > > As Andrey just mentioned, a new upload was needed. You've just gave us > 7.6.2-1, which I've sponsored. So that's done, and it should migrate to > testing shortly. > > > For more info, my latest update v7.6.2 is here: > > https://mentors.debian.net/package/libgrokj2k/ > > I've noticed no problems over what lintian says. > > It would be nice if you could solve them in your next upload. > Thanks for the debian.net link, didn't know about that. I will fix the lintian warnings and also upload a source only package. Cheers, Aaron
Interested in status of libgrokj2k package
Dear Mentors. I submitted the libgrokj2k package over 6 months ago, and I am not clear on its current status. It has been accepted into the NEW repo, and has been released to UNSTABLE. Are there any other steps needed before it is fully upstream ? I have had questions from one user about when this package will be available. For more info, my latest update v7.6.2 is here: https://mentors.debian.net/package/libgrokj2k/ Thanks very much, Aaron
Bug#959143: RFS: libgrokj2k/7.1.0-1 [ITP] -- JPEG 2000 image compression/decompression library
> > > Hi! > Sorry for the delay. > > There's one problem left: the .symbols file for libgrokj2k1 declares a > dependency on libgrokj2k (rather than 2k1). Please bump it a year ahead :) > Thanks! that was the last lintian warning :) All green now.
Bug#959143: RFS: libgrokj2k/7.1.0-1 [ITP] -- JPEG 2000 image compression/decompression library
Hi Adam, Thanks a lot for testing this I've fixed the build error - please try it again when you have time. Cheers, Aaron On Fri, May 1, 2020 at 7:21 PM Adam Borowski wrote: > On Wed, Apr 29, 2020 at 04:53:38PM -0400, Aaron Boxer wrote: > > * Package name: libgrokj2k > >Version : 7.1.0-1 > > > It builds those binary packages: > > > > libgrokj2k1 - JPEG 2000 image compression/decompression library > > libgrokj2k1-dev - development files for Grok, a JPEG 2000 image library > > grokj2k-tools - command-line tools for the Grok JPEG 2000 library > > I'm afraid it doesn't build in a minimal chroot. > Log attached. > > -- > ⢀⣴⠾⠻⢶⣦⠀ > ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. > ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi > ⠈⠳⣄ >
Bug#959143: RFS: libgrokj2k/7.1.0-1 [ITP] -- JPEG 2000 image compression/decompression library
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libgrokj2k". Grok is one of only two actively developed open source JPEG 2000 toolkits on the planet. * Package name: libgrokj2k Version : 7.1.0-1 Upstream Author : boxe...@gmail.com * URL : https://github.com/GrokImageCompression/grok * License : AGPL-3 and BSD-2-clause * Vcs : https://github.com/GrokImageCompression/grok Section : libs It builds those binary packages: libgrokj2k1 - JPEG 2000 image compression/decompression library libgrokj2k1-dev - development files for Grok, a JPEG 2000 image library grokj2k-tools - command-line tools for the Grok JPEG 2000 library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libgrokj2k Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/libg/libgrokj2k/libgrokj2k_7.1.0-1.dsc Changes since the last upload: * Initial release. Closes: #954265 Thank You! -- Aaron Boxer
Re: How to manage CPU-specific features in package ?
On Sat, Apr 25, 2020 at 10:49 PM Charles Plessy wrote: > Le Sat, Apr 25, 2020 at 02:53:51PM -0400, Aaron Boxer a écrit : > > > > My library can use SIMD vector operations such as AVX2 if available on > > system. > > What is the best way of managing this ? > > Hello, > > maybe you can have a look at how other packages use `libsimde-dev`? > > https://wiki.debian.org/SIMDEverywhere Thanks, cool idea. Unfortunately, I do need AVX2 support. > > > Have a nice Sunday > > Charles > > -- > Charles Plessy > Debian Med packaging team, > http://www.debian.org/devel/debian-med > Akano, Uruma, Okinawa, Japan > >
Re: How to manage CPU-specific features in package ?
On Sat, Apr 25, 2020 at 5:10 PM Andrey Rahmatullin wrote: > On Sat, Apr 25, 2020 at 02:53:51PM -0400, Aaron Boxer wrote: > > Hello, > > My library can use SIMD vector operations such as AVX2 if available on > > system. > > What is the best way of managing this ? > Runtime detection. > > > Also, I tried logging onto #debian-mentors on freenode, but I got a > message > > about > > "invite only channel" > The official Debian IRC channels are on OFTC. > Thank you ! > -- > WBR, wRAR >
How to manage CPU-specific features in package ?
Hello, My library can use SIMD vector operations such as AVX2 if available on system. What is the best way of managing this ? For simplicity, I could create two packages, one with all SIMD disabled, and one assuming AVX2. What's the standard way of approaching this? Also, I tried logging onto #debian-mentors on freenode, but I got a message about "invite only channel" Thanks, Aaron
Re: Question about naming
On Wed, Apr 22, 2020 at 12:22 PM Wookey wrote: > On 2020-04-22 11:13 -0400, Aaron Boxer wrote: > > Hello!, > > > > I have created a new package for a library (grok) with the same name as > an > > existing debian package, so I have named my package grok-jpeg2000, > because it > > is an image coder for the JPEG 2000 standard. Will this mismatch between > my > > library name and my package name be a problem getting the package > accepted ? > > No. You can call the package whatever is reasonable, and of course > avoiding name clashes is necessary. And the source package name can be > nearly anything. > > However you can't (easily) just rename the library itself, because > things that depend on it will look it up by name and fail to find > it. This is fine - that package can be grok-jpeg200 (I see arch linux > has used the same name), and the library libgrok-jpeg200 or > libgrokn-jpeg2000, but the _binaries_ it installs are > /usr/lib//libgrok* > > That means that even with the binary package name clash avoided it > will not be co-installable with the other libgrok, because both > provide /usr/lib//libgrok. That may or may not be a problem > in practice (would anyone ever want both?) In this case you should > mark both packages as conflicting. Not idea, but hard to fix. > > You could fix this by using a different library name and fixing up the > name in all packages that depend on it, but that would still be a > problem for compiling external projects that depend on this libray. > > They may have wildly differing sonames and rates of change that are > likely to avoid filename clashes that way (i.e there would be > /usr/lib//libgrok.so.1 in libgrok1 and > /usr/lib//libgrok.so.23) in libgrok23, and not much danger of > the first putting out 22 more versions without the 2nd advancing, > although there is always some risk of that going wrong one day. > > The best thing to do depends on the popularity and satbility of these > projects and how many other packages/external projects use > them. Contacting the grok maintainer to discuss what would be best is > in order IMHO > Thanks a lot, Wookey! I think I will just change my library name. At this stage, no other libraries that I'm aware of are relying on the name. Aaron > > Wookey > -- > Principal hats: Linaro, Debian, Wookware, ARM > http://wookware.org/ >
Question about naming
Hello!, I have created a new package for a library (grok) with the same name as an existing debian package, so I have named my package grok-jpeg2000, because it is an image coded for the JPEG 2000 standard. Will this mismatch between my library name and my package name be a problem getting the package accepted ? Thanks! Aaron
Bug#958107: RFS: grok-jpeg2000/6.0.0-1 [ITP] -- development files for Grok, a JPEG 2000 image library
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "grok-jpeg2000". Grok is one of only two actively developed open source JPEG 2000 toolkits. * Package name : grok-jpeg2000 Version : 6.0.0-1 Upstream Author : boxe...@gmail.com * URL : https://github.com/GrokImageCompression/grok * License : [fill in] * Vcs : https://github.com/GrokImageCompression/grok Section : libs It builds those binary packages: grok-jpeg2000-12-dev - development files for Grok, a JPEG 2000 image library grok-jpeg2000-12 - JPEG 2000 image compression/decompression library grok-jpeg2000-tools - command-line tools using the JPEG 2000 library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/grok-jpeg2000 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/grok-jpeg2000/grok-jpeg2000_6.0.0-1.dsc Changes since the last upload: * Initial release. Closes: #954265 Regards, Aaron Boxer
Bug#956935: RFS: grok-jpeg2000/5.1.0-0 -- development files for Grok, a JPEG 2000 image library
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "grok-jpeg2000" Grok is one of only two actively developed open source JPEG 2000 codecs. * Package name : grok-jpeg2000 Version : 5.1.0-0 Upstream Author : boxe...@gmail.com * URL : https://github.com/GrokImageCompression/grok * License : [fill in] * Vcs : https://github.com/GrokImageCompression/grok Section : libs It builds those binary packages: grok-jpeg2000-10-dev - development files for Grok, a JPEG 2000 image library grok-jpeg2000-10 - JPEG 2000 image compression/decompression library grok-jpeg2000-tools - command-line tools using the JPEG 2000 library To access further information about this package, please visit the following URL: https://mentors.debian.net/package/grok-jpeg2000 Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/grok-jpeg2000/grok-jpeg2000_5.1.0-0.dsc Changes since the last upload: * Initial release Many Thanks! Aaron Boxer
Re: Uploaded packages not showing up on mentors.debian.net
On Fri, Apr 10, 2020 at 1:10 PM Andrey Rahmatullin wrote: > On Fri, Apr 10, 2020 at 12:55:32PM -0400, Aaron Boxer wrote: > > Hello! > > > > Is there a delay between when I upload a new package and when it shows > > up on the web site? I just uploaded a new package but I don't see it in > "My > > Packages". > Yes. Wait for the confirmation email (assuming you did everything > correctly). > Great, thanks! > > -- > WBR, wRAR >
Uploaded packages not showing up on mentors.debian.net
Hello! Is there a delay between when I upload a new package and when it shows up on the web site? I just uploaded a new package but I don't see it in "My Packages". Thanks very much, Aaron Boxer
