Re: New releases for bugfixes
I'm sad other emails sound kinda harsh and without detailed elaboration. Folks, please, let's keep the discussion peaceful. Different people have different set of knowledge, that's life. Angry comments would push people away from the community. On Thu, 2022-09-08 at 19:23 -0230, samuel ammonius wrote: > > and you marry upstream binaries with the distribution update-manager how? > > You don't need to. The app can just check the latest bugfix for that version > on git > and install it if it isn't installed. I don't understand why you stress the > need for the > package manager to have anything to do with the update if it's just a bug fix. You see: when you have versioning of the same file managed by two or more programs, you will inevitably get into conflicts. One program updated the file to one version, then another program overwrote the file with something else. I think it is clear that this will result in all kinds of problems. The obvious one is that your bugfix-update may get overwritten by something else. And this is exactly what you suggest. You suggest we have program update itself, disregarding the package manager. That's not gonna end well. Then there's another problem: tracking of the files. If your "autoupdater" put a new file to the system, and later the user decides "I'm not using the app, let's just remove it", the file would just be left there. Because only package manager knows what files contains the program, but your autoupdater didn't communicate that new file to the package manager. So, as the number of such apps grows bigger, you would have junk all over the system. On a related note, you as a user or developer often want to know where a file on your syste came from. At my $WORK we bulid a system with some proprietary apps, it's a very old project, and the building process for quite some time would just put configs/binaries/stuff into the system, without consulting package manager. While this didn't result in conflicts since the filenames were mostly unique, however this did have a problem, where you often just don't know where a given file came from. You can't run a package manager, point it to the file, and ask it "do you know who owns this file?". We later migrated to creating packages that hold all of that stuff, which greatly simplified things.
[Important] changes to our Matrix homeserver
Hi We are moving to use our SSO (gitlab) for authentication to the KDE Matrix homeserver To be able to retain access to your matrix account you need to ensure on the matrix side that you have set in your account the email address matching that in KDEgitlab On https://webchat.kde.org/ you can access your settings in the bottom left hand corner ⚙ then as shown in the screenshot Please do this as soon as you can Thanks -- Kenny (Pronouns: he/him)
Re: [Important] changes to our Matrix homeserver
I tried adding the matching email address but Matrix says that this is not an authorized email address on the server. What should I do in this case if I want my email addresses to match on invent and matrix? On September 8, 2022 at 10:24:45 AM, Kenny Duffus (ke...@kde.org) wrote: Hi We are moving to use our SSO (gitlab) for authentication to the KDE Matrix homeserver To be able to retain access to your matrix account you need to ensure on the matrix side that you have set in your account the email address matching that in KDEgitlab On https://webchat.kde.org/ you can access your settings in the bottom left hand corner ⚙ then as shown in the screenshot Please do this as soon as you can Thanks -- Kenny (Pronouns: he/him)
Re: [Important] changes to our Matrix homeserver
On Thursday, 8 September 2022 15:35:26 BST Andy B wrote: > I tried adding the matching email address but Matrix says that this is not > an authorized email address on the server. What should I do in this case if > I want my email addresses to match on invent and matrix? > Hi Unfortunately that error was due to a config setting, you should now be able to set any email address -- Kenny (Pronouns: he/him)
Re: [Important] changes to our Matrix homeserver
Thank you Kenny. It worked this time. On September 8, 2022 at 10:55:06 AM, Kenny Duffus (ke...@kde.org) wrote: On Thursday, 8 September 2022 15:35:26 BST Andy B wrote: > I tried adding the matching email address but Matrix says that this is not > an authorized email address on the server. What should I do in this case if > I want my email addresses to match on invent and matrix? > Hi Unfortunately that error was due to a config setting, you should now be able to set any email address -- Kenny (Pronouns: he/him)
Re: New releases for bugfixes
On Thu, Sep 8, 2022 at 12:51 PM samuel ammonius wrote: > Bug fixes don't change the entire package, only the executable, so > why can't apps just be programmed to update themselves? There > could be precompiled binaries stored on the git repos of each project > for a few CPU architectures, or maybe the app could even recompile > itself inside /tmp since most systems KDE runs on come with a compiler > by default (and macros could also be stored so that apps have the > same configuration throughout updates). > That depends entirely on whether the fix was in the executable or a library that it links to. If a library we can't be updating libraries willy nilly on user devices. Plus think about how it was built, which use flags in gentoo, which compile flags, etc. Which distribution specific patches were applied. Once you take all that into account there are many many ways to build kde applications. > > Cheers, > Sam > > On Thu, Sep 8, 2022 at 11:58 AM Heiko Becker wrote: > >> On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote: >> > From the git-archive manual page: >> > >> > «git archive behaves differently when given a tree ID versus >> > when given a commit ID or tag ID. In the first case the current >> > time is used as the modification time of each file in the >> > archive. In the latter case the commit time as recorded in the >> > referenced commit object is used instead. Additionally the >> > commit ID is stored in a global extended pax header if the tar >> > format is used; it can be extracted using git get-tar-commit-id. >> > In ZIP files it is stored as a file comment.» >> >> Before anybody tries that *now*, at least for Gear the tarballs are >> currently created with git archive --remote=kde:$repo $branch .. >> So they currently won't have that information. >> >> Regards, >> Heiko >> >>
Re: New releases for bugfixes
Thanks. I hadn't thought of a lot of these issues before. I think the biggest one is that If there's an update that the package manager didn't know about, the user would have to update right after installing, and the bug would come back if the user re-installed or updated the app. Sorry everybody.
