Re: Announcing the new "pkg-rpm" team
Thanks Thomas, Just created a wiki page: https://wiki.debian.org/Teams/pkg-rpm regards -- Arturo Borrero González
Bug#832580: ITP: openstack-manuals -- docs for installing and using OpenStack
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: openstack-manuals Version : 0~2016.07.17.git63e48423fd Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/openstack-manuals * License : Apache-2.0 Programming Lang: RST Description : docs for installing and using OpenStack This source package contains various manuals: - install-guide - install-guide-debconf - image-guide - admin-guide - etc. The source package will produce a subset of these.
Bug#832596: ITP: ppx-core -- standard library for ppx rewriters
Package: wnpp Severity: wishlist Owner: "Stéphane Glondu" * Package name: ppx-core Version : 113.33.03 Upstream Author : Jane Street Holding, LLC * URL : https://github.com/janestreet/ppx_core * License : Apache-2.0 Programming Lang: OCaml Description : standard library for ppx rewriters Ppx_core is a standard library for OCaml AST transformers. It contains: * various auto-generated AST traversal using an open recursion scheme * helpers for building AST fragments * helpers for matching AST fragments * a framework for dealing with attributes and extension points This is a new (transitive) dependency of ocaml-ipaddr.
Bug#832611: ITP: tinyssh -- Tiny SSH server
Package: wnpp Severity: wishlist Owner: Jan Mojzis * Package name: tinyssh Version : 20160726 Upstream Author : Jan Mojzis * URL : https://tinyssh.org/ * License : public domain Programming Lang: C Description : Tiny SSH server This is tiny SSH server which implement 'less'. TinySSH supports only secure crypto (min 128-bit security, protected against cache-timing attacks). Unnecessary features (such SSH1 protocol, compression, scp, sftp, ...), unsafe crypto (such rsa, dsa, hmac-md5, hmac-sha1, 3des, arcfour, ...) and unsafe features (such password or hostbased authentication) are simply NOT implemented. TinySSH has less than 10 words of code, so it's very easy auditable. I'm an upstream author and I'm going to maintain using collab-maint. I need sponsor.
Bug#832613: ITP: kronatools -- explore hierarchical metagenomic data with zoomable pie charts
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: kronatools Version : 2.7 Upstream Author : Brian Ondov, Nicholas Bergman, and Adam Phillippy * URL : https://github.com/marbl/Krona/wiki * License : BSD Programming Lang: Perl, JS Description : explore hierarchical metagenomic data with zoomable pie charts Krona allows hierarchical data to be explored with zoomable pie charts. Krona charts include support for several bioinformatics tools and raw data formats. The charts can be viewed with a recent version of any major web browser. Remark: This package is a precondition for metabit and will be maintained at https://anonscm.debian.org/cgit/debian-med/kronatools.git
Mitel users contact list
Hi, We're writing to ascertain your interest in acquiring our recent Mitel users' contact list. We also provide user contact list for 1&1, Amdocs, Ascom, Bics, Ciena, Huawei Cloud Core, IDT, Insight, Netcracker, NTT Communications, Plintron, Synway, TDS, West IPC, West Unified Communications, Windstream and many more. We can provide you user contacts or decision makers list from all industries globally that meets your marketing criteria. Kindly let me know your interest, or forward this email to the head of marketing in your company. Thanks, Edith Beck Information Specialist. Reply âRemoveâ to Opt-Out.
Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)
Simon McVittie wrote: Hi, Recommendations for other software that relies on D-Bus === This recommendation applies to ordinary apps that rely on having a session bus but are not a core part of a desktop environment, such as the Empathy real-time communications client. These packages should rely on the distribution and the desktop environment cooperating to ensure that a session bus is provided. A hard requirement for a session bus should be indicated like this: Depends: dbus-user-session | dbus-x11 (Open question: do we prefer d-x | d-u-s?) A softer requirement can be indicated by a similar Recommends or Suggests. These packages should not attempt to run dbus-launch or dbus-daemon, except as a side-effect of using a library that supports X11 autolaunching - it is not their responsibility. Is that really up-to the individual application to declare a dependency against dbus-user-session | dbus-x11 ? If the package name is changing or if we are dropping dbus-x11 in the future that would require modifying again quite some packages. Shouldn't this dependency only be declared at some other level (libdbus, GDBus,...)? my 2¢ Laurent Bigonville
Re: Policy 12.3: should I rename?
]] Sven Bartscher > I am a developer and regardless of the distribution I use, I often have > a slow internet connection. So having to download possibly large > documentation is a problem for me. How do you keep up with unstable or testing, then? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)
On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote: > Is that really up-to the individual application to declare a dependency > against dbus-user-session | dbus-x11 ? At the moment: yes. A dependency on dbus-x11 (in jessie) or on dbus-user-session | dbus-x11 (now) can be used to signify "this application or library is useless without a working session bus". Apps that rely on Telepathy, Tracker or the Evolution servers are good examples of a legitimate dependency on the session bus. Depending on dbus is not enough: that only guarantees working D-Bus binaries (so you have all the right bits to get a session bus, but some assembly is required) and a working system bus. The only other ways I can think of right now to express that requirement are: * introduce a metapackage "dbus-session" with that dependency, and ask these apps to depend on it, or on dbus-session | dbus-x11 to be nice to backports; * give up on it entirely, and consider a working D-Bus session to be an essential/assumed part of desktop environments (like a working X11 server is), with a policy that only desktop environment tasks need to declare the dependency, and random apps can just assume it (Arguably we already have this situation; I'm sure there are lots of apps that don't declare this dependency but are unusable without D-Bus because they rely on GApplication, fd.o Notifications or some other piece of infrastructure that relies on the session bus.) > If the package name is changing or if we are dropping dbus-x11 in the future > that would require modifying again quite some packages. I currently count 55 direct Depends and 17 Recommends on dbus-x11, to give you an idea of the number of packages involved. The last time this changed was the introduction of dbus-x11 in 2007; twice in a decade isn't bad. I don't think it's necessarily going to change again any time soon (unless we do a transition to dbus-x11 | dbus-user-session and then another to dbus-user-session | dbus-x11, which is why I'd prefer not to do that two-stage approach). If we drop dbus-x11 at some point in the future, or even fold dbus-user-session into dbus, those packages won't need modification: as long as either dbus-user-session still exists, or dbus Provides it, those packages are still Policy-compliant (I believe we only require one branch of an "or"-group to be available in main). In practice I don't think this is going to happen any time soon, for the reasons mentioned under "Why should dbus-user-session be optional?" in my original mail. > Shouldn't this > dependency only be declared at some other level (libdbus, GDBus,...)? I think this would have to be a new dbus-session metapackage, unless I'm missing something. dbus is the wrong place, and so are all the obvious libraries. dbus Suggests dbus-user-session | dbus-x11 already. Anything stronger than Suggests seems inappropriate because it would be a circular dependency (dbus-user-session and dbus-x11 both need dbus, for dbus-daemon). libdbus-1-3 shouldn't depend on a session bus, because you might only be using it to access the system bus; conversely, you might be using a different implementation like GDBus or sd-bus or dbus-java and you'd still be missing the dependency. It would also be a circular dependency, via dbus (dbus Depends libdbus-1-3 Depends (dbus-user-session|dbus-x11) Depends dbus). libglib2.0-0 (which contains libgio-2.0.so.0, which contains GDBus) shouldn't depend on a session bus for reasons analogous to libdbus-1-3's, and also your uses of GLib might not involve D-Bus at all (perhaps it's just installed for irssi's benefit). libsystemd0 (which contains sd-bus) definitely must not depend on dbus, because dbus depends on it (circular dependencies again), and because it's transitively Essential (via util-linux). S
Re: Policy 12.3: should I rename?
On 2016-07-23 18:58 +0200, Tollef Fog Heen wrote: > ]] Geert Stappers > > > FWIW I agree with both '"main package "should have documentation' > > and 'additional documentation in separate doc package'. > > I think we should stop recommending documentation be put in a separate > package and tell people who don't want docs to exclude the relevant > parts of /usr/share/doc using dpkg excludes instead. Disk space is > pretty cheap and we keep complaining about the per-package overhead in > Packages.gz, so it should be a net gain for most people. Wouldn't that apply to all packages, as opposed to being able to choose docs-or-not on a per-package basis if installing the packages or not? Being able to chose this per-package rather than in-general seems like something that has value. But perhaps dpkg excludes let me do this per-package too? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
Bug#832639: ITP: haskell-quickcheck-simple -- Haskell library to provide test-properties and default-mains for QuickCheck
Package: wnpp Severity: wishlist Owner: Kei Hibino * Package name: haskell-quickcheck-simple Version : 0.1.0.1 Upstream Author : Kei Hibino * URL : https://github.com/khibino/haskell-quickcheck-simple * License : BSD3 Programming Lang: Haskell Description : Haskell library to provide test-properties and default-mains for QuickCheck This Haskell library contains simple test-properties and default-mains for QuickCheck. - This package is used in Haskell Relatoinal Record ( http://khibino.github.io/haskell-relational-record/ ) project. - I'm planning to maintain this package inside the pkg-haskell team. - I need a sponsor.
Bug#832640: ITP: haskell-th-reify-compat -- Compatibility for the result type of TemplateHaskell reify
Package: wnpp Severity: wishlist Owner: Kei Hibino * Package name: haskell-th-reify-compat Version : 0.0.1.1 Upstream Author : Kei Hibino * URL : https://github.com/khibino/haskell-th-reify-compat * License : BSD3 Programming Lang: Haskell Description : Compatibility for the result type of TemplateHaskell reify This package contains compatible interfaces against the result type of TemplateHaskell reify function. - This package provides compatible interface for the result type of reify query function in TemplateHaskell between GHC 7.x and 8.0 - This package is used in Haskell Relatoinal Record (HRR) ( http://khibino.github.io/haskell-relational-record/ ) project. So, this package is required to package HRR. - I'm planning to maintain this package inside the pkg-haskell team. - I need a sponsor.
Re: Policy 12.3: should I rename?
On Thu, Jul 28, 2016 at 5:09 AM, Tollef Fog Heen wrote: > How do you keep up with unstable or testing, then? pdiffs, debdelta and apt-offline help with that. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Policy 12.3: should I rename?
]] Wookey > On 2016-07-23 18:58 +0200, Tollef Fog Heen wrote: > > ]] Geert Stappers > > > > > FWIW I agree with both '"main package "should have documentation' > > > and 'additional documentation in separate doc package'. > > > > I think we should stop recommending documentation be put in a separate > > package and tell people who don't want docs to exclude the relevant > > parts of /usr/share/doc using dpkg excludes instead. Disk space is > > pretty cheap and we keep complaining about the per-package overhead in > > Packages.gz, so it should be a net gain for most people. > > Wouldn't that apply to all packages, as opposed to being able to > choose docs-or-not on a per-package basis if installing the packages > or not? Being able to chose this per-package rather than in-general > seems like something that has value. But perhaps dpkg excludes let me > do this per-package too? dpkg excludes are path based, so you can exclude a single package (or exclude all and include a single one, etc). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)
On 06/22/2016 02:12 PM, Holger Levsen wrote: > On Wed, Jun 22, 2016 at 08:13:40AM +, Eliran Mesika wrote: >> As I wrote earlier, we're open to making certain features available upon >> request. In the specific case of the feature that was discussed - could you >> please elaborate what is missing and what functionality is available on the >> Enterprise edition that you'd like to be made public? We want to better >> understand the use-case and the requirements to respond to this request. > > I'm obviously not Alex but I also object using a software for Debian's > own infrastructure which is split into a free and an enterprise version. > > It's not about a specific patch. > > Free gitlab and we can talk again. > > It's not that there are no free alternatives. > > Hi all, At this point, I'm dropping work on gitlab for debian and moving to less controversial alternative pagure. I'm going to setup a gitlab.debian.net alias to git.fosscommunity.in for those who want to use gitlab unofficially. Hi DSA team, I'd like to create a VM in debian infra with DNS shukra.debian.org [1]. Hardware spec: minimum 2 GB RAM and 4 virtual CPUs (hope this can be increased when required). Thanks Praveen [1] https://wiki.debian.org/Shukra (wiki page needs updating) signature.asc Description: OpenPGP digital signature
Re: Proposed mass bug filing: use and misuse of dbus-launch (dbus-x11)
Simon McVittie wrote: > On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote: > > Is that really up-to the individual application to declare a > > dependency > > against dbus-user-session | dbus-x11 ? > > At the moment: yes. A dependency on dbus-x11 (in jessie) or on > dbus-user-session | dbus-x11 (now) can be used to signify "this > application or library is useless without a working session bus". > Apps that rely on Telepathy, Tracker or the Evolution servers are > good examples of a legitimate dependency on the session bus. > > Depending on dbus is not enough: that only guarantees working D-Bus > binaries (so you have all the right bits to get a session bus, but some > assembly is required) and a working system bus. > > The only other ways I can think of right now to express that requirement > are: > > * introduce a metapackage "dbus-session" with that dependency, and > ask these apps to depend on it, or on dbus-session | dbus-x11 to be > nice to backports; [...] > The last time this changed was the introduction of dbus-x11 in 2007; > twice in a decade isn't bad. I don't think it's necessarily going to > change again any time soon (unless we do a transition to > dbus-x11 | dbus-user-session and then another to > dbus-user-session | dbus-x11, which is why I'd prefer not to do that > two-stage approach). I can think of another reason that this might change: if we introduce an (experimental, and eventually non-experimental) variant based on a future stable version of kdbus. If we need to go through this transition anyway, could we please go ahead and introduce a dbus-session-bus package for other packages to depend on, to allow for potential future transitions or experiments? - Josh Triplett
