Re: Survey results: git packaging practices / repository format
On Fri, Jul 05, 2019 at 08:37:40AM +0800, Paul Wise wrote: > > I was simply talking about standard upstream contribution mechanisms; > pull requests, requests to pull from repos, patches on mailing lists > etc. I assume that almost all upstream projects have one of these. The (de facto) dead upstream projects do not have these and usually these need patches. Kind regards Andreas. -- http://fam-tille.de
Re: Survey results: git packaging practices / repository format
Hello Enrico, On Sun 30 Jun 2019 at 11:03PM +02, Enrico Zini wrote: > On Sat, Jun 29, 2019 at 09:18:11AM -0400, Sam Hartman wrote: > >> I think it would be helpful for both of us to describe ways in which you >> find that there are objectivity problems that would get in the way of >> presenting the data in that context. >> >> I think especially at that bof we'd like to avoid people feeling that >> some practice that they cared about was mischaracterized or >> misrepresented. >> >> Yet we kind of need one person to give a short presentation to get it >> into something that can fit into a bof. >> >> So any help you can provide pointing at things that seem too subjective >> would be appreciated. > > Trying to unpack my gut feelings, I think the current table intermixes > the presentation of a taxonomy work to Debian as a whole, with an > iteration of dgit design work. > > I'm currently not concerned with dgit[1], and I'm curious to see a > mapping of the complex landscape that is Debian in this regard. When I > read the table, I see "best practice" links that point to dgit > documentation and a "comments" column with judgemental words like > "clumsy", "competent", "avoid". Those are getting in the way of my > attempt to look at the landscape. > > I'd like to be able to look at the landscape first, and take it in, and > then, as a separate step, see what the dgit maintainers, whose opinion I > actually very much respect, are making of it. This is useful and well-structured feedback, thank you. I think that what we want is the current table, with a way to show/hide the last two columns, and have them be hidden by default. ISTM that achieves everything wanted. We would need to move off the Debian wiki to achieve that, but I think that is a price worth paying, given the other footnote and CSS issues with the current wiki page. We could put the source in a repo writeable by all DDs on salsa, so we wouldn't be giving up too much by moving off the wiki. Then we'd use GitLab pages or similar to publish it. On Sun 30 Jun 2019 at 10:44PM +02, Enrico Zini wrote: > I'd say that seeding the wiki with pages for each branch formats could > both provide a link to details to take some load off the big table, and > create a space where the rest of the documentation can grow. This could remain on the Debian Wiki or also move to salsa. -- Sean Whitton signature.asc Description: PGP signature
Re: Survey results: git packaging practices / repository format
On Fri, Jul 05, 2019 at 10:13:01AM +1200, Daniel Reurich wrote: > > There isn't enough information in the packaging and upstream branches > > of a typical git workflow to reconstitute a precisely matching .orig > > tarball: you have to either obtain .orig tarballs out-of-band, or use > > pristine-tar to encode the parts of the tarball that can't be reproduced > > from the git tree. > > Really? I honestly hadn't noticed, but I will out of interest compare > between what's in our archives and yours. Definitely. You can even try to set pristine-tar = False in your ~/.gbp.conf if you want to make sure to get a tarball with wrong size and md5sum. I've done this accidentally and it reproducibly produced different tarball than the previously uploaded package. Kind regards Andreas. -- http://fam-tille.de
Bug#931461: ITP: sentry-python -- New Python SDK for Sentry.io
Package: wnpp Severity: wishlist Owner: William Grzybowski * Package name: sentry-python Version : 0.9.5 Upstream Author : William Grzybowski * URL : https://github.com/getsentry/sentry-python * License : BSD-2-Clause Programming Lang: Python Description : New Python SDK for Sentry.io The new Python SDK for Sentry.io This package is new way to configure python applications to report to the well- known Sentry, cross-platform application monitoring, with a focus on error reporting. This replaces python-raven. I use it myself. I plan on maintining it myself at least until DPMT accepts me in their team :).
Fwd: Packaging of Sugar-toolkit-gtk3 (sugar3) v0.114.
-- Forwarded message - From: ANIKET MATHUR Date: Fri, Jul 5, 2019 at 4:10 PM Subject: Packaging of Sugar-toolkit-gtk3 (sugar3) v0.114. To: G'day, Aniket Mathur this side, an active contributor of Sugarlabs as well as a GSoC 19 participant. This mail is a small query regarding the packaging of "sugar3" module. We currently have v0.112 packaged. In the latest version (0.114) Sugarlabs have made the toolkit compatible with both Python and Python 3. But we don't have Debian multi-version packages for the latest version. This prevents us to scale our testing as well as limits the number of testers. We don't know how to make multi-version local packages, that we can distribute for testing. It would be good if we have Debian packages for v 0.114. Need Help. Regards. Aniket
Re: Fwd: Packaging of Sugar-toolkit-gtk3 (sugar3) v0.114.
Quoting ANIKET MATHUR (2019-07-05 16:44:18) > -- Forwarded message - > From: ANIKET MATHUR > Date: Fri, Jul 5, 2019 at 4:10 PM > Subject: Packaging of Sugar-toolkit-gtk3 (sugar3) v0.114. > To: > > > G'day, > Aniket Mathur this side, an active contributor of Sugarlabs as well as a > GSoC 19 participant. This mail is a small query regarding the packaging of > "sugar3" module. > > We currently have v0.112 packaged. In the latest version (0.114) Sugarlabs > have made the toolkit compatible with both Python and Python 3. But we > don't have Debian multi-version packages for the latest version. This > prevents us to scale our testing as well as limits the number of testers. > > We don't know how to make multi-version local packages, that we can > distribute for testing. > > It would be good if we have Debian packages for v 0.114. Please kindly read my reply to this post at the debian-user mailinglist: https://lists.debian.org/156232842570.7978.2787951495692859...@auryn.jones.dk - 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
Best Pressures Washers 2019
Hi,Best Pressure Washers We are well known of “Cleanliness is the way to good health and happiness.” & “One, who maintains cleanliness keeps away diseases“. I know that , In Busy life, it is becoming very difficulty to maintain the cleanliness, tidiness with normal mops, Clothes consuming much time and giving less output. These Mops/clothes cannot be used in multipurpose usages. Here comes “Pressure Washers” which meets our demands like best cleanliness, Less time consumption, Multipurpose usages. ==> Click Here for BEST PRESSURE WASHERS 2019 [http://10dollarsclub.com/avex/link.php?M=202545&N=74&L=9&F=T] With Love James Click this link to unsubscribe: http://10dollarsclub.com/avex/unsubscribe.php?M=202545&C=6566c9793ef7cd686a5c4815e77ee04f&L=29&N=74
Re: Please help me to create Debian package
Thanks, There is a small problem I'm facing is how to handle the installer bash script? how can I run it during installation? Its function is to install python dependencies, creating configuration files and desktop shortcut. Please have a look at it https://github.com/osdag-admin/UbuntuInstaller/blob/master/2-install-osdag.sh On Thu, Jul 4, 2019 at 9:53 PM Mindaugas Celiesius wrote: > > Hello. Please check this https://wiki.debian.org/Packaging and this > https://www.debian.org/doc/devel-manuals#packaging-tutorial > It is not difficult at all. I think you can do it yourself. > -- > >
Re: Please help me to create Debian package
Le ven. 5 juil. 2019 à 22:24, himanshu Singh a écrit : > Thanks, > There is a small problem I'm facing is how to handle the installer bash > script? > how can I run it during installation? Its function is to install python > dependencies, > You can't. In packages you specify other debian packages to install, they must exist in debian. For other files, during package creation you create/copy files in a a dir representing the final install (/usr... /var...) and at package install they are placed in those locations. There are rules where to place files etc.. in debian package policy. As it seems it is python based, you should first package your soft as a python package + desktop files etc... There are some helpers to package for debian python packages creating configuration files and desktop shortcut. Please have a look at it > > https://github.com/osdag-admin/UbuntuInstaller/blob/master/2-install-osdag.sh > > > > > On Thu, Jul 4, 2019 at 9:53 PM Mindaugas Celiesius > wrote: > >> >> Hello. Please check this https://wiki.debian.org/Packaging and this >> https://www.debian.org/doc/devel-manuals#packaging-tutorial >> It is not difficult at all. I think you can do it yourself. >> -- >> >> > >
