tde-devs@chat.jabb.im < 2021/06/28 >
[01:34]michelec2 has joined
[01:35]michelec2: @Blu.256: thanks
[01:36]michelec2: the tde-bot is great!!
[02:14]michelec2 has left
[07:37]blu.256: Going to be offline for a while, see you!
[07:37]blu.256 has left
[07:37]michelec2 has joined
[07:46]michelec2: I will start the migration of twin-suse2 repo to TDE
[07:46]michelec2: in a few minutes
[08:39]michelec2: While migrating tde-style-suse2, I noticed in the control file in debian the source pacakge is called twin-decor-suse2. More research seems to indicate that twin-decor-suse2 is more appropriate that twin-style-suse2
[08:39]michelec2: what do you think?
[08:40]michelec2: the repo is not yet a submodule of TDE, so we could easily rename it
[08:41]Slávek: Somewhat it departs from the naming of other twin-styles.
[08:42]michelec2: yes, true. how about twin-style-decor-suse2 then?
[08:43]Slávek: For some tde-style-* packages you can notice that there is both - style for widgets and decorations for windows.
[08:44]Slávek: It is true that as a separate package is currently just twin-style-crystal.
[08:44]michelec2: I will be away for 30 minutes. let's discuss later and choose a name
[08:44]Slávek: ok, no problem.
[09:08]michelec2: I am back
[09:08]michelec2: should we name it tde-style-decor-suse2?
[09:08]Slávek: I tried looking for a little bit and seemed that, although in Control Center it is called Windows decoration, most other information uses naming Kwin Styles.
[09:08]michelec2: similar to baghira, domino, lipstick
[09:09]michelec2: debian control file also use twin-decor-suse2
[09:10]Slávek: One thing is that currently here is only one twin-style-crystal package, so it would be a small problem rename it to twin-decor-crystal...
[09:11]Slávek: The second problem is not to bring confusion when users are searching for information and other styles / decorations?
[09:11]Slávek: For example, how are styles / window decorations named on OpenDesktop?
[09:12]michelec2: crystal can remain unchanged
[09:12]michelec2: is only the new style
[09:12]michelec2: osrry, dinner time :-(
[09:13]Slávek: If we add new packages twin-decore-..., then it would be strange to leave twin-style-crystal unchanged.
[09:15]Slávek: On trinity-look.org is category named KDE 3.x Window Decorations, twin-decor-... seems good idea.
[10:06]michelec2: twin-decor-suse provides both window and color scheme
[10:07]michelec2: so maybe an appropriate name would be tde-style-decor-suse2
[10:07]michelec2: this is consistent with the name of the other modules
[10:07]michelec2: and we coumd make a rule that any tde theme is called tde-style-*
[10:08]michelec2: of course, twin-style-crystal will need to be renamed
[10:08]michelec2: what do you think?
[10:09]Slávek: Giving into a package name at the same time style and decor seems to me too combined.
[10:10]michelec2: "style" is to have a general naming convention for all style packages.
[10:10]michelec2: meaning that package is a "tde style" package called "decor suse2"
[10:12]Slávek: At first glance for me, the use of "decor" seems unnecessary.
[10:14]Slávek: For example, tde-style-domino contains everything - style for widgets, window decoration, color scheme.
[10:14]michelec2: so what name do you suggest?
[10:15]michelec2: keep twin-style-suse2?
[10:16]Slávek: We could consider tdde-style-suse2 when there are two of the three style components - window decoration and color scheme.
[10:17]Slávek: BTW, now I noticed - SUSE2.kcsrc is also file in desktop style => should be added into desktop files translations.
[10:18]michelec2: tde-style-suse2 sounds good (y)
[10:19]michelec2: will resume migration later tonight, now I am busy with the kids for a while
[10:19]michelec2: so will change to tde-style-suse2 if no other comments
[10:20]Slávek: OK, we'll see how Phillipe is the opinion.
[10:51]cethyel has joined
[10:57]cethyel: Slávek, Do you have a packaging git repo for the extra packages you provide or is It only a download repo with the source files and the binary packages?
[10:59]Slávek: You can find TDE/extra-dependencies repository, where are sources for these extra build dependencies.
[10:59]tde-bot: Page Not Found - TDE Gitea Workspace
https://mirror.git.trinitydesktop.org/gitea/TDE/extra-dependencies/commit/repository
[11:02]cethyel: I'm not interested in the sources of the extra packages themselves but their Debian packaging, I'd like to see Rules and Control files
[11:03]Slávek: For these packages, Debian packaging files is a part of this repository.
[11:04]Slávek: For example:
https://mirror.git.trinitydesktop.org/gitea/TDE/extra-dependencies/src/branch/master/debian/pilot-link/pilot-link-0.12.5-dfsg/debian
[11:05]cethyel: Iah I can reach the extra-dependencies now
[11:17]cethyel has left
[11:31]michelec2: @Greg: you can also just used pre built packages for extra deps, without having to worry about building them
[11:31]cethyel has joined
[11:36]cethyel: @Michele, I didn't want to compile them but to have a look on them. Yesterday I tried to add patches for glib-1.2 in order to submit It as an extra-dependency for later use (xmms/tdenetwork/kopete) but It was more difficult than anticipated. All that Deb packaging stuff relies on very specific tools for that purpose, furthermore It is a quite long and rather boring process
[11:37]michelec2: ok, understood
[11:40]cethyel: the patches i have for glib/gtk/xmms don't apply clean because Debian have also patched those but I don't get It since the format in use is outdated from what I see right now, so I wanted to start anew with a simple Rules file, the original source, etc
[11:43]cethyel: well let's be back on kopete/kopete-otr for today then tqt3 later this week and keep the Deb stuf/mess for the week-end....
[11:52]michelec2: debian uses quilt to apply patches
[11:53]michelec2: so if you need to add a patch in extra deps, you would need to do it as a quilt patch
[12:03]cethyel: yes, i saw that, but as I said Debian have already patched the original sources and my patches don't apply clean furthermore It is an outdated packaging (without the patches folder without the "series" file) so all that Deb packaging is a mess for me now, furthermore I know I'm rather slow but I'll get It eventually...hopefully :-/
[12:06]michelec2: perhaps we can help out with the patching, if you need
[12:09]cethyel: the station froze, had to restart, probably due to the RAID0 on the disks
[12:11]cethyel: @Michele, you're busy enough, but out of curiosity here where i put my stuff https://mirror.git.trinitydesktop.org/gitea/cethyel/deb-stuff.git
[12:15]michelec2: yeah, I saw that repo yesterday
[12:16]michelec2: if you need some help on a specific patch, please let me know and I will see to make some time for it in coming days
[12:18]cethyel: well i'll be back on It for a week-end, I'd like to bring kopete-otr in kopete before you move the folder's layout and I'd like to try something in tqt3, all these extras are...extras :) but Thanks for the help :yes:
[12:23]cethyel has left
[12:28]cethyel has joined
[12:52]michelec2: (y) you are welcome GReg
[12:53]blu.256 has joined
[12:55]Slávek: Blu.256, there was a discussion about the name of the package / repository where your opinion is welcome - see log:
http://www.trinitydesktop.org/irc/logs/tde-devs%40chat.jabb.im/2021/06/28/#10
[12:55]tde-bot: Page Not Found - TDE Gitea Workspace
https://mirror.git.trinitydesktop.org/gitea/28//issues/10
[12:55]blu.256: Yes I saw it
[12:56]blu.256: I do agree with this logic, even though to be frank I don't consider a color scheme to be of the same importance as a style or a window deco.
[12:57]blu.256: But that's just me ;)
[12:59]blu.256 has left
[13:12]michelec2: so tde-style-suse2? or twin-style-suse2? or tde-decor-suse2? or others?
[13:12]michelec2: the current name in debian stuff is twin-decor-suse2-trinity
[13:14]michelec2: the module now belongs to TDE but is not yet officially in TDE hierarchy, so renaming at this stage is still easy
[13:16]Slávek: For me, there is no problem with the original twin-style-suse2. If the change I'd choose tde-style-suse2.
[13:17]Slávek: Instead of tde-decor-... would be a more concise twin-decor-...
[13:34]michelec2: ok, we can keep twin-style-suse2 then. less work to do and similar to twin-style-crystal
[13:35]michelec2: will change the package name in control file to match accordingly
[13:37]michelec2: I will probably complete the migration tomorrow morning though, since tonight I am busy with other things
[13:38]Slávek: Ok. I have some adjustments related to CMakeL10n rules. I should wait for complete integration to TDE umbrella, prepare PR, or push now?
[13:39]cethyel: guys, when you're compiling do you get this warning? failed to remove resource: ELF resource section not found
[13:41]Slávek: Yes, I believe it is due to the fact that the tdelfeditor call first trying to delete the original section before adding new.
[13:44]cethyel: it says that the warning is harmless, nonetheless I wouldn't mind not reading It :-/
[13:56]michelec2: @Slavek: feel free to push now
[13:56]michelec2: no need to wait for migration to be completed
[13:57]michelec2: @Greg: yes, same warning. Maybe we could look at ways to improve the use of tdelfeditor and only delete a section if it already exists
[13:59]michelec2: @everyone: if you fix or add something worth to mention on release notes, please edit this issue
https://mirror.git.trinitydesktop.org/gitea/TDE/tde/issues/51
[13:59]michelec2: or in case you can't edit, let me/Slavek know here and we can edit
[14:03]cethyel: you're the owner so I can't edit It (nothing to add for the moment)
[14:06]Slávek: Of course, it is also possible to add the comments on this issue.
[14:07]cethyel: yes
[14:14]michelec2: the idea is to try to keep that up to date as we work through a release cycle, so at the end of that it will be easier to prepare the real release notes.
[14:17]cethyel: yes i can add comments, in the end you will sum up everything
[14:19]cethyel: Slávek, I didn't add automake support https://mirror.git.trinitydesktop.org/gitea/TDE/tdenetwork/pulls/35 I hope you don't want It
[14:19]cethyel: wip btw
[14:20]Slávek: Yes, adding automake support in core modules is not needed.
[14:20]cethyel: \m/
[14:21]Slávek: BTW, for kopete-otr I encountered a problem when building with Clang.
[14:21]cethyel: what kind?
[14:24]Slávek: /usr/local/include/tqt3/ntqvaluelist.h:62:37: error: array initializer must be an initializer list
TQValueListNode( const T& t ) : data( t ) { }
^
/usr/local/include/tqt3/ntqvaluelist.h:284:21: note: in instantiation of member function 'TQValueListNode<TQString [5]>::TQValueListNode' requested here
NodePtr p = new Node( x );
^
/usr/local/include/tqt3/ntqvaluelist.h:543:58: note: in instantiation of member function 'TQValueListPrivate<TQString [5]>::insert' requested here
iterator append( const T& x ) { detach(); return sh->insert( end(), x ); }
^
/usr/local/include/tqt3/ntqvaluelist.h:504:2: note: in instantiation of member function 'TQValueList<TQString [5]>::append' requested here
append( x );
^
../src/otrlconfinterface.cpp:133:9: note: in instantiation of member function 'TQValueList<TQString [5]>::operator<<' requested here
list << entry;
^
1 error generated.
[14:29]cethyel: oh my gosh, you got the kind that sucks! ;-)
[14:30]Slávek: I tried to add a kopete-otr port on FreeBSD...
[14:32]michelec2: TQString [5] in "TQValueListNode<TQString [5]>::TQValueListNode" rings a bell. probably a conversion to generic TQString is required in one of the calls.
[14:32]cethyel: yeah i get the same FTBFS with clang-10 (Ubuntu-20.04)
[14:32]michelec2: although it sounds weird, given the code of the contructor called
[14:33]michelec2: I remember seeing something like this some times in the past. That NoePtr is not new to me :-)
[14:33]michelec2: jsut I don't recall where it was
[15:00]cethyel: i'm logging out, see you guys later!
[15:00]cethyel has left
[15:42]michelec2: going off as well
[15:42]michelec2: talk to you tomorrow guys
[15:42]michelec2 has left
[17:02]Slávek has left
[17:07]Slávek has joined
[18:01]cethyel has joined
[18:01]cethyel: @kopete-otr, does the plugin crash with an automake build?
[18:07]Slávek: For the time being, he did not test plugin built with automake.
[18:07]Slávek: * I did not test
[18:08]Slávek: I wanted to avoid another crash :)
[18:09]Slávek: In any case, according to the first view of the backtrace it looks like a crash in kopete, not directly in OTR plugin.
[18:11]cethyel: what did you do for testing? I tickled the otr plugin a gui showed up but I didn't push further.
[18:12]Slávek: I just turned on checkbox to enable plugin and click to Apply.
[18:13]cethyel: i didn't get a crash for this :-[
[18:15]cethyel: I assume you've been using PTB
[18:16]Slávek: Hmm, after installation of the previous version - built with automake, there enabling plugin does not cause crash.
[18:16]Slávek: PSB.
[18:17]cethyel: I did test and make the conversion on my Slackware station (which runs Ubuntu since Saturday)
[18:17]Slávek: Interestingly, when I enabled the plugin, there are some blank characters at the end of each message.
[18:18]Slávek: When I turned plugin off, blank characters are gone again.
[18:20]cethyel: with the automake build as well?
[18:21]cethyel: might be related to symbols visibility
[18:21]Slávek: This was with automake build of plugin - it could be turned on, but it caused blank characters at the end of each message.
[18:22]Slávek: Note: Automake build of plugin is version R14.0.10 == without additional patches.
[18:24]cethyel: I'll start the station, to experience that crash...
[18:24]cethyel has left
[18:29]cethyel has joined
[18:30]cethyel has left
[18:30]cethyel has joined
[18:31]cethyel: yes a wonderful crash :|
[18:31]cethyel: I did not experience this on my Slackware station
[18:35]Slávek: On Slackware, you built with enabled hidden visibility?
[18:38]cethyel: I can't remember, but in the pasts in some cmake conversion it happened that the compiling went fine but once the apps was running It crashed, each time a plugin with the symbols visibility
[18:43]cethyel: I've rebuilt with automake, no crash
[18:43]Slávek: with automake without hidden visibility?
[18:44]cethyel: default config, i just passed --prefix=/opt/trinity
[18:45]cethyel: yeah, should i swich ON/OFF the plugin, no crash
[18:47]cethyel: there is no symbols visibility in the configure options
[18:53]cethyel: I've rebuilt with cmake symbols visibility OFF, no crash
[19:02]cethyel: I'm going, see you later.
[19:02]cethyel has left
[19:25]blu.256 has joined
[19:59]Slávek has left
[20:30]Slávek has joined
[20:39]Slávek has left
[20:48]Slávek has joined
[21:20]cethyel has joined
[21:20]cethyel has left

tde-devs@chat.jabb.im < 2021/06/28 >