Bug#961897: marked as done (RFS: wifi-qr/0.1-1 [ITP] -- WiFi Share and Connect with QR)
Your message dated Sun, 31 May 2020 10:35:22 +0630 with message-id and subject line Fwd: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR has caused the Debian Bug report #961897, regarding RFS: wifi-qr/0.1-1 [ITP] -- WiFi Share and Connect with QR to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 961897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961897 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "wifi-qr" * Package name: wifi-qr Version : 0.1-1 Upstream Author : kokoye2007 * URL : https://github.com/kokoye2007/wifi-qr * License : GPL-2.0+ * Vcs : https://github.com/kokoye2007/wifi-qr Section : utils It builds those binary packages: wifi-qr - WiFi Share and Connect with QR PC to Android Network SSID Password share with QR code. Idea from Xiaomi Android WiFi Password share with QR Its just bash script and qrencode only. now support also QR Scan with connect to WIFI. Make to easy and happy. PC to Android Network SSID Password share with QR code. Idea from Xiaomi Android WiFi Password share with QR Its just bash script and qrencode only. now support also QR Scan with connect to WIFI. Make to easy and happy. OPTIONS wifi-qr option gGUI Main Menu cWiFi QR Create GUI tWiFi QR Create Terminal sQR Scan and Auto Connect WiFi qQR Scan and Connect WiFi GUI vWiFi-QR Version is 0.1.1 ~ https://mentors.debian.net/package/wifi-qr Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wifi-qr_0.1-1.dsc Regards, --- End Message --- --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "wifi-qr" * Package name: wifi-qr Version : 0.1-1 Upstream Author : kokoye2007 * URL : https://github.com/kokoye2007/wifi-qr * License : GPL-3.0+ * Vcs : https://github.com/kokoye2007/wifi-qr Section : utils It builds those binary packages: wifi-qr - WiFi Share and Connect with QR PC to Android Network SSID Password share with QR code. Idea from Xiaomi Android WiFi Password share with QR Its just bash script and qrencode only. now support also QR Scan with connect to WIFI. Make to easy and happy. PC to Android Network SSID Password share with QR code. Idea from Xiaomi Android WiFi Password share with QR Its just bash script and qrencode only. now support also QR Scan with connect to WIFI. Make to easy and happy. OPTIONS wifi-qr option gGUI Main Menu cWiFi QR Create GUI tWiFi QR Create Terminal sQR Scan and Auto Connect WiFi qQR Scan and Connect WiFi GUI To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wifi-qr Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.1-1.dsc Changes since the last upload: * Initial packaging (Closes: #961897). Regards, -- with regards *Ko Ko Ye`* +95 97989 22022 +95 94500 22022 kokoye2...@gmail.com kokoye2...@ubuntu.com skype: kokoye2007 jitsi: kokoye2007 http://ubuntu-mm.net http://wiki.ubuntu.com/kokoye2007 http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm --- End Message ---
Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "wifi-qr" * Package name: wifi-qr Version : 0.1-1 Upstream Author : kokoye2007 * URL : https://github.com/kokoye2007/wifi-qr * License : GPL-3.0+ * Vcs : https://github.com/kokoye2007/wifi-qr Section : utils It builds those binary packages: wifi-qr - WiFi Share and Connect with QR PC to Android Network SSID Password share with QR code. Idea from Xiaomi Android WiFi Password share with QR Its just bash script and qrencode only. now support also QR Scan with connect to WIFI. Make to easy and happy. PC to Android Network SSID Password share with QR code. Idea from Xiaomi Android WiFi Password share with QR Its just bash script and qrencode only. now support also QR Scan with connect to WIFI. Make to easy and happy. OPTIONS wifi-qr option gGUI Main Menu cWiFi QR Create GUI tWiFi QR Create Terminal sQR Scan and Auto Connect WiFi qQR Scan and Connect WiFi GUI To access further information about this package, please visit the following URL: https://mentors.debian.net/package/wifi-qr Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.1-1.dsc Changes since the last upload: * Initial packaging (Closes: #961897). Regards,
Bug#961897: RFS: wifi-qr/0.1-1 [ITP] -- WiFi Share and Connect with QR
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "wifi-qr" * Package name: wifi-qr Version : 0.1-1 Upstream Author : kokoye2007 * URL : https://github.com/kokoye2007/wifi-qr * License : GPL-2.0+ * Vcs : https://github.com/kokoye2007/wifi-qr Section : utils It builds those binary packages: wifi-qr - WiFi Share and Connect with QR PC to Android Network SSID Password share with QR code. Idea from Xiaomi Android WiFi Password share with QR Its just bash script and qrencode only. now support also QR Scan with connect to WIFI. Make to easy and happy. PC to Android Network SSID Password share with QR code. Idea from Xiaomi Android WiFi Password share with QR Its just bash script and qrencode only. now support also QR Scan with connect to WIFI. Make to easy and happy. OPTIONS wifi-qr option gGUI Main Menu cWiFi QR Create GUI tWiFi QR Create Terminal sQR Scan and Auto Connect WiFi qQR Scan and Connect WiFi GUI vWiFi-QR Version is 0.1.1 ~ https://mentors.debian.net/package/wifi-qr Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/w/wifi-qr_0.1-1.dsc Regards,
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/30/20 4:45 PM, Tobias Frost wrote: > On Sat, May 30, 2020 at 03:08:21PM +0200, Roland Plüss wrote: >> On 5/30/20 2:00 PM, Tobias Frost wrote: >>> * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll >>> know for >>> sure if it suitable… >>> >>> [1] https://tracker.debian.org/pkg/fox1.6 >>> >> I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7 >> . There had been API breaking changes in 1.7 . >> >> If this is a vital problem please tell me. It's not possible to remove >> fox1.7 requirement unless various parts of the package are not build >> (namely the basic crash recovery module, the gui launcher and the entire >> IGDE). > Yes, this gonna be a problem due to the Debian Policy about embedded code > copies [1]. > > I see those options: > - talk to the fox-1.6 maintainer about updating the package to 1.7. > (though I see that they generally stick to released versions and 1.7.* seems > to be only development snapshots; a question to ask: is the 1.7 ABI stable > already?) > - make the features optional that requires 1.7 > - use only 1.6 features (listed for completeness, as you said you can't) > > [1] > https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies > To be honest I don't know how stable the author thinks 1.7 is. I had no troubles with stability so far. The features can be made optional but then only the console-launcher is working. This would mean games can be played (from the console) but no gui-launcher can be used and no development environment can be used. To be honest I don't think such a stripped down version is useful except for one scenario: game server hosting. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961883: RFS: rumur/2020.05.27-1 -- model checker for the Murphi language
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rumur" * Package name: rumur Version : 2020.05.27-1 Upstream Author : Matthew Fernandez * URL : https://github.com/Smattr/rumur * License : Unlicense * Vcs : https://github.com/Smattr/rumur.git Section : devel It builds those binary packages: rumur - model checker for the Murphi language To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rumur Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rumur/rumur_2020.05.27-1.dsc Changes since the last upload: * New upstream release. Regards, Matthew
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/30/20 2:00 PM, Tobias Frost wrote: > * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll > know for > sure if it suitable… > > [1] https://tracker.debian.org/pkg/fox1.6 > I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7 . There had been API breaking changes in 1.7 . If this is a vital problem please tell me. It's not possible to remove fox1.7 requirement unless various parts of the package are not build (namely the basic crash recovery module, the gui launcher and the entire IGDE). -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/30/20 11:04 AM, Tobias Frost wrote: > On Sat, May 30, 2020 at 02:38:09AM +0200, Roland Plüss wrote: >> On 5/29/20 10:07 PM, Tobias Frost wrote: >>> On Fri, May 29, 2020 at 12:32:42PM +0200, Roland Plüss wrote: >>> I'm a bit cautious to allow installing games into the user home directory. Game files can quickly grow large (up to GB of data). One reason why I opted for /opt in the first place. >>> Speaking of games, are there free (FOSS) games available? A quick Internet >>> research yielded no results, so I'd appreciate if you could provide >>> pointers. >>> >>> Thanks! >>> >> Not yet. The engine has been released public for the first time >> recently. Available right now are example projects including >> ready-to-run delgas: https://github.com/LordOfDragons/deexamples . The >> engine can be used for both FOSS and commercial alike without troubles. >> To makes games though you need the engine in the first place. It's sort >> of chicken/egg problem here. > Ok, thanks for being honest. (I guess the "GB of game data" is nothing to be > concerned right now and when it becomes a thing you can always extend your > programm to look in more than one location or the games provide some launcher > script. (To be clear, this does not change anything about /opt being > unsuitable.) > > But there is now another chicken-egg problem: In Debian we don't try to > package > every piece of software; e.g it should have have already some relevnace, > users, > games, etc… Please don't think that being in Debian will boost the > userbase significantly. > > We have already plenty other game engines in the archives, so maybe elaborate > a bit what makes yours special over the others? > > One plus I immediatly see is that there are free examples (they should be part > of the package!) and seems to work well with a FLOSS toolchain only. (at least > I have the impression it does). But on the other side, it has yet to proof in > real games that it fit enough for them. > > One the minus side I see that you are alone on the project and despite the > project being quite old (I see featurelists dated 2014) it seems not to have > gained traction. Hinted by the absence of games and contributions to your > project, so I fear that the project is missing relevance. > > I write above not to discourage you, I just want to be frank with you that I'm > not sure that the software is ready for Debian. I want to avoid that you put > significant work into the packagaging just to find it rejected later. > > On the other hand, fixing the issues mentioned can also improving the > quality of your project. > > The videos you have published have kind of impressed me, but _disclaimer_ I'm > not a game developer ;-). > The reason for this is quite simple. I did not wanted to go down the "release early, release crap, become a mess" route so I did not release the source base to the public until recently. The entire design philosophy and workflows are different than other engines so getting the workflows working solid and fast had been important. This required especially waiting with a release until the various parts reached the goal level so changes and additions do not break things left and right (looking at source engine here in particular). Games typically compile engines into the file project or at least link hard-link against engine versions. This creates maintenance costs, tends to break with OS/Platform updates and requires rebuilding/repadistributing for different platforms. This engine fully separates the engine from the project. You do not link against the engine in any way. Delgas are thus truly cross platform and you are not forced into licenses. Even after after a game is release ant not maintained any more if new updates and features get into the engine the game still benefits from it with 0 maintenance cost. This means you can make a game on windows and people can run it on linux although you never touched this OS at all. From the developer side this is a directory based engine so no need to import/export all the time or fighting with assets. Edit an image with GIMP in the project directory and test-run. Export from Blender right into the project directory and run. You can even change the file while test-running and load the file again. The used file formats are open. There are no closed proprietary formats (nor media nor assets) used. For the engine defined file formats Blender scripts are present so you can export anything from Blender straight into your project. The distributing is also WYSIWYG: what is in your project directory becomes the distributable. No hidden magic, no cooking. Due to the directory nature this engine integrates well into existing workflows. Combine all kinds of tools you want. As long as the result ends up as a file in the project directory your golden. Another point is safety for the user. Bugs in games can trash your system (been there, done that, Valve for example trashed my machine with a
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Sat, May 30, 2020 at 03:08:21PM +0200, Roland Plüss wrote: > > On 5/30/20 2:00 PM, Tobias Frost wrote: > > * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll > > know for > > sure if it suitable… > > > > [1] https://tracker.debian.org/pkg/fox1.6 > > > I've seen that. I need though fox1.7 since 1.6 is not compatible to 1.7 > . There had been API breaking changes in 1.7 . > > If this is a vital problem please tell me. It's not possible to remove > fox1.7 requirement unless various parts of the package are not build > (namely the basic crash recovery module, the gui launcher and the entire > IGDE). Yes, this gonna be a problem due to the Debian Policy about embedded code copies [1]. I see those options: - talk to the fox-1.6 maintainer about updating the package to 1.7. (though I see that they generally stick to released versions and 1.7.* seems to be only development snapshots; a question to ask: is the 1.7 ABI stable already?) - make the features optional that requires 1.7 - use only 1.6 features (listed for completeness, as you said you can't) [1] https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies -- tobi signature.asc Description: PGP signature
Bug#943350: marked as done (RFS: nattable/1.5.0+dfsg-1 [ITP] -- high performance SWT data grid)
Your message dated Sat, 30 May 2020 14:19:05 +0200 with message-id and subject line RFS: nattable/1.5.0+dfsg-1 [ITP] -- high performance SWT data grid has caused the Debian Bug report #943350, regarding RFS: nattable/1.5.0+dfsg-1 [ITP] -- high performance SWT data grid to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 943350: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943350 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-j...@lists.debian.org, debian-scie...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "NatTable": * Package Name : nattable Version : 1.5.0+dfsg-1 Upstream author : NatTable developers * URL : https://www.eclipse.org/nattable/ * License : Eclipse Public License 1.0 Programming language : Java Description : high-performace SWT data grid NatTable is a powerful and flexible SWT table/grid widget that is built to handle very large data sets, real-time updates, dynamic styling, and more. NatTable is a subproject of Nebula. This package is a dependency of HDFView. It builds the following binary package: libeclipse-nebula-widgets-nattable-core-java - core java library To find the package, please visit the following URL: https://salsa.debian.org/java-team/nattable Best regards, Vincent Prat --- End Message --- --- Begin Message --- I am now a DD, so I no longer need a sponsor.--- End Message ---
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Sat, May 30, 2020 at 01:11:45PM +0200, Roland Plüss wrote: > I did not wanted to go down the "release early, release crap, become a mess" > route so I did not release the source base to the public until recently. Well, OK, your choice… Though I's recommend reading "The Bazaar and the Cathedral" from Eric S. Raymond. (...) snipped engine summary, thanks for it. Its essence should probably attached to the ITP or it would be a start point for the package description… > Now if you insist this will be rejected because not having yet finished > games projects out for years then there is not much I can do about it. > This engine had been already at a game show and used by players and > didn't falter so I'm positive it is ready. That said I'm doing things > like supporting new OS and packaging for OS also to improve the project. > So if this should be rejected, no problem to me. I've got other path I > can walk too. But please if you really think this has no chance to enter > Debian no matter what I do then tell me this please now. Then I will at > least improve things using the lintian and go on from there. Let me clarify that I only described the mechanics in Debian. I just said it is _possible_ that it could be rejected, but I'm not the one which decides about it, that would be the ftp masters. If you want to go the route and give it a try: great! But there still work to be done on the packaging level before an upload can be made. As said, work on the package*, reupload to mentors, remove the moreinfo tag and we will see how things develop. * Update to my hints list: There is a fox package, fox-1.6 [1]; you'll know for sure if it suitable… [1] https://tracker.debian.org/pkg/fox1.6 > -- > Mit freundlichen Grüssen > Plüss Roland > > Game Development and Game Engine Technologies https://dragondreams.ch > signature.asc Description: PGP signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Sat, May 30, 2020 at 02:38:09AM +0200, Roland Plüss wrote: > > On 5/29/20 10:07 PM, Tobias Frost wrote: > > On Fri, May 29, 2020 at 12:32:42PM +0200, Roland Plüss wrote: > > > >> I'm a bit cautious to allow installing games into the user home > >> directory. Game files can quickly grow large (up to GB of data). One > >> reason why I opted for /opt in the first place. > > Speaking of games, are there free (FOSS) games available? A quick Internet > > research yielded no results, so I'd appreciate if you could provide > > pointers. > > > > Thanks! > > > Not yet. The engine has been released public for the first time > recently. Available right now are example projects including > ready-to-run delgas: https://github.com/LordOfDragons/deexamples . The > engine can be used for both FOSS and commercial alike without troubles. > To makes games though you need the engine in the first place. It's sort > of chicken/egg problem here. Ok, thanks for being honest. (I guess the "GB of game data" is nothing to be concerned right now and when it becomes a thing you can always extend your programm to look in more than one location or the games provide some launcher script. (To be clear, this does not change anything about /opt being unsuitable.) But there is now another chicken-egg problem: In Debian we don't try to package every piece of software; e.g it should have have already some relevnace, users, games, etc… Please don't think that being in Debian will boost the userbase significantly. We have already plenty other game engines in the archives, so maybe elaborate a bit what makes yours special over the others? One plus I immediatly see is that there are free examples (they should be part of the package!) and seems to work well with a FLOSS toolchain only. (at least I have the impression it does). But on the other side, it has yet to proof in real games that it fit enough for them. One the minus side I see that you are alone on the project and despite the project being quite old (I see featurelists dated 2014) it seems not to have gained traction. Hinted by the absence of games and contributions to your project, so I fear that the project is missing relevance. I write above not to discourage you, I just want to be frank with you that I'm not sure that the software is ready for Debian. I want to avoid that you put significant work into the packagaging just to find it rejected later. On the other hand, fixing the issues mentioned can also improving the quality of your project. The videos you have published have kind of impressed me, but _disclaimer_ I'm not a game developer ;-). -- tobi
