More tasks option in Tasksel: what tasks do you want there?
Hi, During Debconf14, I could chat with Joey about the future of Tasksel, and having a "More option" task, which would lead to a new screen which would propose more tasks. Before anyone can implement this plan, we have to make sure that we all agree on what kind of tasks we want to implement. What I already agreed with Joey, is that having a list of 200 tasks will *not* be helpful, so we have to make sure we carefully choose what we will implement. So I have setup a wiki page so that we can share our thoughts. Please write in this wiki page: https://wiki.debian.org/tasksel/MoreTasks and discuss the topic here. Also note that I'm not sure I will have time or skills to implement it myself (I didn't have a look yet), but at least I would like this discussion started, so that me, or anyone else, can do the implementation when we reach that point, with solid grounds we all agree upon. I have for the moment only wrote 4 desktops tasks, plus 5 for the current pure blends, and 2 for OpenStack (which is what motivates me here). These are also up for discussions (though obviously, we don't want as many tasks as we have window manager (that is: more than 40)). Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/540c194b.40...@debian.org
Re: More tasks option in Tasksel: what tasks do you want there?
Thomas Goirand (2014-09-07): > During Debconf14, I could chat with Joey about the future of Tasksel, > and having a "More option" task, which would lead to a new screen which > would propose more tasks. > > Before anyone can implement this plan, we have to make sure that we all > agree on what kind of tasks we want to implement. What I already agreed > with Joey, is that having a list of 200 tasks will *not* be helpful, so > we have to make sure we carefully choose what we will implement. So I > have setup a wiki page so that we can share our thoughts. > > Please write in this wiki page: > https://wiki.debian.org/tasksel/MoreTasks > > and discuss the topic here. > > Also note that I'm not sure I will have time or skills to implement it > myself (I didn't have a look yet), but at least I would like this > discussion started, so that me, or anyone else, can do the > implementation when we reach that point, with solid grounds we all agree > upon. > > I have for the moment only wrote 4 desktops tasks, plus 5 for the > current pure blends, and 2 for OpenStack (which is what motivates me > here). These are also up for discussions (though obviously, we don't > want as many tasks as we have window manager (that is: more than 40)). > > Cheers, > > Thomas Goirand (zigo) It would probably make sense to have debian-boot@ at least in Cc when discussing proposed changes to the installer. What happens in DebConf or on debian-devel@ isn't automatically known by debian-boot@… KiBi. signature.asc Description: Digital signature
Re: Bug#758234: Raising priority of Debian packages
On Fri, Sep 5, 2014 at 3:35 AM, Jakub Wilk wrote: > We should probably also monitor package conflicts. We made a big fuss about > node vs nodejs (and rightly so); but I bet that we have lots of other > package pairs in the archive that can't be co-installed for no good reason. We have this already: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-file-overwrite;users=trei...@debian.org https://qa.debian.org/dose/file-overwrites.html -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6fhf2qpkcr0lvtmok-wtoa4+z7pj3rwfa1qyfub7kx...@mail.gmail.com
Re: systemd, again (Re: Cinnamon environment now available in testing)
On Sat, 6 Sep 2014 15:56:23 +0200, Matthias Urlichs
wrote:
>Marc Haber:
>> On Fri, 05 Sep 2014 15:12:50 +0200, Svante Signell
>> wrote:
>> >On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
>> >> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
>> >> to switch to systemd (by whatever means, the details of which I personally
>> >> am not at all interested in), a dist-upgrade should do so.
>> >
>> >How? All efforts so far and bugs reported are being brought down
>> >actively.
>>
>> #618862, dating back to 2011 and with no Debian maintainer reaction in
>> months?
>>
>This bug's latest entry asks the original reporter whether the bug still
>applies.
The long, anonymous elaborate does not address the actual issue. And,
it's clear that - should the anonymous poster be correct - keyscript
is only supported for the root file system, not for any other fsses
that might get mounted later.
>The systemd transition is not simple. I do not think it's reasonable to
>expect the Debian maintainer to be able to reproduce every problem, so what
>else would you have them do about this bug?
I would expect at least a try to keep something supported that has
been supported in Debian für years. This is a serious regression that
makes systems unbootable and up to now the only fix seems to be to
reduce security by resorting to keys typed in at boot time.
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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1xqyd7-js...@swivel.zugschlus.de
Detecting more undeclared conflicts (was: Re: Bug#758234: Raising priority of Debian packages)
Hi, Quoting Paul Wise (2014-09-07 11:38:27) > On Fri, Sep 5, 2014 at 3:35 AM, Jakub Wilk wrote: > > > We should probably also monitor package conflicts. We made a big fuss about > > node vs nodejs (and rightly so); but I bet that we have lots of other > > package pairs in the archive that can't be co-installed for no good reason. > > We have this already: > > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-file-overwrite;users=trei...@debian.org > https://qa.debian.org/dose/file-overwrites.html would it make sense to extend this test and not only check whether packages that share a file listed in Contents.gz can be co-installed but also packages which access/change/create the same files in their pre/post-install maintainer scripts do? Is the information about which files are touched in any way by maintainer scripts generated already somewhere? I think piuparts only takes two snapshots before installation and after removal but not one in the middle and neither runs a file system access tracer for all other changes to the filesystem? If this could be useful, then I could run some tests locally, using fatrace similar to how I used it to detect unneeded build dependencies. Does this make sense? cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907103606.3685.16945@hoothoot
Re: systemd, again (Re: Cinnamon environment now available in testing)
Hi, Zack Weinberg: > I think this strategy is positively _necessary_ in order to ensure > that systems currently running Wheezy can safely be upgraded to > Jessie. There are simply too many wacky configurations out there; it If we do decide that a default switch is unsafe for too many systems, then I wouldn't have a problem with, for instance, adding a debconf question to systemd-sysv's preinst which tells people what to do if they don't want systemd for whatever reason. > [ symlink and co-installability ] If technically feasible, that would be a far better safety net (just tell people to boot with init=/sbin/sysvinit if they run into a problem) than an "oh dear, it's so dangerous that we don't even install it by default" message. :-/ -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907101808.gn21...@smurf.noris.de
Re: Detecting more undeclared conflicts (was: Re: Bug#758234: Raising priority of Debian packages)
On Sun, Sep 7, 2014 at 6:36 PM, Johannes Schauer wrote: > would it make sense to extend this test and not only check whether packages > that share a file listed in Contents.gz can be co-installed but also packages > which access/change/create the same files in their pre/post-install maintainer > scripts do? Could you provide an example of the kind of bug this test would detect? [I'm subscribed, no need to CC] -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6f4jnh2kmt01bod5f5v9kfbfsfz5o675sfnb5w5xmk...@mail.gmail.com
Re: Bug#758234: Raising priority of Debian packages
* Paul Wise , 2014-09-07, 17:38: We should probably also monitor package conflicts. We made a big fuss about node vs nodejs (and rightly so); but I bet that we have lots of other package pairs in the archive that can't be co-installed for no good reason. We have this already: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-file-overwrite;users=trei...@debian.org https://qa.debian.org/dose/file-overwrites.html Nah, I meant packages that do declare that they can't be co-installed. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907105153.ga5...@jwilk.net
Bug#760729: ITP: python-librtmp -- librtmp binding for Python
Package: wnpp Severity: wishlist Owner: Stefan Breunig * Package name: python-librtmp Version : 0.2.1 Upstream Author : Christopher Rosell * URL : http://pythonhosted.org/python-librtmp/ * License : BSD-2-clause Programming Lang: Python Description : librtmp binding for Python librtmp allows one to dump the media content streamed over the RTMP protocol. This package provides the bindings for Python. python-librtmp is an optional dependency for livestreamer, allowing livestreamer to access ustream desktop streams, for example. I plan to maintain this package myself, but I’m going to need a sponsor. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907110007.3236.90371.reportbug@localhost.localdomain
Re: systemd, again (Re: Cinnamon environment now available in testing)
On Sun, Sep 07, 2014 at 12:18:08PM +0200, Matthias Urlichs wrote: > Hi, > > Zack Weinberg: > > I think this strategy is positively _necessary_ in order to ensure > > that systems currently running Wheezy can safely be upgraded to > > Jessie. There are simply too many wacky configurations out there; it > > If we do decide that a default switch is unsafe for too many systems, then > I wouldn't have a problem with, for instance, adding a debconf question to > systemd-sysv's preinst which tells people what to do if they don't want > systemd for whatever reason. > > > [ symlink and co-installability ] > > If technically feasible, that would be a far better safety net (just tell > people to boot with init=/sbin/sysvinit if they run into a problem) than > an "oh dear, it's so dangerous that we don't even install it by default" > message. :-/ Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking upgrades here, not new installs. -- "If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing." --- Malcolm X -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907111201.GA11840@tal
Bug#760734: general: no sounds on headphones
Package: general Severity: normal Dear Maintainer, Recently I upgraded from Wheezy to Jessie only to find a very annoying bug. There is no sound on headphones, however the speakers still work fine. I googled for answered (purge pulseaudio, delete ~/etc/pulse, make sure alsamixer doesn't mute anything etc.) but nothing works. Please help me fix this soon because I really need headphones for my study. Thank you. -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907113555.3849.54815.reportbug@uyen
Re: Cinnamon environment now available in testing
On Sat, 6 Sep 2014, Michael Biebl wrote: > Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not > going to make it the first alternative. Installing a half-broken logind > whould be a disservice to our users. Uhm, did you read this subthread at all? Let me try to summarise: At best, switching the order would be no change in the systemd scenario, but improve the situation for users of other init systems. At worst, switching the order would install a package that is a no-op in the systemd scenario, but improve the situation for users of other init systems. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1409071406500.4...@tglase.lan.tarent.de
Re: systemd, again
On Sun, 7 Sep 2014, Andreas Metzler wrote: > I think that is terrible idea, because it makes us release a system > that is lot less tested than it should be. If only fresh installs were Nonsense. sysvinit must continue to work anyway, for various reasons (upgrades, kfreebsd, the TC decision). Also, switching during upgrades is potentially harmful and frowned upon, see the ax25-node vs. nodejs discussion and remember those systems in remote locations. (I am not thinking of systemd breaking booting those, but maybe they run targetted code for log analysis, service management… or even getting the network up and running.) What are the options for a GNOME on wheezy user though? • get systemd • get partial GNOME uninstalled • get an error when trying to dist-upgrade None of these are partially appealing. I can’t find a technical solution for something else offhand. On the other hand, a non-GNOME wheezy user SHALL not be upgraded to systemd, true. bye, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1409071359170.4...@tglase.lan.tarent.de
Re: Cinnamon environment now available in testing
Am 07.09.2014 14:08, schrieb Thorsten Glaser: > On Sat, 6 Sep 2014, Michael Biebl wrote: > >> Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not >> going to make it the first alternative. Installing a half-broken logind >> whould be a disservice to our users. > > Uhm, did you read this subthread at all? I did, but apparently you didn't understand what I said. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: systemd, again (Re: Cinnamon environment now available in testing)
On 2014-09-07, Chris Bannister wrote: > Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking > upgrades here, not new installs. I had my systems painfully and transparantly upgraded to systemd. And I'm happy it happens. Please keep it this way. I do want my systems to look the same, no matter if it is my workstation installed-as-woody or my laptop reinstalled yesterday. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/luhiqv$8t6$1...@ger.gmane.org
Bug#760745: ITP: cleo -- Play back shell commands for live demonstrations
Package: wnpp Owner: Axel Beckert Severity: wishlist * Package name: cleo Version : 0.004 Upstream Author : Jeffrey Ryan Thalhammer * URL : https://metacpan.org/release/App-Cleo * License : Artistic or GPL-1+ Programming Lang: Perl Description : Play back shell commands for live demonstrations cleo is a utility for playing back pre-recorded shell commands in a live demonstration. cleo displays the commands as if you had actually typed them and then executes them interactively. The package will maintained under the hat of the Debian Perl Group. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907130508.db24e...@c-cactus.ontheroad.deuxchevaux.org
Re: systemd, again (Re: Cinnamon environment now available in testing)
On 2014-09-07, Sune Vuorela wrote: > I had my systems painfully and transparantly upgraded to systemd. And > I'm happy it happens. Please keep it this way. I apparantly like pain. or maybe s/ful/less/ is the appropriate reading. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/luhkds$qpi$1...@ger.gmane.org
Re: systemd, again (Re: Cinnamon environment now available in testing)
]] Marc Haber
> On Sat, 6 Sep 2014 15:56:23 +0200, Matthias Urlichs
> wrote:
> >Marc Haber:
> >> On Fri, 05 Sep 2014 15:12:50 +0200, Svante Signell
> >> wrote:
> >> >On Fri, 2014-09-05 at 14:20 +0200, Matthias Urlichs wrote:
> >> >> Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
> >> >> to switch to systemd (by whatever means, the details of which I
> >> >> personally
> >> >> am not at all interested in), a dist-upgrade should do so.
> >> >
> >> >How? All efforts so far and bugs reported are being brought down
> >> >actively.
> >>
> >> #618862, dating back to 2011 and with no Debian maintainer reaction in
> >> months?
> >>
> >This bug's latest entry asks the original reporter whether the bug still
> >applies.
>
> The long, anonymous elaborate does not address the actual issue. And,
> it's clear that - should the anonymous poster be correct - keyscript
> is only supported for the root file system, not for any other fsses
> that might get mounted later.
It works for anything that's mounted from the initramfs, not just the
root file system, in addition to anything mounted by hand later, but
otherwise that's correct.
> >The systemd transition is not simple. I do not think it's reasonable to
> >expect the Debian maintainer to be able to reproduce every problem, so what
> >else would you have them do about this bug?
>
> I would expect at least a try to keep something supported that has
> been supported in Debian für years. This is a serious regression that
> makes systems unbootable and up to now the only fix seems to be to
> reduce security by resorting to keys typed in at boot time.
You make the assumption that there's not been an tries to resolve this,
which is wrong. As for security, well, I have a keyscript that unlocks
my boot drive just fine, but handled through initramfs, not systemd.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2bnqr36e4@rahvafeir.err.no
Re: systemd, again (Re: Cinnamon environment now available in testing)
Hi, On Samstag, 6. September 2014, Matthias Urlichs wrote: > No. I expect them all to continue running just peachy fine and seamlessly. > I also expect the Jessie upgrade to switch to systemd. Because, frankly and > strictly IMHO, doing anything else makes no sense whatsoever. > > On the other hand, I *do* expect anybody who does NOT want to switch to > systemd to already know before upgrading that they'll need to do somethink > non-standard if they really want to stay with sysVinit / switch to > [another_init] instead, simply because they already know that the default > upgrade will switch. FWIW, I fully agree. This is how I expect upgrades to Jessie and new installs will be handled. I also think installing with legacy or less widely used initsystems should be well hidden (and probably explained in the manual). I guess a good opportunity for contributors not captable of extending d-i to do this, is to contribute patches to the manual. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#760756: ITP: python-dib-utils -- Standalone tools related to diskimage-builder
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-dib-utils Version : 0.0.6 Upstream Author : OpenStack developers * URL : https://github.com/openstack/dib-utils * License : Apache-2.0 Programming Lang: Python Description : Standalone tools related to diskimage-builder These tools were originally part of the diskimage-builder project, but they have uses outside of that project as well. Because disk space is at a premium in base cloud images, pulling in all of diskimage-builder and its dependencies just to use something like dib-run-parts is not desirable. This project allows consumers to use the tools while pulling in only one small package with few/no additional dependencies. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907142943.20810.3750.report...@buzig.gplhost.com
Re: systemd, again (Re: Cinnamon environment now available in testing)
Hi,
Chris Bannister:
> > If technically feasible, that would be a far better safety net (just tell
> > people to boot with init=/sbin/sysvinit if they run into a problem) than
> > an "oh dear, it's so dangerous that we don't even install it by default"
> > message. :-/
>
> Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking
> upgrades here, not new installs.
>
I am talking "if we decide to use a configurable symlink, then
surely systemd will have the highest priority". [*]
Yes, that does mean that, if you do not do anything else, your system will
boot with systemd. Which IMHO is as it should be.
Quite frankly: If you're savvy enough to do something to your init setup
that is no longer supported, and at the same time stupid enough to upgrade
to Jessie without reading the release notes _and_ ignore systemd-sysv's
debconf notice (which doesn't exist yet, but should probably be added),
then that's your own damn fault.
[*] /etc/alternatives isn't really suitable for this, because you could not
boot with an empty /etc directory. systemd wants to be able to do that
("factory reset"). But there are other possibilities.
--
-- Matthias Urlichs
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140907151102.go21...@smurf.noris.de
Re: Bug#758234: Raising priority of Debian packages
Hello, On Sun, Sep 07, 2014 at 12:51:53PM +0200, Jakub Wilk wrote: > * Paul Wise , 2014-09-07, 17:38: > >>We should probably also monitor package conflicts. We made a big fuss > >>about node vs nodejs (and rightly so); but I bet that we have lots of > >>other package pairs in the archive that can't be co-installed for no > >>good reason. > > > >We have this already: > > > >https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=edos-file-overwrite;users=trei...@debian.org > >https://qa.debian.org/dose/file-overwrites.html > > Nah, I meant packages that do declare that they can't be co-installed. Jakub is right, the bugs that I am tracking on [1] concern only cases where there is no conflict declared in the metadata, yet the two packages fail to install together. Having said that, it might be possible to use dose-debcheck to do the check you have in mind. Maybe you can spare me reading the 139 messages in the bug report and tell me what precisely you need: Is it that every single package can be installed using only packages of the same or higher priority ? -Ralf. [1] https://qa.debian.org/dose/file-overwrites.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907154514.gb1...@seneca.home.org
Re: systemd, again (Re: Cinnamon environment now available in testing)
On Sun, 07 Sep 2014 15:30:11 +0200, Tollef Fog Heen wrote: >You make the assumption that there's not been an tries to resolve this, >which is wrong. As for security, well, I have a keyscript that unlocks >my boot drive just fine, but handled through initramfs, not systemd. Those tries are invisible in the bug report, which is bad. To investigate, I need time to set up a breakable reference system. I broke an important productive system by an unwanted "upgrade" to systemd once, that's not going to happen to me again. 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xqell-0001dx...@swivel.zugschlus.de
Re: Cinnamon environment now available in testing
Hey. On Sat, 2014-09-06 at 14:08 +0200, Michael Biebl wrote: > Steve, as long as bugs like [1] are not fixed in systemd-shim, I'm not > going to make it the first alternative. Installing a half-broken logind > whould be a disservice to our users. Kinda strange to use *that* as an argument, while you guys to basically the very same with NetworkManager for a long time now. It's more any more forced upon users while at the same time, it's basically broken for most but a very little subset of lowest-end-user scenarios. At the same time, both upstream and the maintainers, state that they do not intend to make NM working/integrate with the native network managing tools, or other such toolsets. So apart from the fact that I'm mostly in favour of systemd, it's kinda strange to read the argument we should not "install a half-broken [...] whould be a disservice to our users." o.O Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Standardizing the layout of git packaging repositories
On Sat, 2014-09-06 at 22:03 -0700, Manoj Srivastava wrote: > On Sun, Sep 07 2014, Scott Kitterman wrote: > > > On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava > > wrote: > > > I'll confess up front that I'm a neophyte when it comes to git. From > > what I can tell though we've been using git-dpm for feature branches > > in pkg-clamav and it seems to me to work fine. > > Oh, it works mostly fine, with some finicky handling of the > ephemeral patched branch. I must worry about checking out the patched > branch, sherry picking commits to it, handling conflicts, rebasing, > squashing, rearranging -- and I did all that for a while before I > discovered git-debcherry, It got old fast. Perhaps it is my fault, my > feature branches sometimes have slightly overlapping changes. I never > ever want to muck with something merely to create serialized linear > patches for packaging. [...] How does git-debcherry cope with the overlapping changes when generating debian/patches? What can you do if it fails to linearise the changes (as, apparently, it may sometimes do)? Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Bug#760788: ITP: jarisplayer -- flash video and audio player for embedding into a web page
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: jarisplayer Version : 2.0.15 Upstream Author : Jefferson González * URL : http://jarisflvplayer.org/ * License : LGPL-3+ or GPL-3+ Programming Lang: HaXe Description : flash video and audio player for embedding into a web page Jaris FLV Player is a flash flv/mp4 video and audio player with the most important basic features found in other commercial players. . Features: * Aspect ratio switcher * Fullscreen support * H.264 playback support * Http pseudo-streaming support * RTMP streaming support * Youtube player API support * Poster image * Use your own logo with link * Hide controls on fullscreen * Custom control colors * Hardware scaling * Keyboard shortcuts * Javascript interface to control the player Package will be maintained in collab-maint area. Co-maintainers are quite welcome. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQF8BAEBCgBmBQJUDMAfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0 RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vW9xIH+gN1duxl6nOsiM0UHHRbjfAS 5eUv5/OuzWPfoDLhhqEmtMAHYIvEiaoTKfC8powodSeMoqCV7X8AfX53zL0NJhgg fTnzY6wvl3/7Kbe4Dm+2Q/yi89AbSU9O83Qr7dUtGnvMx4HyXPsTJYY5fs/5p2O8 ZCfKQkeSBEEXp8EmSfWou+KQjmFwiCfblK6MeHFES7SJoybr2LKNjoBoJJ8cfUAe a9z5o0wJa0p53ka90dzDsxVtBQ1pCRxiVN+80N5KXxyByYVj0O1+MewI70wk+OYg SUD0x1GdYF/EzPQByP7KbHQY8xcHa9dKpirAn4tzOqAqKD8CB1JHad1z/VDBVrg= =Wz80 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907202923.8060.52582.report...@bastian.jones.dk
Re: There should not be dependencies on systemd
El sáb, 6 de sep 2014 a las 2:18 , Ansgar Burchardt escribió: Noel Torres writes: If you need dbus, you should Depend on dbus, and systemd should Provides dbus. Then, if Ann programs her Own Dbus Implementation she can package it as aodi (Ann's Own Dbus Implementation) and have aodi Provides dbus. Same for logind (systemd Provides logind and random-package Depends logind), and any other piece of the big systemd ecosystem. Any dependence on systemd or any other init system should be considered an RC bug (except only packages designed to manage the init system, like an imaginary systemd-tweaking-tool). That doesn't change anything in practice as long as systemd would be the only package providing logind. So until someone writes an alternative implementation, it would just be useless work. systemd-shim can get you a logind implementation w/o systemd as PID 1. With the above scenario (virtual packages like logind), apt would be smart and install the least disruptive package. Do you think that would be systemd-shim (no removal of current init) or systemd-sysv (removal of packages)? Best, -- Cameron Norman
Re: More tasks option in Tasksel: what tasks do you want there?
On Sun, Sep 07, 2014 at 04:37:31PM +0800, Thomas Goirand wrote: > Hi, > > During Debconf14, I could chat with Joey about the future of Tasksel, > and having a "More option" task, which would lead to a new screen which > would propose more tasks. > > Before anyone can implement this plan, we have to make sure that we all > agree on what kind of tasks we want to implement. What I already agreed > with Joey, is that having a list of 200 tasks will *not* be helpful, so > we have to make sure we carefully choose what we will implement. So I > have setup a wiki page so that we can share our thoughts. Is there a page for "LessTasks"? The current d-i tasksel page is: ☑ Debian desktop environment ☐ web server ☑ print server ☐ SQL database ☐ DNS server ☐ file server ☐ mail server ☐ SSH server ☐ laptop ☑ standard system utilities What is "SQL database"? Current it stands for just "unconfigured postgres". No mysql which any newbish person would think of when they hear the words "linux database". We may have valid reasons to claim postgres is better, but that doesn't mean a vast majority of random howtos on the Interwebs will talk about mysql. Then, why not mariadb? Why not sqlite? Why not firebird? Database selection aside, unconfigured postgres is worthless. I won't buy that someone able to learn how to create an user + database, allow them to login then allow connections from the outside world would have trouble with "apt-get install postgresql". Same applies to "file server". This task installs nfs-kernel-server, samba. Not owncloud or whatever. Both unconfigured. How is that better than just letting the user install whatever file server kind they want? "DNS server" at least works, but I doubt it's worth taking space on the primary task screen. "laptop" could be hidden -- there's a lot more configuration that d-i autodetects for you. It's not like a machine is likely to switch between being a laptop and not... (tablets with detachable keyboard need all laptop machinery too). So let's start with trimming the list. This will provide some space for choosing between XFCE/Mate/Gnome3/KDE/WindowMaker/fvwm/etc, which is an important decision to be made at tasksel step. -- // If you believe in so-called "intellectual property", please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907220222.ga30...@angband.pl
Re: More tasks option in Tasksel: what tasks do you want there?
On 07.09.2014 18:02, Adam Borowski wrote: On Sun, Sep 07, 2014 at 04:37:31PM +0800, Thomas Goirand wrote: Hi, During Debconf14, I could chat with Joey about the future of Tasksel, and having a "More option" task, which would lead to a new screen which would propose more tasks. Before anyone can implement this plan, we have to make sure that we all agree on what kind of tasks we want to implement. What I already agreed with Joey, is that having a list of 200 tasks will *not* be helpful, so we have to make sure we carefully choose what we will implement. So I have setup a wiki page so that we can share our thoughts. Is there a page for "LessTasks"? The current d-i tasksel page is: ☑ Debian desktop environment ☐ web server ☑ print server ☐ SQL database ☐ DNS server ☐ file server ☐ mail server ☐ SSH server ☐ laptop ☑ standard system utilities [...] So let's start with trimming the list. This will provide some space for choosing between XFCE/Mate/Gnome3/KDE/WindowMaker/fvwm/etc, which is an important decision to be made at tasksel step. Having just recently rebuilt one of my laptops with the current Jessie image it would have been nice if "Debian desktop environment" were able to give me a choice as I didn't want Xfce so I had to wait till it finished installing, rebooted, found out Xfce was picked for me so I could purge it and install what I wanted for my desktop environment. Likewise Exim4 might be well and good for some but it's not my MTA of choice when I go to install a mail server, so being able to have a choice between the MTAs available would actually be nice. At this point the only viable option is to uncheck everything, install as a bare base system and then deal with package inclusion post-install reboot. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/6eb0e27a00a517bc90a1618f849ba...@undergrid.net
Re: Cinnamon environment now available in testing
On Fri, Sep 05, 2014 at 12:37:12PM -0700, Cameron Norman wrote: > On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette wrote: > > Noel Torres wrote: > >> So we are clearly failing to follow the least surprise (for the user) path. > >> > >> Should not logind depend on systemd-shim | systemd-sysv instead? > > > > No. Systemd is the default init system. The default dependencies should > > reflect that. > > It has already been explained that it being the default makes the > order switching irrelevant for what you recommend. If people are using > the default init, the dependency will already be satisfied and life > will not be disrupted. The same thing should happen if people are > using a different init: that decision should be maintained unless they > manually uninstall the package that satisfies the init package's > dependency. Most Debian systems aren't using sysvinit by active choice, but because it was the default when they installed their machines, so this argument doesn't really make sense. Kind regards, David Weinehall -- /) David Weinehall /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140907224512.gc3...@hirohito.acc.umu.se
Re: Standardizing the layout of git packaging repositories
Hi, You have to ask Paul Bremer that. Me, I am merely a happy user. I did grok it at one point, but I no longer recall that. Manoj On September 7, 2014 11:05:50 AM PDT, Ben Hutchings wrote: >On Sat, 2014-09-06 at 22:03 -0700, Manoj Srivastava wrote: >> On Sun, Sep 07 2014, Scott Kitterman wrote: >> >> > On September 6, 2014 11:30:11 PM EDT, Manoj Srivastava > wrote: >> >> > I'll confess up front that I'm a neophyte when it comes to git. >From >> > what I can tell though we've been using git-dpm for feature >branches >> > in pkg-clamav and it seems to me to work fine. >> >> Oh, it works mostly fine, with some finicky handling of the >> ephemeral patched branch. I must worry about checking out the >patched >> branch, sherry picking commits to it, handling conflicts, rebasing, >> squashing, rearranging -- and I did all that for a while before I >> discovered git-debcherry, It got old fast. Perhaps it is my fault, >my >> feature branches sometimes have slightly overlapping changes. I >never >> ever want to muck with something merely to create serialized linear >> patches for packaging. >[...] > >How does git-debcherry cope with the overlapping changes when >generating >debian/patches? What can you do if it fails to linearise the changes >(as, apparently, it may sometimes do)? > >Ben. > >-- >Ben Hutchings >Experience is directly proportional to the value of equipment >destroyed. >- Carolyn Scheppner -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: More tasks option in Tasksel: what tasks do you want there?
Adam Borowski wrote: > >Is there a page for "LessTasks"? ... >So let's start with trimming the list. This will provide some space for >choosing between XFCE/Mate/Gnome3/KDE/WindowMaker/fvwm/etc, which is an >important decision to be made at tasksel step. This is (almost) exactly what's being worked on after discussions at DebConf. By removing some of the less useful tasks, we'll be able to add some extra more useful options. -- Steve McIntyre, Cambridge, UK.st...@einval.com You raise the blade, you make the change... You re-arrange me 'til I'm sane... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1xqm23-0007xw...@mail.einval.com
Re: More tasks option in Tasksel: what tasks do you want there?
Hi, On Montag, 8. September 2014, Steve McIntyre wrote: > This is (almost) exactly what's being worked on after discussions at > DebConf. By removing some of the less useful tasks, we'll be able to > add some extra more useful options. so where's the commit doing what Adam described? The freeze is near ;) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: python-openssl unavailable in sid
On 21 August 2014 10:42, Cyril Brulebois wrote: > Adding ftpmasters in the loop to make sure they see your report. > > dak sees: > python-openssl | 0.14-1 | sid | all > > while the amd64 Packages file only lists: > python-openssl-dbg (amd64) > python-openssl-doc (all) > python3-openssl-dbg (amd64) > > https://ftp-master.debian.org/removals.txt reports that the following > packages were indeed removed from sid: > python-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, > kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc > python3-openssl | 0.13.1-2+b1 | amd64, armel, armhf, hurd-i386, i386, > kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x, sparc > > So it looks to me it might “just” be about getting arch:all packages > listed again in Packages files. > As far as I can tell, this problem has been fixed. ftp-master didn't respond, maybe it come good by itself? -- Brian May
Re: More tasks option in Tasksel: what tasks do you want there?
On Sep 08, Adam Borowski wrote: > Same applies to "file server". This task installs nfs-kernel-server, samba. > Not owncloud or whatever. Both unconfigured. How is that better than just > letting the user install whatever file server kind they want? > What is "SQL database"? Current it stands for just "unconfigured > postgres". Agreed. There is no point in having tasks which are mostly equivalent to "apt-get install something" and do not even provide something which immediately works for less technical users (who are the target audience of tasks). They do no help these users (even worse: they create false expectations) and can be immeditely recognized as a stupid waste of attention by everybody else. On Sep 08, "Jeremy T. Bouse" wrote: > Having just recently rebuilt one of my laptops with the current Jessie image > it would have been nice if "Debian desktop environment" were able to give me > a choice as I didn't want Xfce so I had to wait till it finished installing, Me too, and I expect many many others as well. If we really have to appease the followers of the single CD install religion then at least we should provide a Gnome task for everybody else. -- ciao, Marco signature.asc Description: Digital signature
Re: Standardizing the layout of git packaging repositories
On 8 September 2014 04:05, Ben Hutchings wrote: > How does git-debcherry cope with the overlapping changes when generating > debian/patches? What can you do if it fails to linearise the changes > (as, apparently, it may sometimes do)? > I am not sure this needs to be an issue. Or maybe I am just not seeing the problem correctly... Where do I get git-debcherry from? Would like to get a copy so I can prove my preconceived and fixed ideas on which one is better .^C^C^C^C^C^C^C Would like to get a copy so I can understand some of these issues better myself. -- Brian May
Re: More tasks option in Tasksel: what tasks do you want there?
Steve McIntyre (2014-09-08): > This is (almost) exactly what's being worked on after discussions at > DebConf. By removing some of the less useful tasks, we'll be able to > add some extra more useful options. At some point it would really be nice to have a summary of what happened or what was discussed at DebConf, but on mailing lists. While I'm very happy to see stuff happen during in person meetings, keeping people who weren't there out of the loop shouldn't happen IMO. (I'm probably biased since I'm in that category; and maybe additionally slightly annoyed since I spent quite some time providing material for discussion with no feedback as of yet.) Mraw, KiBi. signature.asc Description: Digital signature
Re: More tasks option in Tasksel: what tasks do you want there?
On Mon, Sep 08, 2014 at 02:33:06AM +0200, Cyril Brulebois wrote: >Steve McIntyre (2014-09-08): >> This is (almost) exactly what's being worked on after discussions at >> DebConf. By removing some of the less useful tasks, we'll be able to >> add some extra more useful options. > >At some point it would really be nice to have a summary of what happened >or what was discussed at DebConf, but on mailing lists. While I'm very >happy to see stuff happen during in person meetings, keeping people who >weren't there out of the loop shouldn't happen IMO. > >(I'm probably biased since I'm in that category; and maybe additionally >slightly annoyed since I spent quite some time providing material for >discussion with no feedback as of yet.) ACK. I'm planning on writing up summaries of all three of my DebConf sessions, much as I did for DC12. Expect that in the next couple of days. I'd encourage other people to do the same where possible, but I understand it's a lot of effort. -- Steve McIntyre, Cambridge, UK.st...@einval.com "When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908004407.ge24...@einval.com
Re: Standardizing the layout of git packaging repositories
Hi, You need to bag Ron, or pull from the hit repositories directly. Manoj On September 7, 2014 5:24:18 PM PDT, Brian May wrote: >On 8 September 2014 04:05, Ben Hutchings wrote: > >> How does git-debcherry cope with the overlapping changes when >generating >> debian/patches? What can you do if it fails to linearise the changes >> (as, apparently, it may sometimes do)? >> > >I am not sure this needs to be an issue. Or maybe I am just not seeing >the >problem correctly... > >Where do I get git-debcherry from? > >Would like to get a copy so I can prove my preconceived and fixed ideas >on >which one is better .^C^C^C^C^C^C^C >Would like to get a copy so I can understand some of these issues >better >myself. >-- >Brian May -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Cinnamon environment now available in testing
El dom, 7 de sep 2014 a las 3:45 , David Weinehall escribió: On Fri, Sep 05, 2014 at 12:37:12PM -0700, Cameron Norman wrote: On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette wrote: > Noel Torres wrote: >> So we are clearly failing to follow the least surprise (for the user) path. >> >> Should not logind depend on systemd-shim | systemd-sysv instead? > > No. Systemd is the default init system. The default dependencies should > reflect that. It has already been explained that it being the default makes the order switching irrelevant for what you recommend. If people are using the default init, the dependency will already be satisfied and life will not be disrupted. The same thing should happen if people are using a different init: that decision should be maintained unless they manually uninstall the package that satisfies the init package's dependency. Most Debian systems aren't using sysvinit by active choice, but because it was the default when they installed their machines, so this argument doesn't really make sense. But some are, and this completely leaves them out in the cold. One option is to put a "heads up" in systemd-sysv, or some other type of glue so that on an upgrade, people know what is happening to their systems. Best regards, -- Cameron
Bug#760803: ITP: strip-nondeterminism -- tool for stripping non-determinism from files
Package: wnpp Severity: wishlist Owner: Andrew Ayer * Package name: strip-nondeterminism Version : 0.001 Upstream Author : Andrew Ayer * URL : https://anonscm.debian.org/cgit/reproducible/strip-nondeterminism.git * License : GPL-3+ Programming Lang: Perl Description : tool for stripping non-determinism from files strip-nondeterminism is a tool to strip bits of non-deterministic information, such as timestamps, from files. It can be used as a post-processing step to make a build reproducible, when the build process itself cannot be made deterministic. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908015844.13355.25439.report...@wagg.int.beanwood.com
Re: Removing < 2048 bit keys from the Debian keyrings
peter green dijo [Sun, Aug 31, 2014 at 01:27:11PM +0100]: > Jonathan McDowell wrote: > >I would ask that DDs make some effort to help > >those with weak keys get their new, stronger keys signed. Please sign > >responsibly[4], > If you have signed someones old key is it considered "responsible" > to sign their new key based on a transition statement signed by the > old key? or is a new face-to-face meeting required? I've seen plenty > of (sometimes conflicting) advice on signing keys of a person you > have never signed keys for before but not much on the transition > situation. (note: this is a general question to consider, I'm not > personally in a position where it would apply) As you saw through others' answers to your question, it varies a lot. I personally also don't sign based on transition documents, but would do so in case the requester *really* needed it. Now, I know that if at some point my key were to be compromised, I'd also be in a "needy" situation (as I'm currently the only DD in a ~1000Km radius), and would have to find a way out. I have found several people who would sign based on transition documents, and it's also OK. It's completely a personal issue, although it does impact us all as a project. Yes, at some point we will need to make our rules a *little* bit more flexible, but I'd prefer that flexibility to be made on specific accounts' behalf (i.e. either by DAM or by keyring-maint, and based on specific checks such as a phone verification) than to suggest to everybody to relax. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908023701.ga124...@gwolf.org
Bug#760734: general: no sounds on headphones
Hey, On 07/09/14 13:35, quang wrote: > Recently I upgraded from Wheezy to Jessie only to find a very annoying bug. > There is no sound on headphones, however the speakers still work fine. I > googled for answered (purge pulseaudio, delete ~/etc/pulse, make sure > alsamixer > doesn't mute anything etc.) but nothing works. Please help me fix this soon > because I really need headphones for my study. Thank you. > > -- System Information: > Debian Release: jessie/sid > APT prefers testing-updates > APT policy: (500, 'testing-updates'), (500, 'testing') > Architecture: amd64 (x86_64) You seem to be looking for a user support. Did you try asking at: [1] IRC at #debian-next channel at irc.oftc.net [2] debian-user mail group [3] Debian User Forums [4] Ask Debian page Please update this bug report (you can do that by sending an email to 760...@bugs.debian.org) if your problem was resolved or if no one was able to help you there. Regards, T. [1] https://wiki.debian.org/IRC [2] http://lists.debian.org/debian-user/ [3] http://forums.debian.net/ [4] http://ask.debian.net/ signature.asc Description: OpenPGP digital signature
Re: Standardizing the layout of git packaging repositories
On 8 September 2014 04:05, Ben Hutchings wrote: > How does git-debcherry cope with the overlapping changes when generating > debian/patches? What can you do if it fails to linearise the changes > (as, apparently, it may sometimes do)? > Just did some fiddling. I have no idea if this is the git-debcherry I should be using or not, so far it is the only copy I have found: git://pivot.cs.unb.ca/gitpkg.git I created a script that generates a some commits on different feature branches, with a deliberate conflict. Unexpectedly, this means there is only one patch generating with both feature branches included. However the results appear to be technically correct. My random thought: I like being able to predict what will happen to patches in git-dpm. For example, if I supply the git-debcherry produced patch file name, when upstream get around to looking at it, that patch may no longer exist because I (accidentally?) created a newer patch that conflicts. Not sure if there is an easy way to tell if two feature branches conflict or not. This might be me and/or something that can be fixed in git-debcherry though. Regardless, if you need to make a sequence of changes, say to one file, git-dpm would appear to be the better choice, I think. Note the script does a "rm -rf a", so don't do this on anything important. git-debcherry location is also hard coded. === cut === #!/bin/sh set -ex rm -rf a mkdir a cd a git init touch readme.txt git add readme.txt git commit -m "upstream" git branch upstream # feature a version 1 git checkout -b feature_a upstream echo "My line 1" > readme.txt echo "My line 1" > readme0.txt git add readme.txt readme0.txt git commit -m "feature a version 1" # feature b version 1 git checkout -b feature_b upstream echo "My line 2" > readme2.txt git add readme2.txt git commit -m "feature b version 1" # merge feature a and feature b into debian git checkout -b debian upstream git merge feature_a -m "merge feature a" git merge feature_b -m "merge feature b" # modify feature a git checkout feature_a echo "My line 1 (modified)" > readme.txt git add readme.txt git commit -m "feature a version 2" # merge feature a into debian git checkout debian git merge feature_a -m "merge feature a" # modify feature b, make it conflict with feature a git checkout feature_b echo "My line 1 (extra modified)" > readme.txt echo "My line 2 (extra modified)" > readme2.txt git add readme.txt readme2.txt git commit -m "feature b version 2" # merge feature b into debian, resolve conflict git checkout debian git merge feature_b -m "merge feature b" -X theirs # generate patch ../gitpkg/git-debcherry -o debian/patches upstream ../gitpkg/git-debcherry --stat upstream === cut === The gives me one patch file, with all the changes: === cut === >From 71ed7d5182996226fdaa4c1195a3e0dd0bb3fce7 Mon Sep 17 00:00:00 2001 From: Brian May Date: Mon, 8 Sep 2014 13:13:35 +1000 Subject: [PATCH] debcherry fixup patch 18eb718 feature b version 2 - no changes against upstream or conflicts 558086e feature a version 2 - extra changes or conflicts a898018 feature b version 1 - extra changes or conflicts daa2cc6 feature a version 1 - extra changes or conflicts --- readme.txt | 1 + readme0.txt | 1 + readme2.txt | 1 + 3 files changed, 3 insertions(+) create mode 100644 readme0.txt create mode 100644 readme2.txt diff --git a/readme.txt b/readme.txt index e69de29..2f782d4 100644 --- a/readme.txt +++ b/readme.txt @@ -0,0 +1 @@ +My line 1 (extra modified) diff --git a/readme0.txt b/readme0.txt new file mode 100644 index 000..d6d5ab4 --- /dev/null +++ b/readme0.txt @@ -0,0 +1 @@ +My line 1 diff --git a/readme2.txt b/readme2.txt new file mode 100644 index 000..977df1d --- /dev/null +++ b/readme2.txt @@ -0,0 +1 @@ +My line 2 (extra modified) -- 1.9.1 === cut === -- Brian May
Re: Standardizing the layout of git packaging repositories
On 7 September 2014 13:30, Manoj Srivastava wrote: > > | I commit | Ephemeral gbranch contains | Master contains | > |--++-| > | B2 | A11, B12, B21 | D6 | > > There are there nodes in the ephemeral branch, and three patches > are produced -- Corresponding to A1, B1, and B2. > Oh, so you want separate patches for each stage, B1, B2, etc? I assumed you would want to combine them into one patch. If I understand this correctly, I think your git debcherry example would squash them into one commit. Or at least, that seems to be what happens for my specific test case. -- Brian May
Re: Standardizing the layout of git packaging repositories
hi, no, I get one patch per commit, plus a fixup patch. no squashing. Manoj On September 7, 2014 8:53:04 PM PDT, Brian May wrote: >On 7 September 2014 13:30, Manoj Srivastava >wrote: > >> >> | I commit | Ephemeral gbranch contains | Master contains | >> |--++-| >> | B2 | A11, B12, B21 | D6 | >> >> There are there nodes in the ephemeral branch, and three >patches >> are produced -- Corresponding to A1, B1, and B2. >> > >Oh, so you want separate patches for each stage, B1, B2, etc? > >I assumed you would want to combine them into one patch. > >If I understand this correctly, I think your git debcherry example >would >squash them into one commit. Or at least, that seems to be what happens >for >my specific test case. >-- >Brian May -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: Standardizing the layout of git packaging repositories
hi, ill send out a concrete example when I get back home Manoj On September 7, 2014 8:41:45 PM PDT, Brian May wrote: >On 8 September 2014 04:05, Ben Hutchings wrote: > >> How does git-debcherry cope with the overlapping changes when >generating >> debian/patches? What can you do if it fails to linearise the changes >> (as, apparently, it may sometimes do)? >> > >Just did some fiddling. > >I have no idea if this is the git-debcherry I should be using or not, >so >far it is the only copy I have found: git://pivot.cs.unb.ca/gitpkg.git > >I created a script that generates a some commits on different feature >branches, with a deliberate conflict. > >Unexpectedly, this means there is only one patch generating with both >feature branches included. However the results appear to be technically >correct. > >My random thought: I like being able to predict what will happen to >patches >in git-dpm. For example, if I supply the git-debcherry produced patch >file >name, when upstream get around to looking at it, that patch may no >longer >exist because I (accidentally?) created a newer patch that conflicts. > >Not sure if there is an easy way to tell if two feature branches >conflict >or not. This might be me and/or something that can be fixed in >git-debcherry though. > >Regardless, if you need to make a sequence of changes, say to one >file, git-dpm would appear to be the better choice, I think. > >Note the script does a "rm -rf a", so don't do this on anything >important. git-debcherry location is also hard coded. > > >=== cut === >#!/bin/sh > >set -ex > >rm -rf a > >mkdir a >cd a >git init > >touch readme.txt >git add readme.txt >git commit -m "upstream" > >git branch upstream > ># feature a version 1 >git checkout -b feature_a upstream >echo "My line 1" > readme.txt >echo "My line 1" > readme0.txt >git add readme.txt readme0.txt >git commit -m "feature a version 1" > ># feature b version 1 >git checkout -b feature_b upstream >echo "My line 2" > readme2.txt >git add readme2.txt >git commit -m "feature b version 1" > ># merge feature a and feature b into debian >git checkout -b debian upstream >git merge feature_a -m "merge feature a" >git merge feature_b -m "merge feature b" > ># modify feature a >git checkout feature_a >echo "My line 1 (modified)" > readme.txt >git add readme.txt >git commit -m "feature a version 2" > ># merge feature a into debian >git checkout debian >git merge feature_a -m "merge feature a" > ># modify feature b, make it conflict with feature a >git checkout feature_b >echo "My line 1 (extra modified)" > readme.txt >echo "My line 2 (extra modified)" > readme2.txt >git add readme.txt readme2.txt >git commit -m "feature b version 2" > ># merge feature b into debian, resolve conflict >git checkout debian >git merge feature_b -m "merge feature b" -X theirs > ># generate patch >../gitpkg/git-debcherry -o debian/patches upstream >../gitpkg/git-debcherry --stat upstream >=== cut === > >The gives me one patch file, with all the changes: > >=== cut === >>From 71ed7d5182996226fdaa4c1195a3e0dd0bb3fce7 Mon Sep 17 00:00:00 2001 >From: Brian May >Date: Mon, 8 Sep 2014 13:13:35 +1000 >Subject: [PATCH] debcherry fixup patch > >18eb718 feature b version 2 > - no changes against upstream or conflicts >558086e feature a version 2 > - extra changes or conflicts >a898018 feature b version 1 > - extra changes or conflicts >daa2cc6 feature a version 1 > - extra changes or conflicts >--- > readme.txt | 1 + > readme0.txt | 1 + > readme2.txt | 1 + > 3 files changed, 3 insertions(+) > create mode 100644 readme0.txt > create mode 100644 readme2.txt > >diff --git a/readme.txt b/readme.txt >index e69de29..2f782d4 100644 >--- a/readme.txt >+++ b/readme.txt >@@ -0,0 +1 @@ >+My line 1 (extra modified) >diff --git a/readme0.txt b/readme0.txt >new file mode 100644 >index 000..d6d5ab4 >--- /dev/null >+++ b/readme0.txt >@@ -0,0 +1 @@ >+My line 1 >diff --git a/readme2.txt b/readme2.txt >new file mode 100644 >index 000..977df1d >--- /dev/null >+++ b/readme2.txt >@@ -0,0 +1 @@ >+My line 2 (extra modified) >-- >1.9.1 >=== cut === >-- >Brian May -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Re: systemd, again (Re: Cinnamon environment now available in testing)
On Sun, Sep 07, 2014 at 11:12:01PM +1200, Chris Bannister wrote: > Surely, it should be an OPT-IN choice, not an OPT-OUT one? I'm talking > upgrades here, not new installs. I have no clue why we are continuing to discuss this. The ctte resolution says that "the default init system for Linux architectures in jessie should be systemd". There is no extra provision "on new installs" in the resolution. If you want OPT-IN, your options are: * Ask the ctte to further clarify their position. * Raise a GR. Your options do not include: * Further pester debian-devel with this matter. That said, it certainly makes sense to document how to opt out of systemd in the release notes. I guess you just volunteered. Thanks in advance Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140908060511.ga27...@alf.mars
