Re: Survey results: git packaging practices / repository format
Hi Ian,
thanks for your work on this.
On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Survey: git packaging practices / repository format"):
> > While trying to write the dgit FAQ, and some of the relevant docs, it
> > has become even more painfully obvious that we lack a good handle on
> > what all the different ways are that people use git to do their Debian
> > packaging, and what people call these formats/workflows, and what
> > tools they use.
> >
> > Can you please look through the table below and see if I have covered
> > everything you do ?
>
> Thanks to everyone who responded. I (with some help from Sean and
> some review from Sam) have worked the answers into a wiki page:
>
>https://wiki.debian.org/GitPackagingSurvey
I admit I did not joined the dgit discussion - may be that's the reason
I can not really match the branches that are used in Perl team policy
https://perl-team.pages.debian.net/git.html#repository_layout
(which is used by several other teams I'm working in) to the table in
the Wiki.
> Please let us know if we have missed one. It is probably better if
> you ask us rather than just adding it, unless you're sure that what
> you are adding isn't the same as one of the existing ones. In
> particular it seems that "unapplied" is used by a large number of
> people with disjoint tooling and disjoint terminology.
So I'm just asking if its just me not understanding the table properly
or whether the layout I'm used to in close to all teams I'm working in
is not mentioned.
Kind regards and keen on joining your BoF at DebConf
Andreas.
--
http://fam-tille.de
Bug#931296: general: Camera flash drive mount does not show up on desktop
Package: general Severity: important Tags: a11y Dear Maintainer, * What led up to the situation? Plugging in camera in Buster does not show flash storage on desktop as it did in previous versions with Xfce DE. * What exactly did you do (or not do) that was effective (or ineffective)?Tried to turn on the display of icons for drives, but it was already on. All other drives show up as expected * What was the outcome of this action? * What outcome did you expect instead? -- System Information: Debian Release: 10.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Re: Survey results: git packaging practices / repository format
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 decoupling would probably also give those people who are using a layout currently commented as "avoid", "poor", or "clumsy", the dignity of seeing documented the objective fact that they exist and took time to document it by responding to the survey. And at the same time, could give full freedom to the dgit maintainers to be as judgemental of any workflow as they see fit[2], because it will be all well framed in the specific context of dgit design. Enrico [1] I'm quite dgit-agnosting. My currently packaging practice is "burnt out by a complex and changing ecosystem and trying not to do any of it if I can avoid it. Excited at what is currently going on, waiting excitedly at something sane to get established as a standard and gain clear documentation and simple tooling. Possibly, as little tooling as possible over a decently maintained upstream source." [2] you know what I mean, please don't take it as a challenge :) -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Survey results: git packaging practices / repository format
On Sat, Jun 29, 2019 at 01:16:28PM +0100, Ian Jackson wrote:
> The current presentation lists *branch formats* not *workflows*.
>
> Everything in the current page other than the comments and best
> practices columns is objective, but I see it as lower level than what
> I think you are looking for.
Whoops, indeed, you're totally right here.
> It would probably be useful for there to be a wiki page for each
> branch format which has a section for each kind of task ("modify an
> upstream file", "cherry pick a patch from upstream", "switch to new
> upstream version") etc. and describes all the different ways of
> achieving that taxk with that branch format.
>
> That would be "less raw" but perhaps is what you actually want ? :-)
Agreed.
> > I could suggest a descriptive wiki page for each style you identified,
> > that then the users of that workflow can add to, and can serve as seeds
> > for growing comprehensive documentation, if that is doable with the data
> > you collected.
>
> I can probably write a skeleton for most of these workflows. At
> least, for the most popular ones. In many cases a good starting point
> is probably a copy of a README.source from some package which actually
> mentions it, or of course the dgit workflow tutorial manpage.
>
> Maybe I should write one skeleton and then others can help ?
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.
Enrico
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
signature.asc
Description: PGP signature
Bug#931291: ITP: pdqsort -- pdqsort is a drop-in replacement for std::sort
Package: wnpp Severity: wishlist Owner: Alexander GQ Gerasiov * Package name: pdqsort Version : git snapshot Upstream Author : Orson Peters * URL : https://github.com/orlp/pdqsort * License : zlib Programming Lang: C++ Description : pattern-defeating quicksort compile-time c++ library Pattern-defeating quicksort (pdqsort) is a novel sorting algorithm that combines the fast average case of randomized quicksort with the fast worst case of heapsort, while achieving linear time on inputs with certain patterns. pdqsort is an extension and improvement of David Mussers introsort. This package provides c++ header with drop-in replacement for std::sort.
Bug#931290: general: Asrock A300 Deskmini AMD Athlon 200GE ends in black screen Monitor has no Signal
Package: general Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** After normal installation of Debian Buster (Testing) with Default desktop the grub screen comes up and the system boots. When it normally switches to graphics mode it shows only a blinking cursor. After installing firmware-linux and rebooting the system does not show the blinking server, but a black screen and the monitor shows "No signal". Tested with 3 monitors. Afterwards reinstalled without "Default desktop". Now the system started ok and ended in the login. After installing firmware-linux unfortunately the system did not show the login after booting, but ended once again in a black screen (no Monitor signal). With nomodeset in grub I could start, but had to press "Ctrl + alt + F2" to go in the login as the system stopped after initializing the network card. So graphical interface is not possible with this hardware configuration and Debian 10 Buster. Normally Kernel 4.19... should be good enough for Vega 3 graphics. Live system (LXDE) fails as well with blinking cursor. "Lubuntu 19.04" does the job, but I do not like it and would appreciate if I could stay with Debian. -- System Information: Debian Release: 9.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#931289: ITP: croaring -- Portable Roaring bitmaps in C (and C++)
Package: wnpp Severity: wishlist Owner: Alexander GQ Gerasiov * Package name: croaring Version : 0.2.63 Upstream Author : Daniel Lemire and others * URL : https://github.com/RoaringBitmap/CRoaring * License : Apache 2.0 Programming Lang: C, C++ Description : Portable Roaring bitmaps in C (and C++) Bitsets, also called bitmaps, are commonly used as fast data structures. Unfortunately, they can use too much memory. To compensate, we often use compressed bitmaps. Roaring bitmaps are compressed bitmaps which tend to outperform conventional compressed bitmaps such as WAH, EWAH or Concise.
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Hi, Am 29.06.19 um 23:32 schrieb Thomas Goirand: > On 6/29/19 3:33 PM, Tomas Pospisek wrote: >> Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: >>> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: TLDR; year based release identifiers should be prefered since they are much more intuitive to reason about than codenames and sequentialy numbered release identifiers. If Debian should improve/change release identifiers, then I'd suggest to ponder a year based versioning scheme (as Ubuntu is using). >>> This only works with Ubuntu because they set the release date in advance. >> >> You assign the year to the release identifier when the release is ready: >> release_id = now().year(). There's certainly some infrastructure stuff >> that needs that release_id that needs to be prepared in advance, but I >> think that can be done pragmatically, when the release is "99%" ready. >> Am I missing something? >> *t [...] > > In some software we have in buster, they already have hard-wired the > names of the 2 next Debian releases. How would you do this with years if > we don't know the release dates in advance? Allow me to start with the inverse question: should the fact that software makes assumptions about the future preclude humans from shaping that future as they deem best? Now what if there was a way to have both: a better naming scheme *and* compatibility with software that hard codes the future? Lets see - one possibility would be to have both year based release identifiers and code name based ones. That could possibly solve both issues (better naming + compatibility). Or maybe there are yet other ways to solve the supposed contradiction? F.ex. updating the hard-coded SW comes to my mind. > Besides this, I very much dislike the way it sounds. :) The way what sounds? *t
Testing release images - Call for help
Hi there, We have the release of Buster scheduled to happen next Saturday. As always on a release day new iso images are generated and *before* they get signed we try and smoke test them to make sure that the builds went ok and nothing critical is missing from the manifests. We do the same for live images as well. If you can spare the time your help would be greatly appreciated in testing some of these images on the day. If you have time to test before then too, that would be even more helpful! Along with the usual amd64/i386/arm64 installer builds we'll be explicitly testing, we need specific help for testing LIVE images (including 2 different install methods) on BARE METAL PCs (i.e. NOT a VM). We are looking for tests to be carried out on machines running BIOS as well as UEFI. Buster will also be our first Debian release to include support for UEFI Secure Boot, and more test coverage there would be lovely. Additionally we are also looking for people who can test the following: * debian-mac.10.0.0-amd64-netinst.iso * debian-mac.10.0.0-i386-netinst.iso * debian-10.0.0-mips-*.iso (Multiple images) * debian-10.0.0-mipsel-*.iso (Multiple images) * debian-10.0.0-mips64el-*.iso (Multiple images) * debian-10.0.0-ppc64el-*.iso (Multiple images) * debian-10.0.0-s390x-*.iso(Multiple images) On release day (Saturday 6th July), we are expecting installer images to become available from around 1300 UTC, with live images between 1.5 and 2 hours later. To get a reasonable coverage of DI there is a wiki matrix [0] of the install tests that we will perform (although feel free to try 'your' specific install options. Wiki is not the *best* solution for a matrix that will change quite a bit during the test process, it is far to easy to have edit clashes. To reduce this we try and coordinate our action in on #debian-cd or irc.debian.org Please check in on irc *before* starting a test to reduce duplicate tests being carried out. Finally if you want to get in some early testing of DI over the next few days please do. if you find a critical problem there may just be enough time to fix it Let's make buster the smoothest release yet :-) /Andy [0] https://wiki.debian.org/Teams/DebianCD/ReleaseTesting/Buster_r0
