Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.
On 07/10/2016 08:39 AM, Emilio Pozuelo Monfort wrote: > I found http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/, > which makes things clearer. This seems to be a cross-desktop (Mate, > Cinnamon... > XFCE?) project to provide some core apps. Which we wouldn't end up with > multiple > forks of the same stuff, and that addresses my concerns. Yep, same concern here. I'm on the MATE packaging team and I am strongly against packaging any of these X apps. They don't bring any benefit really, any of the existing applications they are forking run perfectly fine on any desktop that Debian offers. I also fear additional work load for the security team if multiple instances of the same media player have to be taken care of. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.
Quoting John Paul Adrian Glaubitz (2016-07-10 08:59:59) > On 07/10/2016 08:39 AM, Emilio Pozuelo Monfort wrote: > > I found > > http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/, > > which makes things clearer. This seems to be a cross-desktop (Mate, > > Cinnamon... XFCE?) project to provide some core apps. Which we > > wouldn't end up with multiple forks of the same stuff, and that > > addresses my concerns. > > Yep, same concern here. I'm on the MATE packaging team and I am > strongly against packaging any of these X apps. They don't bring any > benefit really, any of the existing applications they are forking run > perfectly fine on any desktop that Debian offers. > > I also fear additional work load for the security team if multiple > instances of the same media player have to be taken care of. I don't follow how it is "same concern": As I understand the blog post, the very purpose of X-Apps is to be desktop-agnostic. Do you consider pluma well suited as a desktop-agnostic editor? It currently links against libmate-desktop-2-17 and mate-desktop-common which seems not agnostic to me. I agree that if there are no real difference between programs tied to specific desktops and not tied to specific desktops, then we should maintain only one of them - but in my opinion it then makes better sense to maintain those *not* tied to MATE or any other desktop. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?
>Yes, btrfs in kernel 3.16-18 might still be unstable, but since then >it is got some important fixes, it is production ready and is actually >pretty amazing in many ways. But does Debian Stable have this new and relatively stable version of btrfs or it just uses old and not_so_stable version from 3.16 version of Linux kernel?
Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.
On 07/10/2016 09:55 AM, Jonas Smedegaard wrote: > I don't follow how it is "same concern": As I understand the blog post, > the very purpose of X-Apps is to be desktop-agnostic. Do you consider > pluma well suited as a desktop-agnostic editor? It currently links > against libmate-desktop-2-17 and mate-desktop-common which seems not > agnostic to me. I didn't claim that Pluma is desktop-agnostic, I just said it runs just fine on any of the desktops that Debian offers. And I'm not sure how any of the X apps are supposed to be truly desktop- agnostic when they are using a particular toolkit like GTK or Qt. Unless they have completely rewritten Pluma from scratch - which I doubt because there wouldn't be a point of forking things - their version of Pluma will still be linking against GTK3 (hopefully not GTK2) which means it won't bring any huge improvements when running under any non-GTK desktops. Given the history of Linux Mint with their weird view on security (Linux Mint is the very definition of a FrankenDebian [1]) where they withhold important security updates because their weird mixture of packages would otherwise break too often or their hijacking of package names (mdm, for example), I don't really trust them to come up with a clean design for desktop agnostic applications. Heck, the first thing they wanted to do was naming their forked version of Pluma "xedit". Adrian > [1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.
m On 10 July 2016 08:59:59 CEST, John Paul Adrian Glaubitz wrote: >On 07/10/2016 08:39 AM, Emilio Pozuelo Monfort wrote: >> I foupml0lnd >http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/, >> which makes things clearer. Thisf seems to be a cross-desktop (Matea) >> $₩p5p!4♧''. jj >Cinnamon... >> XFCE?) project to provide some core apps. Which we wouldn't end up >with multiple >> forks of the same stuff, and that addressemt. I:.!I! ki;,H.i:s my concerns. > >Yep, same concern here. I'm on the MATE packaging team and I am against/£♥♥♥]e I iit-.su', >packaging any of these X apps. They don't bring any benefit really, any >of the >existing applications they are forking run perfectly fine on any >desktop that >Debian offers. > >I also fear additional work load for the security team if multiple >instances >of the same media player have to be taken care of. > >Adrian
Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.
On 10/07/16 15:14, Bjørn Mork wrote: > Emilio Pozuelo Monfort writes: >> On 09/07/16 22:31, Franciscarlos Santos Soares wrote: >>> Hi Emilio! >>> >>> Thank you for contacting us. In fact, like independent application of any >>> DE, >>> but they were compatible with the traditional look of windows and based on >>> the >>> GTK library. So would provide a good working environment in the old >>> computers >>> that read daily in public schools that work. >> >> I found >> http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/, >> which makes things clearer. This seems to be a cross-desktop (Mate, >> Cinnamon... >> XFCE?) project to provide some core apps. Which we wouldn't end up with >> multiple >> forks of the same stuff, and that addresses my concerns. > > That's the forking version of https://xkcd.com/927/ , isn't it? That blog post made me think this was a coordinated effort between various DEs to create some apps that they all would use. Which would mean we wouldn't need a gnome-$foo fork Cinnamon, another one for Mate, etc... But it seems I was too naïve and that is not the case, and we're just going to end up with one more fork as I initially feared. I so hope I am wrong on this... Cheers, Emilio
Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.
Emilio Pozuelo Monfort writes: > On 09/07/16 22:31, Franciscarlos Santos Soares wrote: >> Hi Emilio! >> >> Thank you for contacting us. In fact, like independent application of any >> DE, >> but they were compatible with the traditional look of windows and based on >> the >> GTK library. So would provide a good working environment in the old >> computers >> that read daily in public schools that work. > > I found http://segfault.linuxmint.com/2016/02/the-first-two-x-apps-are-ready/, > which makes things clearer. This seems to be a cross-desktop (Mate, > Cinnamon... > XFCE?) project to provide some core apps. Which we wouldn't end up with > multiple > forks of the same stuff, and that addresses my concerns. That's the forking version of https://xkcd.com/927/ , isn't it? Bjørn
Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?
On Sun, 10 Jul 2016 09:39:03 +0300, Otto Kekäläinen wrote: >Yes, btrfs in kernel 3.16-18 might still be unstable, but since then >it is got some important fixes, it is production ready and is actually >pretty amazing in many ways. I have severe allocation issues in btrfs with recent kernels and recent btrfs-tools when using thousands of snapshots. All the community had to offer was "well, try to restrict yourself to at most a few hundred snapshots". btrfs rebalance brings the whole system to a halt until it has finished, since it places some kind of lock on the file system. The effect on the system's other seervice is severe up to "sit back and wait until system becomes responsive again". That's not what I'd call production ready. It's simply just betafs at the moment. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?
On Sun, 10 Jul 2016 10:10:19 +0200, german...@ya.ru wrote: >But does Debian Stable have this new and relatively stable version of btrfs or >it just uses old and not_so_stable version from 3.16 version of Linux kernel? Stop ranting. Say what you want. And while you're at it, think about stating your name. You're coming across as a troll otherwise. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Introducing default-mysql-* metapackages
Hello maintainers of packages that depend in MySQL/MariaDB! TL;DR; We will soon ask you to change packages that depend on MySQL or MariaDB as follows: BEFORE: Build-Depends: libmysqlclient-dev AFTER: Build-Depends: default-libmysqlclient-dev BEFORE: Depends: mysql-server | virtual-mysql-server OR Depends: mariadb-server | virtual-mysql-server AFTER: Depends: default-mysql-server | virtual-mysql-server BEFORE: Depends: mysql-client | virtual-mysql-client OR Depends: mariadb-client | virtual-mariadb-client AFTER: Depends: default-mysql-client | default-mysql-client You can already test this in experimental. We will announce when you should do this in unstable. Details follow: The release team decided earlier in the spring that MariaDB should be made the default MySQL variant in Debian. The release team also wished to have a facility that allows easy switching of the default. Therefore we are now about to introduce the following metapackages from the mysql-defaults source package: - default-mysql-server - default-mysql-server-core - default-mysql-client - default-mysql-client-core - default-libmysqlclient-dev All maintainers of packages that currently depend directly on mysql-server, mariadb-server, or any of the other packages in these series, will at a later time be asked to update the dependencies in their packages to point to default-mysql-* instead. Installing the metapackage default-mysql-server will pull in mariadb-server-10.0. Users who had mysql-server-5.6 will have it removed and replaced by the MariaDB equivalent on upgrade. Note that once you have switched to MariaDB, it might not possible to convert your in-place database files back to MySQL automatically, since Oracle does not maintain tools to convert possible MariaDB features present in the binary format. Please back up your data first if you wish to switch or experiment. Manual dump/import is the most reliable way to import data from one installation to another. A virtual package scheme virtual-mysql-* already exists since 2013, and will continue to exist. All MySQL variants in Debian (and outside in 3rd party repositories too) have Provides for these virtual-mysql-* packages. Maintainers can must use "Depends: default-mysql-server | virtual-mysql-server" if their package can be satisfied by any MySQL variant (Oracle, MariaDB, Percona, mysql-wsrep). The first dependency should be default-mysql-*, which is a metapackage, that in turn depends on exactly one option, which for now is MariaDB. If a maintainer knows that his/her package only works with one variant, then the package can depend directly on that package and not use the default-mysql-* (matches one) or virtual-mysql-* (matches any) schemes. Please get in touch if this applies to you. At the moment there should be no such packages, but in the future cases like this can arise when MySQL and MariaDB develop diverging feature sets. Packages built against default-mysqlclient-dev and link using "-lmysqlclient" will end up with a shared library dependency on either libmysqlclient.so.X or libmariadbclient.so.X depending on the default defined by the release team at build time. These will be provided by the libmysqlclient18 (soon to be libmysqlclient20) and libmariadbclient18 packages, which will be co-installable. Packages which require particular functionality available from only one of the forks may Build-Depend directly on libmysqlclient-dev or libmariadbclient-dev and then link using "-lmysqlclient" or "-lmariadbclient" respectively. Again, please get in touch if this applies to you. Users that want to rebuild packages against a different variant of lib*client-dev for experimenting and testing locally should prefer using a locally modified default-libmysqlclient-dev over modifying each client application source package individually. The default-mysql-* metapackages will be uploaded to Experimental soon and to Unstable once we are confident there are no regressions. Once they are available in Unstable, we will announce this on debian-devel-announce@ officially and later mass file bugs for packages that have not updated their dependencies in a reasonable time otherwise. If you wish to participate in testing or finalizing this scheme, please reply to this thread or write to pkg-mysql-maint@. On behalf ot the pkg-mysql team, - Otto
Re: Thinking about a "jessie and a half" release
Hi, On 2016-07-04 18:08, Cyril Brulebois wrote: How would we keep that working given that backports keeps changing? Backports changing isn't an issue AFAICT if we're only publishing a netinst image which has all the kernel bits (kernel udebs), as opposed to netboot. Or are you thinking of other issues? that was the main issue. Apart from the updates part below. Would we copy the kernel at the time into a special suite? I don't think that's needed. How would updates work? Updates to? - d-i: nothing has to change (except if we want to republish a new image with an ever newer kernel version), see above. Where to would we upload d-i? Under what name? With what content? Would we re-spin stable d-i plus backports-related changes into backports? Would backports ftp-masters be ok with that? I feel somewhat uncomfortable with one-offs that are not being updated anymore and cannot even be updated if need be because the kernel will have disappeared by them (as it tracks testing rather than its own version line). - installed system: as usual for systems with backported packages (NotAutomatic & ButAutomaticUpgrades). So which metapackages would we need to install to keep track of new major kernel versions in backports? Kind regards and thanks Philipp Kern
Re: Thinking about a "jessie and a half" release
Philipp Kern (2016-07-10): > On 2016-07-04 18:08, Cyril Brulebois wrote: > >>How would we keep that working given that backports keeps changing? > >Backports changing isn't an issue AFAICT if we're only publishing a > >netinst image which has all the kernel bits (kernel udebs), as opposed > >to netboot. > > > >Or are you thinking of other issues? > > that was the main issue. Apart from the updates part below. OK. > > >>Would we copy the kernel at the time into a special suite? > > > >I don't think that's needed. > > > >>How would updates work? > > > >Updates to? > > - d-i: nothing has to change (except if we want to republish a new > > image with an ever newer kernel version), see above. > > Where to would we upload d-i? jessie-backports. > Under what name? Not sure I understand the question. If that's for an “jessie+1/2” alternative, I have no proposals right now. > With what content? For src:debian-installer? fork from master, remove everything not fitting backports (package renames etc.), is probably a better idea than trying to backport (mostly) kernel config changes. Later such versions (if needed) can then be prepared by git merging further from master. > Would we re-spin stable d-i plus backports-related changes into > backports? Based on the above reply, no. > Would backports ftp-masters be ok with that? Based on the above reply, that's just the usual “copy most of it, leave changes that don't make sense for stable aside” policy, so I would expect they would be. But right, I didn't ask yet. The installer-$arch/ thing shouldn't have any consequences since it isn't used yet AFAICT; we might need to iron out some bugs though. > I feel somewhat uncomfortable with one-offs that are not being > updated anymore and cannot even be updated if need be because the > kernel will have disappeared by them (as it tracks testing rather > than its own version line). I don't see why we wouldn't be able to update that. Just git merge from master (and pick whatever newer kernel version it depends on), and adjust as I mentioned, done. Note: I don't think it's reasonable to require someone to commit to doing regular updates for this one-off. But anyway, the “cannot” part seems bogus to me, as I've just explained. > > - installed system: as usual for systems with backported packages > > (NotAutomatic & ButAutomaticUpgrades). > > So which metapackages would we need to install to keep track of > new major kernel versions in backports? Hm? linux-image-$arch from src:linux-latest, as usual? KiBi. signature.asc Description: Digital signature
Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?
>Say what you want. Now I want to know if Debian Stable can in some extreme cases, like in this case with btrfs, replace not_very_good kernel module that is shipped with its current kernel with a kernel module from other (older or newer) version of Linux kernel and if yes, is it the case with btrfs? >think about stating your name. My full name is Davidyants Vazgen Samsonovich. Are you happy now?
Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?
❦ 11 juillet 2016 05:07 CEST, german...@ya.ru : >>Say what you want. > > Now I want to know if Debian Stable can in some extreme cases, like in this > case with btrfs, replace > not_very_good kernel module that is shipped with its current kernel > with a kernel module from other (older or newer) version of Linux > kernel and if yes, is it the case with btrfs? It is possible, but not once stable has been released. Therefore, it is too late now. -- To be or not to be. -- Shakespeare To do is to be. -- Nietzsche To be is to do. -- Sartre Do be do be do. -- Sinatra signature.asc Description: PGP signature
Browserified files and DFSG
Hi, There is a bug with severity serious filed against libjs-handlebars [1] (it is also a bug in ruby-handlebars-assets). The corresponding source code is present in libjs-handlebars (only in experimental right now, but it could be reuploaded to unstable once I have clarity). It needs grunt to be packaged [2] to be able to browserify it in debian. I agree it is nice to be able to browsetrify it in debian, but I don't think it is serious enough to be removed from debian or moved to non-free. Do we have a consensus on this issue? Thanks Praveen [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817092 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673727 signature.asc Description: OpenPGP digital signature
Re: Browserified files and DFSG
Pirate Praveen writes: > There is a bug with severity serious filed against libjs-handlebars [1] > (it is also a bug in ruby-handlebars-assets). The bug report (bug#817092) has IMO a misleading title. The software may or may not be free; what is at issue is that a compiled file is non-source and so does not satisfy the requirement for the Debian source package. > The corresponding source code is present in libjs-handlebars (only in > experimental right now, but it could be reuploaded to unstable once I > have clarity). That's good, though it does mean the source package in ”unstable“ still has the bug. > It needs grunt to be packaged [2] to be able to browserify it in > debian. Okay. So if I understand correctly, you're acknowledging that the compiled form of the work requires a build tool that is not yet in Debian. > I agree it is nice to be able to browsetrify it in debian, but I don't > think it is serious enough to be removed from debian or moved to > non-free. If the build tool needed to build the compiled form of the work is not yet in Debian, by my understanding that means the work cannot be in Debian in that compiled form. -- \ “Are you pondering what I'm pondering?” “Umm, I think so, | `\Brain, but what if the chicken won't wear the nylons?” —_Pinky | _o__) and The Brain_ | Ben Finney
Re: Browserified files and DFSG
On Monday 11 July 2016 12:18 PM, Ben Finney wrote: > If the build tool needed to build the compiled form of the work is not > yet in Debian, by my understanding that means the work cannot be in > Debian in that compiled form. > But the difference here is: The compiled form is also readable and modifiable source form. signature.asc Description: OpenPGP digital signature
Re: Browserified files and DFSG
On Monday 11 July 2016 12:21 PM, Pirate Praveen wrote: > On Monday 11 July 2016 12:18 PM, Ben Finney wrote: >> If the build tool needed to build the compiled form of the work is not >> yet in Debian, by my understanding that means the work cannot be in >> Debian in that compiled form. >> > > But the difference here is: > > The compiled form is also readable and modifiable source form. > This is the "compiled" file: https://anonscm.debian.org/cgit/pkg-ruby-extras/ruby-handlebars-assets.git/tree/vendor/assets/javascripts/handlebars.js signature.asc Description: OpenPGP digital signature
