Bug#926769: ITP: puppet-module-placement -- Puppet module for OpenStack Placement
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: puppet-module-placement Version : 1.2.0 Upstream Author : OpenStack Foundation * URL : https://github.com/openstack/puppet-placement * License : Apache-2.0 Programming Lang: Python Description : Puppet module for OpenStack Placement Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . This module manages both the installation and configuration of OpenStack Placement. . OpenStack Placement provides an HTTP service for managing, selecting, and claiming providers of classes of inventory representing available resources in a cloud. Note: This service is mandatory for OpenStack Stein, which I'm currently finalizing in Debian.
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On Wed, 10 Apr 2019 03:17:39 +, Mo Zhou wrote: >The design of .durpkg is permissive enough because the header part, i.e. >the shell script is fully controled by the user. In this shell script, >one could just copy the nearby debian directory to the root dir of >source tree, and/or optionally unfold the trailing HFT[1] part. >Without the HFT part, every file will only have one syntax. >Template with an auxiliary debian/ directory is missing but that >doesn't mean it's not supported. Is there a vim mode (folding, syntax hilight) for that file type? If not, then this format has a _significant_ disadvantage over the way we have been doing things for two decades. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
Hi, On Wed, Apr 10, 2019 at 09:46:28AM +0200, Marc Haber wrote: > On Wed, 10 Apr 2019 03:17:39 +, Mo Zhou wrote: > >The design of .durpkg is permissive enough because the header part, i.e. > >the shell script is fully controled by the user. In this shell script, > >one could just copy the nearby debian directory to the root dir of > >source tree, and/or optionally unfold the trailing HFT[1] part. > >Without the HFT part, every file will only have one syntax. > >Template with an auxiliary debian/ directory is missing but that > >doesn't mean it's not supported. > > Is there a vim mode (folding, syntax hilight) for that file type? If > not, then this format has a _significant_ disadvantage over the way we > have been doing things for two decades. As a vim user, I'd love to explore the syntax script for HFT format, although I have little knowledge about vim scripting. The issue is tracked here[1], and the vim syntax looks possible to implement according to some links there. The HFT format is supposed to work like sort of "plain text tar". I also planned to add file mode support. Due to the nature of the HFT format, one can actually complete the debian/ directory first, then pack it into the HFT format and append the HFT file to the .durpkg. When editing the debian/ files in .durpkg feels bad, one can temporarily unfold the HFT part into the debian/ directory and edit. See [2]. Or one can just keep the debian/ directory unfolded. Anyway, it would be much better if a vim syntax for HFT is available. And it would be much appreciated if any vim expert can point me the shortest path to implement that :-) [1] https://github.com/dupr/duprkit/issues/40 [2] See point.2 at https://github.com/dupr/duprkit#create-new-recipe
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
> "Marc" == Marc Haber writes: Marc> On Wed, 10 Apr 2019 03:17:39 +, Mo Zhou wrote: >> The design of .durpkg is permissive enough because the header >> part, i.e. the shell script is fully controled by the user. In >> this shell script, one could just copy the nearby debian >> directory to the root dir of source tree, and/or optionally >> unfold the trailing HFT[1] part. Without the HFT part, every >> file will only have one syntax. Template with an auxiliary >> debian/ directory is missing but that doesn't mean it's not >> supported. Marc> Is there a vim mode (folding, syntax hilight) for that file Marc> type? If not, then this format has a _significant_ Marc> disadvantage over the way we have been doing things for two Marc> decades. I think Russ has a good point here. There are some people who prefer the single file format and some people who prefer the directory. The current discussion is sounding a lot like sniping and if it were directed at me I'd find it really frustrating. It seems an area where it matters to the people contributing to the project and basically no one else. As a non-vim user, for example, I find the lack of vim syntax hilight entirely irrelevant. As someone who isn't likely to contribute to this project, my opinion shouldn't matter anyway. Mo has already indicaded that you can package up directories rather than files. If you're interested in the project but would prefer to use that format, then go do that and submit PRs. If there are specific packages in the project you'd like to improve but the format of that package makes it something you don't want to work on, then give Mo that feedback. Otherwise, I'd encourage you to let the issue rest.
Profesjonalna Strona Internetowa na WordPress. Sprawdź.
Dzień dobry, specjalizuję się w realizacji projektów nowoczesnych* Stron* Internetowych na *WordPress. * Będzie mi miło, jeśli wyrazicie Państwo zainteresowanie moją propozycją. Aby to zrobić wystarczy odpisać "*TAK*" w odpowiedzi na tego e-mail’a. Z pozdrowieniami, Mariusz Stok Dział Wdrożeń
Re: PPAs (Re: [Idea] Debian User Repository? (Not simply mimicing AUR))
Hi Mo, On Mon, Apr 08, 2019 at 11:18:14AM +, Mo Zhou wrote: > The proposed idea is to take some advantages from source-based > software distribution tools. Examples are available here: > https://github.com/dupr/duprkit > https://github.com/dupr/DefaultCollection I looked into this. Your reasons are sound and you are scratching your itch. This is great. It seems that a key aspect of this thing is avoiding to (re)distribute sources. You give good reasons for why this is needed and I see no need to reiterate or discuss them. Your implementation goes straight from .durpkg -> .deb. I question this decision: We already have lots of tools to go from .dsc to .deb. Your implementation replicates part of that and I think, this is bad as it makes it harder to collaborate. Let me propose a rather intrusive interface change to duprkit. What if the result of building a .durpkg was a .dsc rather than a .deb? Then you could split duprkit into two tools: * One tool to build source packages from .durpkg files on demand. * One tool to build a specific binary package from a given deb-src repository. Now in principle, the latter is simply sbuild or pbuilder, but there is more to it: * Given the binary package name, figure out which source package must be built. * Given that source package's Build-Depends, figure out what other binary packages need to be built. * Recurse. * Build them in a suitable order. (Some people will observe that this is the "bootstrap" problem. ;) There is one major difficulty here (and duprkit doesn't presently solve that either): If you figure that some binary package is missing, you have no way of knowing which .durpkg file to build to get the relevant source package. Before tackling that problem, the question arises of whether that problem is in scope. Does duprkit really want to handle complex dependencies or is the idea really to just get the stuff into users hands? In the latter case, vendoring likely is a simple way to avoid this problem entirely. Now let's assume that you do want to allow complex dependencies in this user repository. In this case, it would make sense to trade .durpkg files for plain "debian" directories with an additional debian/rules target to obtain the source. (We removed "get-orig-source" from policy a while ago, but maybe this is what you want here.) If you go this route, you can just scrape those debian/control files to figure out which .durpkg files to convert into .dsc files. I don't think I would start using such a user repository. I'm much too scared about it. Yet, the second part of the problem seems interesting to me: Taking a (possibly local) repository of source packages and building a specific binary package (plus everything that's needed to get there). I think that you can increase collaboration by changing your interface in a way that makes it easier to reuse in other settings. Helmut
Bug#926804: ITP: golang-github-x86kernel-htmlcolor -- HTML syntax highlighter for Go
Package: wnpp Severity: wishlist Owner: Dawid Dziurla * Package name: golang-github-x86kernel-htmlcolor Version : 0.0~git20170417.cf1d377-1 Upstream Author : JaeYoung Mun * URL : https://github.com/x86kernel/htmlcolor * License : Not specified Programming Lang: Go Description : HTML syntax highlighter for Go Pretty print HTML source code with syntax highlighting in Go. This package is an additional dependency of newer version of package "wuzz".
Bug#926807: RFP: signal-cli -- A command-line and D-BUS interface for Signal Messenger
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: signal-cli Version : 0.6.2 Upstream Author : AsamK * URL : https://github.com/AsamK/signal-cli * License : GPL-3 Programming Lang: Java Description : A command-line and D-BUS interface for Signal Messenger signal-cli is a command-line interface for libsignal-service-java. It supports registering, verifying, sending and receiving messages. For registering you need a phone number where you can receive SMS or incoming calls. signal-cli is primarily intended to be used on servers to notify admins of important events. For this use-case, it has a D-BUS interface, that can be used to send messages from any programming language that has D-BUS bindings. Packaging this would also require: * Updating libbcprov-java to 1.61 * Updating libargparse4j-java to 0.8.1 * Packaging https://github.com/Turasa/libsignal-service-java/ The last item may be controversial, as it is a fork, but it appears to be kept up to date and it allows signal-cli to be a slave device, which is quite a useful feature. That would require: * Packaging libphonenumber8-java: https://github.com/googlei18n/libphonenumber/ * Packaging https://github.com/signalapp/libsignal-metadata-java (Technically also requires threetenbp, but with Java SE 8 and newer it can be replaced with data and time support from Java) I may change this to an ITP later if I have time, but for the foreseeable future I do not. signature.asc Description: OpenPGP digital signature
Re: [Prototype] DUPR 0.0c: Brand New Look and Feel
Hi Holger, On Tue, Apr 09, 2019 at 04:23:31PM +, Holger Levsen wrote: > On Tue, Apr 09, 2019 at 04:17:32PM +, Mo Zhou wrote: > > https://github.com/dupr/DefaultCollection/blob/master/rover/rover.durpkg > > The last example is the shortest yet complete one -- only 25 lines. > > I only looked at this one and I am disappointed: there's just git clone, > but no verification of signed tags. I think you got the scope of the project wrong. The idea was to throw away a ton of Debian's quality measures (including license vetting, availability of source, source redistribution, policy compliance, reproducibility, ... and checking signatures). To me, dupr looks like a way to replace "curl ... | bash". I'm in a similar position to yours. In my other mail I wrote that I'm too scared to use it, but I'm not disappointed. It's scratching Mo's itch and not yours. I see it's working as intended, but it's not scratching my itch. On the flip side, I guess that Mo has understood that the user base of dupr will not primarily be people reading d-devel. Most of the people that have replied to this thread are deeply involved with Debian. It's natural that most of them prefer the things as they are in the main archive. That shouldn't rule out other people's needs however (especially when they're doing the work), but rather make us look how we can collaborate on the bits that can be shared. Helmut
Re: [Idea] Debian User Repository? (Not simply mimicing AUR)
On 4/7/19 4:34 PM, Mo Zhou wrote: > Hi, > > The problem is not "who is responsible for implementing this", but "is > this valuable enough to implement". Opposite way. The problem is who's implementing. We all know this has a lot of values. > If a group of people think it worthwhile to do something I believe everybody think it is. > I as the > initiator of the idea would definitely take action if I got enough > positive feedbacks. Great! Go ahead, and get in touch with the FTP team. Cheers, Thomas Goirand (zigo)
