- Package:
- wnpp
- Source:
- wnpp
- Submitter:
- nodiscc
- Date:
- 2026-06-22 10:49:01 UTC
- Severity:
- wishlist
- Blocked By:
-
Bug Title 984864 2
rust-reqwest: depends on multiple unavailable packages grave about 4 years ago
987324 7
rust-hashbrown: missing ahash feature makes building hashlink crate impossible normal stable about 4 years ago
1006533 2
ITP: libshumate -- libshumate is a C library providing a GtkWidget to display maps wishlist almost 4 years ago
* 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.
Hi! Is there any progress on the packaging of fractal in Debian? Any blockers or missing crates? Thanks!
@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) 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: 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
On 2022-04-12 12:23:07, Jonas Smedegaard wrote: [...] I'd be happy to do some testing, thanks for taking this on!
[ dropping Andrej from cc ] Quoting Antoine Beaupré (2022-04-12 15:07:03) Great! 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: 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
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) Now reduced to needing 370 crates embedded. A few more should be 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. - Jonas
Hi, 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 🙂 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.
Hi Andrej, Quoting Andrej Shadura (2022-04-12 19:02:11) Good to hear from you - and enjoy those other things keeping you busy! :-) - Jonas
Needs embedding 247 crates (16 from git snapshot); Builds in ~40 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
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 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
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 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
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 - Jonas
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 - Jonas
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)
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
I packaged all gtk releated deps on my local branch (except ashpd and oo7). This is a huge chunk out of the missing crates. comrak is apparently not needed anymore for fractal. this leaves some minor crates and matrix-sdk/ruma . I will continue to work towards the remaining deps. CC jonas: I strongly suggest maintaining fractal within the GNOME team since it's a Circle App. regards, --- Matthias Geiger (werdahias)
Hi Jonas, 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. 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. 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. 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) Sorry for a bit of an rant and the wall of text, I hope this clears things up. regards, --- Matthias Geiger (werdahias)
Hi Matthias, [quoting previous private post to help establish context] Quoting matthias.geiger1024@tutanota.de (2023-03-14 11:39:30) Quoting matthias.geiger1024@tutanota.de (2023-04-13 14:57:41) 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. 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. 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. 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. Thanks a lot for all that you wrote, and thanks for your work on packaging crates. - Jonas
13. Apr. 2023, 17:39 von jonas@jones.dk: thanks. that's what I hoped to avoid. I won't do that for the rust crates (except binary ones) since that is the Rust Teams' policy. You choose not to do so. While I agree that a big monorepo is not ideal the updating process is way more streamlined and that much crates can't all be maintained each in a seperate repo. That'd be madness. they use a pretty standardized workflow (DEP 14). just a thought. well it's always teamwork I guess; I can claim the GTK update as my efforts. No. This is (while indirectly caused by me) not an issue imo, rather ftpmasters insisting the GTK-rs code generator needs to be shipped. (Note that this was fine before for some time) See the linked thread on the bug. Agreed. See above. 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. Regards, Matthias Geiger
Quoting matthias.geiger1024@tutanota.de (2023-04-13 18:04:54) [...] 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
13. Apr. 2023, 19:18 von jonas@jones.dk: No, I do use debugs to track ITPs (like this one, see comments above on my progress). No one except you uses it to track rust library crates because the policy of the rust team states that. And I think most maintainers have better use of their little time to file 20+ ITPs for rust crates. ftpmasters are also ok with that, so I really don't see the issue here. And updating stacks with 60+ crates like GTK is way easier if it all is in one repo. I hoped to avoid this can of worms exactly because of that. regards,--- Matthias Geiger (werdahias)
Quoting matthias.geiger1024@tutanota.de (2023-04-13 19:28:16) I was referring to the packages you "have been constantly working on" yet didn't appear in the header of this bug#900928. [...] 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: Quoting matthias.geiger1024@tutanota.de (2023-03-14 11:39:30) When you work on, say, gtk+3.0, then you receive recognition for your 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
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. I will upload the rest of the ruma crates once the one in NEW has been accepted.
Quoting Matthias Geiger (2023-10-22 23:55:18) Yes, I noticed. Thanks! Great! Thanks for all your work in this, - Jonas
On Mon, 23 Oct 2023 06:36:00 +0200 Jonas Smedegaard <jonas@jones.dk> wrote: > 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, > > - Jonas Running cargo debstatus on the 5.x tree yields: NEW packages that need packaging from scratch: - html5gum - rqrr - html2pango - htmlescape
Are there already patches that work with Fractal7? https://gitlab.gnome.org/World/fractal/-/tags These no longer work with Fractal7. They still worked with 6. https://salsa.debian.org/matrix-team/fractal/-/tree/debian/latest/debian/patches /hsp
Quoting Holger Schröder (2024-05-05 08:52:55) Fractal is written in aggressively modern rust. Newest releases of Fractal requires a newer version of rustc than packaged in Debian, and consequently those releases cannot be packaged for Debian. I have attempted to backport some code patterns to work with older rustc, but I cannot keep up, and I find it extremely difficult to locate online examples of backporting patterns, since more commonly the focus is on modernizing rather than stabilizing. Help patching code that fails to build with rustc in Debian (currently 1.70) is much welcome. If anyone steps up to help with that but need concrete code patterns that currently fail, please tell me, and I will try extend by routines to identify and list such patterns (instead of only noting such patterns locally as I do now since it is less effort). Mvh. Jonas
Am 05.05.24 um 11:41 schrieb Jonas Smedegaard: Then I'll probably have to install the flatpac which I don't really like... too bad https://flathub.org/apps/org.gnome.Fractal
Quoting Holger Schröder (2024-05-05 14:01:21) https://wiki.debian.org/Matrix You might "prefer", depending on various criteria, but those are irrelevant here, so please refrain from further elaborating on your reasons for concluding that in your view you "have to" do something. - Jonas
Woah, why so aggressive? What is wrong with saying something like "I will have to look for other ways of installing it, in order to use the software, as the method I was hoping for is not available"? Yes, it might be irrelevant for you when people tell you that they cannot help, but I don't think that this is a very nice response to when someone politely says that they cannot help and will look for alternatives. Not everyone is capable of solving every bug. We all know that there's a lot of hard work required in packaging software, but that is not a good reason to get snappy. I bet more people would work on free software if the communication was more polite. And I might as well argue that your unfriendly 'You might "prefer"' and telling someone that their polite response is "irrelevant here" might be in itself an irrelevant response, don't you think? *rolls eyes* Best Regards
Quoting erebion (2024-05-05 15:27:32) words may have caused. What I find wrong is the "have to [...] use [this particular] software". I am not upset about imposing such contraint, and (and stated above) didn't mean to upset anyone by pointing out the constraint either. What I wanted to do was bring attention to alternatives closer to Debian than the use of flatpack. And then immediately after providing such suggestion I wanted to make it clear that I am not inviting further discussion here, regardless if about shifting packaging format or about shifting application. I will not dive into the vast areas of what I don't think. (hint: asking negative questions is passive agressive) Regardless of your tone, I do appreciate your pointing out how my tone can be perceived negatively. Thanks for that. - Jonas
On Sun, 26 Nov 2023 11:34:28 +0100 Matthias Geiger <werdahias@riseup.net> wrote: > Running cargo debstatus on the 5.x tree yields: > > NEW packages that need packaging from scratch: > > > - html5gum > > - rqrr > > - html2pango > > - htmlescape > > -geo-uri > > - djb_hash > > - eyeball-im > > Once the ruma stack is in debian I'll update it to the latest release; > then packaging fractal should be trivial. > Well still didn't have time for ruma (I hope to finish this in August). Good news: sourceview5 just was accepted from NEW. This means all GTK-related deps are present and up to date. This leaves ruma plus some other crates (haven't checked). I'll file a leaf ITP for ruma soon™. best, werdahias
Liebe(r) Preis-Gewinner/in Ich freue mich, Ihnen mitzuteilen, dass Sie unsere 2025 Worldbank / Google Email Lotto Gewinner vom 08.04.2025 sind! Ihre Email Adresse mit der Kartenseriennummer 1340890 hat in der dritten Kategorie gewonnen. Gewinnzahlen : 06-15-27-39-44 + 03,11 Sie haben einen Betrag in Höhe von EUR 1.915.810,00 (Eine Million Neun hundert Fünfzehn Tausend acht hundert zehn Euro) gewonnen! Für Ihren Gewinnanspruch,schicken Sie bitte die folgenden angaben per mail [ judith.newmann@tutamail.com ] an Frau Judith Newmann: Gewinnzahlen : 06-15-27-39-44 + 03,11 Name........................ Beruf....................... Alter....................... Land........................ Kontaktadresse............. Telefon / Handynummer...... Faxnummer.................. Geschlecht................... Familienstand................. Herzlichen Glückwunsch!!! Mit freundlichen Grüßen Amanda Princeton WorldBank Email Award Programme Tooting SW17 0QT - United Kingdom
Release 13 succesfully builds as an unofficial draft package, when embedding 62 crates (45 missing, 17 outdated) which needs to be packaged before this can officially enter Debian. The built binary runs and works fine. Main task now is to package the remaining missing Rust crates. Here's how you can help: As user running Debian, you can test this draft package: Either build it yourself from source, or if you want to test the binary that I've built then tell by posting to this bugreport and I will share that. As developer (any developer: you need not 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
Snapshot 13+20251208 succesfully builds as an unofficial draft package, when embedding 46 crates (34 missing, 12 outdated) which needs to be packaged before this can officially enter Debian. The built binary runs and works fine. Main task now is to package the remaining missing Rust crates. Here's how you can help: As user running Debian, you can test this draft package: Either build it yourself from source, or if you want to test the binary that I've built then tell by posting to this bugreport and I will share that. As developer (any developer: you need not 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
Snapshot 14+20260613 succesfully builds as an unofficial draft package, when embedding 40 crates (31 missing, 1 incomplete, 8 outdated) which needs to be packaged before this can officially enter Debian. The built binary runs and works fine. Main task now is to package the remaining missing Rust crates. Here's how you can help: As user running Debian, you can test this draft package: Either build it yourself from source, or if you want to test the binary that I've built then tell by posting to this bugreport and I will share that. As developer (any developer: you need not 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