Processed: closing 931988
Processing commands for cont...@bugs.debian.org: > close 931988 Bug #931988 [wnpp] ITP: kopano-webapp-plugin-intranet -- Kopano WebApp intranet plugin Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 931988: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931988 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: closing 931882
Processing commands for cont...@bugs.debian.org: > close 931882 Bug #931882 [wnpp] ITP: kopano-webapp-plugin-desktopnotifications -- Kopano WebApp desktopnotifications plugin Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 931882: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931882 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#810890: Packaging caddyserver-certmagic
Hi, On 3/17/21 07:04, SECOB271_Ganesh Pawar wrote: Hey there! I would like to package and maintain caddyserver's certmagic package if you allow me to. I would like to ultimately package the caddy server. Yes, see the other comments on this bug (thread) and coordinate the work with them. Z
Bug#984497: weasels and doves
> Op 08-03-2021 17:36 schreef Andrius Merkys : > > > Hi, > > On 2021-03-08 15:44, Albert van der Horst wrote: > > I don't see the problem here. If there is a bug in an old version supplied > > with Debian, the bug report lands with Debian. > > Not necessary. Many users cannot tell whether a bug is caused by > upstream code or Debian packaging. Many users do not know about Debian > BTS. Thus Debian-specific bugs land in upstream trackers, and some > upstreams do not want to provide support outside what they consider > "canonical" use of their software. This surprises me. I use Debian for reliability. I expect the Debian package more reliable than whatever upstream supplies. So I would file a bug in the Debian system. I also expect that Debian wants to know the bugs of all packages, not just "Debian-specific" in order to remove packages of low quality. Maybe my esteem/expectation of Debian is too high ... > > > Then Debian can solve the bug report by renewing upstream. Sot that bug > > report is not against the package, but against the packaging. > > True, but this might be slowed down by the update process in stable. Right, but then bugs against a stable version should be rare. > Definitive fixing maybe. But if I have a problem and stable I can always load a fixed version from test. I can now see that bleeding edge developpers, who are fast moving and generating many bugs, will want to keep out of Debian. But why would Debian want them in? Anywhere, obviously it is best to grant their wish, even if they have no legal standing. FOSS is FOSS, right? > Best, > Andrius Groetjes Albert
Bug#787080: Bug#894119: libreoffice: Please add libreoffice-online to the debian repository.
Hi, Am 16.03.21 um 22:02 schrieb Adi Kriegisch: > thank you very much for the hard work you've put in packaging libreoffice > online. Starting from your salsa repo[1] I was able to successfully build > loolwsd and loleaflet packages with the libreoffice packages from > buster-backports. There were, however, some issues with the unit tests. > After trying to investigate some of the issues, I decided to skip the test > by adding an empty override_dh_auto_test target. Yeah, that one is a mess upstream: - unit tests need debug - tests need write permissions in the LO directory (which they of course don't have in /usr/lib/libreoffice) ... > Is there any reason why you use loolwsd's init script to configure it > instead of setting the defaults in /etc/loolwsd/loolwsd.xml? With the > current init script this does not work. That part wasn't updated for some time, I wouldn't be surprised if it broke. /etc/default is a well-known location for environment variables needed by init scripts, though. That said, for init script I'd stay as close as with upstream as possible since maintaining an initi script is a PITA. (People ideally should use systemd and the systemd unit anyway but init scripts still should be shipped if feasible.) But MRs (or patches if you don't have an account on salsa) welcome. > I very much hope, you're going to continue your excellent work and > libreoffice online hits the debian archive any time in a not too distant > future! ;-) If someone sorts out the JS mess and packages the modules (and keeps the chain uptodate) ;-) Then we just need to figure out the test mess (maybe not run them during the build at all indeed and make it a "needs-root breaks-testbed" autopkgtest. One should probably add a autopkgtest anyway.) Regards, Rene
