Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#900928: RFP: fractal -- Matrix group messaging app
17 views
Skip to first unread message
nodiscc
Jun 6, 2018, 5:00:03 PM6/6/18
to
Package: wnpp
Severity: wishlist
* Package name : fractal
* Version : 0.1.30
* Upstream Author : Daniel Garcia Moreno
* URL : https://gitlab.gnome.org/World/fractal
* License : gplv3
* Programming Lang: Rust
* Description : Matrix group messaging app
https://wiki.gnome.org/Apps/Fractal
Fractal is a Matrix messaging app for GNOME written in Rust. Its
interface is optimized for collaboration in large groups, such as free
software projects.
Severity: wishlist
* Package name : fractal
* Version : 0.1.30
* Upstream Author : Daniel Garcia Moreno
* URL : https://gitlab.gnome.org/World/fractal
* License : gplv3
* Programming Lang: Rust
* Description : Matrix group messaging app
https://wiki.gnome.org/Apps/Fractal
Fractal is a Matrix messaging app for GNOME written in Rust. Its
interface is optimized for collaboration in large groups, such as free
software projects.
Antoine Beaupré
Mar 17, 2022, 11:00:03 AM3/17/22
to
Hi!
Is there any progress on the packaging of fractal in Debian? Any
blockers or missing crates?
Thanks!
--
Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty.
Beauty is not love. Love is not music.
Music is the best. - Frank Zappa
Is there any progress on the packaging of fractal in Debian? Any
blockers or missing crates?
Thanks!
--
Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty.
Beauty is not love. Love is not music.
Music is the best. - Frank Zappa
Jonas Smedegaard
Apr 12, 2022, 6:30:04 AM4/12/22
to
Control: owner -1 !
@Andrej: I took your silence to mean that you stopped working on this -
feel free to take back this ITP if I am mistaken.
Quoting Antoine Beaupré (2022-03-17 15:51:22)
https://salsa.debian.org/matrix-team/fractal
It compiles, also in an non-networked build environment if first
fetching 428 Rust crates (see debian/README.source).
Build takes ~40 minutes on my local amd64 system.
The built executable segfaults, however:
> $ LANG=C fractal
>
> (fractal:354481): GLib-GIO-ERROR **: 12:02:22.755: Settings schema 'org.gnome.Fractal' does not contain a key named 'markdown-active'
> Sporings-/stoppunkts-fælde (smed kerne)
That last message oddly ignores the LANG variable - it says something
like "Tracing/stoppoint trap (threw core)" which I guess essentially
means a segfault.
My plan is to continue refine this package until suitable for release
into Debian, and then maintain it in the Matrix team.
@Antoine (and others reading along): You are quite welcome to help. If
you want to help test, then please tell if you want me to provide
pre-built binaries (when no longer segfaulting I expect to compile for
amd64 and arm64 for my own use, and can share those more widely if there
is interest).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
@Andrej: I took your silence to mean that you stopped working on this -
feel free to take back this ITP if I am mistaken.
Quoting Antoine Beaupré (2022-03-17 15:51:22)
> Is there any progress on the packaging of fractal in Debian? Any
> blockers or missing crates?
I have now put together a draft source package, tracked at
> blockers or missing crates?
https://salsa.debian.org/matrix-team/fractal
It compiles, also in an non-networked build environment if first
fetching 428 Rust crates (see debian/README.source).
Build takes ~40 minutes on my local amd64 system.
The built executable segfaults, however:
> $ LANG=C fractal
>
> (fractal:354481): GLib-GIO-ERROR **: 12:02:22.755: Settings schema 'org.gnome.Fractal' does not contain a key named 'markdown-active'
> Sporings-/stoppunkts-fælde (smed kerne)
That last message oddly ignores the LANG variable - it says something
like "Tracing/stoppoint trap (threw core)" which I guess essentially
means a segfault.
My plan is to continue refine this package until suitable for release
into Debian, and then maintain it in the Matrix team.
@Antoine (and others reading along): You are quite welcome to help. If
you want to help test, then please tell if you want me to provide
pre-built binaries (when no longer segfaulting I expect to compile for
amd64 and arm64 for my own use, and can share those more widely if there
is interest).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
Antoine Beaupré
Apr 12, 2022, 9:10:04 AM4/12/22
to
On 2022-04-12 12:23:07, Jonas Smedegaard wrote:
[...]
> @Antoine (and others reading along): You are quite welcome to help. If
> you want to help test, then please tell if you want me to provide
> pre-built binaries (when no longer segfaulting I expect to compile for
> amd64 and arm64 for my own use, and can share those more widely if there
> is interest).
I'd be happy to do some testing, thanks for taking this on!
--
If I can't dance, I don't want to be part of your revolution.
- Emma Goldman
[...]
> @Antoine (and others reading along): You are quite welcome to help. If
> you want to help test, then please tell if you want me to provide
> pre-built binaries (when no longer segfaulting I expect to compile for
> amd64 and arm64 for my own use, and can share those more widely if there
> is interest).
--
If I can't dance, I don't want to be part of your revolution.
- Emma Goldman
Jonas Smedegaard
Apr 12, 2022, 9:50:04 AM4/12/22
to
[ dropping Andrej from cc ]
Quoting Antoine Beaupré (2022-04-12 15:07:03)
The segfault can apparently be avoided by removing
/usr/share/glib-2.0/schemas/org.gnome.Fractal.gschema.xml and then
running "glib-compile-schemas /usr/share/glib-2.0/schemas".
I can now log in, and Fratal begins indexing data (I can hear
matrix-synapse churning at my self-hosted non-SSD server few meters from
me), but when done it presents no rooms, and in terminal it spewed this:
> Error: Can't store the password using libsecret
> Error: Can't store the token using libsecret
If you want to compile on your own, then try if you get as far as me -
or further if you happen to be running GNOME, which I suspect might
provide a smoother ride than my sway environment.
If you want to try packages I build, then say so and I can arrange to
put them online.
Quoting Antoine Beaupré (2022-04-12 15:07:03)
> On 2022-04-12 12:23:07, Jonas Smedegaard wrote:
>
> [...]
>
> > @Antoine (and others reading along): You are quite welcome to help.
> > If you want to help test, then please tell if you want me to provide
> > pre-built binaries (when no longer segfaulting I expect to compile
> > for amd64 and arm64 for my own use, and can share those more widely
> > if there is interest).
>
> I'd be happy to do some testing, thanks for taking this on!
Great!
>
> [...]
>
> > @Antoine (and others reading along): You are quite welcome to help.
> > If you want to help test, then please tell if you want me to provide
> > pre-built binaries (when no longer segfaulting I expect to compile
> > for amd64 and arm64 for my own use, and can share those more widely
> > if there is interest).
>
> I'd be happy to do some testing, thanks for taking this on!
The segfault can apparently be avoided by removing
/usr/share/glib-2.0/schemas/org.gnome.Fractal.gschema.xml and then
running "glib-compile-schemas /usr/share/glib-2.0/schemas".
I can now log in, and Fratal begins indexing data (I can hear
matrix-synapse churning at my self-hosted non-SSD server few meters from
me), but when done it presents no rooms, and in terminal it spewed this:
> Error: Can't store the password using libsecret
> Error: Can't store the token using libsecret
If you want to compile on your own, then try if you get as far as me -
or further if you happen to be running GNOME, which I suspect might
provide a smoother ride than my sway environment.
If you want to try packages I build, then say so and I can arrange to
put them online.
Jonas Smedegaard
Apr 12, 2022, 12:50:03 PM4/12/22
to
Needs embedding 370 crates (16 from git snapshot); Builds in ~40
minutes; Runs but has issues with glib schema file and libsecret
Quoting Jonas Smedegaard (2022-04-12 12:23:07)
possible to replace with system crates, but a large part is either not
yet packaged at all or needs upgrading to link with gtk4.
As mentioned in previous posts, on my (non-GNOME) environment it
segfaults unless I remove
/usr/share/glib-2.0/schemas/org.gnome.Fractal.gschema.xml, and then it
logs in but then apparently disconnects again whe it cannot store
credentials. Maybe those two issues are connected, and maybe they
disappear on a GNOME desktop (i.e. are a matter of depending on and
loading proper desktop daemons): Help needed to investigate that.
minutes; Runs but has issues with glib schema file and libsecret
Quoting Jonas Smedegaard (2022-04-12 12:23:07)
> It compiles, also in an non-networked build environment if first
> fetching 428 Rust crates (see debian/README.source).
Now reduced to needing 370 crates embedded. A few more should be
> fetching 428 Rust crates (see debian/README.source).
possible to replace with system crates, but a large part is either not
yet packaged at all or needs upgrading to link with gtk4.
As mentioned in previous posts, on my (non-GNOME) environment it
segfaults unless I remove
/usr/share/glib-2.0/schemas/org.gnome.Fractal.gschema.xml, and then it
logs in but then apparently disconnects again whe it cannot store
credentials. Maybe those two issues are connected, and maybe they
disappear on a GNOME desktop (i.e. are a matter of depending on and
loading proper desktop daemons): Help needed to investigate that.
Andrej Shadura
Apr 12, 2022, 1:40:04 PM4/12/22
to
Hi,
On Tue, 12 Apr 2022, at 12:23, Jonas Smedegaard wrote:
> Control: owner -1 !
>
> @Andrej: I took your silence to mean that you stopped working on this -
> feel free to take back this ITP if I am mistaken.
Yeah, I've been quite busy lately and I was unable to work on this package. Sorry for not replying, I didn’t have time back then and then I forgot 🙂
> Quoting Antoine Beaupré (2022-03-17 15:51:22)
>> Is there any progress on the packaging of fractal in Debian? Any
>> blockers or missing crates?
>
> I have now put together a draft source package, tracked at
> https://salsa.debian.org/matrix-team/fractal
>
> It compiles, also in an non-networked build environment if first
> fetching 428 Rust crates (see debian/README.source).
>
> Build takes ~40 minutes on my local amd64 system.
>
> The built executable segfaults, however:
>
>> $ LANG=C fractal
>>
>> (fractal:354481): GLib-GIO-ERROR **: 12:02:22.755: Settings schema 'org.gnome.Fractal' does not contain a key named 'markdown-active'
>> Sporings-/stoppunkts-fælde (smed kerne)
>
> That last message oddly ignores the LANG variable - it says something
> like "Tracing/stoppoint trap (threw core)" which I guess essentially
> means a segfault.
>
> My plan is to continue refine this package until suitable for release
> into Debian, and then maintain it in the Matrix team.
It would be great if you could get the Rust team involved, as the majority of the dependencies should go in there. I started packaging dependencies for the non-next-Fractal back in the day, but the crypto stuff (for secret-service) was taking ages to get through NEW, which is why I gave up at some point.
--
Cheers,
Andrej
On Tue, 12 Apr 2022, at 12:23, Jonas Smedegaard wrote:
> Control: owner -1 !
>
> @Andrej: I took your silence to mean that you stopped working on this -
> feel free to take back this ITP if I am mistaken.
> Quoting Antoine Beaupré (2022-03-17 15:51:22)
>> Is there any progress on the packaging of fractal in Debian? Any
>> blockers or missing crates?
>
> I have now put together a draft source package, tracked at
> https://salsa.debian.org/matrix-team/fractal
>
> It compiles, also in an non-networked build environment if first
> fetching 428 Rust crates (see debian/README.source).
>
> Build takes ~40 minutes on my local amd64 system.
>
> The built executable segfaults, however:
>
>> $ LANG=C fractal
>>
>> (fractal:354481): GLib-GIO-ERROR **: 12:02:22.755: Settings schema 'org.gnome.Fractal' does not contain a key named 'markdown-active'
>> Sporings-/stoppunkts-fælde (smed kerne)
>
> That last message oddly ignores the LANG variable - it says something
> like "Tracing/stoppoint trap (threw core)" which I guess essentially
> means a segfault.
>
> My plan is to continue refine this package until suitable for release
> into Debian, and then maintain it in the Matrix team.
--
Cheers,
Andrej
Jonas Smedegaard
Apr 12, 2022, 2:30:03 PM4/12/22
to
Hi Andrej,
Quoting Andrej Shadura (2022-04-12 19:02:11)
:-)
Quoting Andrej Shadura (2022-04-12 19:02:11)
> On Tue, 12 Apr 2022, at 12:23, Jonas Smedegaard wrote:
> > @Andrej: I took your silence to mean that you stopped working on
> > this - feel free to take back this ITP if I am mistaken.
>
> Yeah, I've been quite busy lately and I was unable to work on this
> package. Sorry for not replying, I didn’t have time back then and then
> I forgot 🙂
Good to hear from you - and enjoy those other things keeping you busy!
> > @Andrej: I took your silence to mean that you stopped working on
> > this - feel free to take back this ITP if I am mistaken.
>
> Yeah, I've been quite busy lately and I was unable to work on this
> package. Sorry for not replying, I didn’t have time back then and then
> I forgot 🙂
:-)
Jonas Smedegaard
Apr 14, 2022, 4:20:03 AM4/14/22
to
Needs embedding 247 crates (16 from git snapshot); Builds in ~40
embedded (not a Rust crate), so my plan to continuously update to
upstream HEAD is currently stalled.
So I suspect I will now mostly wait for upstream to stabilize and wait
for the Rust team to bugfix and upgrade existing libraries already in
Debian.
You can help by testing this draft package (either build it yourself or
tell if you want me to provide you a binary package) and provide
feedback on how well it works in your desktop environment.
You can also help by joining the Rust team in Debian and help unbreak
and upgrade packaged crates, and add more:
https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
minutes; Runs but has issues with glib schema file and libsecret
Upstream code now requires a new library not in Debian and not easily
embedded (not a Rust crate), so my plan to continuously update to
upstream HEAD is currently stalled.
So I suspect I will now mostly wait for upstream to stabilize and wait
for the Rust team to bugfix and upgrade existing libraries already in
Debian.
You can help by testing this draft package (either build it yourself or
tell if you want me to provide you a binary package) and provide
feedback on how well it works in your desktop environment.
You can also help by joining the Rust team in Debian and help unbreak
and upgrade packaged crates, and add more:
https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
Jonas Smedegaard
Apr 21, 2022, 11:50:05 AM4/21/22
to
5.0.0~~git20220412-0.0 draft 4 needs embedding 234 crates (108 missing,
87 outdated, 14 ahead, 1 broken, 16 unreleased); runs but has issues
of fatal bugs in dependencies, the amount of embedded crates are now
reduced to 234.
My plan is still to mainly wait for upstream to stabilize their
codebase, and to wait for Rust team to update/upgrade more crate
packages.
You can help by testing this draft package (either build it yourself or
tell if you want me to provide you a binary package) and provide
feedback on how well it works in your desktop environment.
You can also help by joining the Rust team in Debian and help unbreak
and upgrade packaged crates, and add more:
https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
87 outdated, 14 ahead, 1 broken, 16 unreleased); runs but has issues
with glib schema file and libsecret
Thanks especially to Peter Michael Green in the Rust team fixing a slew
of fatal bugs in dependencies, the amount of embedded crates are now
reduced to 234.
My plan is still to mainly wait for upstream to stabilize their
codebase, and to wait for Rust team to update/upgrade more crate
packages.
You can help by testing this draft package (either build it yourself or
tell if you want me to provide you a binary package) and provide
feedback on how well it works in your desktop environment.
You can also help by joining the Rust team in Debian and help unbreak
and upgrade packaged crates, and add more:
https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
Jonas Smedegaard
Jun 10, 2022, 7:50:03 AM6/10/22
to
5.0.0~~git20220412-0.0 draft 5 needs embedding 230 crates (108 missing,
9 broken, 83 outdated, 14 ahead, 16 unreleased); apparently works fine
when gnome-keyring is installed.
Until now I had accidentally tested an old custom-installed binary, so
possibly this is true even for older draft releases as well: The issue
with glib schema is gone, and when package gnome-keyring is installed
Fractal succesfully logs into my self-hosted Matrix instance.
My plan is still to mainly wait for upstream to stabilize their
codebase, and to wait for Rust team to update/upgrade more crate
packages.
Now is a good time for you to help test this draft package (either build
9 broken, 83 outdated, 14 ahead, 16 unreleased); apparently works fine
when gnome-keyring is installed.
Until now I had accidentally tested an old custom-installed binary, so
possibly this is true even for older draft releases as well: The issue
with glib schema is gone, and when package gnome-keyring is installed
Fractal succesfully logs into my self-hosted Matrix instance.
My plan is still to mainly wait for upstream to stabilize their
codebase, and to wait for Rust team to update/upgrade more crate
packages.
it yourself or tell if you want me to provide you a binary package) and
provide feedback on how well it works in your desktop environment.
You can also help by joining the Rust team in Debian and help unbreak
and upgrade packaged crates, and add more:
https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
provide feedback on how well it works in your desktop environment.
You can also help by joining the Rust team in Debian and help unbreak
and upgrade packaged crates, and add more:
https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
Jonas Smedegaard
Nov 19, 2022, 12:31:25 PM11/19/22
to
5.0.0~~git20221105 draft 5 needs embedding 140 crates (73 missing, 3 broken, 49 outdated, 15 ahead); works fine.
Main tasks now are to keep package up-to-date with upstream releases, and wait for Rust team to upgrade GTK and GStreamer crates.
Here's how you can help:
As user running Debian, you can test this draft package: Either build it yourself from source or tell (by posting to this bugreport) if you prefer testing the binary packages I built - then I will share those.
As developer (but no need to be official member of Debian!), you can join the Debian Rust team and help package these missing crates: https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
Main tasks now are to keep package up-to-date with upstream releases, and wait for Rust team to upgrade GTK and GStreamer crates.
Here's how you can help:
As user running Debian, you can test this draft package: Either build it yourself from source or tell (by posting to this bugreport) if you prefer testing the binary packages I built - then I will share those.
As developer (but no need to be official member of Debian!), you can join the Debian Rust team and help package these missing crates: https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
Jonas Smedegaard
Nov 20, 2022, 6:10:04 AM11/20/22
to
5.0.0~~git20221105 draft 5 needs embedding 140 crates (73 missing, 3 broken, 49 outdated, 15 ahead); works fine; newer code requires rustc 1.63.
Main task now is to wait for Rust team to upgrade rustc: GIO/GLIB crates v0.16 and GStreamer crates v0.19 require rustc 1.63.
Here's how you can help:
As user running Debian, you can test this draft package: Either build it yourself from source or tell (by posting to this bugreport) if you prefer testing the binary packages I built - then I will share those.
As developer (but no need to be official member of Debian!), you can join the Debian Rust team and help package these missing crates: https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
Main task now is to wait for Rust team to upgrade rustc: GIO/GLIB crates v0.16 and GStreamer crates v0.19 require rustc 1.63.
Here's how you can help:
As user running Debian, you can test this draft package: Either build it yourself from source or tell (by posting to this bugreport) if you prefer testing the binary packages I built - then I will share those.
As developer (but no need to be official member of Debian!), you can join the Debian Rust team and help package these missing crates: https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO
matthias....@tutanota.de
Nov 25, 2022, 2:20:04 PM11/25/22
to
The two big chunks still missing for fractal are the matrix-sdk crate and all GTK and gstreamer related crates.
I started working on the matrix sdk tree, but it has a lot (!) of reverse and missing dependencies. The GTK and gstreamer crates can't be packaged because of #1017905 (#970059 which is needed for fractal is also affected). I started working on that, too. ftpmasters still haven't exactly told me how to properly ship the affected crates. (imho this isn't needed at all, but I digress). The remaining dependencies are somewhat trivial like comrak or oo7. I will continue working on packaging the missing crates, but it could prove difficult if #1017905 can't be resolved.
Cheers
Matthias Geiger (werdahias)
matthias....@tutanota.de
Nov 25, 2022, 2:40:04 PM11/25/22
to
did myself a favour and made a table illustrating the missing crates:
+────────────────────────────+──────────+───────────────────────+──────────────────+────────+
| ruma | | | | |
+────────────────────────────+──────────+───────────────────────+──────────────────+────────+
| depends on | | | | |
| ruma-appservice-api | | | | |
| ruma-state-res | depends | ruma-common | | |
| ruma-signatures | depends | ruma-common | ed25519-dalek | pkcs8 |
| ruma-push-gateway-api | depends | ruma-common | | |
| ruma-identity-service-api | depends | ruma-common | | |
| ruma-federation-api | depends | ruma-common | | |
| ruma-client | depends | ruma-common | ruma-client-api | |
| ruma-client-api | depends | ruma-common | | |
| ruma-common | depends | js_option | | |
| | | | | |
| | | | | |
| matrix-sdk-common | | | | |
| depends on | | | | |
| ruma | | | | |
| wasm-timer | depends | wasm-bindgen-futures | | |
| (optional) | | | | |
| wasm-bindgen-futures |
+────────────────────────────+
This is just the ruma stuff. The further up you go into the dependency jungle the messier it gets.
Once js_option is sponsored (I already packaged it) I can work on the ruma mess since I already packaged some other ruma crates.
Cheers
werdahias
Jonas Smedegaard
Apr 13, 2023, 11:40:03 AM4/13/23
to
Hi Matthias,
[quoting previous private post to help establish context]
Quoting matthias....@tutanota.de (2023-03-14 11:39:30)
> I wanted to discuss fractal. I also have a somewhat related interest to it. I have been constantly working on it. My wip-gtk branch covers most of its missing dependencies, so the big chunks missing are the matrix sdk and comrak. I have been constantly working on those, too. I'd like fractal to be maintained within the GNOME team since 1) it uses the GTK stack and 2) is also a circle app. Since I also put in some effort I also would like to be included as uploader. I think this is fair since now 80% of the dependencies are covered.
Quoting matthias....@tutanota.de (2023-04-13 14:57:41)
> > Is your work available publicly somewhere?
> >
> Yes. The matrix-sdk depends mainly on ruma which is 80% packaged in the debcargo-conf repo.
> The GTK-rs update is visible here: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/463 and most of the *debs are here: https://salsa.debian.org/werdahias/obfuscate-wip/-/tree/debs?ref_type=heads
>
> Stuff still missing: ashpd, oo7 and matrix-sdk. The former two are GTK related and I will package them as soon as the GTK update gets uploaded because I need them anyway. the latter needs ruma which I have constantly been working on.
> comrak isn't needed anymore apparently.
Ah, makes sense now. I thought you meant that you mean a wip-gtk branch
of the fractal packaging - i.e. this git repo:
https://salsa.debian.org/matrix-team/fractal
I appreciate your work on getting dependent Rust crates packaged for
Debian.
Personally I dislike the all-crates-in-one-git approach practiced in the
Rust team, and since the team has made it a "must" to do so within the
team I am not in that team at all.
Please consider using the Debian bugtracker to communicate "intents to
package" by filing an ITP bugreport for each single upstream project
that you work on packaging for Debian. That enables us to keep track of
efforts targeted but not yet included formally into Debian - i.e. the
very purpose of that class of bugreports in the Debian bugtracker.
> wrt maintaining: I thought all GNOME circle apps should be also maintained within the GNOME team, maybe even in a separate workspace, but that is just my opinion (especially since I maintain three of those programs that way). You're free to maintain it however you see fit, I didn't want to impose.
There are benefits of streamlining packaging within a team, but there
are also drawbacks of "optimizations" done within single teams. There
is a real risk that packages may bitrot when maintained by a team with a
too large focus, as single packages at the edge of their focus may not
get adequate attention.
Obviously a package may lack attention *anywhere - we do not magically
get more hands by splitting the task into more smaller buckets. But in
a smaller team mistreated packages has arguably a higher chance of
getting noticed - either by the team itself or by fellow Debian devopers
outside of the team or by users.
I mean, the task list for the security team is several pages long:
https://udd.debian.org/dmd/?team%2Bpkg-security%40tracker.debian.org#todo
...but that pales in comparison with the task list for the python team:
https://udd.debian.org/dmd.cgi?email1=team%2Bpython%40tracker.debian.org
There is no single obvious way to group packaging efforts.
Some teams streamline for one build systems (e.g. Rust team). Some
teams streamline for one programming language, across build systems
(e.g. Perl, Java, and Python teams). Some teams streamline for one
widget toolkit use, across languages (e.g. the GNOME team). Some teams
streamline for one desktop environment, across widget toolkits (e.g.
LXQT team)
Most packaging teams at https://wiki.debian.org/Teams, however, have a
scope of concrete tools or a smaller collection of interrelated tools.
The GNOME team likely has a team policy that optimized towards projects
closely related to the GNOME core infrastructure, at the expense of
packages more loosely related to that. That does not mean that all
projects close to GNOME is better off maintained by that team, only that
maintenance of the projects there benefits from that optimization - but
the backside is that maintainers are then expected to align with the
policy.
I don't use the GNOME desktop myself, and do not maintain a range of
packages tightly related to GNOME, so for me it would be more a burden
to engage in yet another team with maybe-peculiar-to-me policies.
> Regarding the "credit": also maybe came off wrong. My POV: I made a list of all the fractal deps and slowly started working those off. I put in a lot of effort to get the GTK-rs update underway and the rest of the fractal stuff like ruma. I guess that resulted in me thinking "Well, I do want some of the credit for working on fractal!" And I think while that may seem selfish I still deserve that as I put in constant work towaord the goal of packaging fractal. It's not my intention to come off that way but I think you get my point.
I totally get that.
It pains me that when I ask about your work, you point me to what I
perceive as a teamwork with little visibility of your efforts in it.
In a parallel universe, you would have posted to this ITP each and every
time you initiated the packaging of a dependency, exactly because you
initiated it with Fractal in mind. Then your work would have gained
visibility for anyone looking for progress on the Fractal packaging,
including me who have been attacking the challenge from the other end.
Personally I suspect that some of the pain you have gone through in
getting those packages in shape is due to the Rust team "streamlining",
and I fear that the current blocker of bug#1017905 is a sign of that.
> Honestly: Feel free to do whatever you think best for debian. The GTK stack will land in trixie and then it's straightforward to finish packaging. Please don't interfere with a) the gtk stack and b) the rest of the ruma stack,
> I kinda don't care about the rest. (not trying to start a side discussion which rust packaging is better; if I have an overview for both stacks that makes things easier)
What I think is best for Debian is that we collaborate more in Debian.
In Debian as a whole, not (only) within teams.
I dislike several things in the Rust team, and I suspect that
bug#1017905 exists because of the Rust team insisting that Debian
packaging should mimic upstream distribution design. That bug is about
a project packaged by redistributing pregenerated files, instead of what
is supposed to be the core rule in Debian: Packaging the preferred form
for editing.
You apparently work in the Rust team. If it works for you, then great -
I am not saying you should leave. But I am saying that I am torn
between wanting to collaborate and then having strong opinions myself
that arguably hinders collaboration.
I was preparing packaging of Ruma, but then saw a single package related
to that trickle into Debian, and I gave up on it: I would have packaged
a *collection* of packages together, because that is clearly how
upstream "preferred form for editing is for that codebase. But that
conflicts with the Rust team style of packaging. *SIGH*
I think a good step towards a better overview is to file ITPs. Also for
library-only crates, not only for applications.
> Sorry for a bit of an rant and the wall of text,
Thanks a lot for all that you wrote, and thanks for your work on
packaging crates.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[quoting previous private post to help establish context]
Quoting matthias....@tutanota.de (2023-03-14 11:39:30)
> I wanted to discuss fractal. I also have a somewhat related interest to it. I have been constantly working on it. My wip-gtk branch covers most of its missing dependencies, so the big chunks missing are the matrix sdk and comrak. I have been constantly working on those, too. I'd like fractal to be maintained within the GNOME team since 1) it uses the GTK stack and 2) is also a circle app. Since I also put in some effort I also would like to be included as uploader. I think this is fair since now 80% of the dependencies are covered.
Quoting matthias....@tutanota.de (2023-04-13 14:57:41)
> > Is your work available publicly somewhere?
> >
> Yes. The matrix-sdk depends mainly on ruma which is 80% packaged in the debcargo-conf repo.
> The GTK-rs update is visible here: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/463 and most of the *debs are here: https://salsa.debian.org/werdahias/obfuscate-wip/-/tree/debs?ref_type=heads
>
> Stuff still missing: ashpd, oo7 and matrix-sdk. The former two are GTK related and I will package them as soon as the GTK update gets uploaded because I need them anyway. the latter needs ruma which I have constantly been working on.
> comrak isn't needed anymore apparently.
Ah, makes sense now. I thought you meant that you mean a wip-gtk branch
of the fractal packaging - i.e. this git repo:
https://salsa.debian.org/matrix-team/fractal
I appreciate your work on getting dependent Rust crates packaged for
Debian.
Personally I dislike the all-crates-in-one-git approach practiced in the
Rust team, and since the team has made it a "must" to do so within the
team I am not in that team at all.
Please consider using the Debian bugtracker to communicate "intents to
package" by filing an ITP bugreport for each single upstream project
that you work on packaging for Debian. That enables us to keep track of
efforts targeted but not yet included formally into Debian - i.e. the
very purpose of that class of bugreports in the Debian bugtracker.
> wrt maintaining: I thought all GNOME circle apps should be also maintained within the GNOME team, maybe even in a separate workspace, but that is just my opinion (especially since I maintain three of those programs that way). You're free to maintain it however you see fit, I didn't want to impose.
There are benefits of streamlining packaging within a team, but there
are also drawbacks of "optimizations" done within single teams. There
is a real risk that packages may bitrot when maintained by a team with a
too large focus, as single packages at the edge of their focus may not
get adequate attention.
Obviously a package may lack attention *anywhere - we do not magically
get more hands by splitting the task into more smaller buckets. But in
a smaller team mistreated packages has arguably a higher chance of
getting noticed - either by the team itself or by fellow Debian devopers
outside of the team or by users.
I mean, the task list for the security team is several pages long:
https://udd.debian.org/dmd/?team%2Bpkg-security%40tracker.debian.org#todo
...but that pales in comparison with the task list for the python team:
https://udd.debian.org/dmd.cgi?email1=team%2Bpython%40tracker.debian.org
There is no single obvious way to group packaging efforts.
Some teams streamline for one build systems (e.g. Rust team). Some
teams streamline for one programming language, across build systems
(e.g. Perl, Java, and Python teams). Some teams streamline for one
widget toolkit use, across languages (e.g. the GNOME team). Some teams
streamline for one desktop environment, across widget toolkits (e.g.
LXQT team)
Most packaging teams at https://wiki.debian.org/Teams, however, have a
scope of concrete tools or a smaller collection of interrelated tools.
The GNOME team likely has a team policy that optimized towards projects
closely related to the GNOME core infrastructure, at the expense of
packages more loosely related to that. That does not mean that all
projects close to GNOME is better off maintained by that team, only that
maintenance of the projects there benefits from that optimization - but
the backside is that maintainers are then expected to align with the
policy.
I don't use the GNOME desktop myself, and do not maintain a range of
packages tightly related to GNOME, so for me it would be more a burden
to engage in yet another team with maybe-peculiar-to-me policies.
> Regarding the "credit": also maybe came off wrong. My POV: I made a list of all the fractal deps and slowly started working those off. I put in a lot of effort to get the GTK-rs update underway and the rest of the fractal stuff like ruma. I guess that resulted in me thinking "Well, I do want some of the credit for working on fractal!" And I think while that may seem selfish I still deserve that as I put in constant work towaord the goal of packaging fractal. It's not my intention to come off that way but I think you get my point.
I totally get that.
It pains me that when I ask about your work, you point me to what I
perceive as a teamwork with little visibility of your efforts in it.
In a parallel universe, you would have posted to this ITP each and every
time you initiated the packaging of a dependency, exactly because you
initiated it with Fractal in mind. Then your work would have gained
visibility for anyone looking for progress on the Fractal packaging,
including me who have been attacking the challenge from the other end.
Personally I suspect that some of the pain you have gone through in
getting those packages in shape is due to the Rust team "streamlining",
and I fear that the current blocker of bug#1017905 is a sign of that.
> Honestly: Feel free to do whatever you think best for debian. The GTK stack will land in trixie and then it's straightforward to finish packaging. Please don't interfere with a) the gtk stack and b) the rest of the ruma stack,
> I kinda don't care about the rest. (not trying to start a side discussion which rust packaging is better; if I have an overview for both stacks that makes things easier)
What I think is best for Debian is that we collaborate more in Debian.
In Debian as a whole, not (only) within teams.
I dislike several things in the Rust team, and I suspect that
bug#1017905 exists because of the Rust team insisting that Debian
packaging should mimic upstream distribution design. That bug is about
a project packaged by redistributing pregenerated files, instead of what
is supposed to be the core rule in Debian: Packaging the preferred form
for editing.
You apparently work in the Rust team. If it works for you, then great -
I am not saying you should leave. But I am saying that I am torn
between wanting to collaborate and then having strong opinions myself
that arguably hinders collaboration.
I was preparing packaging of Ruma, but then saw a single package related
to that trickle into Debian, and I gave up on it: I would have packaged
a *collection* of packages together, because that is clearly how
upstream "preferred form for editing is for that codebase. But that
conflicts with the Rust team style of packaging. *SIGH*
I think a good step towards a better overview is to file ITPs. Also for
library-only crates, not only for applications.
> Sorry for a bit of an rant and the wall of text,
Thanks a lot for all that you wrote, and thanks for your work on
packaging crates.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
Jonas Smedegaard
Apr 13, 2023, 1:20:05 PM4/13/23
to
Quoting matthias....@tutanota.de (2023-04-13 18:04:54)
> 13. Apr. 2023, 17:39 von jo...@jones.dk:
> the Rust Teams' policy.
[...]
> I will maintain the GTK stack within the rust team as ITP some more
> GTK-rs stuff. fwiw I continuously commented my progress here and in
> the debcargo-confs' TODO file.
Ok, so your avoiding Debbugs to track ITPs is deliberate.
I shall try to remember that, to not waste more time for both of us.
> 13. Apr. 2023, 17:39 von jo...@jones.dk:
> > Please consider using the Debian bugtracker to communicate "intents
> > to package" by filing an ITP bugreport for each single upstream
> > project that you work on packaging for Debian.
> >
> I won't do that for the rust crates (except binary ones) since that is
> > to package" by filing an ITP bugreport for each single upstream
> > project that you work on packaging for Debian.
> >
> the Rust Teams' policy.
[...]
> I will maintain the GTK stack within the rust team as ITP some more
> GTK-rs stuff. fwiw I continuously commented my progress here and in
> the debcargo-confs' TODO file.
Ok, so your avoiding Debbugs to track ITPs is deliberate.
I shall try to remember that, to not waste more time for both of us.
Jonas Smedegaard
Apr 13, 2023, 3:10:05 PM4/13/23
to
Quoting matthias....@tutanota.de (2023-04-13 19:28:16)
> 13. Apr. 2023, 19:18 von jo...@jones.dk:
I was referring to the packages you "have been constantly working on"
yet didn't appear in the header of this bug#900928.
> No one except you uses it to track rust library crates
[...]
> I really don't see the issue here.
Fine. I thought you saw an issue with recognition, and apologize for
having wasted your time with a collaboration practice that (according to
you) noone but me bothers doing.
Let's dial back to your original request before my ramblings:
> I wanted to discuss fractal. [...] I have been constantly working on
> [deps]. [...] I have been constantly working on [more deps], too.
> [...] Since I also put in some effort I also would like to be included
work in that package. Not in e.g. gnome-control-center or firefox
despite both of those other packages depend on gtk+3.0 and thus benefit
from your contribution there.
Similarly, that you "have been constantly working on" a shitload of
dependencies for fractal does not grant uploader right/recognition
for fractal. Not because you are any lesser than me nor because of how I
choose to create packages nor because I am not member of the Rust team,
but because it would not be fair to do so.
I welcome collaboration. Both indirect ones like packaging of needed
dependencies, and direct ones like patches to packaging.
I shall gladly acknowledge contributions, fairly.
> 13. Apr. 2023, 19:18 von jo...@jones.dk:
> > Quoting matthias....@tutanota.de (2023-04-13 18:04:54)
> >> I won't do that for the rust crates (except binary ones) since that
> >> is the Rust Teams' policy.
> > [...]
> >> I will maintain the GTK stack within the rust team as ITP some more
> >> GTK-rs stuff. fwiw I continuously commented my progress here and in
> >> the debcargo-confs' TODO file.
> >>
> >
> > Ok, so your avoiding Debbugs to track ITPs is deliberate.
> >
> No, I do use debugs to track ITPs
> >> is the Rust Teams' policy.
> > [...]
> >> I will maintain the GTK stack within the rust team as ITP some more
> >> GTK-rs stuff. fwiw I continuously commented my progress here and in
> >> the debcargo-confs' TODO file.
> >>
> >
> > Ok, so your avoiding Debbugs to track ITPs is deliberate.
> >
I was referring to the packages you "have been constantly working on"
yet didn't appear in the header of this bug#900928.
> No one except you uses it to track rust library crates
[...]
> I really don't see the issue here.
Fine. I thought you saw an issue with recognition, and apologize for
having wasted your time with a collaboration practice that (according to
you) noone but me bothers doing.
Let's dial back to your original request before my ramblings:
> I wanted to discuss fractal. [...] I have been constantly working on
> [deps]. [...] I have been constantly working on [more deps], too.
> [...] Since I also put in some effort I also would like to be included
> as uploader. I think this is fair since now 80% of the dependencies
> are covered.
When you work on, say, gtk+3.0, then you receive recognition for your
> are covered.
work in that package. Not in e.g. gnome-control-center or firefox
despite both of those other packages depend on gtk+3.0 and thus benefit
from your contribution there.
Similarly, that you "have been constantly working on" a shitload of
dependencies for fractal does not grant uploader right/recognition
for fractal. Not because you are any lesser than me nor because of how I
choose to create packages nor because I am not member of the Rust team,
but because it would not be fair to do so.
I welcome collaboration. Both indirect ones like packaging of needed
dependencies, and direct ones like patches to packaging.
I shall gladly acknowledge contributions, fairly.
Jonas Smedegaard
Oct 23, 2023, 12:53:06 AM10/23/23
to
Quoting Matthias Geiger (2023-10-22 23:55:18)
> While the ruma-stack is still a lot of crates to go through NEW, all are
> prepared. Meanwhile I uploaded rust-libshumate and rust-libadwaita to
> unstable.
Yes, I noticed. Thanks!
> I will upload the rest of the ruma crates once the one in NEW has been
> accepted.
Great! Thanks for all your work in this,
> While the ruma-stack is still a lot of crates to go through NEW, all are
> prepared. Meanwhile I uploaded rust-libshumate and rust-libadwaita to
> unstable.
Yes, I noticed. Thanks!
> I will upload the rest of the ruma crates once the one in NEW has been
> accepted.
Great! Thanks for all your work in this,
0 new messages