Re: It's Time to Talk About Free Software Again
So
Re: Debconf - adding "treeselect" type(s)?
Thomas Goirand wrote: >On 11/29/20 11:37 PM, Timo Weingärtner wrote: >> >> Would checking "a" automatically also check "a/*"? >> Is it only about UI, meaning "a/*" would be collapsed under "a"? >> Shall it be possible to check "a", but uncheck "a/b"? >> >> GrüÃe >> Timo > >I very much agree that this needs to be discussed, then specified correctly. I think I've been clear on this bit in the thread? What's missing? >Also, would that sound crazy if we were to introduce the tree as >described with json? That's simple enough, so that even a human can do >it by hand, and also understood by all languages. json is all well and good for more powerful languages (and yes, I'd be convinced there!), but nigh-on impossible to do reliably in shell AFAICS. Shell is (one of) the most common environments for driving debconf, in package config and postinst scripts. I don't think that's going to fly. Oh, except... We'd only have to generate the json from shell, not parse it. That may be more tractable. Thanks, that could be a good suggestion! >Otherwise, what would be the way to describe a tree? I'm playing with ideas so far, let's see shortly. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Debconf - adding "treeselect" type(s)?
Thomas Goirand wrote: >On 11/30/20 11:18 AM, Steve McIntyre wrote: >> I'm envisaging treating the Choices *mostly* like in an existing >> select/multiselect, but with extra decoration to indicate the position >> in the tree for display. It would then be up to the frontend to decode >> that and work out a sensible way to display things as best it can. Not >> sure on the best way to do the decoration, hoping there'll be an >> available special character or similar that we could use in strings to >> avoid too big an upheaval here. > >å§ [1] Maybe... >>> Although these require manual selection, I think they do have at least >>> some use, and I'd rather keep them going. It shouldn't be too hard to >>> get full coverage, pulling in help from specialists if necessary. >> >> I guess so. > >How would it be pre-seeded? Just like a multiselect? With only leafs >that could potentially be in the pre-seed? That's exactly my plan, yes. The non-leaf bits are just syntactic sugar for the UI. -- Steve McIntyre, Cambridge, UK.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Sample Small Organisation Server now has email
Quoting John Lines (2020-12-02 19:47:02) > > Where is the code? > > Much of the code, which is essentially a set of configuration options > is on my test system at present, but I am cleaning it up and migrating > it to https://salsa.debian.org/jlines/smallorganisationserver > > On salsa at present is the start of a framework, Great. Thanks! - 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
Bug#976272: ITP: libnewuoa-cpp -- C++ implementation of the NEWUOA algorithm
Package: wnpp Severity: wishlist Owner: "Maarten L. Hekkelman" * Package name: libnewuoa-cpp Version : 0.1.0 Upstream Author : Roman Siromakha * URL : https://github.com/elsid/newuoa-cpp * License : MIT Programming Lang: C++ Description : C++ implementation of the NEWUOA algorithm This library contains the C++ implementation of the NEWUOA derivative free optmization algorithm originally published by Michael J. D. Powell.
Re: [External] Re: Lenovo discount portal update (and a few other things)
Hi, On 2020-12-02 2:35 a.m., Yves-Alexis Perez wrote: On Wed, 2020-11-04 at 13:45 -0500, Mark Pearson wrote: I've started chasing this directly myself, but last week was crazy busy. I have the owner of a number of S and Central America countries looking into it - I need to go chase some others. Sorry - really slow going :( Hi Mark, I hope a monthly ping is ok for you. Did you have a chance to talk to EU geos people? Regards, > I didand I have some good news on the Europe portal front coming really soon. They are setting it up and I'm just waiting for confirmation of it being done. I'm hoping I can confirm next week but it is busy season for the folks who work on this though so I can't make promises. I'm still having headaches actually getting Linux systems up in Europe, but I'm making (sadly slow) progress there. They tried to get the first systems up and hit same internal rule/configuration issues that have to be fixed first. That's a long process with getting approvals to change the rules (that was supposed to be fixed when we did the systems in the US but turns out was not done correctly...sigh). My hair is getting both pulled out and greyer.which is not a good combo. Still - there is forward progress there too :) Mark
Re: Sample Small Organisation Server now has email
> > Where is the code? Much of the code, which is essentially a set of configuration options is on my test system at present, but I am cleaning it up and migrating it to https://salsa.debian.org/jlines/smallorganisationserver On salsa at present is the start of a framework, > > At the link you share above, I only essentially find "there is no > step > by step guide." > > The actual steps I took to get to where the system is had many stages of going in circles, I now intend to script the installation, so far and put that onto salsa > > A "Debian Pure Blend" is developed and maintained _in_ Debian. > The intention is to be a Debian Pure Blend. I am aware that there is a long way to go, but The Greatest Journey Starts with a Single Step. Best wishes John
Re: Sample Small Organisation Server now has email
Quoting John Lines (2020-12-02 15:03:47) > My demonstrator Small Organisation Server now has working email, set > up, as described, in overview > at > https://wordpress.debian.social/jlines/2020/12/02/ambridge-garden-club-email/ > > Pretty much all the components came from software packaged in Debian, > and I think, even though the current setup went down a number of blind > alleys, it should only need, for the email setup, the domain name to be > served (which is the normal system domain name) and users having > standard fields in an LDAP schema. > > There is quite a lot of overlap with Freedombox, although for > flexilbity of LDAP administration it currently has phpldapadmin and > FusionDirectory installed. I also had GOSA installed, but at present it > conflicts in too many places with FusionDirectory. Where is the code? At the link you share above, I only essentially find "there is no step by step guide." If you seek input for something not developed withing Debian itself, then that's perfectly fine and I wish you all the best for your project, just please then call it a Debian Derivative and please use the various user forums instead of this -devel list meant for developing Debian itself. A "Debian Pure Blend" is developed and maintained _in_ Debian. A "Debian Blend" is done outside Debian, for later merging into Debian. A "Debian Derivative" is based on Debian, i.e. maybe a Blend maybe not. Kind regards, - 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: A Small Organisation Server as a Debian Pure Blend
On Tue, 2020-11-17 at 02:07 +, Wookey wrote: > On 2020-11-16 19:20 +, John Lines wrote: > > > I think this is a worthy technical goal. Given the decade it has > taken for Fredombox to get this far I suspect the pandemic will be > over before we get something working at a reasonably numpty-proof > level, unless an impressive level of enthusiasm is collected and > applied. > > I have just set up a small server yesterday in order to experiment > with this stuff (setting up matrix-synapse initially, but jangouts > and BBB are also of interest, although neither are packaged). > > So yes, knock something up and I will be happy to at least test it. > > Wookey Would you like to pick an Ambridge character, and I will set you up an account John
Sample Small Organisation Server now has email
My demonstrator Small Organisation Server now has working email, set up, as described, in overview at https://wordpress.debian.social/jlines/2020/12/02/ambridge-garden-club-email/ Pretty much all the components came from software packaged in Debian, and I think, even though the current setup went down a number of blind alleys, it should only need, for the email setup, the domain name to be served (which is the normal system domain name) and users having standard fields in an LDAP schema. There is quite a lot of overlap with Freedombox, although for flexilbity of LDAP administration it currently has phpldapadmin and FusionDirectory installed. I also had GOSA installed, but at present it conflicts in too many places with FusionDirectory. John
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Wed, 02 Dec 2020 at 11:15:44 +0100, Raphael Hertzog wrote:
> But this has the obvious downside that "${source:Version}" is unchanged
> and that you might have issues with dependencies against the arch: all
> package.
Yes, I already said that this is why OBS can't realistically do its builds
like binNMUs (or more precisely, with binary-only=yes changelog entries).
Breaking the ${source:Version} assumption would break the packages listed
in https://lintian.debian.org/tags/maybe-not-arch-all-binnmuable.html and
possibly others, which is undesirable if your goal is to rebuild Debian or
Ubuntu packages with minimal modification (which is the case for my
employer's uses of OBS).
smcv
Re: Architecture: all binNMUs (was: deduplicating jquery/)
On Wed, 02 Dec 2020, Raphael Hertzog wrote: > > potentially different content, breaking the important design principle > > that things that are different should have different names. [...] > And as an aside, the archive has big holes when enforcing this "design > principle": > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876643 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620356 > It would be nice to have this fixed. I knem I missed one, there's this one too which caught me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=949962 Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Architecture: all binNMUs (was: deduplicating jquery/)
Hi,
On Tue, 01 Dec 2020, Simon McVittie wrote:
> If I understand correctly, one of the ftp team's objections to discarding
> and rebuilding maintainer-uploaded binaries is that if I upload foo_1.2-3,
> and they discard my binary upload and rebuild it on the buildds, this
> would result in having two binary builds of foo-bin_1.2-3_amd64.deb and two
> binary builds of foo-data_1.2-3_all.deb with the same version number but
> potentially different content, breaking the important design principle
> that things that are different should have different names.
That objection is debatable for packages that have not yet reached the
archive. Dropping the binary after NEW review ought to be sufficient.
And as an aside, the archive has big holes when enforcing this "design
principle":
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876643
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620356
It would be nice to have this fixed.
> At the moment, builds in OBS cannot make use of Debian's binNMU machinery
> for this, because if they did, they would break the same ${source:Version}
> assumption I described in my previous message. The result is that they
> have to behave as though +bsos1 was a new sourceful upload, and
> foo-bin_1.2-3+bsos1_amd64.deb and foo-data_1.2-3+bsos1_all.deb both have
> Source: foo (= 1.2-3+bsos1). Consumers have to "just know" that to
> get the source code for foo-bin_1.2-3+bsos1_amd64.deb, you strip the
> /\+bsos[0-9]+$/ suffix from the version number before looking for the
> foo=1.2-3 source package. Obviously, this scales poorly if you are looking
> at multiple derivatives each with its own pseudo-binNMU suffix.
>
> If we had a way to do Architecture: all binNMUs, then OBS would be able to
> use it for all builds: for instance, foo-bin_1.2-3+bsos1_amd64.deb and
> foo-data_1.2-3+bsos1_all.deb could both have Source: foo (= 1.2-3).
In fact, dpkg has support for such binary-only rebuild. Have your
changelog entry like this:
| foo (1.2-3+bsos1) unstable; urgency=low,binary-only=yes
|
| * Binary rebuild.
|
| -- Raphaël Hertzog Wed, 02 Dec 2020 10:48:12 +0100
And then "arch: all" and "arch: any" packages will have the proper
"Source" entry with a value of "foo (1.2-3)".
I just tested it and it works (at least with raw dpkg-buildpackage).
But this has the obvious downside that "${source:Version}" is unchanged
and that you might have issues with dependencies against the arch: all
package.
In the end, the solution to make it easy to bump the version with a no-change
source upload is more likely to happen quickly.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Epoch version for golang-github-gomodule-redigo-dev?
* Clément Hermann [Thu Nov 26, 2020 at 02:19:38PM +0100]: > On 26/11/2020 09:31, Paul Gevers wrote: > > As it seems not unreasonable to expect the upstream version to go past > > 2.0.0 in the not infinite future, this is the approach I would take. > > Because you ask here, it suggests to me that doing this has some pain > > for the packaging that you didn't elaborate on. Why do you even raise > > the question here on debian-devel and don't just do this established way > > of fixing these kind of temporarily versioning issues in Debian? > Well, I was the one suggesting Michael start a discussion on > debian-devel about it, so I thought I'd chime in. [...] > An epoch might be overkill here, but also seems more appropriate to me > since we have to work around upstream decision in this case. And since > the Policy states it needs to be discussed first here, I suggested to do > just that. ACK and thanks. > I do agreee that the best and most logical thing would be for upstream > to start using 3.0, as Simon pointed out. Michael, did you bring this > issue upstream ? Would you suggest this option to them ? If they're > willing to do that in a reasonable timeframe, we could go the +really > route and wait until 3.0 is available upstream. Otherwise, we can go for > an epoch if we reach consensus here. Yes, raising the version to v3.0 was brought up within https://github.com/gomodule/redigo/pull/440, which was referred to from https://github.com/gomodule/redigo/issues/532, quoting Steven Hartland (one of the upstream maintainers of redigo) from there: | See the conversation on #440 but in short major version bumps in gomod are painful for users :( So I'm afraid this won't happen "soon". :-/ > Thanks to everyone participating, by the way! +1 also from my side, great feedback - thanks Paul, Holger, Mattia and Simon! So AFAICS we agree to fix the situation via an epoch upload. regards -mika- signature.asc Description: Digital signature
The phpMyAdmin package needs a review on a merge request
Hi developers,
I am unsure about the format of my email but I decided to write here.
As a team member of phpMyAdmin and also of the packaging team I want to have
the latest version packaged.
Currently 4.9 is in Debian, I prepared all the work for 5.0.
I am asking for the help to review my work, there is nothing particularly
difficult in the diff. I am a new DM and need to be sure the changes I do are
correct.
You can find the merge request here:
https://salsa.debian.org/phpmyadmin-team/phpmyadmin/-/merge_requests/30
Feel free to comment or send approvals if you think the work is good to be
integrated into Debian.
Tips: you can navigate to the debian/* files diffs using the hierarchy button
on https://salsa.debian.org/phpmyadmin-team/phpmyadmin/-/merge_requests/30/diffs
You can find all the branches duplicated and named {name}-5.x ready to be
merged in {name}.
Kind regards,
William Desportes
signature.asc
Description: PGP signature
