No processing/acceptance from dak for some packages?
Hi, I have been trying to upload yaggo 1.5.10-5 for more than 12 hours by now. And I have done this several times by now[look here] It gets to the ftp upload server, sits there for a while, and vanishes eventually. There is however no further processing, neither accept, nor reject. I however, tried uploading golang-github-shenwei356-bio 0.3.2-1, and golang-github-shenwei356-util 0.4.0-1 and these went smoothly. This looks just... weird. Would someone know why this happens? [look here]: All attempts visible here: https://alioth-lists.debian.net/pipermail/debian-med-packaging/2021-September/thread.html Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: Bundling
Hi Jonas, Thanks for taking time to try to sort this out! On 25/09/2021 18:52, Jonas Smedegaard wrote: Quoting Alec Leamas (2021-09-25 18:23:42) On 25/09/2021 18:04, Jonas Smedegaard wrote: Quoting Alec Leamas (2021-09-25 17:47:04) So, the question: would it be acceptable to bundle the wxWidgets 3.1.5 sources in next OpenCPN release in such a situation? How do you and OpenCPN upstream expect to handle bugs for that specific embedded version of wxWidgets? Sounds more sensible to me to (coordinate with wxwidgets maintainers to have) wxWidgets 3.1.x packaged as a separate package, tracked with its proper upstream source. Then when we get near freeze it can be assessed how many of the wxWidgets branches we want to include with the upcoming stable Debian release - and include in that assessment how many packages reverse-depend on each. My thinking so far has been that a wxWidgets 3.1.5 package just isn't possible since there is no ABI stability guarantee. Am I wrong? Lack of stable ABI means that each library change may require recompilation of reverse dependencies. This can be handled in packaging either by declaring tight dependencies (see e.g. `man dh_shlibdeps`), or by tracking library symbols and use those to resolve dependencies (see e.g. https://wiki.debian.org/UsingSymbolsFiles) Tight dependencies should be fine. This is C++, so library symbols is bit convoluted. What do you think about a plan like this: - We make a provisionary, internal packaging of 3.1.5 and uses that in next cycle. - Around February-March -22 we assess the situation again. If we believe that 3.2 will ready and packaged before our own release, we just wait for that to happen. - If not, we approach the wxWidgets maintainer about getting our provisionary, temporary package in shape and released, probably in experimental. - If the maintainer refuses to make such a release we have to bundle the library in our own package. Thoughts? --alec
Re: partman, growlight, discoverable partitions, and fun
On Sun, Sep 26, 2021 at 01:41:18AM -0400, nick black wrote: > Marco d'Itri left as an exercise for the reader: > > And the preseeding syntax is as powerful as it is inconvenient. > > Implementing support for more partition formats, if missing, should be > > rather easy. > > But which ones do we need for architectures which are not actually dead? > > So, as I responded to Adrian [0], the only missing partition > types appear to be amiga, atari, and sun. Adding them ought be > simple enough, though I'd need testers with the hardware, or > access to the hardware. I'd start with asking porters of m68k and sparc64 whether today's systems even run anything but Linux. I think there's little point in keeping compat with 80s' OSes. At a risk of drawing ire of m68k/sparc64 folks, I'd also suggest not putting your tuits there until this millenium's hardware is covered well. > My biggest worry personally (aside from the realpolitik of > getting this change through) regards the automated partitioning > language available through the preseed system. Trying to emulate > this bug-for-bug is a non-starter, I think, both from a > technical and quality-of-life standpoint. If the emulation can't > be perfectly accurate, I don't think it ought be attempted for > such a critical, delicate procedure. I personally think that preseed is nasty enough that users who do automation on a scale that would make learning it worthwhile already have a better way to do such automation. For me, d-i is for manual installs, scripted stuff wants a partitioner + glorified debootstrap. I do have a different wish, though. Could you please purge any references to drivemakers' units (stuff like MiB = million bytes, which current partitioner maliciously[1] swaps around with proper MB of 1048576B)? Having them in the user interface is deeply harmful: people will get unoptimal alignment unless they 1. know about it, and 2. are careful enough. >From your comments before I see that you try to do proper alignment, but in too many cases no matter how you try, the installer won't align well enough because the hardware might be newer than the version of growlight, hide its inner workings for marketing reason (like stealth SMR drives), etc. On the other hand, a completely oblivious user will get good alignment if you show numbers measured in gigabytes rather than gillionbytes. I know of only one case of multi-GB alignment (some early versions of ipmctl wanted a multiple of 32GB because certain vendor BIOSes had problems with smaller blocks), but the required alignment there is 1GB for years. And most importantly: thanks for this effort, it's greatly appreciated! Meow. [1]. The malice hasn't been invented by the implementor of the old partitioner -- it was done by marketing departments of disk vendors in the old days; they don't even do so anymore but as they tried going through standard bodies while fighting lawsuits, some damage lingers on. The fault of our old partitioner is that it didn't filter out the malice. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A white dwarf seeks a red giant for a binary relationship. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Re: Debian choice of upstream tarballs for packaging
On Mon, 16 Aug 2021 09:18:34 +0800, Paul Wise wrote: > I noticed that sometimes Debian's choice of upstream source for > packaging can be suboptimal. This is especially apparent for the > different per-language upstream packaging ecosystems[1], where the > upstream packaging differs from the upstream VCS in some significant > ways, including missing files, prebuilt files, embedded copies etc. > > While the upstream VCS also sometimes has these issues, it is often > much less problematic than the upstream packaging ecosystems. > > I'd like to suggest that we standardise on the upstream VCS for our > orig.tar.gz files and phase out use of upstream packaging ecosystems. […] > 1. the ecosystems I'm talking about include cargo, npm, browser > extensions, rubygems, pypi, CPAN etc. Sorry for being a bit late to the party; as you mention CPAN here, I thought I'd share some thoughts about it. (We briefly discussed the topic at the pkg-perl BoF during DebConf [0] but this is not an offical team statement.) I see the advantages of the proposal but I think for the perl ecosystem it doesn't make a whole lot of sense, for two reasons: - First, CPAN and Debian are quite similar (for better or worse :)); not only about the same age but for both projects the canonical way of distribution is via tarballs from mirrors - the Debian archive and the CPAN mirror network. And for both project there is no requirement to use any VCS or even less a specific one or a specific hosting for a VCS. - Second, using only the VCS of a CPAN distribution is not ideal because it misses information which is created at release time and which we rely on. So taking the code from an upstream repo basically means doing part of a release ourselves. In general, the above mentioned problems of discrepancies between upstream VCS (if they exist) and upstream tarballs are minor or close to non-existant in the CPAN world. Hence switching to a VCS-based approach wouldn't really solve any actual problem in almost all cases and would create challenges for our tools and workflows. There are exceptions where we do use the upstream VCS as the tarball indeed contains undesirable artifacts; and we agreed in the BoF that improving our tooling to work from a VCS instead of tarballs would be nice. Cheers, gregor [0] https://lists.debian.org/debian-perl/2021/08/msg00013.html -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: partman, growlight, discoverable partitions, and fun
Hello Nick! On 9/26/21 00:49, Nick Black wrote: > It supports MBR, GPT, and APM: > > https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123 > > (sorry for the gmail-style top posting; i can't find your mail in my mbox > for whatever reason) > > Any other partition schemes ought be trivial to add; they've not been added > yet > simply because I don't have means with which to test them. So, you are not using libparted then? > Looking at the "partition types" section of the Linux configuration, I see: > Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris > x86, Unixware, > Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68. > > Looking at the disk-label code from partman, I see: > gpt, msdos, amiga, atari, mac, sun > > So the only ones covered by partman and not covered by growlight would be: > amiga, atari, sun, > and mac (if mac is not the same as APM). I don't see any difficulty in > adding these four, so long > as there's someone with an Amiga or ATARI who'd be willing to test them > out. If there are no such > people, is it that important? Yes, it is important as we're supporting these architectures in Debian Ports and I invested quite some time to get Atari partition support added [1], for example. I think it makes little sense to not use libparted as it already supports all common and less common partition types and reimplementing everything that libparted makes little sense to me. Adrian > [1] > https://git.savannah.gnu.org/cgit/parted.git/commit/?id=9c266205416ec956d6205c828211480de3767d02 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bundling
Quoting Alec Leamas (2021-09-26 10:05:04) > Hi Jonas, > > > Thanks for taking time to try to sort this out! > > On 25/09/2021 18:52, Jonas Smedegaard wrote: > > Quoting Alec Leamas (2021-09-25 18:23:42) > >> On 25/09/2021 18:04, Jonas Smedegaard wrote: > >>> Quoting Alec Leamas (2021-09-25 17:47:04) > > So, the question: would it be acceptable to bundle the wxWidgets > 3.1.5 sources in next OpenCPN release in such a situation? > > >>> > >>> How do you and OpenCPN upstream expect to handle bugs for that > >>> specific embedded version of wxWidgets? > >>> > >>> Sounds more sensible to me to (coordinate with wxwidgets maintainers > >>> to have) wxWidgets 3.1.x packaged as a separate package, tracked > >>> with its proper upstream source. Then when we get near freeze it > >>> can be assessed how many of the wxWidgets branches we want to > >>> include with the upcoming stable Debian release - and include in > >>> that assessment how many packages reverse-depend on each. > >> > >> > >> My thinking so far has been that a wxWidgets 3.1.5 package just isn't > >> possible since there is no ABI stability guarantee. Am I wrong? > > > > Lack of stable ABI means that each library change may require > > recompilation of reverse dependencies. > > > > This can be handled in packaging either by declaring tight dependencies > > (see e.g. `man dh_shlibdeps`), or by tracking library symbols and use > > those to resolve dependencies (see e.g. > > https://wiki.debian.org/UsingSymbolsFiles) > > > Tight dependencies should be fine. This is C++, so library symbols is > bit convoluted. See https://wiki.debian.org/PkgKde/DhSymbolsFile > What do you think about a plan like this: > > - We make a provisionary, internal packaging of 3.1.5 and uses that in > next cycle. > > - Around February-March -22 we assess the situation again. If we > believe that 3.2 will ready and packaged before our own release, we > just wait for that to happen. > > - If not, we approach the wxWidgets maintainer about getting our > provisionary, temporary package in shape and released, probably in > experimental. > > - If the maintainer refuses to make such a release we have to bundle > the library in our own package. I am concerned that you a) seemingly prefer to postpone involving wxWidget package maintainers, and b) did not anwer my question about maintenance: > How do you and OpenCPN upstream expect to handle bugs for that > specific embedded version of wxWidgets? I think that if you do not want to properly maintain the wxWidget code you need, then the best for Debian is that you postpone introducing this newer OpenCPN release until the wxWidget package maintainers consider it reasonable to introduce the code needed for it. If what you call "provisionary" is something done outside of Debian or only in Debian experimental, then is seems you agree. But I am not sure - in particular your "and uses that in next cycle" sounds like you will not treat it as only experimental but rely on that newer release, no matter if embedded code is maintainable or not. - 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: partman, growlight, discoverable partitions, and fun
Adam Borowski left as an exercise for the reader: > I do have a different wish, though. Could you please purge any references > to drivemakers' units (stuff like MiB = million bytes, which current > partitioner maliciously[1] swaps around with proper MB of 1048576B)? this really probably belongs over in the growlight bugtracker, but: * i actually use the "memory units" for almost all interfaces, because that gives you the numbers you expect. for instance, my Seagate Exos 12TBs are 5859442688 4GB AF physical sectors, addressable as 23437770752 512B logical sectors. using tebibytes, this is 10.914TiB, as opposed to 12.000TB. as you can see at [0], we see 12T. there's only one place off the top of my head where they're *not* used, which is... > Having them in the user interface is deeply harmful: people will get > unoptimal alignment unless they 1. know about it, and 2. are careful enough. * alignment =] there we absolutely want to be using MiB etc., and we do. > >From your comments before I see that you try to do proper alignment, but in > too many cases no matter how you try, the installer won't align well enough > because the hardware might be newer than the version of growlight, hide its > inner workings for marketing reason (like stealth SMR drives), etc. > On the other hand, a completely oblivious user will get good alignment if > you show numbers measured in gigabytes rather than gillionbytes. so i'm not sure i necessarily buy that claim. if i'm overriding the default alignment, i typically want to specify a value that's independent of the disk size, and i always want it to be in a *iB unit. oh, do you mean secondary and later partitions? iirc, i accept (in addition to absolute sector numbers) a "+" syntax where "+1M" would mean "the first possible 1MiB alignment within this empty space", equal to the beginning of the empty space when it happens to start on 1MiB multiple. i don't know, mang; if i'm explicitly supplying sectors for alignment purposes, i'm checking units pretty carefully. preferably, i'm never doing that -- the only reason i can see would be if i want to leave some large (larger than the desirable alignment) chunk of empty space between two partitions. and again, in any kind of alignment context, that's when you *want* to be using MiB. and in such a context, "M" by itself is interpreted that way. > I know of only one case of multi-GB alignment (some early versions of ipmctl > wanted a multiple of 32GB because certain vendor BIOSes had problems with > smaller blocks), but the required alignment there is 1GB for years. where here i assume you mean 1GiB aka 2³⁰ bytes, not 1GB aka 10⁹ bytes, correct? you could enter that as 1G, or 1GiB, or 1024MiB, or 1048576KiB, or 1073741824. Using 1GB or 1000MB or 100KB or 10 would force undesirable behavior. changes to the text/UI to gently nudge users to the correct behavior will be cheerfully considered! > And most importantly: thanks for this effort, it's greatly appreciated! thank you for your kind words! i'd love to see this happen. --nick [0] https://nick-black.com/images/growlight-2021-09-26.png -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Bundling
Hi Jonas, On 26/09/2021 11:08, Jonas Smedegaard wrote: Quoting Alec Leamas (2021-09-26 10:05:04) Hi Jonas, Thanks for taking time to try to sort this out! On 25/09/2021 18:52, Jonas Smedegaard wrote: Tight dependencies should be fine. This is C++, so library symbols is bit convoluted. See https://wiki.debian.org/PkgKde/DhSymbolsFile After some tries in this area I have leaned to Russ Allberry's post https://www.eyrie.org/~eagle/journal/2012-02/001.html. Is this outdated? What do you think about a plan like this: - We make a provisionary, internal packaging of 3.1.5 and uses that in next cycle. - Around February-March -22 we assess the situation again. If we believe that 3.2 will ready and packaged before our own release, we just wait for that to happen. - If not, we approach the wxWidgets maintainer about getting our provisionary, temporary package in shape and released, probably in experimental. - If the maintainer refuses to make such a release we have to bundle the library in our own package. I am concerned that you a) seemingly prefer to postpone involving wxWidget package maintainers, and b) did not anwer my question about maintenance: As for postponing, it's just about that if 3.2 arrives in time there is nothing to discuss, and the issue is void. But OTOH, we could always discuss things anyway, agreed. >> How do you and OpenCPN upstream expect to handle bugs for that >> specific embedded version of wxWidgets? [upstream hat on] As for maintenance, using 3.1.5 places us in a loop with wxWidgets upstream where possible patches introduced will be forwarded, reviewed and eventually released with 3.2. This is also how bugs will be handled. (I have too many hats here...) I think that if you do not want to properly maintain the wxWidget code you need, then the best for Debian is that you postpone introducing this newer OpenCPN release until the wxWidget package maintainers consider it reasonable to introduce the code needed for it. As long as we don't miss Bookworm it's not that bad. It will still affect downstreams like Ubuntu and Raspbian, though. However, question is how much effort we should put in this, since we still don't know if 3.2 will arrive in time or not. If what you call "provisionary" is something done outside of Debian or only in Debian experimental, then is seems you agree. But I am not sure - in particular your "and uses that in next cycle" sounds like you will not treat it as only experimental but rely on that newer release, no matter if embedded code is maintainable or not. I totally agree with you that embedding is the last option and should be avoided if possible. After all, I'm raising this issue in time... I also share your view that if bundling, it must be a temporary measure. It must definitely not linger in upcoming releases. Is there a route where we keep things in experimental (bundled or not) and let it stay there until wxWidgets 3.2 is out? And we then can make a sid package without any other dependencies or bundled wxWidgets code? To me, this looks like a road forward (?) Cheers! --alec
Re: No processing/acceptance from dak for some packages?
Nilesh Patra writes: > This looks just... weird. Would someone know why this happens? Someone uploaded a broken .changes file that had different sizes for the same file: +--- | Checksums-Sha256: | [...] | 209dda5709e1a67eab2762013136adc7c3b6977a17a7e3d8a12f5b2c27569875 156580 [...] | Files: | [...] | cda6f0841c01ae3ffb3f9584ba9c5f20 157910 science optional [...] +--- The error handling in the archive software is not very good for this error: it stops processing, thus all .changes files sorted after this one did not get processed. The file was now moved away. Anyway, people should *not* edit .changes files manually as it is too easy to refer to the wrong files, e.g., a different .orig tarball than was used to build the package. I suspect someone did manually edit the file here. Ansgar
Re: Bundling
On 2021-09-26 12:16 +0200, Alec Leamas wrote: > > See https://wiki.debian.org/PkgKde/DhSymbolsFile > > After some tries in this area I have leaned to Russ Allberry's post > https://www.eyrie.org/~eagle/journal/2012-02/001.html. Is this outdated? That KDE tool does help a lot but for large C++ packages symbols files are so large as to be of limited usefulness IMHO. If you are upstream too and actually know which symbols should be coming and going then they can have some utility as a check, but if you are just a packager struggling to keep up and all you ever do is generate a new one (as opposed to checking to see if the changes make sense) then I can't see the point. Having a much simpler shlibs file is more maintainable, and may be sufficient to track basic ABI/APi compatibility. > Is there a route where we keep things in experimental (bundled or not) and > let it stay there until wxWidgets 3.2 is out? Yes. This is what I'd do for the time being. That way you are not committed to this path where you might end up maintaining (or not maintaining, just hoping for the best on!) an unstable wxwidgets version for several years. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
Hello! On 9/26/21 12:40, Luca Boccassi wrote: > Does libparted support the discoverable partitions spec? I'm not sure, this thread is the first time I have heard about discoverable partitions. I have read up first what the motivations for these are and how useful they would be for Debian. Also, since parted is maintained by RedHat, I would expect that this feature would land in parted soon as well. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: partman, growlight, discoverable partitions, and fun
On Sun, 26 Sept 2021 at 10:05, John Paul Adrian Glaubitz wrote: > > Hello Nick! > > On 9/26/21 00:49, Nick Black wrote: > > It supports MBR, GPT, and APM: > > > > https://github.com/dankamongmen/growlight/blob/master/src/ptable.c#L51-L123 > > > > (sorry for the gmail-style top posting; i can't find your mail in my mbox > > for whatever reason) > > > > Any other partition schemes ought be trivial to add; they've not been added > > yet > > simply because I don't have means with which to test them. > > So, you are not using libparted then? > > > Looking at the "partition types" section of the Linux configuration, I see: > > Acorn, AIX, Alpha, Amiga, Atari, Macintosh, MSDOS, BSD, Minix, Solaris > > x86, Unixware, > > Windows LDM, SGI, Ultrix, Sun, Karma, EFI/GPT, and SYSV68. > > > > Looking at the disk-label code from partman, I see: > > gpt, msdos, amiga, atari, mac, sun > > > > So the only ones covered by partman and not covered by growlight would be: > > amiga, atari, sun, > > and mac (if mac is not the same as APM). I don't see any difficulty in > > adding these four, so long > > as there's someone with an Amiga or ATARI who'd be willing to test them > > out. If there are no such > > people, is it that important? > > Yes, it is important as we're supporting these architectures in Debian Ports > and I invested quite some time to get Atari partition support added [1], > for example. > > I think it makes little sense to not use libparted as it already supports > all common and less common partition types and reimplementing everything > that libparted makes little sense to me. > > Adrian Does libparted support the discoverable partitions spec? Kind Regards, Luca Boccassi
Re: Bug#980889: RFP: binutils-sh-elf -- cross binary utilities for SuperH bare-metal systems
Hi John! > This package would provide GNU Binutils suited for embedded targets, and > would be suited for both SH-1 and SH-2 hardware at least [1]. This is needed > to build carl9170, the libre wireless firmware for AR9170 devices that's > currently in firmware-linux-free. That will require GCC and Newlib as well. I'm Debian's sh4 maintainer and I would be willing to sponsor this provided that Matthias is fine with a separate binutils package. Also, please join the debian-superh mailing list [1] and the #debian-ports IRC channel. Thanks, Adrian > [1] https://lists.debian.org/debian-superh/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bundling
Quoting Alec Leamas (2021-09-26 12:16:00) > On 26/09/2021 11:08, Jonas Smedegaard wrote: > > Quoting Alec Leamas (2021-09-26 10:05:04) > >> Thanks for taking time to try to sort this out! > >> > >> On 25/09/2021 18:52, Jonas Smedegaard wrote: > > >> Tight dependencies should be fine. This is C++, so library symbols > >> is bit convoluted. > > > > See https://wiki.debian.org/PkgKde/DhSymbolsFile > > After some tries in this area I have leaned to Russ Allberry's post > https://www.eyrie.org/~eagle/journal/2012-02/001.html. Is this > outdated? Russ Allberry tried to provide more intimately track individual symbols, but for the packages he did the experiment he considered it too much work for too little gain, so he reverted to tracking stable ABIs. Others have come to different conclusions for different packages - myself included. I bring it up here - despite Russ finding it unsuitable for his package maintenance work - to help you explore options _beyond_ the conventional wisdom of "only rely on stable ABIs. > >> What do you think about a plan like this: > >> > >> - We make a provisionary, internal packaging of 3.1.5 and uses that in > >> next cycle. > >> > >> - Around February-March -22 we assess the situation again. If we > >> believe that 3.2 will ready and packaged before our own release, we > >> just wait for that to happen. > >> > >> - If not, we approach the wxWidgets maintainer about getting our > >> provisionary, temporary package in shape and released, probably in > >> experimental. > >> > >> - If the maintainer refuses to make such a release we have to bundle > >> the library in our own package. > > > > I am concerned that you a) seemingly prefer to postpone involving > > wxWidget package maintainers, and b) did not anwer my question about > > maintenance: > > > As for postponing, it's just about that if 3.2 arrives in time there > is nothing to discuss, and the issue is void. But OTOH, we could > always discuss things anyway, agreed. I deliberately ignored the timing part of your proposal, and instead think in "stages" - here is a plan I find sensible: * maybe you make an test packaging of 3.1.5 - not uploaded to Debian at all * if wxWidgets 3.2 is in Debian when you are ready to upload to Debian, then have your package link against that * if not, then you approach the wxWidgets maintainer about creating a package for it, which would stay in experimental until no longer experimental (i.e. when either ABI has stabilized or packaging contains reasonable tracking of unstable ABI e.g. using symbols tracking). * if wxWidgets maintainer find it unreasonable to package wxWidgets 3.2 before its ABI has stabilized, you might consider embedding a snapshot in your own package - released only to Debian experimental. * of there is still no wxWidgets 3.2 package in Debian when Debian gets close to freeze **AND YOU ARE FULLY WILLING TO MAINTAIN YOUR FORK OF WXWIDGETS YOURSELF FOR SEVERAL YEARS**, then release your experimental package to Debian unstable. * otherwise wait until wxWidgets maintainer consider it reasonable to provide the needed version of the wxWidgets library. > >> How do you and OpenCPN upstream expect to handle bugs for that > >> specific embedded version of wxWidgets? > > [upstream hat on] As for maintenance, using 3.1.5 places us in a loop > with wxWidgets upstream where possible patches introduced will be > forwarded, reviewed and eventually released with 3.2. This is also how > bugs will be handled. You are describing a healthy relationship between a code fork and its upstream origin. That's great to hear - it means your fork will likely be in good shape for as long as it needs to exist. My concern is that there is a real risk that you will need to maintain it for longer than you intended if you release your code to Debian unstable and let it migrate to Debian testing, and if that happens that you cannot maintain a _stable_ fork - i.e. that you 2 years from now will need to rebase your fork on a newer upstream snapshot to fix some bug that is too difficult for you to rebase and that upstream has progressed too far away from to care about solving it twice - both for their own codebase and again for your (to them) ancient codebase. > > I think that if you do not want to properly maintain the wxWidget > > code you need, then the best for Debian is that you postpone > > introducing this newer OpenCPN release until the wxWidget package > > maintainers consider it reasonable to introduce the code needed for > > it. > > As long as we don't miss Bookworm it's not that bad. It will still > affect downstreams like Ubuntu and Raspbian, though. However, > question is how much effort we should put in this, since we still > don't know if 3.2 will arrive in time or not. I understand your concern for your codebase to get into stable Debian. My concern is that stable Debian should stay stable: Debian testing i
Re: partman, growlight, discoverable partitions, and fun
John Paul Adrian Glaubitz left as an exercise for the reader: > So, you are not using libparted then? i am not. > Yes, it is important as we're supporting these architectures in Debian Ports > and I invested quite some time to get Atari partition support added [1], > for example. I'd be delighted to support them -- as in, I am honestly eager to add ATARI support; that sounds awesome -- I just need some way to test the implementations, either via someone running it on the environment, or getting access to such a machine. > I think it makes little sense to not use libparted as it already supports > all common and less common partition types and reimplementing everything > that libparted makes little sense to me. parted did not have ZFS support when I embarked on this project (it appears to have it now). i would not be opposed to leveraging libparted if it presents a definite advantage; supporting more partition types, so long as it exposes an API i can easily work with, would be such an advantage. i do note that libparted2 is 621K in the archive, whereas growlight itself is only 555K. it is of course possible that all that weight is desirable functionality. with that said, i would *still want to test on the target environment*, to make sure i'm using libparted correctly there. so that necessity remains. would this allay your concerns? --nick -- nick black -=- https://www.nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: partman, growlight, discoverable partitions, and fun
On 26.09.21 10:50, Adam Borowski wrote: My biggest worry personally (aside from the realpolitik of getting this change through) regards the automated partitioning language available through the preseed system. Trying to emulate this bug-for-bug is a non-starter, I think, both from a technical and quality-of-life standpoint. If the emulation can't be perfectly accurate, I don't think it ought be attempted for such a critical, delicate procedure. I personally think that preseed is nasty enough that users who do automation on a scale that would make learning it worthwhile already have a better way to do such automation. For me, d-i is for manual installs, scripted stuff wants a partitioner + glorified debootstrap. As someone who has tried in the past to get partitioning correct using preseeding on a wider variety of disk shapes, I think anything but would be an improvement. FAI's setup-storage is obviously better. But good riddance to the lack of sensible debugging of the shell script horror story that is the existing system. :) Kind regards Philipp Kern
Bug#995121: ITP: dioptas -- Python based GUI-Program for integration and exploration of 2D x-ray diffraction images
Package: wnpp Severity: wishlist Owner: Roland Mas X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: dioptas Version : 0.5.2 Upstream Author : Clemens Prescher * URL : https://github.com/Dioptas/Dioptas * License : GPL-3 Programming Lang: Python Description : Python based GUI-Program for integration and exploration of 2D x-ray diffraction images A GUI program for fast analysis of powder X-ray diffraction Images. It provides the capability of calibrating, creating masks, having pattern overlays and showing phase lines.
Re: binutils-m68hc1x: Repackage as a native package
Hello Vincent! > It is suggested to use a native package structure to package binutils > for a less common target. The way this package should be packaged is > described in https://wiki.debian.org/PackagingLessCommonBinutilsTargets > > Please update the packaging to follow the above suggestions. I'm the primary maintainer of Debian's m68k port and I would be happy to sponsor the package for you. Let me know if you're interested. Please join the debian-68k mailing list and the #debian-ports IRC channel on OFTC if you want to get in touch with the rest of us. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bundling
Hi Jonas, On 26/09/2021 14:41, Jonas Smedegaard wrote: Quoting Alec Leamas (2021-09-26 12:16:00) On 26/09/2021 11:08, Jonas Smedegaard wrote: Quoting Alec Leamas (2021-09-26 10:05:04) Thanks for taking time to try to sort this out! On 25/09/2021 18:52, Jonas Smedegaard wrote: Tight dependencies should be fine. This is C++, so library symbols is bit convoluted. See https://wiki.debian.org/PkgKde/DhSymbolsFile After some tries in this area I have leaned to Russ Allberry's post https://www.eyrie.org/~eagle/journal/2012-02/001.html. Is this outdated? Russ Allberry tried to provide more intimately track individual symbols, but for the packages he did the experiment he considered it too much work for too little gain, so he reverted to tracking stable ABIs. Others have come to different conclusions for different packages - myself included. I bring it up here - despite Russ finding it unsuitable for his package maintenance work - to help you explore options _beyond_ the conventional wisdom of "only rely on stable ABIs. OK, thanks. I deliberately ignored the timing part of your proposal, and instead think in "stages" - here is a plan I find sensible: * maybe you make an test packaging of 3.1.5 - not uploaded to Debian at all * if wxWidgets 3.2 is in Debian when you are ready to upload to Debian, then have your package link against that * if not, then you approach the wxWidgets maintainer about creating a package for it, which would stay in experimental until no longer experimental (i.e. when either ABI has stabilized or packaging contains reasonable tracking of unstable ABI e.g. using symbols tracking). * if wxWidgets maintainer find it unreasonable to package wxWidgets 3.2 before its ABI has stabilized, you might consider embedding a snapshot in your own package - released only to Debian experimental. * of there is still no wxWidgets 3.2 package in Debian when Debian gets close to freeze **AND YOU ARE FULLY WILLING TO MAINTAIN YOUR FORK OF WXWIDGETS YOURSELF FOR SEVERAL YEARS**, then release your experimental package to Debian unstable. * otherwise wait until wxWidgets maintainer consider it reasonable to provide the needed version of the wxWidgets library. OK, see below. >> How do you and OpenCPN upstream expect to handle bugs for that >> specific embedded version of wxWidgets? [upstream hat on] As for maintenance, using 3.1.5 places us in a loop with wxWidgets upstream where possible patches introduced will be forwarded, reviewed and eventually released with 3.2. This is also how bugs will be handled. You are describing a healthy relationship between a code fork and its upstream origin. That's great to hear - it means your fork will likely be in good shape for as long as it needs to exist. My concern is that there is a real risk that you will need to maintain it for longer than you intended if you release your code to Debian unstable and let it migrate to Debian testing, and if that happens that you cannot maintain a _stable_ fork - i.e. that you 2 years from now will need to rebase your fork on a newer upstream snapshot to fix some bug that is too difficult for you to rebase and that upstream has progressed too far away from to care about solving it twice - both for their own codebase and again for your (to them) ancient codebase. Agreed, we should not do that, se below. If what you call "provisionary" is something done outside of Debian or only in Debian experimental, then is seems you agree. But I am not sure - in particular your "and uses that in next cycle" sounds like you will not treat it as only experimental but rely on that newer release, no matter if embedded code is maintainable or not. I totally agree with you that embedding is the last option and should be avoided if possible. After all, I'm raising this issue in time... I also share your view that if bundling, it must be a temporary measure. It must definitely not linger in upcoming releases. Sounds like we agree, then - sorry if I mistook you as less careful in my previous remarks... No offense taken ;) Is there a route where we keep things in experimental (bundled or not) and let it stay there until wxWidgets 3.2 is out? And we then can make a sid package without any other dependencies or bundled wxWidgets code? I think the route I outline above covers what you describe here - do you agree? Yes, besides that I don't really consider releasing the experimental package an option. At least as it looks now. Thanks for all input, I think we are reaching some consensus here. There is a plan... Cheers! --alec
