Bug#975040: ITP: dde-printer -- Deepin Print Manager is a eazy tool to manage printers
Package: wnpp Severity: wishlist Owner: Hu Feng X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : dde-printer Version : 0.6.3 Upstream Author : Wei xie * URL : https://github.com/linuxdeepin/dde-printer License : GPL-3+ Programming Lang : C++ Description : Deepin Print Manager is a eazy tool to manage printers. Deepin Print Manager is a printer management tool,which supports adding and removing printers,managing print jobs and so on. . It is part of Deepin software and DDE (Deepin Desktop Environment). . I intend to co-maintain this package inside pkg-deepin group.
Re: A Small Organisation Server as a Debian Pure Blend
On Wed, 2020-11-18 at 00:15 +, Paul Wise wrote: > On Mon, Nov 16, 2020 at 7:30 PM John Lines wrote: > > > I have been thinking about how to offer alternatives to Facebook, > > WhatsApp, Zoom etc for non-technical people, many of whom are > > finding the Internet and computers much more central to their lives > > than they did before the pandemic. > > This idea reminds me of Sandstorm, which aims to be a platform for > making it easy for non-technical folks to deploy and run web > applications. Nextcloud also comes to mind. > > https://sandstorm.io/ > https://nextcloud.com/ > > My main concern is who will be the sysadmins for such hosting (both > the physical machines and the operating system etc) and how will they > be motivated to continue doing that for the lifetime of the group? A > volunteer will eventually get bored and wander off at a critical > moment, leading to security problems, data loss or complete loss of > the service. Most groups won't have the money to hire a sysadmin. > There aren't many sustainable SaaS businesses that provide sysadmin > services by offering hosted FLOSS web applications at a price. Those > that do exist are mostly focussed around a limited number of > projects. That is why my target sysadmin is an 80 year old with an iPad. During lockdown many people have set up Facebook Groups (open and closed), managed membership and security for choirs, craft groups etc. They thus become keen salespeople for closed software systems, as generally, if their members want to remain in the group they have to join Facebook. I am not strongly against Facebook, but do not think they should be the only option. I believe/hope it should be possible to this type of thing another way, and that a technical sysadmin should not be needed. The SaaS businesses providing hosted FLOSS web applications at a price are a valid model, but they generally, quite reasonably, want to lock the customer into their service. Everything has to be paid for, but moving the payment point to a hosted system at an ISP allows flexibility and freedom by reducing lock-in. My thought experiment example is the Ambridge Garden Club, described at https://wordpress.debian.social/jlines/2020/11/07/the-ambridge-garden-club/ I hope to document how it was done, but also how it could have been done more easily. > Perhaps eventually AWS could do something like this, but they seem to > mainly be focussed on providing infrastructure to technical folks > rather than to consumers. I have set up systems on AWS for myself, but it is much too big a barrier for anybody non technical. I do suggest in https://wordpress.debian.social/jlines/2020/11/13/ambridge-garden-club-registering-the-domain/ that AWS might be a possibility, or Azure, or Google Cloud >
Re: Split Packages files based on new section "buildlibs"
Hello, (I thought I had sent this mail already, but it looks I haven't) One of the basic things we want is that users can get the source of their packages, modify a little, and make a new package for their own use. So in particular we want to be able to "apt source" and get all the sources, in their exact versions that were used when the package was built (pinned). A wish we can have in the case of libraries is to separate libraries and their lifecycles, so that e.g. if I have 10 packages relying on libc (dynamically), one security upgrade of libc will be immediately taken into account by the 10 packages that use it. So in that case it's nice to separate the library from the binary. But Rust and Go basically use static linking, so whatever they produce will embed the libraries. So it looks like this wish does not apply in the case of Rust and Go. So let's say that we do not packages libraries as binary packages: we do binary packages of only the applications. We will have one binary package built from e.g.: Application App 1.0 depends on Library Lib1 1.2 depends on Library Lib2 1.1 depends on Library Lib3 1.0 I'm not sure what is the mechanism used in Go or Rust to "pin" the versions of Lib1, Lib2 and Lib3, but it is necessary that if a user does "apt source App" the correct versions of the dependencies are checked out. And I guess most Application release tarballs do not pin them themselves, so it would need to be pinned somewhere else, such as inside the debian/ directory, or in an aggregate upstream tarball that would contain all the sources. If we choose to make an aggregate upstream tarball, it would contain all the sources of all the dependency tree inside one single tarball: App-aggregate-1.2.tar.gz: Application App 1.0 (contents of the source tarball) Library Lib1 1.2 Library Lib2 1.1 Library Lib3 1.0 App-aggregate would be versioned wholly instead of versioning the parts. So if we want to bump e.g. Lib3 to 1.1, we would need to make a new version of the upstream tarball. The issue which this aggregate is that there will probably be lots of duplicated source code. For example, if some library Lib1 is very popular and used by lots of applications, we will have its source code embedded into the source packages of all these applications, and that would be wasteful in terms of storage of the source packages. Can we find a way for source packages to indicate /several/ upstream tarballs, so that each version of the Lib1 upstream tarball is stored only once? App_1.0-1.dsc: Files: App-1.0.orig.tar.gz App-1.0-1.debian.tar.xz Lib1-1.2.orig.tar.gz Lib2-1.1.orig.tar.gz Lib3-1.0.orig.tar.gz -- Fabrice BAUZAC-STEHLY PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D
Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Paul, sorry for the late reply. On Tue, Nov 10, 2020 at 09:02:56PM +0100, Paul Gevers wrote: > On 10-11-2020 13:21, Andreas Tille wrote: > > Yes, that's true but its part of my question: Why should all these > > tests be run if the dependencies are not available on that architecture. > > Wouldn't it be more sane to check dependencies first before running > > a test that will fail for sure? > > The are not running, clearly, as the text says. But you are wondering if > we should not put that text there because it confuses you? Because other > people may be wondering why they are not seeing the results. Well, the test is not actually run - since it can not be run. In those cases we see a long log to create the debci environment and try to install the package ... which fails. I'm wondering whether it would be easy to find out in advance whether it is possible to install that package on that architecture (for instance by an UDD query whether all dependencies are available or whatever) and just stop if it turns out that the package is not installable. > >>> While the package itself is > >>> > >>>Architecture: all > >>> > >>> it depends from picard-tools which is amd64 only. In this example we will now see a change since there was just an upload of picard-tools which will be arch all ... (see last paragraph of this mail) > >> The release team recently swapped i386 for arm64 in > >> "NOBREAKALL_ARCHES"[0][1]. That means that arch:all packages need to be > >> installable on arm64 and yours isn't. AFAIK. > > > > OK, fine. For the example drop-seq-tools I could make it > > > > Architecture: amd64 > > > > which is solving the current migration problem. However, I'm currently > > checking failing autopkgtests for Debian Med packages and add > > Architecture fields to debian/tests/control. In most cases this is > > perfectly easy auto-detectable from the package dependencies that the > > test will fail. > > Please elaborate. In my experience, things only go ill when package > build both arch:all and some arch specific packages, as in that case the > migration software just doesn't have enough information available. As I tried to say above: I would prefer to find out before apt runs in a fully setup test environment whether the package is installable at all. > > I would love to see that dependency issue resolved by > > debci in the first place instead of assuming that maintainers will > > maintain this inside the control file. Chances are pretty good that > > once those dependencies might become available maintainers will simply > > forget to add a new architecture to debian/tests/control. That way we > > might hide future tests on those architectures from debci. > > Yes, that's something I worry about too, but I also don't have a better > solution with the current information available to the migration > software. Obviously we could expend that, but that has a rather high > price so we better design it well and balance pro's and con's. My idea is to find out whether a package is installable on some architecture and add a new test result say "NOT_INSTALLABLE" or "NOT_INSTALLABLE_ON_ARCH" which is considered "neutral" as test result. Than there would be no pressure on maintainers side to actively exclude these architectures from tests. Kind regards Andreas. -- http://fam-tille.de
Re: A Small Organisation Server as a Debian Pure Blend
On Wed, 2020-11-18 at 11:06 +, John Lines wrote: > I believe/hope it should be possible to this type of thing another way, > and that a technical sysadmin should not be needed. You would still need a sysadmin to do the hardware, OS and software setup, fixes, tweaks, replacement, etc. > I have set up systems on AWS for myself, but it is much too big a > barrier for anybody non technical. I was suggesting that AWS themselves would be the right folks to do this, since they have the scale to distribute the sysadmin/etc costs over many many customers in order to make it affordable enough. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: A Small Organisation Server as a Debian Pure Blend
On Tue, 2020-11-17 at 22:10 +0530, Joseph Nuthalapati wrote: > FreedomBox has been successfully used in community deployments to > serve > a number of useful applications from a locally hosted server. This is > documented in the WikiBook, FreedomBox for Communities[1]. > > I agree with you that a Debian Pure Blend for small organizations > overlaps significantly with FreedomBox. However, there are some > differences to keep in mind: > > 1. FreedomBox's primary focus is on privacy, not self-hosting in > general. > 2. FreedomBox is meant to be small and personal, so supporting an > organization with a thousand users is not a priority for the project. > An organisation with a thousand users, or more should expect to be putting more resources into administration than one of 20 to 200, which is what I would call a small organisation. I presume, for example that the members know each other already, as they have something which brings them together. An important part of privacy is to separate what you intend to make public from what you wish to keep private. If all content creation happens on platforms where the content consumers need (free, but exchanged for their privacy) registration to access that content then accessing them through Tor does not provide any benefit. > The applications desired by home users and office users can be > different. For example, a home user can be satisfied with a simple > expense tracker to manage personal finances, while an organization > might > require full-blown accounting software. > I would not normally expect the small organisation to do their accounts on a hosted web service, even self hosted, as that is the type of thing which I would regard as private (at least up to the stage where they publish their accounts). I would prefer that their treasurer did they type of simple home office work via LibreOffice Calc and so on, but realistically they probably use Excel - but that is a different topic. > That being said, FreedomBox is currently the only pure blend that is > primarily meant for hosting servers. Hence it can be a very good > foundation on which to start the pure blend for small organizations. > I am experimenting with a fork of Freedombox which does takes some of the things which are only relevant for a system behind NAT on a home network, and which I hope than then back pulled back into the main code base. > FreedomBox is already being published as an Amazon Machine Image for > easy self-hosting on AWS EC2[2]. Currently, this is only being > recommended for trial purposes to FreedomBox users. > > As Wookey mentioned, in case of a cloud setup, some modules that > assume > that the device is on a home network can be turned off or some > features > selectively disabled. > > Regardless of whether applications are integrated into FreedomBox > itself > or a new pure blend is made, the primary challenge is still packaging > large web applications for Debian. In my opinion, it is better to not > invest effort into building another web application like FreedomBox. > Instead, reuse the parts which FreedomBox got right and put more > efforts > into bringing more server applications into Debian. > > 1. https://en.wikibooks.org/wiki/FreedomBox_for_Communities > 2. https://freedombox.org/cloud/ > One of the first things I want for my ambrige-gaden-club.org.uk example is email, as in an MTA (postfix), with IMAP server (Dovecot) and web access (roundcube) - but with the expectation that in general most members will have an existing mail address, so it will just be forwarding. This is a very common use-case for small organisations at present, but hard to get right. (one of the reasons for using an example organisation rather then one of the ones I am involved in is that I can experiment without losing real people's email etc.
Re: A Small Organisation Server as a Debian Pure Blend
On Tue, 2020-11-17 at 02:07 +, Wookey wrote: > On 2020-11-16 19:20 +, John Lines wrote: > > > ... > >I have written > >at > > https://wordpress.debian.social/jlines/2020/11/07/the-ambridge-garden-club/ > > about > >a such a group, as I am interested to know if others feel this > > is also a > >problem, and a one worth trying to solve. > > Definitely. I have been frustrated that our local charity has to pay > zoom several hundred pounds to hold our AGM virtually because they > want some of the advanced features which cost money (broadcasting > with > central control of audio and attendees not visible). They have no > idea > that things like Big Blue Button exist (which I suspect, but don't > know) also has these features. And even if they did know they have no > technical expertise/bandwidth to set it up. I think Big Blue Button is beyond the scope of the type of organisation I have in mind, in terms of requirements, though it would be good to have them more widely known. I find the mind share that Zoom has a bit alarming, and I seem to be spending over 8 hours a week in Zoom meetings - I do not thing it is good that any single product becomes synonymous with a type of service. > > Similarly it would be great if _everything_ wasn't only on twitter > and > facebook and somethings made it to matrix, disapora and mastodon. But > the network effect is really powerful here, and groups might discover > these things if they had their own service for some other reason > (such > as wanting jitsi/wordpress/BBB services they controlled). > > >My proposed solution is a Debian Pure Blend for a Small > > Organisation > >Server (sos) designed to be installed at a hosting provider, and > > accessed > >and administered through a web interface. It shares quite a lot > > of > >similarity, and should probably, have as much as possible in > > common with > >the FreedomBox project - for example probably plinth. > > Another relevant model is framasoft, who provide these services (as a > collective service, rather than a per-organisation server), but would > like many more organsations to do this. I don't know how easily > reproducible their setup is. I like Framasofts software and philosophy. I suppose some of the motivation for the Small Organisation Server comes down to economics. I appreciate they way they, as well as the many ethically motivated groups, provide free services for anybody, but I do not think that scales to the selfish wider world. The Ambrige Garden Club - my sample small organisation is funded by its members subscriptions (hypothetically - actually by me), and has control of the resources consumed by its members, thus if somebody uses excessive disk space on the subject, say of steam trains, it is up to them to suggest that member put those pictures etc somewhere else. > > >It is differentiated from FreedomBox at at technical level by, > > for > >example, not using avahi - the Small Organisation Sever would > > share a > >local network at an ISP with other completely unrelated servers, > > neither > >would should it depend on netcat-openbsd, ppp, pppoe etc, which > > are > >targetted at a different situation. > > Does it need to be a new blend to work, or can it be a config option > on freedombox? The targets are so similar it seems like we ought to > be > able to use the same codebase? I have not followed the project > closely > after the first year or two so don't actually know exactly how it is > now. > > >I think it would be good to be able to provide the facilities > > available > >via https://wiki.debian.org/Teams/DebianSocial to other > > organisations, and > >wonder it you agree ? > > I think this is a worthy technical goal. Given the decade it has > taken for Fredombox to get this far I suspect the pandemic will be > over before we get something working at a reasonably numpty-proof > level, unless an impressive level of enthusiasm is collected and > applied. > I am really keen for the pandemic to be over, and in the mean time am seeing how far this will get. I want to avoid re-inventing the wheel as much as possible, hoping to work with Freedombox people on common ground. > I have just set up a small server yesterday in order to experiment > with this stuff (setting up matrix-synapse initially, but jangouts > and BBB are also of interest, although neither are packaged). > > So yes, knock something up and I will be happy to at least test it. I will let you know when there is something at the testable level. I am putting bits up at https://wordpress.debian.social/jlines/ though that often lags where I am. > > Wookey
Re: A Small Organisation Server as a Debian Pure Blend
On Wed, 2020-11-18 at 19:48 +0800, Paul Wise wrote: > On Wed, 2020-11-18 at 11:06 +, John Lines wrote: > > > I believe/hope it should be possible to this type of thing another > > way, > > and that a technical sysadmin should not be needed. > > You would still need a sysadmin to do the hardware, OS and software > setup, fixes, tweaks, replacement, etc. > At that level the paid sysadmin would be the hosting provider from which the host was rented, which might be Amazon, or a independent. Within the system, apt automatic updates seem to be doing a pretty good job now. The tricky part is major version upgrades, which Debian does pretty well - I think - although the system I am writing this on was installed with wheezy and has been updated through all the releases since, and is now running bullseye, I usually - like now, jump to a testing release before the freeze. I have done upgrades from one stable release to another, and think they should be OK. Most people running on Windows used to just buy a new server every major release, which kept everybody (hardware sales and Microsoft) quite happy > > I have set up systems on AWS for myself, but it is much too big a > > barrier for anybody non technical. > > I was suggesting that AWS themselves would be the right folks to do > this, since they have the scale to distribute the sysadmin/etc costs > over many many customers in order to make it affordable enough. >
Re: A Small Organisation Server as a Debian Pure Blend
Hi John, Quoting John Lines (2020-11-18 13:35:42) > On Tue, 2020-11-17 at 02:07 +, Wookey wrote: > > On 2020-11-16 19:20 +, John Lines wrote: > > > I have written at > > > https://wordpress.debian.social/jlines/2020/11/07/the-ambridge-garden-club/ > > > > > > about a such a group, as I am interested to know if others feel > > > this is also a problem, and a one worth trying to solve. I see this problem too, and am working on addressing it. But slowly. My aim is to purely integrate tools officially in Debian (which is what I defined as "Debian Pure Blend", btw). So to me, the first step is to make sure all parts are packaged officially in Debian, and is well maintained and in healthy shape upstream as well... > > Definitely. I have been frustrated that our local charity has to pay > > zoom several hundred pounds to hold our AGM virtually because they > > want some of the advanced features which cost money (broadcasting > > with central control of audio and attendees not visible). They have > > no idea that things like Big Blue Button exist (which I suspect, but > > don't know) also has these features. And even if they did know they > > have no technical expertise/bandwidth to set it up. > > I think Big Blue Button is beyond the scope of the type of > organisation I have in mind, in terms of requirements, though it would > be good to have them more widely known. > > I find the mind share that Zoom has a bit alarming, and I seem to be > spending over 8 hours a week in Zoom meetings - I do not thing it is > good that any single product becomes synonymous with a type of > service. I distinguish between 4 categories of video conferencing services: a) frontend-only b) frontend + lighweight backend c) frontend + heavyweight backend d) cloud-only or in other ways non-free BigBueButton and Jitsi are both in category c). My interest is category b) because - unlike c) or d) - can most realistically be hosted on small hardware with reduced administration, and - unlike a) - can serve rooms of more than 6-8 participants. Among category b) solutions, I am aware of these in active development: * jangouts, using janus backend * multiparty-meeting, using mediasoup backend I maintain the janus package and am happy to collaborate on getting more (both related and competing) components packaged. I am also interested in information about tools that I might have missed. Here's what I am aware of already: https://source.redpill.dk/media-stream-hosting/tree/DEVELOP.md If your interest is in integrating something *now* to have it quickest possible usable, then I recommend that you collaborate closely with [FreedomBox] to not fork it but improve it to be flexible enought to fit also your needs. [FreedomBox]: https://wiki.debian.org/FreedomBox If your interest is too different from FreedomBox and you have strong ideas and opinions on exactly how you want to approach it, then I recommend that you draft your ideas and principles on the Debian wiki, and invite people to check it out and join you more concretety. If your interest is too different from FreedomBox and you are flexible or undecided on how to realize it, then maybe you like my [SolidBox] project. :-) [SolidBox]: https://wiki.debian.org/Solidbox Even if you dislike my SolidBox project, I am also working on another more practical and less ambitious one called Redpill. That one lack documentation, however: Join the irc channel #tinker on OFTC and let me try explain it to you... :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: A Small Organisation Server as a Debian Pure Blend
On 2020-11-18 11:06:20 + (+), John Lines wrote: [...] > I do suggest in > > https://wordpress.debian.social/jlines/2020/11/13/ambridge-garden-club-registering-the-domain/ > > that AWS might be a possibility, or Azure, or Google Cloud If you're going to advocate for free/libre open source software, remember that AWS, Azure and Google Cloud are the antithesis of it yet have many, many, many competitors based entirely on F/LOSS you could be recommending instead. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Andreas, On 18-11-2020 12:45, Andreas Tille wrote: > On Tue, Nov 10, 2020 at 09:02:56PM +0100, Paul Gevers wrote: >> On 10-11-2020 13:21, Andreas Tille wrote: >>> Yes, that's true but its part of my question: Why should all these >>> tests be run if the dependencies are not available on that architecture. >>> Wouldn't it be more sane to check dependencies first before running >>> a test that will fail for sure? >> >> The are not running, clearly, as the text says. But you are wondering if >> we should not put that text there because it confuses you? Because other >> people may be wondering why they are not seeing the results. > > Well, the test is not actually run - since it can not be run. In those > cases we see a long log to create the debci environment and try to > install the package ... which fails. I have the strong impression that we're talking past each other. The log message that you quoted in your initial e-mail said "uninstallable on arch *, not running autopkgtest there". This means the test is not triggered *and* that fact will *not* block the package. However, you are now saying we're scheduling the test which fails. That's a completely different category. > I'm wondering whether it would > be easy to find out in advance whether it is possible to install that > package on that architecture (for instance by an UDD query whether > all dependencies are available or whatever) and just stop if it turns > out that the package is not installable. Yes, we can (and do) that, but what then? If the non-installability is a regression, we should block the package. If the non-installablility is already existing, the package should just move on. We already do that (or at least try very hard). So, which *exact* use case do you consider here (real life examples help). >> Please elaborate. In my experience, things only go ill when package >> build both arch:all and some arch specific packages, as in that case the >> migration software just doesn't have enough information available. > > As I tried to say above: I would prefer to find out before apt runs > in a fully setup test environment whether the package is installable > at all. As I tried to say above, we already don't schedule the test in *most* cases and as far as I'm aware, we only have some issues where arch:all packages are involved. In some cases, I don't think there is a "right" answer, so we need to get the most acceptable solution. >>> I would love to see that dependency issue resolved by >>> debci in the first place instead of assuming that maintainers will >>> maintain this inside the control file. Chances are pretty good that >>> once those dependencies might become available maintainers will simply >>> forget to add a new architecture to debian/tests/control. That way we >>> might hide future tests on those architectures from debci. >> >> Yes, that's something I worry about too, but I also don't have a better >> solution with the current information available to the migration >> software. Obviously we could expend that, but that has a rather high >> price so we better design it well and balance pro's and con's. > > My idea is to find out whether a package is installable on some > architecture and add a new test result say "NOT_INSTALLABLE" or > "NOT_INSTALLABLE_ON_ARCH" which is considered "neutral" as test result. We don't schedule those cases we can catch. So we don't need to have a new state. If we can find the exact problem you're describing we can try to add it to the set we don't trigger. (By the way, are you aware of the skip-not-installable restriction? It's not great, as it hides real issues, but could be a solution for a class of packages, maybe the ones you worry about). > Than there would be no pressure on maintainers side to actively exclude > these architectures from tests. Indeed. That should be hardly needed. Paul signature.asc Description: OpenPGP digital signature
Bug#975091: ITP: r-cran-lomb -- Computes the Lomb-Scargle Periodogram for unevenly sampled time series. Includes a randomization procedure to obtain reliable p-values.
Package: wnpp Severity: wishlist Owner: Benjamin Morledge-Hampton Package name: r-cran-lomb Version : 1.2-1 Upstream Author : Thomas Ruf URL : https://salsa.debian.org/r-pkg-team/r-cran-lomb/ License : GPL-2+ Programming Lang: R Description : Computes the Lomb-Scargle Periodogram for unevenly sampled time series. Includes a randomization procedure to obtain reliable p-values. Function lsp computes the Lomb-Scargle periodogram for unevenly sampled time series (e.g., series with missing data). P-values for the highest peak in the periodogram are computed from the exponential distribution. Alternatively, function randlsp computes a p-value for the largest peak in the periodogram by repeatedly randomising the time- series sequence. Both functions allow setting the range of frequencies to be inspected, as well as the stepsize (oversampling factor) used for frequency scanning.
Bug#975107: ITP:deepin-album -- The album for Deepin Desktop Environment
Package:wnpp Severity: wishlist Owner: Tu Qinggang X-Debbugs-Cc: debian-devel@lists.debian.org * Package name : deepin-album Version : 5.6.9.34 Upstream Author : Deepin Technology Co, Ltd. * URL : https://github.com/linuxdeepin/deepin-album License : GPL-3.0 Programming Lang: C++ Description : The album for Deepin Desktop Environment Deepin-album is a fashion photo manager for viewing and organizing pictures. It is part of Deepin software and DDE (Deepin Desktop Environment) I intend to maintaining this.
Bug#975110: ITP: webpackage -- WebPackage is a revolutionary way of distributing web apps.
Package: wnpp Severity: wishlist Owner: Witherking25 * Package name: webpackage Version : 1.5.2 Upstream Author : Name * URL : https://github.com/WebPackage/WebPackage * License : GPL3 Programming Lang: C++ Description : WebPackage is a revolutionary way of distributing web apps. WebPackage is a revolutionary new way of distributing web apps on any platform. It works by packaging the web app in a .webpkg file, a special kind of zip file designed for distributing web apps.
Bug#975111: ITP: webpackage -- WebPackage is a revolutionary way of distributing web apps.
Package: wnpp Severity: wishlist Owner: Witherking25 * Package name: webpackage Version : 1.5.2 Upstream Author : Witherking25 * URL : https://github.com/WebPackage/WebPackage * License : GPL3 Programming Lang: C++ Description : WebPackage is a revolutionary way of distributing web apps. WebPackage is a revolutionary new way of distributing web apps on any platform. It works by packaging the web app in a .webpkg file, a special kind of zip file designed for distributing web apps.
Re: Migration of packages blocked if (Build-)Depends are missing on some test architectures
Hi Paul, On Wed, Nov 18, 2020 at 08:18:01PM +0100, Paul Gevers wrote: > > Well, the test is not actually run - since it can not be run. In those > > cases we see a long log to create the debci environment and try to > > install the package ... which fails. > > I have the strong impression that we're talking past each other. The log > message that you quoted in your initial e-mail said "uninstallable on > arch *, not running autopkgtest there". This means the test is not > triggered *and* that fact will *not* block the package. However, you are > now saying we're scheduling the test which fails. That's a completely > different category. What I mean when looking at the armhf log[1] this starts with autopkgtest [21:45:36]: host ci-worker-armhf-01; command line: /usr/bin/autopkgtest --no-built-binaries '--setup-commands=echo '"'"'drop-seq unstable/armhf'"'"' > /var/tmp/debci.pkg 2>&1 || true' --user debci --apt-upgrade '--add-apt-source=deb http://incoming.debian.org/debian-buildd buildd-experimental main contrib non-free' --add-apt-release=experimental --pin-packages=experimental=src:plexus-archiver --output-dir /tmp/tmp.R29JBBc7iX/autopkgtest-incoming/unstable/armhf/d/drop-seq/7114930 drop-seq -- lxc --sudo --name ci-265-4a1a79f8 autopkgtest-unstable-armhf autopkgtest [21:46:22]: test bed setup Get:1 http://incoming.debian.org/debian-buildd buildd-experimental InRelease [39.8 kB] Get:2 http://incoming.debian.org/debian-buildd buildd-experimental/main armhf Packages [26.3 kB] Fetched 66.1 kB in 1s (71.0 kB/s) Reading package lists... Get:1 http://deb.debian.org/debian experimental InRelease [72.3 kB] Get:2 http://deb.debian.org/debian experimental/contrib Sources [2,052 B] Get:3 http://deb.debian.org/debian experimental/non-free Sources [3,416 B] Get:4 http://deb.debian.org/debian experimental/main Sources [334 kB] Get:5 http://deb.debian.org/debian experimental/main armhf Packages [400 kB] Get:6 http://deb.debian.org/debian experimental/contrib armhf Packages [2,500 B] Get:7 http://deb.debian.org/debian experimental/non-free armhf Packages [1,776 B] Fetched 816 kB in 0s (2,498 kB/s) and way later in the end it says Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: drop-seq-tools : Depends: libgkl-java but it is not installable Depends: libpicard-java but it is not installable Depends: picard-tools but it is not installable E: Unable to correct problems, you have held broken packages. run-unit-testFAIL badpkg blame: drop-seq badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U. autopkgtest [21:46:47]: summary run-unit-testFAIL badpkg For me that's an attempt to run a test when apt starts getting files. That's what I was talking about. I think this has changed now since for arm64[2]. This log is way shorter and ends with run-unit-testSKIP Test lists explicitly supported architectures, but the current architecture amd64 isn't listed. The result is "neutral" - and I think you was talking about the latter which seems to be relatively new when looking at the overview page[3]. The log from 2020-11-08 looks similar to the armhf log above but since 2020-11-11 it has the neutral result (which is what I tried to suggest). > > I'm wondering whether it would > > be easy to find out in advance whether it is possible to install that > > package on that architecture (for instance by an UDD query whether > > all dependencies are available or whatever) and just stop if it turns > > out that the package is not installable. > > Yes, we can (and do) that, but what then? If the non-installability is a > regression, we should block the package. This is definitely a good question. > If the non-installablility is > already existing, the package should just move on. We already do that > (or at least try very hard). So, which *exact* use case do you consider > here (real life examples help). I think my real life example drop-seq was a good one. > > As I tried to say above: I would prefer to find out before apt runs > > in a fully setup test environment whether the package is installable > > at all. > > As I tried to say above, we already don't schedule the test in *most* > cases and as far as I'm aware, we only have some issues where arch:all > packages are involved. In some cases, I don't think there is a "right" > answer, so we need to get the most acceptable solution. That's true and I agree that the decision whether the missing of a package has to be considered a fai
