Re: LXDE web page bashing thread Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
The website is on GitHub so anyone can suggest things by throwing me issues or PRs at https://github.com/lxde/lxde.org The hamburger menu requiring JavaScript is something that I don't have good alternative with right now. Also, welcome back, Martin :) Yao Wei On Fri, 19 May 2017 at 21:18 Martin Bagge / brother wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2017-05-19 15:00, Zlatan Todoric wrote: > > Well Debian on its page doesn't mention it is Linux based > > or has Linux kernel or at all word Linux. > We have Linux, HURD and the FreeBSD kernel, though. I > suspect the thought was Debian hopes its practices, values > and community will outlive any specific kernel, just like > they could outlive apt/dpkg. > > >>> You could add the quote on which I quoted (lxde page doesn't > >>> say it can be installable on linux) so my comment makes more > >>> sense > >> Sorry, I'm still not sure what you mean. > >> > > I mentioned Linux because it was previously mentioned that LXDE > > page doesn't mention it can be installed on Linux (and afaik it can > > be also on FreeBSD/Hurd?). > > You need to be some special type of person to not understand that > At > http://lxde.org > they have one big red button in the center that takes you to > http://lxde.org/get/ > Linux is mentioned in the second sentence. > BSD is mentioned in the second bold sentence. > > The LXDE page has some problems but lack of mentioning supported > systems isn't one of them. > > It seems like they decided to focus on two types of audiences. > - those who are somewhat familiar with LXDE by name and like to try it. > - those who like to find the code of it. > > If I still was involved in the project I would suggest they move the > "join" part up to a more prominent spot, it's buried at the the front > page after help text and unhelpful texts about some features of LXDE > (in panels that are totally not clickable but should have been). > > The hamburger menu top right shows the join option as number three, > more sane priority in my opinion. > > - -- > brother > http://sis.bthstudent.se > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlke8IsACgkQOIRDexPY > /4v5Nw/7B9UBwo9221aPALXxqFYepekr6c5UOhC0bZcnOCLhf1bXgT7F1wBYDxU+ > JdEPSDTn8kNs6H+cbdHCbaSPA3WCMMdHUooylpj02yuvpuC84zjXxD7utnT6KLNE > On3V4RbwzegMTgnKCaZz8YTNsVV9DQTCTnayKeuQ4n+C1e/zffQaI3ppkpZjSViM > Oobt7Hp87yLKHTU2DgEZiKmI3L5brdNGQtV9hAglRgwTtMMcYaB+JHT2MHKj1YnY > TXUdWDexQqsz47bsZa7UO4PAR+/o/L8hJB3MytV4hc6BCka3CVESYkrttoRqnyRu > rh4W1no/ko6wRUjIuK2C2E6e0RB7vadGnSZUaowDyvFPr1+VF2Q8pv8ajaM6bMLG > 0Tq97yj8iNM+QodsX2e2mjXe31LUOxgVUiB2wLMko+AN5FssLoOmFDzzA1AW9+oo > RWi0KkGmMFjE/q8tItIAFgT9BJmd/xWOokdwNyc45gVXpSpIrja1/ZKJaHFzg59M > Chf6en/hYtUlUlQFlaVdIdxn5VCGAfteDwdvV3t4SXcAxO4DEIgxonPlPIX7EoHa > HfyNKR9IvSiAH8fdf9wdFnVaIuTkgUYcwn7/6Ps6xKAt9MnQ1BxEnkEyTV1c4ZWX > EyE6gwmb65chmA6mmt2RyBW1FLbILyHHTaHIHwJBBon9MoyInBU= > =qXxI > -END PGP SIGNATURE- > >
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
[loads of bikeshedding and grandstanding] So this thread is a shitshow. Has anyone thought about taking the website (or really, anything we put out), going and talking with **our users** and see what they have to say? What they think of the site? Record them finding and creating an install medium? I, frankly, don't even pretend to care what our developer community thinks of the site -- the site isn't just for you. Until someone comes back with data on what things are easy, what things are hard, and large enough sample sizes covering an *accurate* slice of our userbase, I don't care about what anyone on this thread says. Paul signature.asc Description: PGP signature
Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)
2017-05-19 2:35 GMT+02:00 Paul Wise : > On Thu, May 18, 2017 at 10:37 PM, Matthias Klumpp wrote: > >> Unfortunately though, the D language ABI isn't stable, so any future >> compiler update might break the software in weird ways unless all D >> software is recompiled when a new compiler is released. >> To make things worse, D also has three different compilers (which >> share the same frontend), the GNU D Compiler (GDC), LLVM D Compiler >> (LDC) and the reference compiler Digital Mars D compiler (DMD). >> All compilers have different advantages, but they also have >> incompatible ABI, especially because each comes with a separate >> version of the D runtime and standard libraries. > > Is there any chance of the D community creating a standard ABI that > will be stable and shared all of the compilers? There is a chance, and I was pushing rather hard for that, but I don't think this will happen in the near future. It's also one of these cases where you ask others to do something for you which has never been a big issue for them. For the record, see https://forum.dlang.org/post/och4d8$1i1n$1...@digitalmars.com (Very) long-term, there might be a stable, shared ABI, in the short term though, that definitely won't be the case.
Re: Packaging of libraries with unstable ABI (D, Rust, Go, ...)
2017-05-18 19:52 GMT+02:00 Sean Whitton : > Hello Matthias, > > On Thu, May 18, 2017 at 04:37:58PM +0200, Matthias Klumpp wrote: >> Looking at what other languages with the same problem have done, there >> are basically two ways to deal with the issue: >> >> 1) Rebuild every reverse-dependency of the languages' compiler every >> time the compiler is updated. This is done by Haskell and OCaml and >> resulted in permanent transition trackers for the libraries. >> >> 2) Ship source code instead of libraries in packages, and compile it >> directly into the target binaries. That way, the maintenance overhead >> of the languages' packages is greatly reduced, but code is statically >> linked (boo!) and a lot of code needs to be rebuilt for every >> dependency (meaning more work for the autobuilders). This is done by >> Go, and apparently also the plan to do for Rust. > > Note that Haskell is statically linked, too. We rebuild every > reverse-dependency of every library that changes, not just the compiler. > > Are you saying that with D, it's only changes to the compiler that are > problematic? No. D can also build shared libraries even. The problem is that you can only combine libraries and binaries built with the same D compiler and the same D compiler version. This results in problems: If I have an application A that depends on (shared or static) library B, and we update the D compiler that was used to build both components initially, and then do an upload of application A, we will get linker errors. Since A is now built with the newer compiler and B still has the ABI used with the old D compiler, a mismatch happens. So, if a new D compiler is made available in the archive, we would need to ensure all D stuff gets rebuilt in order. If source code is shipped, the code is only compiled once, so we wouldn't run in that issue (but doing that is maybe no so nice?). Cheers, Matthias -- Debian Developer | Freedesktop-Developer I welcome VSRE emails. See http://vsre.info/
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
Hi there, please remember: it is not the design, that makes a website interesting, but the content! So maybe we should first discuss, and maybe confirm, what might people interest on the debian site. I suggest just to collect ideas, and make a ranking (i.e. freedom was named 1563 times, low cost was named 873 times and so on) and then express the top ranks on the site. IMO for example, "stability" and "freedom" might new users not interest at first, but maybe "runs office, multimedia, graphics" or "be safe from windows viruses" or "faster than windows" might interest people more than "freedom". Also the term "cost nothing, for free!" might not interest people, as people believe, MS-Windows on computers they buy is also for free (which of course is NOT!) I think, you know, what I want to say. Just my 3,1415926 cents. Best regards Hans
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Thu, May 18, 2017 at 01:40:03PM +0200, Andreas Tille wrote: > In last GSoC the student was not comfortable with SVN. I have converted > lots of packages at request of the student. So I'm perfectly following > your reasoning if (and only if) there are potential packaging > contributors at horizon. Oh sure, I didn't mean to say I think you should be *doing* any different, merely that the rationale you gave (user experience) for doing so (or not) didn't cover the problem case. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
LXDE web page bashing thread Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2017-05-19 15:00, Zlatan Todoric wrote: > Well Debian on its page doesn't mention it is Linux based > or has Linux kernel or at all word Linux. We have Linux, HURD and the FreeBSD kernel, though. I suspect the thought was Debian hopes its practices, values and community will outlive any specific kernel, just like they could outlive apt/dpkg. >>> You could add the quote on which I quoted (lxde page doesn't >>> say it can be installable on linux) so my comment makes more >>> sense >> Sorry, I'm still not sure what you mean. >> > I mentioned Linux because it was previously mentioned that LXDE > page doesn't mention it can be installed on Linux (and afaik it can > be also on FreeBSD/Hurd?). You need to be some special type of person to not understand that At http://lxde.org they have one big red button in the center that takes you to http://lxde.org/get/ Linux is mentioned in the second sentence. BSD is mentioned in the second bold sentence. The LXDE page has some problems but lack of mentioning supported systems isn't one of them. It seems like they decided to focus on two types of audiences. - those who are somewhat familiar with LXDE by name and like to try it. - those who like to find the code of it. If I still was involved in the project I would suggest they move the "join" part up to a more prominent spot, it's buried at the the front page after help text and unhelpful texts about some features of LXDE (in panels that are totally not clickable but should have been). The hamburger menu top right shows the join option as number three, more sane priority in my opinion. - -- brother http://sis.bthstudent.se -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEVlIsX3Eri6ICyZwJOIRDexPY/4sFAlke8IsACgkQOIRDexPY /4v5Nw/7B9UBwo9221aPALXxqFYepekr6c5UOhC0bZcnOCLhf1bXgT7F1wBYDxU+ JdEPSDTn8kNs6H+cbdHCbaSPA3WCMMdHUooylpj02yuvpuC84zjXxD7utnT6KLNE On3V4RbwzegMTgnKCaZz8YTNsVV9DQTCTnayKeuQ4n+C1e/zffQaI3ppkpZjSViM Oobt7Hp87yLKHTU2DgEZiKmI3L5brdNGQtV9hAglRgwTtMMcYaB+JHT2MHKj1YnY TXUdWDexQqsz47bsZa7UO4PAR+/o/L8hJB3MytV4hc6BCka3CVESYkrttoRqnyRu rh4W1no/ko6wRUjIuK2C2E6e0RB7vadGnSZUaowDyvFPr1+VF2Q8pv8ajaM6bMLG 0Tq97yj8iNM+QodsX2e2mjXe31LUOxgVUiB2wLMko+AN5FssLoOmFDzzA1AW9+oo RWi0KkGmMFjE/q8tItIAFgT9BJmd/xWOokdwNyc45gVXpSpIrja1/ZKJaHFzg59M Chf6en/hYtUlUlQFlaVdIdxn5VCGAfteDwdvV3t4SXcAxO4DEIgxonPlPIX7EoHa HfyNKR9IvSiAH8fdf9wdFnVaIuTkgUYcwn7/6Ps6xKAt9MnQ1BxEnkEyTV1c4ZWX EyE6gwmb65chmA6mmt2RyBW1FLbILyHHTaHIHwJBBon9MoyInBU= =qXxI -END PGP SIGNATURE-
Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)
On 05/18/2017 12:32 PM, Sean Whitton wrote: > Hello Zlatan, > [...] > > The community consensus seems to be that we want to promote ourselves, > but we care more about providing quality information than do the people > who designed sites like lxde.org (sorry to keep using that example). > This consensus position is itself a value of our community, and an > aspect of its identity. lxde page is bad, I didn't say anything about the quality of information on it but I do think (and would love to be proven otherwise) that average Joe of 2017 will feel more appealed towards lxde page than our debian.org. I do agree that quality shouldn't suffer but than we do have a lot of out-of-date docs, Arch wiki being much better than our own etc etc. We need to improve the quality overall and make it more accessible to everyone and that includes people who use modern workflows/moder views/designs etc. Or run a huge global survey what people want to see from Debian... Well Debian on its page doesn't mention it is Linux based or has Linux kernel or at all word Linux. >>> We have Linux, HURD and the FreeBSD kernel, though. I suspect the >>> thought was Debian hopes its practices, values and community will >>> outlive any specific kernel, just like they could outlive apt/dpkg. >>> >> You could add the quote on which I quoted (lxde page doesn't say it can >> be installable on linux) so my comment makes more sense > Sorry, I'm still not sure what you mean. > I mentioned Linux because it was previously mentioned that LXDE page doesn't mention it can be installed on Linux (and afaik it can be also on FreeBSD/Hurd?). signature.asc Description: OpenPGP digital signature
Re: Moving away from (unsupportable) FusionForge on Alioth?
Hi Guido, On Fri, May 19, 2017 at 01:35:58PM +0200, Guido Günther wrote: > > Keeping only debian/ in git is supported by gbp as well (see > --git-overlay). Thanks for the hint - I've seen this and I'm aware of it. > AFAIK It's not that commonly used so there might be bugs > lurking and features lacking but it might be worth a try in case there > is some momenturm for moving to git. If (and only if) there would be some momentum for a move to Git neither I nor any other member of the Debian Med team will block this. But for the moment I keep on failing to see an advantage only out of the fact that "it is possible". Thanks anyway Andreas. -- http://fam-tille.de
Re: Moving away from (unsupportable) FusionForge on Alioth?
On Wed, May 17, 2017 at 10:19:24PM +0200, Andreas Tille wrote: > Hi, > > On Mon, May 15, 2017 at 02:43:56PM +0200, Johannes Schauer wrote: > > > > The top 10 teams with packages in SVN are: > > > > 347 Debian Med Packaging Team > > > > This number contains possibly 150 packages that *could* be migrated - > provided somebody wants to take the time for some unproductive work. > However, we intentionally do packaging of new R CRAN packages in SVN > since in this case packaging is brain dead simple and we keep only the > debian/ dir and not the upstream source in VCS. This is a sensible and > established workflow and currently there is no short term plan to change > this. Keeping only debian/ in git is supported by gbp as well (see --git-overlay). AFAIK It's not that commonly used so there might be bugs lurking and features lacking but it might be worth a try in case there is some momenturm for moving to git. Cheers, -- Guido > > In short: There is no doubt that Git is the better VCS but spending > developer time simply to switch lots of packages from an old VCS to a > modern one has zero effect on users desktops and has no high priority. > > Kind regards > >Andreas. > > -- > http://fam-tille.de >
Re: Bug#862954: ITP: mvdsv -- a modern QuakeWorld server
On Fri, 19 May 2017 at 11:50:51 +0200, Lee Garrett wrote: > I will be maintaining it alone. [...] > I'm open to co-maintaining this package if any individual or team is > interested. > I will need a sponsor for this package. Please consider joining the Games Team. We have Quake enthusiasts who can probably help with this package and/or sponsor your uploads. (We also maintain all the other Quake engines packaged so far.) In particular, Michael Gilbert maintains ezquake in the Games Team. I try not to maintain heavily multiplayer-focused games, so I'm unlikely to want to co-maintain mvdsv myself; but I do co-maintain the more single-player-focused Quake engines, the game-data-packager tool that packages the required game data, the quake-server package that wraps systemd units and sysvinit scripts around the various Quake engines, and the Debian Quake mini-policy. The debian-devel-games mailing list is an appropriate place for discussion of these packages. S
Bug#862954: ITP: mvdsv -- a modern QuakeWorld server
Package: wnpp Severity: wishlist Owner: Lee Garrett * Package name: mvdsv Version : 0.31 Upstream Author : Alexandre Nizoux * URL : https://github.com/deurk/mvdsv * License : GPLv2 Programming Lang: C Description : a modern QuakeWorld server mvdsv (MultiView Demo Server) is a QuakeWorld-compatible server that is the most common Quake server used today[0]. There are two other available quake servers in Debian, quakespasm and darkplaces. quakespasm uses the FitzQuake network protocol, while darkplaces uses DARKPLACES7. Both are incompatible with the QuakeWorld network protocol. There is an overview of (incompatible) Quake network protocols[1]. mvdsv fills the gap by being QuakeWorld-compatible, allowing to use the most popular clients, ezquake and nQuake (which is just a fancy installer for ezquake), and also offering many features not available in the other Quake servers. The documentation is severely lacking, I plan on writing the man page and the list of config file parameters as part of the packaging process. I will be maintaining it alone. Since Quake has been out for 20+ years now, I don't expect a quick release cycle, so the maintenance burden for this package will be minimal. I'm open to co-maintaining this package if any individual or team is interested. I will need a sponsor for this package. [0] https://www.quakeservers.net/quakeworld/stats/ [1] https://quakewiki.org/wiki/Network_Protocols
Bug#862947: ITP: vasptools -- python module and tools for postprocessing VASP quantum computations
Package: wnpp Severity: wishlist Owner: Drew Parsons * Package name: vasptools Version : 20142003 Upstream Author : Germain Vallverdu * URL : http://gvallver.perso.univ-pau.fr/vasptools/ * License : GPL Programming Lang: Python Description : python module and tools for postprocessing VASP quantum calculations vasptools is a python module which define the class VaspRun and provide a set of functions in order to do simple post treatments on VASP quantum chemical calculations. The main features are the following: - extract or plot density of state - extract or plot bands - get structural data - control convergence - simple operations on CHGCAR file (split, sum) vasptools contains the following submodules : - vasptools.vasprun : contains the VaspRun class which is the core part of the module. - vasptools.dos : density of states output functions - vasptools.bands : energy bands output functions - vasptools.utils : operations on CHGCAR file - vasptools.atom : an atom class This package also includes the independent crystal module and myxml module, used by vasptools. crystal module provides the Crystal class with which you can easily manipulate a crystal (lattice parameters, coordinates conversion, etc). myxml module is used in order to read the file vasprun.xml. This package will be team-maintained under debichem.
