Bug#732997: new upstream version(s) available
Package: ledgersmb Version: 1.3.25 Severity: wishlist Tags: security 1.3.35 has been released some time ago, so we are several releases behind here... There's at *least* one _set_ of security vulnerabilities affecting both wheezy and sid right now, documented here: http://ledgersmb.org/news/ledgersmb-130-1327-security-advisories There's also this: http://ledgersmb.org/release/ledgersmb-1328-released-contains-security-fixes So neither stable or sid are secure right now... -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
On 2013-12-31 05:45:01, Andreas Cadhalpun wrote: > Hi anarcat, Hi Andreas! > Installing on UEFI firmware is supported, but is a little bit tricky, > see for example [1]. Particularly you need a GPT partitioned hard disk > with two additional partitions, one EFI partition marked with the 'boot' > flag in gparted and a partition for grub marked as 'bios_grub' in > gparted. Yeah... I struggled with that before, and I *was* able to make it work, but since it wasn't obvious this was necessary *during* the installer, I did a normal MBR-based partitionning. When the boot loader failed to install, I didn't want to go back and redo everything, especially since this is a dual-boot system and I was happy to have been able to resize the NTFS partition at all... ;) (That resize, btw, was quite scary - I am not sure I did it right. First off it was very fast, so I suspect only the boundaries of the filesystem were changed, without telling NTFS. Then when we rebooted into Windows 7, it did a disk check which thankfully worked fine and it seems the Windows install is okay. But I can't think of doing this on an older system - it would have probably destroyed data, which is not clearly stated in partman. > Then the installer has to support installing on UEFI, which the > default installer does, but I don't know about the one you created. I was able to dig out more information about the image since then: $ less .disk/info Debian GNU/Linux 7.0.0 "Wheezy" - Official Snapshot amd64 LIVE/INSTALL Binary 20130505-18:46 $ less .disk/udeb_include netcfg ethdetect pcmciautils-udeb live-installer From what I understand, debian-installer supports installing on UEFI/GPT, but partman doesn't support *creating* GPT partitions, do I get this right? Shouldn't we create GPT partitions all the time now anyways? > Last but not least, you have to select the UEFI:USB in the firmware > and not BIOS:USB, which every firmware has a different marking scheme > for, but disabling legacy-bios (or equivalent option) in the UEFI > BIOS, should always disable the BIOS:USB option. (It can be enabled > again after installation.) Right, I guess this is the tricky bit. It seems that in any case, the user needs to go fiddle in the BIOS, which is annoying. In my case, I was able to install by *disabling* UEFI in the BIOS, but the reverse might be the case for others. Tricky. > > The next missing thing was wifi. I tried installing firmware-linux- > > nonfree, but that wasn't enough - firmware-iwlwifi was the one that > > was required. > > The installer should install the correct firmware, if you have (on some > partition accessible during installation) a /firmware folder that > contains the unpacked firmware bundle, which can be downloaded from [2]. > But this is currently broken, see [3]. Understood. The weird thing is that the live image did find the wifi card without a problem, but it wasn't found after the install was done. Oh, and I forgot to mention that I had to remove this block for Network-Manager to properly pickup the wired interface: auto eth0 iface eth0 inet dhcp Otherwise it would say wired: not managed, which is strange to me... > > I also had to go in the gnome control center to make sure the touch > > pad works as expected. > > What exactly did you have to do in the gnome control center? I went into "Mouse and Touchpad", clicked on the "Touchpad" tab, and enabled "touch to click" and two fingers scrolling. (I type this from memory, from my desktop where I don't have a touch pad. ;) > What do you mean by 'works as expected'? My user was expecting the "touch to click" to work out of the box, and we were worried this wasn't supported, and in fact it wasn't until gnome was installed (XFCE failed to configure it properly). This is especially annoying on this laptop because the buttons are completely part of the touchpad construction, so it's actually difficult to "click" without moving the mouse slightly. > > Wanting this thing to be pretty, I also had to manually install > > plymouth to get a nicer boot up sequence, *and* I had to edit > > /etc/default/grub to make that work (add the "splash" parameter), > > something I wouldn't expect a novice to be able to do at all on a > > first install. > > While I also prefer having plymouth installed, I think there are many > users that prefer not to have it, so one cannot make everyone happy with > the default installation. Clearly bike shed material. ;) > That being said, I think it really might be a good idea to install > plymouth by default, as 'novices' generally prefer it, and anyone who > wants to see the boot messages should have sufficient knowledge to > remove it. I totally agree with that. One thing I noticed with plymouth is that even when you install it, it doesn't properly configure grub, you still have to go around the grub config and (*gasp*) edit a weird configuration file! ;) I would have expected the plymouth postinst to configure grub autom
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
On 2013-12-31 10:23:18, Luca Capello wrote: > Hi there! > > On Tue, 31 Dec 2013 15:50:39 +0100, Antoine Beaupré wrote: >> On 2013-12-31 05:45:01, Andreas Cadhalpun wrote: >> Yeah... I struggled with that before, and I *was* able to make it work, >> but since it wasn't obvious this was necessary *during* the installer, I >> did a normal MBR-based partitionning. When the boot loader failed to >> install, I didn't want to go back and redo everything, especially since >> this is a dual-boot system and I was happy to have been able to resize >> the NTFS partition at all... ;) > > Sorry, but there is something strange here. In the first email you > reported that "when I rebooted, grub was not installed in the MBR and I > was brought back into windows", which means that partman used the > partition table already present. This can be checked with a simple > `fdisk -l /dev/sda`: if there is no GPT mention, then the partition > table is plain old MBR. > > BTW, Windows 7 does not mandate GPT nor UEFI, but can use both. Oh right - I used the original partitionning I guess. I assumed it was MBR. >> Shouldn't we create GPT partitions all the time now anyways? > > Why? IMHO if there is no need for it (because BIOS is used) plain old > MBR is easier. The reason is that it will fail on newer BIOS, from what I can tell. >>> Last but not least, you have to select the UEFI:USB in the firmware >>> and not BIOS:USB, which every firmware has a different marking scheme >>> for, but disabling legacy-bios (or equivalent option) in the UEFI >>> BIOS, should always disable the BIOS:USB option. (It can be enabled >>> again after installation.) >> >> Right, I guess this is the tricky bit. It seems that in any case, the >> user needs to go fiddle in the BIOS, which is annoying. In my case, I >> was able to install by *disabling* UEFI in the BIOS, but the reverse >> might be the case for others. > > No need to fiddle in the BIOS if you simply use UEFI (d-i supports it). That would imply reformatting the whole drive and destroying all the data, from what I understand. Unless d-i can convert a MBR partition to GPT? A. -- Voter, c'est abdiquer - Élisée Reclus pgpYRHOG2JOFO.pgp Description: PGP signature
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
On 2014-01-01 05:05:18, Andreas Cadhalpun wrote: > On 31.12.2013 15:50, Antoine Beaupré wrote: >> (That resize, btw, was quite scary - I am not sure I did it right. First >> off it was very fast, so I suspect only the boundaries of the filesystem >> were changed, without telling NTFS. Then when we rebooted into Windows >> 7, it did a disk check which thankfully worked fine and it seems the >> Windows install is okay. But I can't think of doing this on an older >> system - it would have probably destroyed data, which is not clearly >> stated in partman. > > The resize usually is relatively fast, if the part you are removing from > the filesystem does not contain any data, because then no data has to be > moved and only the file system has to be updated to the new size. I > think chkdsk is always scheduled after a resize of NTFS, just to be on > the safe side. > This should also work perfectly fine on an older system, but there it > might take considerably longer, since the data is more likely to be > distributed over the whole partition. > Of course, one should always have backups of important data. Well, that's reassuring - I somehow thought only the partitions were resized, without telling the filesystem. Good job there! :) In my days, you had to to move bits around with a magnet to resize FAT12 partitions and NTFS was satan! You kids have it t easy. ;) >>> > The next missing thing was wifi. I tried installing firmware-linux- >>> > nonfree, but that wasn't enough - firmware-iwlwifi was the one that >>> > was required. >>> >>> The installer should install the correct firmware, if you have (on some >>> partition accessible during installation) a /firmware folder that >>> contains the unpacked firmware bundle, which can be downloaded from [2]. >>> But this is currently broken, see [3]. >> >> Understood. The weird thing is that the live image did find the wifi >> card without a problem, but it wasn't found after the install was done. > > Did you have a /firmware folder around? As you installed wheezy, this > should have worked, because it is only broken in jessie/sid. Yes, there was a firmware folder, it only contained a .deb of linux-firmware. >> Oh, and I forgot to mention that I had to remove this block for >> Network-Manager to properly pickup the wired interface: >> >> auto eth0 >> iface eth0 inet dhcp >> >> Otherwise it would say wired: not managed, which is strange to me... > > This is bug #724928 [1], which was fixed in the Wheezy 7.2 installer. That sounds familiar! I guess I need to update my image. ;) >> My user was expecting the "touch to click" to work out of the box, and >> we were worried this wasn't supported, and in fact it wasn't until gnome >> was installed (XFCE failed to configure it properly). >> >> This is especially annoying on this laptop because the buttons are >> completely part of the touchpad construction, so it's actually difficult >> to "click" without moving the mouse slightly. > > These seem to be bugs in xfce4 and gnome respectively. You should report > them there. It seems more users prefer this (see [2]) and I also do. Well, #2 is about a serious bug that makes unrelated things just not work when you enable "disable touchpad while typing". It seems to me this bug should be fixed, but it is not related to enabling the touch functionality on the... touch pad. ;) Probably not related to gnome only either... But I understand this is another serious bikeshed material and fold. :) >>> That being said, I think it really might be a good idea to install >>> plymouth by default, as 'novices' generally prefer it, and anyone who >>> wants to see the boot messages should have sufficient knowledge to >>> remove it. >> >> I totally agree with that. One thing I noticed with plymouth is that >> even when you install it, it doesn't properly configure grub, you still >> have to go around the grub config and (*gasp*) edit a weird >> configuration file! ;) >> >> I would have expected the plymouth postinst to configure grub >> automagically. :) But then that's more an issue with plymouth itself >> than the installer. > > You could report this as a bug in plymouth, but it is probably not > trivial to fix, because which configuration file has to be changed, > depends on which boot loader is used. Actually I'm not even sure it is > possible, because the boot loader may be installed after plymouth (as > the installer does), or it might be changed after plymouth is installed. Yeah, this se
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
On 2014-01-01 14:18:21, Andreas Cadhalpun wrote: > Do you agree that this bug can be closed now? Sure yes. I was hoping to improve the process a little, but the challenge seems to be beyond my patience in dealing with multiple packages... Besides, there are significant problems related to the way I built the installer which will not happen again in a more recent one. I mostly wanted to document that Debian works on the E431 anyways. :) Thanks for the feedback! A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker http://www.ad-mad.co.uk/quotes/freespeech.htm pgp08cT60No3z.pgp Description: PGP signature
Bug#724471: smokeping: FTBFS: configure.ac:24: error: required file 'conftools/compile' not found
On 2014-02-14 05:42:16, Niko Tyni wrote: > On Tue, Sep 24, 2013 at 08:50:59AM +0300, Damyan Ivanov wrote: >> Package: src:smokeping >> Version: 2.6.8-2 >> Severity: serious >> Justification: FTBFS >> >> smokeping fails to build in a clean current sid pbuilder chroot: >> >> make[1]: Entering directory `/tmp/buildd/smokeping-2.6.9' >> aclocal >> autoconf >> automake >> configure.ac:24: error: required file 'conftools/compile' not found >> configure.ac:24: 'automake --add-missing' can install 'compile' >> make[1]: *** [override_dh_auto_configure] Error 1 >> make[1]: Leaving directory `/tmp/buildd/smokeping-2.6.9' >> make: *** [build] Error 2 > > Antoine, are you still maintaining smokeping? It's been RC buggy for > half a year and was removed from testing three months ago. I have been quite busy. If anyone wants to NMU this, feel free. I'm happy to keep on maintaining smokeping, but if others want to step in to help, that is always welcome. smokeping is in collab-maint and i'm in the LowNMU treshold list. But right now I use smokeping mostly on wheezy, so this problem doesn't really affect us so $WORK can't pay for this right now. I'll certainly fix this by the time jessie is released. :) A. -- Be who you are and say what you feel Because those who mind don't matter And those who matter don't mind. - Dr. Seuss pgpkHLwid8wfr.pgp Description: PGP signature
Bug#738732: build_trans fails if called seperately
Control: tags -1 pending Thanks for the heads up, this is fixed in the git repo. A. -- The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.- Friedrich Nietzsche pgpRtoEhDsQ5A.pgp Description: PGP signature
Bug#738731: build_slides fails of two reasons
Control: tags -1 pending On 2014-02-12 08:59:51, Felix Dreissig wrote: > Package: monkeysign > Version: 2.x > Severity: minor > > There are two minor issues with the build_slides() function, which attempts > to build 'presentation.html' from 'presentation.rst': > > 1. It is always part of the build, but `rst2s5` might not always be present. > Thus it should either be removed from the standard build, or > 'python-docutils' may be listed as a dependency on the website and not only > in 'debian/control'. i have added a predicate so this doesn't fail if rst2s5 is missing, can you try the 2.x branch again? i also cherry-picked this to the 1.x branch. > 2. Even if `rst2s5` is available, the command fails because > ‘presentation.rst' is not in the top directory. > Simly changing `file=` to `doc/presentation.rst` in 'setup.cfg' unfortunately > breaks the way the output path is determined, but that is probably easily > fixable. fixed as well, but only in the affected branch (2.x). A. -- A ballot is like a bullet. You don't throw your ballots until you see a target, and if that target is not within your reach, keep your ballot in your pocket. - Malcom X pgpfjpAHfta8e.pgp Description: PGP signature
Bug#738730: build_manpage only works because of PyGTK encoding changes
Control: tags -1 pending
On 2014-02-12 08:56:03, Felix Dreissig wrote:
> Package: monkeysign
> Version: 2.x
> Severity: normal
>
> I wanted to build the manpage only for Monkeysign’s CLI version, so I removed
> `monkeyscan:monkeysign.gtkui:MonkeysignScanUi.parser` from ‘setup.cfg' and
> ran `setup.py build_manpage`.
> That failed with:
>
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 55:
>> ordinal not in range(128)
>
> An encoding problem didn’t make any sense to me, so I tried to track the
> issue down. Turns out it doesn’t occur when PyGTK is imported into the build
> process, either directly through 'gtkui.py' or via 'msg_exception.py'.
> The explanation for this behaviour is that PyGTK sets Python’s default
> encoding to UTF-8. This is GNOME bug 132040 from back in 2004:
> https://bugzilla.gnome.org/show_bug.cgi?id=132040
>
> So what exactly causes the above error?
> It is the accent in your surname, anarcat, that causes manpage writing to
> fail with ASCII encoding ;-). The best way to fix this would in my opinion be
> using an unicode string for `author` in 'setup.py', but Disutils seem not to
> respect that.
damn french. ;)
i agree that author should be unicode, no idea while distutils is
dropping that to the floor. oh well.
> I used the following patch, which works:
>
>> --- a/monkeysign/documentation.py
>> +++ b/monkeysign/documentation.py
>> @@ -84,7 +84,7 @@ class build_manpage(Command):
>> def _write_footer(self, parser):
>> ret = []
>> appname = self.distribution.get_name()
>> -author = '%s <%s>' % (self.distribution.get_author(),
>> +author = '%s <%s>' %
>> (self.distribution.get_author().decode('utf-8'),
>>self.distribution.get_author_email())
>> ret.append(('.SH AUTHORS\n.B %s\nwas written by %s.\n'
>> % (self._markup(appname), self._markup(author
>> @@ -109,7 +109,7 @@ class build_manpage(Command):
>> path = os.path.join(self.output, parser.prog + '.1')
>> self.announce('writing man page to %s' % path, 2)
>> stream = open(path, 'w')
>> -stream.write(''.join(manpage))
>> +stream.write(''.join(manpage).encode('utf-8'))
>> stream.close()
I used a slight variation, i decode in the ret.append() call so that the
email can also contain accents, which may be illegal, but I don't care:
i'm not going to go enforcing standards here, i want to avoid crashes at
build time. :)
> It might, however, not be the most comprehensive way to deal with the issue:
> The whole process of generating manpages uses a mixture of ordinary and
> unicode strings and might need some review with respect to encoding issues.
true. this was messy in the first place, although I am not sure i want
to pursue this much further. :P
thanks for all the patches and help!
a.
--
That's the kind of society I want to build. I want a guarantee - with
physics and mathematics, not with laws - that we can give ourselves
real privacy of personal communications.
- John Gilmore
pgpyhjfp6iEYW.pgp
Description: PGP signature
Bug#718624: still fails with systemd
On 2014-02-14 17:03:02, anarcat wrote: > I tried the workarounds proposed in the bug report: > > 1. changing the user in the service file > 2. changing the home directory (sudo usermod debian-transmission -d > /var/lib/transmission-daemon/) > 3. adding -g to the service file Alright, I finally got it to work, with similar steps than #22. Here's what I did: 1. override the service file in /etc/systemd/system/transmission-daemon.service 2. create the home directory *and* related .config directory: usermod debian-transmission -d /var/lib/transmission-daemon mkdir -p /var/lib/transmission-daemon/.config/transmission-daemon chown -R debian-transmission /var/lib/transmission-daemon 3. optionally: migrate my old status files: cd /var/lib/transmission-daemon/ ; mv info/* .config/transmission-daemon 4. start with systemd: systemctl start transmission-daemon This works! Here's the modified service file: [Unit] Description=Transmission BitTorrent Daemon After=network.target [Service] User=debian-transmission Type=simple #EnvironmentFile=-/etc/default/transmission-daemon ExecStart=/usr/bin/transmission-daemon -f --log-error [Install] WantedBy=multi-user.target Notice how I *don't* import the environment from the existing defaults file, which is a shame because we loose some settings, but this is unavoidable because --config-dir really breaks everything. Maybe there would be a way to still import $OPTIONS from the defaults yet override the --config-dir somehow to fix those problems? Anyways, it would be nice to have a clean upgrade path here. :) Thanks for the help and pointers to the folks in #debian-systemd! A. PS: I opened bug report #739071 in systemd regarding the difficulties I had diagnosing that core dump. I feel we were just shooting in the dark, and that's a problem... -- Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208 pgpLZmRpFLKsy.pgp Description: PGP signature
Bug#736120: traceback when signing --- monkeysign.gpg.GpgProtocolError
On 2014-02-15 07:06:18, Emilien Klein wrote: > Hi Antoine, > > 2014-01-21 8:49 GMT+01:00 Emilien Klein : >> You should have received mine just now. >> Thanks for looking into it. > > Were you able to look into the examples Zack and I sent you? No, I haven't, sorry. A. -- I'm sorry if any of you are catholic. I'm not sorry if you're offended, I'm actually just sorry by the fact that you're catholic - Bill Hicks pgpMwMfSoqmsB.pgp Description: PGP signature
Bug#738731: build_slides fails of two reasons
On 2014-02-15 21:34:27, Felix Dreissig wrote: > On 14 Feb 2014, at 17:13, Antoine Beaupré wrote: >> i have added a predicate so this doesn't fail if rst2s5 is missing, can >> you try the 2.x branch again? > > The approach generally works, however I still see a "rst2s5: command not > found" error message. > It now just doesn’t emerge from the actual slides build, but from the > has_rst2s5() check. You should probably send stdout to '/dev/null' as well. Actually, I prefer to see that warning there, so that people know a bit is missing if they want a complete build. A. -- Thousands of candles can be lit from a single candle And the life of the candle will not be shortened. Happiness never decreases by being shared. - Buddha pgpuDXJbQSbl_.pgp Description: PGP signature
Bug#739071: [Pkg-systemd-maintainers] Bug#739071: no core dumps and hard to diagnose
On 2014-02-17 14:07:13, Michael Stapelberg wrote: > Hi Antoine, > > Antoine Beaupré writes: >> I have tried to set a path for core dumps to make sure they are written: >> >> sysctl kernel.core_pattern=/var/cache/core/%u-%e-%p-%s-%t.core >> mkdir /var/cache/core >> chmod 1777 /var/cache/core >> >> No effect: no core dump is created by tranmission. > You need LimitCORE=infinity in your service file (which does the same as > ulimit -c unlimited in sysv init scripts). This was not very clear in the manpages I could find. All that systemd.exec says is to refer to setrlimit(2) which is not very clear that we can use the keyword "infinity". So maybe the bug is over there. ;) > With that setting, getting a core dump works fine on my machine, > i.e. after installing transmission-daemon 2.81-1 and dropping the > following file in > /etc/systemd/system/transmission-daemon.service.d/fixes.conf: > > [Service] > LimitCORE=infinity > User=debian-transmission > > I get a core dump after running systemctl daemon-reload && systemctl > restart transmission-daemon.service. > > Can you confirm that it works for you? Then I’ll close the bug. I'll do my best to reproduce, thanks for the support! A. -- Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas. - Sébastien Faure pgpWKyziJMoJA.pgp Description: PGP signature
Bug#739071: [Pkg-systemd-maintainers] Bug#739071: no core dumps and hard to diagnose
On 2014-02-17 14:43:03, Michael Stapelberg wrote: > Hi Antoine, > > Antoine Beaupré writes: >>> You need LimitCORE=infinity in your service file (which does the same as >>> ulimit -c unlimited in sysv init scripts). >> >> This was not very clear in the manpages I could find. All that >> systemd.exec says is to refer to setrlimit(2) which is not very clear >> that we can use the keyword "infinity". So maybe the bug is over >> there. ;) > > I think you overread the third sentence entirely, which describes > precisely the keyword “infinity”: > >LimitCPU=, LimitFSIZE=, LimitDATA=, LimitSTACK=, LimitCORE=, >LimitRSS=, LimitNOFILE=, LimitAS=, LimitNPROC=, LimitMEMLOCK=, >LimitLOCKS=, LimitSIGPENDING=, LimitMSGQUEUE=, LimitNICE=, >LimitRTPRIO=, LimitRTTIME= >These settings control various resource limits for executed >processes. See setrlimit(2) for details. Use the string >infinity to configure no limit on a specific resource. Ouch, okay, i totally overlooked that, sorry. :) A. -- Information is not knowledge. Knowledge is not wisdom. Wisdom is not truth. Truth is not beauty. Beauty is not love. Love is not music. Music is the best. - Frank Zappa pgpxgDBNnxBa6.pgp Description: PGP signature
Bug#734753: About your intent to packaging wallabag
On 2014-02-18 11:13:47, Victor Moral wrote: > On 18/02/14 16:45, Antoine Beaupré wrote: > > Of course! All help is welcome! :) In fact, the message you saw was a > "RFP" > (Request For Package) and not an "ITP" (Intent To Package). So in reality, > I wasn't planning to package this myself, but merely looking for someone > else to make a package. > > > Excellent ! Then I'll begin to read the links and build a skeleton for it. > The > name has changed from poche to wallabag some weeks ago (see this link for a > explanation). I think that the package name will be wallabag-0.1-1, isn't it ? The name of the package would be wallabag, the version would be 1.5.0-1. A. -- Ce que les siècles des grands abatoirs nous aura appris Devrait être inscrit au fond de toutes les écoles; Voici l'homme: le destructeur des mondes est arrivé. - [no one is innocent] pgpzQD8NIyD8c.pgp Description: PGP signature
Bug#739645: RFP: hubot -- A customizable, kegerator-powered life embetterment robot.
Package: wnpp Severity: wishlist * Package name: hubot Version : 2.7.1 Upstream Author : GitHub Inc. * URL : http://hubot.github.com/ * License : Expat Programming Lang: Coffeescript Description : A customizable, kegerator-powered life embetterment robot. Hubot is a chat bot, modeled after GitHub's Campfire bot, hubot. He's pretty cool. He's extendable with community scripts and your own custom scripts, and can work on many different chat services. This seems to be the new cool kit in the town of IRC/Jabber/etc bots... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739647: please upload to sid
Package: irker Version: 1.17+dfsg-3 Severity: normal Can this package be uploaded to sid please? -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages irker depends on: ii python 2.7.5-5 ii python-irc 8.5.3+dfsg-2 irker recommends no packages. irker suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#739651: consider switching to the limnoria codebase
Package: supybot Severity: normal It seems this now the most active codebase for supybot: https://github.com/ProgVal/Limnoria -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729203: Packaging for FFmpeg avoiding conflicts with libav
On 2014-02-22 12:39:20, Andreas Cadhalpun wrote: > Hi all, > > I have looked at the packaging provided by Antoine and it seems - no > offense intended - a little bit messy. Hehe, none taken. To my defense, I did that in about an hour, using Marillat's packages... :) > Thus I have started from scratch and packaged FFmpeg 2.1.3 [1] (see > attached debian.tar.xz). Awesome! > I have taken care to avoid conflicts with libav as far as possible, but > the development files have to conflict, as it is really no good idea to > build against both ffmpeg and libav at the same time. You mean the -dev libraries? > The ffmpeg package does not provide qt-faststart to avoid a conflict > with libav-tools. Fair enough - there could be a qt-faststart binary package which could conflict with libav-tools. > The libraries are build with --enable-raise-major, which bumps the > sonames by 100 to get i.e. libavcodec155, thus avoiding conflicts. > Note that there is also --enable-incompatible-libav-abi that would allow > packages build against libav to be used with the ffmpeg library, but > upstream thinks this would not work the other way round as well. And I > think there wouldn't be too much use for FFmpeg libraries that can only > be used as a drop in replacement the libav ones, but not to compile > programs. Makes sense. > As the libav development packages are called libavcodec-dev etc., FFmpeg > has to use different names and I chose libavcodec-ffmpeg-dev and so on. I guess that makes sense... > I'm not sure if this package will build on every architecture, because I > can't test that. Maybe an upload to experimental could test that? :) > Any build failures could probably be sorted out by disabling some > features for some architectures, as I enabled as many features as > possible for building on linux-amd64, as long as the result is still > GPLv2 licensed. (Only four codecs are GPLv3.) Makes sense as well. > I fixed most of the lintian problems, but some remain: > > * E: debian-watch-file-pubkey-file-is-missing: >This is a bug in lintian [2]. > * E: embedded-library: I don't understand this one: >Does it complain about libavfilter embedding libavfilter? >Seems like a bug in lintian. Not sure about those. > * W: manpage-has-errors-from-man: >I don't know how to fix the manpages. Can someone help? I had the manpage errors as well, I think we can ignore those for now. > * I: no-symbols-control-file: >If anyone wants to create one, feel free to do so. > > With this package, users can install either ffmpeg or libav-tools and > developers can either depend on lib*-ffmpeg-dev or on lib*-dev and > everyone should be happy. That would be awesome. > Adrian, do you agree that this is sane? > > If the security team is not willing to support both, they can ask the TC > to decide which one to use, but this does not prevent an upload of FFmpeg. I don't see why security would complain: as things stand there are hundreds of security issues that have been fixed in ffmpeg (see the Google audit) which have not been fixed in libav... It seems to me ffmpeg is only more secure than libav at this point... > I think this package is ready for upload, but I'm neither DD nor DM, so > I can't do this. I would be hesistant in doing so, considering the controversy, but if we reach consensus here, i'd be happy to sponsor it. > Rogério, Jackson are you willing to review my packaging and then > upload/maintain it? I can help e.g. rebuilding reverse-dependencies for > future transitions and similar stuff. > > In fact, If have rebuild the 109 reverse build-dependencies of src:libav > simply exchanging lib*-dev with lib*-ffmpeg-dev and 59 build > successfully, only 50 FTBFS (similarly many fail building with libav 10 > [3], probably due to the same reasons [4]). > Most failures are due to missing AVCODEC_MAX_AUDIO_FRAME_SIZE and > CodecID. Only two packages check for a version smaller than 100 and thus > fail to configure. > > I hope FFmpeg will be back in Debian soon. Good work, cheers! A. -- We have no friends but the mountains. - Kurdish saying pgpKIxKRpxgP4.pgp Description: PGP signature
Bug#577955: xscreensaver: runs unicode with invalid options
Package: xscreensaver-data-extra Version: 5.23-1 Followup-For: Bug #577955 This is still a problem. Now I see: Usage: unicode [options] arg unicode: error: no such option: -t A. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xscreensaver-data-extra depends on: ii dictionaries-common 1.21.0 ii libc62.17-97 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.38.2-5 ii libice6 2:1.0.8-2 ii libjpeg-progs8d-2 ii libsm6 2:1.2.1-2 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxmu6 2:1.1.1-1 ii libxpm4 1:3.5.10-1 ii libxt6 1:1.1.4-1 ii netpbm 2:10.0-15+b2 ii xscreensaver-data5.23-1 xscreensaver-data-extra recommends no packages. xscreensaver-data-extra suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#577955: xscreensaver: runs unicode with invalid options
Package: xscreensaver-data-extra Followup-For: Bug #577955 Actually, the problem here is that the unicode-screensaver package is not installed, so instead of looking at /usr/lib/xscreensaver, it looks into $PATH, which fails. Maybe it should disable the screensaver instead? a. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xscreensaver-data-extra depends on: ii dictionaries-common 1.21.0 ii libc62.17-97 ii libgdk-pixbuf2.0-0 2.28.2-1+b1 ii libglib2.0-0 2.38.2-5 ii libice6 2:1.0.8-2 ii libjpeg-progs8d-2 ii libsm6 2:1.2.1-2 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii libxmu6 2:1.1.1-1 ii libxpm4 1:3.5.10-1 ii libxt6 1:1.1.4-1 ii netpbm 2:10.0-15+b2 ii xscreensaver-data5.23-1 xscreensaver-data-extra recommends no packages. xscreensaver-data-extra suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740025: RFP: liquidfeedback -- platform for proposition development and decision making
Package: wnpp
Severity: wishlist
* Package name: liquidfeedback
Version : 2.2.5
Upstream Author : Public Software Group e. V., Berlin, Germany
* URL : http://liquidfeedback.org/
* License : MIT/X
Programming Lang: Lua, PL/SQL
Description : platform for proposition development and decision making
>From wikipedia:
LiquidFeedback (abbreviated lqfb) is a free software for political
opinion formation and decision making, combining aspects of
representative and direct democracy. Its most important feature is
the implementation of a Delegated voting system ("Liquid Democracy")
which is to establish a new form of political representation and
participation that takes into account the knowledge disparity of its
participants.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740038: pulseaudio hangs in D (uninterruptible sleep)
Package: pulseaudio Version: 4.0-6+b1 Severity: important It is somewhat unclear to me how this happened, but a pulseaudio daemon has hanged on my machine: PID STARTED S TTY TIME COMMAND 10093 Feb 21 D ?01:15:42 /usr/bin/pulseaudio --start --log-target=syslog I have tried to kill the process (even with -KILL), and it just stays there. It has been like this for a while now. I have a rather convoluted setup, with liquidsoap driving pulseaudio, however liquidsoap is stopped now yet PA is still running. Some details on the setup can be perused here: http://anarc.at/services/radio/ I have tried to attach an strace or a gdb to the process, but both simply hang when attaching. Here are some relevant logs: /var/log/syslog.2.gz:Feb 22 11:06:13 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé /var/log/syslog.2.gz:Feb 22 11:06:14 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé /var/log/syslog.2.gz:Feb 22 11:06:23 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé /var/log/syslog.3.gz:Feb 21 17:50:06 marcos pulseaudio[10093]: [pulseaudio] pid.c: Stale PID file, overwriting. /var/log/syslog.3.gz:Feb 21 19:16:24 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé /var/log/syslog.3.gz:Feb 21 19:16:27 marcos pulseaudio[10093]: [alsa-sink-ALC887 Analog] alsa-sink.c: Error opening PCM device front:0: Périphérique ou ressource occupé /var/log/syslog.1:Feb 23 21:11:21 marcos pulseaudio[10093]: [pulseaudio] module-combine-sink.c: Assertion 'pa_idxset_remove_by_data(o->userdata->outputs, o, NULL)' failed at modules/module-combine-sink.c:927, function output_free(). Aborting. /var/log/syslog.1:Feb 23 21:11:21 marcos kernel: [796082.449407] CPU: 1 PID: 10093 Comm: pulseaudio Not tainted 3.12-1-amd64 #1 Debian 3.12.9-1 Here is a translation of the french sentence: "Périphérique ou ressource occupé" means "Resource or device busy" or something to that effect. Note that liquidsoap crashed on feb 21st: 2014/02/21 17:44:46 [threads:2] Queue generic queue #2 crashed with exception File "request.ml", line 512, characters 2-8: Assertion failed 2014/02/21 17:44:46 [threads:2] Called from file "duppy.ml", line 280, characters 9-26 2014/02/21 17:44:46 [threads:1] PANIC: Liquidsoap has crashed, exiting.. 2014/02/21 17:44:46 [threads:1] Please report at: savonet-us...@lists.sf.net 2014/02/21 17:44:47 >>> LOG START 2014/02/21 17:44:46 [protocols.external:3] Found "/usr/bin/wget". 2014/02/21 17:44:46 [main:3] Liquidsoap 1.1.1 Then it was restarted and it's when that dreaded pulseaudio process got spawned: 2014/02/21 17:51:44 [threads:3] Created thread "wallclock_pulse" (1 total). 2014/02/21 17:51:44 [clock.wallclock_pulse:3] Streaming loop starts, synchronized by active sources. I am not sure, however, it was actually writing to that pulseaudio process at that point. I tried to restart liquidsoap yesterday, but it failed: 2014/02/23 21:17:01 [clock.wallclock_pulse:2] Error when starting output pulse_out(liquidsoap:): Pulseaudio error: Timeout! 2014/02/23 21:17:01 [threads:3] Created thread "wallclock_pulse" (1 total). 2014/02/23 21:17:01 [clock.wallclock_pulse:3] Streaming loop starts, synchronized by active sources. 2014/02/23 21:17:01 [server:3] Unlink anaradio.socket 2014/02/23 21:17:01 [main:3] Shutdown started! Notice how it times out talking to pulseaudio. Other commandline tools also fail to talk to PA: liquidsoap@marcos:~$ LANG=C pacmd list Daemon not responding. liquidsoap@marcos:~$ LANG=C pactl list Connection failure: Timeout I understand liquidsoap's pulseaudio implementation may be limited or wrong, but from my perspective, it shouldn't be crashing the daemon the way it is doing right now. I would welcome hints on how to debug this problem, right now I feel that only a reboot will allow me to kill that process, something which is a little odd in itself. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages pulseaudio depends on: ii adduser 3.113+nmu3 ii consolekit0.4.6-3+b1 ii libasound21.0.27.2-3 ii libasound2-plugins1.0.27-2+b1 ii libc6 2.17-97 ii libcap2 1:2.22-1.2 ii libdbus-1-3 1.8.0-1 ii libfftw3-single3 3.3.3-7 ii libgcc1 1:4.8.2-15 ii libice6 2:1.0.8-2 ii libltdl7
Bug#740038: workaround
Lovely... A workaround is to do this: mv .pulse .pulse.old cp .pulse.old/default.pa .pulse Of course the old process is still there, but at least the daemon starts again. A. -- Thousands of candles can be lit from a single candle And the life of the candle will not be shortened. Happiness never decreases by being shared. - Buddha pgp2Tnb3xKR23.pgp Description: PGP signature
Bug#740038: core dump kernel paging oops?
So it seems this could not be PA's fault - I actually had a kernel oops yesterday evening... It could be bad memory but it's the first time I see such a problem: [796082.448453] BUG: unable to handle kernel paging request at c90004efe000 [796082.448521] IP: [] memmove+0x4a/0x1a0 [796082.448568] PGD 21f027067 PUD 21f028067 PMD 216986067 PTE 0 [796082.448615] Oops: 0002 [#1] SMP [796082.448642] Modules linked in: rfcomm bluetooth rfkill usblp joydev hid_dr ff_memless ufs nls_utf8 nls_cp437 vfat fat usb_storage snd_hrtimer cpufreq_stats ppdev lp cpufreq_powersave cpufreq_conservative cpufreq_userspace binfmt_misc iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek kvm_intel kvm pcspkr snd_hda_intel snd_hda_codec snd_hwdep lpc_ich snd_pcm_oss snd_mixer_oss mfd_core snd_pcm evdev snd_page_alloc rng_core snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer parport_pc parport snd asus_atk0110 i915 soundcore video acpi_cpufreq drm_kms_helper drm button processor thermal_sys i2c_algo_bit i2c_core coretemp loop firewire_sbp2 firewire_core crc_itu_t fuse autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq crc32c libcrc32c sha256_ssse3 sha256_generic cbc hid_generic usbhid hid dm_crypt dm_mod sd_mod crct10dif_generic sg sr_mod cdrom crc_t10dif crct10dif_common ata_generic ata_piix libata scsi_mod atl1e ehci_pci uhci_hcd ehci_hcd usbcore usb_common [796082.449407] CPU: 1 PID: 10093 Comm: pulseaudio Not tainted 3.12-1-amd64 #1 Debian 3.12.9-1 [796082.449457] Hardware name: System manufacturer System Product Name/P5G41-M LE, BIOS 050606/11/2010 [796082.449513] task: 880215fe17c0 ti: 8801a38f task.ti: 8801a38f [796082.449559] RIP: 0010:[] [] memmove+0x4a/0x1a0 [796082.449611] RSP: 0018:8801a38f1ad0 EFLAGS: 00010287 [796082.449645] RAX: c90004efe000 RBX: 8800a4f49d40 RCX: ffd7 [796082.449690] RDX: ffe8 RSI: c90004efdff8 RDI: c90004efe000 [796082.449734] RBP: 011a R08: 534547415353454d R09: 5f434c2f72662f65 [796082.449778] R10: 6c61636f6c2f6572 R11: 6168732f7273752f R12: ffd8 [796082.449822] R13: c90004efaa80 R14: 0028 R15: c90004efe028 [796082.449867] FS: 7ff540460740() GS:88021fc8() knlGS: [796082.449916] CS: 0010 DS: ES: CR0: 8005003b [796082.449953] CR2: c90004efe000 CR3: 0001c7402000 CR4: 000407e0 [796082.449997] Stack: [796082.450011] 811c134c c90004ef9000 c90004efad98 8801a38f1d10 [796082.450067] 880094d0aec0 88001d98 81824460 88025000 [796082.450122] 8800013d 013d 1d98 880215fe17c0 [796082.450177] Call Trace: [796082.450200] [] ? elf_core_dump+0x9ac/0x1390 [796082.450252] [] ? __ext4_journal_stop+0x2d/0x80 [ext4] [796082.450296] [] ? fsnotify+0x24e/0x330 [796082.450333] [] ? do_coredump+0xa0b/0xd90 [796082.450372] [] ? get_signal_to_deliver+0x1c0/0x5b0 [796082.450415] [] ? do_signal+0x3d/0x5b0 [796082.450450] [] ? do_send_sig_info+0x4f/0x70 [796082.450488] [] ? do_notify_resume+0x68/0x90 [796082.450527] [] ? int_signal+0x12/0x17 [796082.450560] Code: 00 00 48 81 fa a8 02 00 00 72 05 40 38 fe 74 41 48 83 ea 20 48 83 ea 20 4c 8b 1e 4c 8b 56 08 4c 8b 4e 10 4c 8b 46 18 48 8d 76 20 <4c> 89 1f 4c 89 57 08 4c 89 4f 10 4c 89 47 18 48 8d 7f 20 73 d4 [796082.450833] RIP [] memmove+0x4a/0x1a0 [796082.450871] RSP [796082.450895] CR2: c90004efe000 [796082.452927] ---[ end trace 71e1f157bace73b5 ]--- 796082 is 2014-02-23T21:11:20Z-5 -- That's the kind of society I want to build. I want a guarantee - with physics and mathematics, not with laws - that we can give ourselves real privacy of personal communications. - John Gilmore pgpF6eDW9lGWr.pgp Description: PGP signature
Bug#729203: Intent to package FFmpeg
Stripping CC's. On 2014-02-25 11:43:25, Andreas Cadhalpun wrote: > Antoine, are you willing to sponsor this, maybe becoming a co-maintainer? I am willing to sponsor an upload, but I don't have much time, especially not to become a co-maintainer. It also seems that I may not be perfectly qualified to handle all the subtelties of this tricky package, so if someone else wants to step in, that would be great. > In the not too far future, the long term supported FFmpeg 2.2 will be > released, which I intend to get into jessie. That would be awesome. A. -- Les écrivains qui ont recours à leurs doigts pour savoir s'ils ont leur compte de pieds ne sont pas des poètes, ce sont des dactylographes. - Léo Ferré, "Préface" pgp7Q0Vz3jSop.pgp Description: PGP signature
Bug#736120: traceback when signing --- monkeysign.gpg.GpgProtocolError
On 2014-01-20 19:35:46, Emilien Klein wrote: > I do get the same type of error when trying to sign one particular key > (ironically, Zack's). > I have today signed 15 other keys successfully without this problem. If you guys could both send me, in private if you wish, the output of the same command with --debug, it would be very helpful. Note that this may contain private information so you may want to filter it before sending. You can also send it encrypted to my GPG key, which should be in the debian keyring and well connected. In any case, check the output before sending. A. -- Si les triangles avaient un Dieu, ils lui donneraient trois côtés. - Montesquieu, Lettres persanes pgp6uhpuX_gq5.pgp Description: PGP signature
Bug#721556: photofloat: only suggest *php* packages
On 2014-01-23 22:17:39, Jerome Charaoui wrote: > I agree with the general idea, but PHP is also required by > staticrender.php, which is used to make photofloat (as an AJAX app) > crawlable. I'm not sure relegating that to examples/ as you suggest for > the Zenphoto stuff is optimal. What do you think? I would prefer to keep upstream functionality and file structure. If we want to remove the PHP dependency (which is only a Recommends, mind you), we could simply make our own apache config and ship it in /etc/apache2/conf.d (or whatever it's called nowadays), if the .htaccess is a problem. A. -- The Net treats censorship as damage and routes around it. - John Gilmore pgpMKfpGVT514.pgp Description: PGP signature
Bug#721567: photofloat: should use separately packaged libjs-* packages (not include convenience code copies)
Hi Jonas, On 2013-09-01 19:05:52, Jonas Smedegaard wrote: > It seems photofloat does some attempt at reusing JavaScript packages, > by use of symlinks, but lack declaring dependency on them, I think that will be fixed with the next upload, that's #721562, right? > and still ship with minified files, and a file scripts.min.js bundling > seemingly bundling all JavaScript files - assumingly from included > convenience code copy, not from the separately maintained library > packages. Right, that's the intention anyways. > The package should solely use Javascript library packages for reusable > Javascript code - including getting the jQuery modules packaged which do > not currently exist: If not interested in maintaining those packages > yourself try ask the JavaScript Team to take care of that. Indeed, I think Jerome took care of that. > For the bundling file I think best would be for the package to generate > that file using a dpkg trigger, so that it gets regenerated whenever one > of its dependent library packages are updated. That makes sense. I am not familiar with dpkg triggers, any pointers on where to start? > The bundle file is most optimally minimized if done in one go, instead > of concatenating individually minimized parts. The most efficient and > also most reliable minimizer is uglifyjs. Noted. > Seems only the minified bundle file is the only JavaScript file needed > at the location for use at runtime - other files and symlinks to files > might be better located at a different location, if setting up above > suggested auto-bundling. Right. Maybe we don't even need to ship those in the binary package at all. There are some rough edges in the packaging, I just wanted to get this out the door. I have also made some noise upstream about some patches in the software itself which is itself pretty rough: http://lists.zx2c4.com/pipermail/photofloat/2014-January/31.html Hopefully things will settle down with time. Thanks for your excellent feedback in any case, A. -- Il n'existe aucune limite sacrée ou non à l'action de l'homme dans l'univers. Depuis nos origines nous avons le choix: être aveuglé par la vérité ou coudre nos paupières. - [no one is innocent] pgpn5H6J4C6dX.pgp Description: PGP signature
Bug#721567: [PATCH] Re: photofloat: should use separately packaged libjs-* packages (not include convenience code copies)
On 2014-01-27 00:37:13, Jerome Charaoui wrote: > That should do the trick. Antoine, I should note that instead of creating a > distinct "update-photofloat-js" as we discussed, I reverted to shipping the > upstream Makefile and simply call that to minify+bundle js. Oh yeah, good idea. Quick review of the patch... > diff --git a/debian/photofloat.triggers b/debian/photofloat.triggers > new file mode 100644 > index 000..db0ecc7 > --- /dev/null > +++ b/debian/photofloat.triggers > @@ -0,0 +1,2 @@ > +interest /usr/share/javascript/jquery/jquery.js > +interest /usr/share/javascript/jquery-mousewheel/jquery.mousewheel.js That seems absurdly easy. Did you actually try this out and it works? :) > diff --git a/debian/rules b/debian/rules > index 118de9d..49f0824 100755 > --- a/debian/rules > +++ b/debian/rules > @@ -20,11 +20,5 @@ export DH_OPTIONS > %: > dh $@ --with=python2 > > -override_dh_auto_build: > - dh_auto_build > - ln -s /usr/share/javascript/jquery/jquery.js > $(CURDIR)/web/js/000-jquery-1.7.2.js > - ln -s /usr/share/javascript/jquery-mousewheel/jquery.mousewheel.js > $(CURDIR)/web/js/003-mousewheel.js > - cd $(CURDIR)/web && $(MAKE) > - > override_dh_install: > - dh_install -X.gitignore -XMakefile -Xutils/ > + dh_install -X.gitignore -X*.min.js -Xutils/ Does that mean we still build the minified versions during build, but then don't ship them? Shouldn't just skip that? > diff --git a/web/Makefile b/web/Makefile > index 72aea0d..8224ac5 100644 > --- a/web/Makefile > +++ b/web/Makefile > @@ -7,7 +7,7 @@ CSS_MIN = $(CSS_DIR)/styles.min.css > JS_MIN_FILES := $(sort $(patsubst %.js, %.min.js, $(filter-out %.min.js, > $(wildcard $(JS_DIR)/*.js > CSS_MIN_FILES := $(sort $(patsubst %.css, %.min.css, $(filter-out %.min.css, > $(wildcard $(CSS_DIR)/*.css > > -JS_COMPILER = yui-compressor --type js > +JS_COMPILER = uglifyjs > CSS_COMPILER = yui-compressor --type css > > .PHONY: all clean Another patch with upstream, but nothing in debian/patches. I think we should instead use: JS_COMPILER ?= yui-compressor --type js ... to respect upstream's default yet allow ourselves an override. Then we just call make with: cd /usr/share/photofloat/web && make JS_COMPILER=uglifyjs We should also add a ?= to the CSS_COMPILER while we're there to make sure we can replace that one as well per #721568. Thanks for the patch! A. -- Wire telegraph is a kind of a very, very long cat. You pull his tail in New York and his head is meowing in Los Angeles. Radio operates exactly the same way: you send signals here, they receive them there. The only difference is that there is no cat. - Albert Einstein pgpenPzA4VH06.pgp Description: PGP signature
Bug#721567: [PATCH] Re: photofloat: should use separately packaged libjs-* packages (not include convenience code copies)
On 2014-01-27 11:21:19, Jerome Charaoui wrote: >>> diff --git a/debian/rules b/debian/rules index 118de9d..49f0824 >>> 100755 --- a/debian/rules +++ b/debian/rules @@ -20,11 +20,5 @@ >>> export DH_OPTIONS %: dh $@ --with=python2 >>> >>> -override_dh_auto_build: - dh_auto_build - ln -s >>> /usr/share/javascript/jquery/jquery.js >>> $(CURDIR)/web/js/000-jquery-1.7.2.js - ln -s >>> /usr/share/javascript/jquery-mousewheel/jquery.mousewheel.js >>> $(CURDIR)/web/js/003-mousewheel.js -cd $(CURDIR)/web && $(MAKE) >>> - override_dh_install: -dh_install -X.gitignore -XMakefile >>> -Xutils/ + dh_install -X.gitignore -X*.min.js -Xutils/ >> >> Does that mean we still build the minified versions during build, >> but then don't ship them? Shouldn't just skip that? > > I removed the whole override_dh_auto_build code block, so the > build-time minify doesn't happen anymore. Hum.. I would have thought that without the override, dh_auto_build would still get called and hit the makefile and so on... > Sounds pretty reasonable to me! However upstream uses google-compiler, > so the change would look like : > > - -JS_COMPILER = utils/google-compiler --warning_level QUIET > +JS_COMPILER =? utils/google-compiler --warning_level QUIET Understood. Can you take care of posting the patch upstream as well? Thanks! A. -- Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est pas réfutable relève de la magie ou de la mystique. - Popper, Karl pgpPEpzMVvaB3.pgp Description: PGP signature
Bug#736901: RFP: twister-core -- Peer-to-peer microblogging
Package: wnpp Severity: wishlist * Package name: twister-core Version : N/A Upstream Author : Miguel Freitas * URL : http://www.twister.net.co * License : Expat Programming Lang: C? Description : Peer-to-peer microblogging twister is the fully decentralized P2P microblogging platform leveraging from the free software implementations of Bitcoin and BitTorrent protocols. Packaging may be hindered by the following factor: 1. no release 2. project is alpha 3. twister-core ships convenience (?) copies of: * libtorrent * leveldb 4. it doesn't actually compile on wheezy https://github.com/miguelfreitas/twister-core/issues/18 Maybe it compiles on sid however. Remains to be seen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736901: upstream issues
Relevant upstream issues: * leveldb: https://github.com/miguelfreitas/twister-core/issues/141 * libtorrent: https://github.com/miguelfreitas/twister-core/issues/140 * build failures: https://github.com/miguelfreitas/twister-core/issues/18 * versionning: https://github.com/miguelfreitas/twister-core/issues/52 That's all for now, I will probably not work on this further until the project stabilises. A. -- Travail, du latin Tri Palium trois pieux, instrument de torture. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
Jérome: what's wrong with sass? you seem to be looking through heaven and earth for an alternative... :) a. -- The idea that Bill Gates has appeared like a knight in shining armour to lead all customers out of a mire of technological chaos neatly ignores the fact that it was he who, by peddling second-rate technology, led them into it in the first place. - Douglas Adams (1952-2001) pgpA1iVpqVt4d.pgp Description: PGP signature
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
On 2014-01-29 23:12:50, Jerome Charaoui wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Le 2014-01-29 22:16, Antoine Beaupré a écrit : >> Jérome: what's wrong with sass? you seem to be looking through >> heaven and earth for an alternative... :) > > I don't have any bias against it, it's only that pulling in ruby does > seem a bit overkill. Plus, if we want PhotoFloat to use sass and > handle css syntax errors I think that may require some adjustments > upstream to the Makefile and/or patches, or at least a ship custom > script with the package like Jonas suggests. That's a good point. Ruby is huge, maybe we don't want to add that extra dependency. I am not sure we should worry about CSS syntax errors, that seems like a nice feature anyways. > On the other hand something like cleancss, while it won't exit with a > non-zero status in case of errors in the CSS, would be a drop-in > replacement for yui-compressor (which is still a positive change since > yui-compressor is now deprecated). But then cleancss brings in nodejs, which brings in libv8, which is a whole other beast. > Anyway, I'm okay with both approaches, the first one is more > maintenance but more functional, while the second is only marginally > better than the status quo yet quite trivial to implement. As you wish, I would say. A. -- Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge. - Jimmy Wales, co-founder of Wikipedia pgpQLMGwQHa9M.pgp Description: PGP signature
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
On 2014-01-30 09:29:08, Jonas Smedegaard wrote: > runtime pkgsize bloat: 0 Thanks for those measurements Jonas!! > If you insist on uglifying at runtime, then I still recommend compacting > CSS at build time (300 bytes win is silly when using jQuery bloat!). > > If you insist on uglifying _CSS_ at runtime, then I still recommend > using ruby-sass, and switch to sassc later (see bug#694733,694730). I don't insist at all, in fact I don't understand why we would compress CSS at runtime at all. For JS it makes sense because of section 4.13 (convenience copies), but the CSS is native... We could *suggest* an uglifier of some sort (and the jury's still out on that I guess) but I strongly feel we should compress at build time. Moving below /etc is a nice extra, but not entirely necessary at this stage, IMHO. A. -- Software gets slower faster than hardware gets faster. - Wirth's law pgpynziaen6cl.pgp Description: PGP signature
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
On 2014-01-30 12:15:00, Jonas Smedegaard wrote: > Quoting Antoine Beaupré (2014-01-30 16:34:47) >> On 2014-01-30 09:29:08, Jonas Smedegaard wrote: >> > runtime pkgsize bloat: 0 >> >> Thanks for those measurements Jonas!! >> >>> If you insist on uglifying at runtime, then I still recommend >>> compacting CSS at build time (300 bytes win is silly when using >>> jQuery bloat!). >>> >>> If you insist on uglifying _CSS_ at runtime, then I still recommend >>> using ruby-sass, and switch to sassc later (see bug#694733,694730). >> >> I don't insist at all, in fact I don't understand why we would >> compress CSS at runtime at all. > > Ok. > > >> For JS it makes sense because of section 4.13 (convenience copies), but >> the CSS is native... > > Not sure I understand you here. Debian do not allow redistribution of > upstream-compressed JavaScript, but that does not force you to compress > at runtime: distributing buildtime-complressed JavaScript is fine to > distribute in Debian. Right. > Same is in principle true for CSS (and HMTL etc.) but less strongly > enforced (because such declarative code is more likely to be still > readable). The difference being that the CSS is not "upstream" so we do not need to fiddle around with symlinks. We can just shipped the compressed code in the binary package and the original in the source without breaking policy. Of course, we probably want to ship the source CSS anyways as a convenience to allow our users to modify it, but that's a separate feature... >> We could *suggest* an uglifier of some sort (and the jury's still out on >> that I guess) but I strongly feel we should compress at build time. > > I don't understand what you are saying here. Are you distinguishing > between "uglify" and "compress", about JavaScript and CSS, or only about > buildtime and runtime?!? I was specifically saying that we could allow users to modify the CSS and recompress it, in which case we should Suggest: some kind of "CSS compressor" so that this can be done easily. But in my opinion, this shouldn't be a hard Depends: we should compress at build time and not force people to install nodejs or ruby to use the photofloat binary package. If they want to edit the CSS and recompress it, then yes, they will need to install one of those bundles, but we shouldn't enforce that if we can avoid it. A. -- Be who you are and say what you feel Because those who mind don't matter And those who matter don't mind. - Dr. Seuss pgpgUeNSJm96s.pgp Description: PGP signature
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
On 2014-01-30 13:25:33, Jonas Smedegaard wrote: > Quoting Antoine Beaupré (2014-01-30 18:27:04) >> On 2014-01-30 12:15:00, Jonas Smedegaard wrote: >>> Quoting Antoine Beaupré (2014-01-30 16:34:47) >>>> For JS it makes sense because of section 4.13 (convenience copies), >>>> but the CSS is native... >>> >>> Not sure I understand you here. Debian do not allow redistribution >>> of upstream-compressed JavaScript, but that does not force you to >>> compress at runtime: distributing buildtime-complressed JavaScript is >>> fine to distribute in Debian. >> >> Right. >> >>> Same is in principle true for CSS (and HMTL etc.) but less strongly >>> enforced (because such declarative code is more likely to be still >>> readable). >> >> The difference being that the CSS is not "upstream" so we do not need >> to fiddle around with symlinks. > > I don't follow. What do you mean not "upstream"? What symlinks? Sorry I wasn't clear again. The CSS files are in the Photofloat, and not convenience copies like some javascript files. The symlinks I am refering to are the symlinks to the jquery javascript source files which we use to regenerated the compressed javascript with triggers. What I am saying is we don't need such a convoluted, runtime build procedure for CSS as they are part of the photofloat source and not convenience copies of code. > I am talking about DFSG requirements above. Are you perhaps talking > (also) about user ability to customize (by storing below /etc)? Later yes, but here I was specifically talking about 4.13/DFSG and CSS files which, unless I am mistaken, are not covered because they are not convenience copies of code. >> We can just shipped the compressed code in the binary package and the >> original in the source without breaking policy. > > Do you mean to say that as a difference?!? That's true for both > JavaScript and CSS (just not equally strong enforced). I am not saying there's a theorical difference, I am saying that in the case of photofloat there is because the CSS is not a convenience copy. >>>> We could *suggest* an uglifier of some sort (and the jury's still >>>> out on that I guess) but I strongly feel we should compress at build >>>> time. >>> >>> I don't understand what you are saying here. Are you distinguishing >>> between "uglify" and "compress", about JavaScript and CSS, or only >>> about buildtime and runtime?!? >> >> I was specifically saying that we could allow users to modify the CSS >> and recompress it, in which case we should Suggest: some kind of "CSS >> compressor" so that this can be done easily. >> >> But in my opinion, this shouldn't be a hard Depends: we should >> compress at build time and not force people to install nodejs or ruby >> to use the photofloat binary package. >> >> If they want to edit the CSS and recompress it, then yes, they will >> need to install one of those bundles, but we shouldn't enforce that if >> we can avoid it. > > I now understand one thing you don't want (mandatory runtime dependency > on helper tools), but still not what you do want. Right. > Here is - I think - all sensible options: > > CSS can be compressed or compacted or simply collated during build, and > install that once below /usr, or once below /etc with symlink below > /usr, or once below /etc recompressed or recompacted on-demand below > /var with symlink below /usr. That seems fair enough. I would say: a. compress CSS during build (or compact, i don't care) b. install CSS compressed in /var c. install CSS sources in /etc d. provide a clear way for users to get from c to b, but don't do it automatically. e. symlink in /usr to /etc and /var for consistency and simplicity > (difference between "compacting" and "compressing" is that the latter > has slightly size gain at the loss of readability) Understood. > I recommend to compact during build, and install that once below /etc > with a symlink below /usr. What about the source files? How do people rebuild if they modify in /etc? > Simply collating during build loose a few kilobytes at the most, but > more importantly ships eventual broken CSS undetected (and hard to > discover, because it is passed unexamined to the Browser). I am not sure I understand that, but okay. :) > Installing below /usr (as done now) is frustrating as it allows no > option for customization. Right, I don't object to changing that. > On-demand recomputing is IMO overdoing it (local admin can run Sass on > the file below /etc if they feel the need for that). Agreed. -- You Are What You Is - Frank Zappa pgpfFlfS5oIZy.pgp Description: PGP signature
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
On 2014-01-30 15:17:31, Jonas Smedegaard wrote: > Quoting Antoine Beaupré (2014-01-30 19:38:15) >> On 2014-01-30 13:25:33, Jonas Smedegaard wrote: >>> Quoting Antoine Beaupré (2014-01-30 18:27:04) >>>> On 2014-01-30 12:15:00, Jonas Smedegaard wrote: >>>>> Quoting Antoine Beaupré (2014-01-30 16:34:47) >>>>>> For JS it makes sense because of section 4.13 (convenience >>>>>> copies), but the CSS is native... >>>>> >>>>> Not sure I understand you here. Debian do not allow redistribution >>>>> of upstream-compressed JavaScript, but that does not force you to >>>>> compress at runtime: distributing buildtime-complressed JavaScript >>>>> is fine to distribute in Debian. >>>> >>>> Right. >>>> >>>>> Same is in principle true for CSS (and HMTL etc.) but less strongly >>>>> enforced (because such declarative code is more likely to be still >>>>> readable). >>>> >>>> The difference being that the CSS is not "upstream" so we do not >>>> need to fiddle around with symlinks. >>> >>> I don't follow. What do you mean not "upstream"? What symlinks? >> >> Sorry I wasn't clear again. The CSS files are in the Photofloat, and >> not convenience copies like some javascript files. The symlinks I am >> refering to are the symlinks to the jquery javascript source files >> which we use to regenerated the compressed javascript with triggers. >> >> What I am saying is we don't need such a convoluted, runtime build >> procedure for CSS as they are part of the photofloat source and not >> convenience copies of code. > > Convenience code copies don't require *runtime* compression. What? Isn't that why we are talking about triggers for javascript? Sure, maybe it was respecting policy to compress at build time (the package is in Debian after all), but it is a potential security problem anyways. > ...as I wrote 8 hours ago - at the top of this quote! > > DFSG issue is lack of proper source (i.e. preferred form of editing). > Choice of when to compress (if at all) is completely independent from > that issue. It seems to me that section 4.13 goes a little further than DFSG then, as it specifically refers to maintainability of the code from a security perspective. >>> Here is - I think - all sensible options: >>> >>> CSS can be compressed or compacted or simply collated during build, >>> and install that once below /usr, or once below /etc with symlink >>> below /usr, or once below /etc recompressed or recompacted on-demand >>> below /var with symlink below /usr. >> >> That seems fair enough. I would say: >> >> a. compress CSS during build (or compact, i don't care) > > Seems we agree on that, then. One down... 4 to go! :) >> b. install CSS compressed in /var >> c. install CSS sources in /etc >> d. provide a clear way for users to get from c to b, but don't do it >> automatically. >> e. symlink in /usr to /etc and /var for consistency and simplicity > > Why? Seems exactly what I argue below is overkill and you agree with? Sorry, why what? I thought you were arguing that recompiling on the fly at runtime is overkill. Recompiling on the fly at runtime is not what I am suggesting here. >>> I recommend to compact during build, and install that once below /etc >>> with a symlink below /usr. >> >> What about the source files? How do people rebuild if they modify in >> /etc? > > You tell me - I suggest to not do such overkill. Why on earth would we ship undecipherable configuration files in /etc if we do not allow people to rebuild them from source? What I propose above (in d) is that we provide a way (either in README.Debian or with an update-foo script) to recompile from sources in /etc. That should be simple enough. >>> Simply collating during build loose a few kilobytes at the most, but >>> more importantly ships eventual broken CSS undetected (and hard to >>> discover, because it is passed unexamined to the Browser). >> >> I am not sure I understand that, but okay. :) > > Many bugs in compiled languages like C cause build failures, whereas in > interpreted languages like Python they are most often spotted only at > runtime. Correct. > Running testsuites help catch errors early, but for most interpreted > languages it is uncommon to include a testsuite (and for Nodejs > specifically many testsuites rely on DFSG-nonfree jshint). Right. > Bugs in interp
Bug#721568: photofloat: move css below /etc and minify during install and on-demand
On 2014-01-30 16:30:37, Jonas Smedegaard wrote: > Quoting Antoine Beaupré (2014-01-30 21:34:21) >> On 2014-01-30 15:17:31, Jonas Smedegaard wrote: >>> Convenience code copies don't require *runtime* compression. >> >> What? Isn't that why we are talking about triggers for javascript? > > Uhm, no. At least I am not. Yes, you are. > Perhaps if you quote the text giving you that impression we can > locate the cause of misunderstanding. In the original #721567 bug report: > For the bundling file I think best would be for the package to > generate that file using a dpkg trigger, so that it gets regenerated > whenever one of its dependent library packages are updated. But anyways, that's beside the point here. The point is that the Jquery library (for example) we use is the one from the jquery package, so we need runtime compression to update it when the jquery package updates. We don't have this problem with CSS because the CSS is shipped with Photofloat and not part of another package. That's the point I am trying to make here. >> Sure, maybe it was respecting policy to compress at build time (the >> package is in Debian after all), but it is a potential security >> problem anyways. > > No, I believe you are mistaken. I believe not using triggers, in the case of jquery, for example, is a security issue because if we simply use a symlink and build at install time, when jquery is updated for a security vulnerability, we are still vulnerable. >> It seems to me that section 4.13 goes a little further than DFSG then, >> as it specifically refers to maintainability of the code from a >> security perspective. > > What complicates security work is lack of proper source. Yes, that as well. However, Photofloat was shipping some JS library non-minified, which is still an issue if we skip those and compile from other packages. >>>>> Here is - I think - all sensible options: >>>>> >>>>> CSS can be compressed or compacted or simply collated during build, >>>>> and install that once below /usr, or once below /etc with symlink >>>>> below /usr, or once below /etc recompressed or recompacted >>>>> on-demand below /var with symlink below /usr. > >>>> b. install CSS compressed in /var >>>> c. install CSS sources in /etc >>>> d. provide a clear way for users to get from c to b, but don't do >>>> it automatically. >>>> e. symlink in /usr to /etc and /var for consistency and simplicity >>> >>> Why? Seems exactly what I argue below is overkill and you agree >>> with? >> >> Sorry, why what? >> >> I thought you were arguing that recompiling on the fly at runtime is >> overkill. Recompiling on the fly at runtime is not what I am >> suggesting here. > > Above you propose /usr + /etc + /var, and compressing. > > Below I recommend /usr + /etc, and compacting. > > Why compress, I said: > a. compress CSS during build (or compact, i don't care) So I don't care. > and what "consistency and simplicity" is in that + /var? The consistency is not related to /var, but to symlinks within the rest of the photofloat install in /usr. I think compacted files should be shipped in /var, because they can be potentially regenerated by the user from the sources in /etc. This is along the policy of allowing /usr to be readonly. >>>>> I recommend to compact during build, and install that once below >>>>> /etc with a symlink below /usr. >>>> >>>> What about the source files? How do people rebuild if they modify in >>>> /etc? >>> >>> You tell me - I suggest to not do such overkill. >> >> Why on earth would we ship undecipherable configuration files in /etc >> if we do not allow people to rebuild them from source? > > You tell me - I recommend compacting, not compressing as you propose. I guess it's still unclear to me what compacting does then. Are we still talking about the same 3 miserable CSS files? >> What I propose above (in d) is that we provide a way (either in >> README.Debian or with an update-foo script) to recompile from sources >> in /etc. That should be simple enough. > > If you say so. I am not against such additional complication, just ask > why, because you also write that you agree that exactly that is > overdoing it. You misunderstand me. I think overdoing it is using triggers or recompiling at "postinst configure" time. >> I believe it goes beyond our duty as package maintainers to extend >> Photofloat to include a CSS test suite. If we
Bug#724077: charybdis: FTBFS: configure.ac:18: error:, required file './compile' not found
On 2014-02-01 11:50:11, Andreas Moog wrote: > On Tue, 15 Oct 2013 21:52:47 -0400, Antoine Beaupre > wrote: > >> Control: tags -1 +pending >> >> Sure, upload coming rght up, thanks!! >> >> A. > > ping? ;) Totally forgot, sorry! I'll upload soon. A. -- Voter, c'est abdiquer - Élisée Reclus pgpTwpIFmXgpU.pgp Description: PGP signature
Bug#737494: fails to upgrade from wheezy to jessie
Package: monkeysphere Version: 0.36-1 Severity: serious I couldn't upgrade this package from wheezy to jessie, because of this error: Setting up monkeysphere (0.36-1) ... gpg: can't open `/var/lib/monkeysphere/authentication/sphere/pubring.gpg' gpg: keydb_get_keyblock failed: eof gpg: no writable keyring found: eof gpg: error reading `[stdin]': general error gpg: import from `[stdin]' failed: general error Failed running transition script /usr/share/monkeysphere/transitions/0.23 dpkg: error processing package monkeysphere (--configure): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: monkeysphere E: Sub-process /usr/bin/dpkg returned an error code (1) That file is readable and doesn't seem corrupted: root@marcos:~# file /var/lib/monkeysphere/authentication/sphere/pubring.gpg /var/lib/monkeysphere/authentication/sphere/pubring.gpg: GPG key public ring No idea what's going on here, i'll finish my jessie upgrade before investigating further. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.10-0.bpo.3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages monkeysphere depends on: ii adduser3.113+nmu3 ii gnupg 1.4.16-1 ii libcrypt-openssl-rsa-perl 0.28-1 ii libdigest-sha-perl 5.71-2+deb7u1 ii lockfile-progs 0.1.17 ii perl [libdigest-sha-perl] 5.14.2-21+deb7u1 ii procmail 3.22-21 Versions of packages monkeysphere recommends: ii cron 3.0pl1-124 ii netcat 1.10-40 ii netcat-traditional [netcat] 1.10-40 ii openssh-client 1:6.4p1-2 ii socat1.7.2.2-1 ii ssh-askpass 1:1.2.4.1-9 Versions of packages monkeysphere suggests: pn monkeysphere-validation-agent -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737496: upgrade to jessie hoses notmuch-emacs
Package: notmuch
Version: 0.17-3
Severity: serious
It seems that upgrading from wheezy to jessie has mostly destroyed my
capability of using notmuch in emacs.
My workflow was simply to call "M-x notmuch" after starting emacs.
I load notmuch as follows, from my .emacs:
(safe-require 'notmuch)
(safe-require is a wrapper around require that doesn't crash .emacs if
it fails)
When I run M-x notmuch, I get this:
Welcome to notmuch. You have 188 254 messages.
... then nothing, and a backtrace:
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p A)
#[(elem) "@A:\203 \211A@)\202 A\306p!\307y\210 \310
\311\"\204) \n\312V\2053 \f\313 \310
\314\"\"\nE+\207" [elem x message-count search-query name options read 1
plist-get :show-empty-searches 0 notmuch-hello-filtered-query :filter]
7](("nonkoumbit inbox" . "tag:inbox and not tag:koumbit and not tag:rt"))
mapcar(#[(elem) "@A:\203 \211A@)\202 A\306p!\307y\210 \310
\311\"\204) \n\312V\2053 \f\313 \310
\314\"\"\nE+\207" [elem x message-count search-query name options read 1
plist-get :show-empty-searches 0 notmuch-hello-filtered-query :filter] 7]
(("nonkoumbit inbox" . "tag:inbox and not tag:koumbit and not tag:rt")
("koumbit inbox" . "tag:koumbit and tag:inbox and not tag:drupalorg\n
and not tag:rt") ("unread inbox" . "tag:inbox and tag:unread") ("inbox" .
"tag:inbox") ("todos" . "tag:todo") ("RT" . "tag:inbox and tag:rt")
("Drupal.org" . "tag:koumbit and tag:inbox and tag:drupalorg") ("inso" .
"tag:inso and tag:unread") ("quoifaire" . "tag:quoifaire and tag:unread")
("notmuch" . "to:notm...@notmuchmail.org and tag:unread") ("freshports" .
"tag:freshports and tag:unread") ("denyhosts" . "tag:denyhosts and tag:rapports
and tag:unread") ("backups" . "tag:backupninja and tag:rapports and
tag:unread") ("cron" . "tag:cron and tag:rapports and tag:unread") ("bounces" .
"
tag:bounces and tag:rapports and tag:unread") ("upgrades" . "tag:upgrades and
tag:rapports and tag:unread") ("rapports" . "tag:rapports and tag:unread")
("sent" . "tag:sent") ("drafts" . "tag:draft")))
notmuch-hello-query-counts((("nonkoumbit inbox" . "tag:inbox and not
tag:koumbit and not tag:rt") ("koumbit inbox" . "tag:koumbit and tag:inbox and
not tag:drupalorg\nand not tag:rt") ("unread inbox" . "tag:inbox
and tag:unread") ("inbox" . "tag:inbox") ("todos" . "tag:todo") ("RT" .
"tag:inbox and tag:rt") ("Drupal.org" . "tag:koumbit and tag:inbox and
tag:drupalorg") ("inso" . "tag:inso and tag:unread") ("quoifaire" .
"tag:quoifaire and tag:unread") ("notmuch" . "to:notm...@notmuchmail.org and
tag:unread") ("freshports" . "tag:freshports and tag:unread") ("denyhosts" .
"tag:denyhosts and tag:rapports and tag:unread") ("backups" . "tag:backupninja
and tag:rapports and tag:unread") ("cron" . "tag:cron and tag:rapports and
tag:unread") ("bounces" . "tag:bounces and tag:rapports and tag:unread")
("upgrades" . "tag:upgrades and tag:rapports and tag:unread") ("rapports" .
"tag:rapports and tag:unread") ("sent" . "tag:sent") ("drafts" . "tag:draft"))
:show-empty-searches nil
)
notmuch-hello-insert-saved-searches()
#[(section) "`\302 !\203 \210\202 \303 @
A\"\210`=?\205 \304\305!)\207" [point-before section functionp apply
widget-insert "\n"] 3](notmuch-hello-insert-saved-searches)
mapc(#[(section) "`\302 !\203 \210\202 \303 @
A\"\210`=?\205 \304\305!)\207" [point-before section functionp apply
widget-insert "\n"] 3] (notmuch-hello-insert-header
notmuch-hello-insert-saved-searches notmuch-hello-insert-search
notmuch-hello-insert-recent-searches notmuch-hello-insert-alltags
notmuch-hello-insert-footer))
notmuch-hello()
notmuch()
call-interactively(notmuch t nil)
execute-extended-command(nil)
call-interactively(execute-extended-command nil nil)
NEWS.Debian.gz doesn't seem to explain this.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages notmuch depends on:
ii libc6 2.17-97
ii libglib2.0-02.36.4-1
ii libgmime-2.6-0 2.6.19-3
ii libnotmuch3 0.17-3
ii libtalloc2 2.1.0-1
Versions of packages notmuch recommends:
ii gnupg-agent2.0.22-3
ii notmuch-emacs 0.17-3
notmuch suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737496: upgrade to jessie hoses notmuch-emacs
Control: severity -1 normal So it turns out I had a newline in my `notmuch-saved-searches', which didn't matter before the upgrade but crashed latest notmuch version. A bit of a WTF, but recoverable. Not sure how to deal with this, but I'll at least downgrade severity. A. pgpQ4FbEfhOYS.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 12:18:45, Adrian Bunk wrote: > Can you clarify whether you are sincerely asking for clarification, or > whether that would be pointless since you've anyway already decided that > everything I write are "flames" and anything I'll answer you'll only use > for further attacks against me? It is interesting that you feel specifically targeted when I mention flames whereas I haven't specifically mentionned you were the source of the heat. There were numerous messages in this bug report so far and a number of them have been out of line. I would prefer if you would assume I was asking in good faith, in general. So yes, I am genuinely asking for clarification. A. -- À force de ne jamais réfléchir, on a un bonheur stupide - Jean Cocteau pgpwXdc75rYy6.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 16:22:38, Adrian Bunk wrote: > On Mon, Feb 03, 2014 at 12:48:45PM -0500, Antoine Beaupré wrote: >> On 2014-02-03 12:18:45, Adrian Bunk wrote: >> > Can you clarify whether you are sincerely asking for clarification, or >> > whether that would be pointless since you've anyway already decided that >> > everything I write are "flames" and anything I'll answer you'll only use >> > for further attacks against me? >> >> It is interesting that you feel specifically targeted when I mention >> flames whereas I haven't specifically mentionned you were the source of >> the heat. There were numerous messages in this bug report so far and a >> number of them have been out of line. >> >> I would prefer if you would assume I was asking in good faith, in >> general. > > You used "flames" in an email directly answering to me, and in a > sentence where you told someone to go ahead without even waiting > for the clarification you just asked from me. > > You should re-read how that sounded to me. I am sorry you felt targeted, that was not my intention. >> So yes, I am genuinely asking for clarification. > > First of all, your "The library names of ffmpeg and libav now seem > perfectly orthogonal" is AFAIK not completely true, e.g. libswscale > still seems to have the same soname in both projects. So you might > end up mixing libav and ffmpeg libraries, and I wouldn't be sure > that this would work smoothly in all cases. I didn't know libswscale still had the same soname, but then I only summarily looked at the package contents. > And if it would be true, then something like the suggested > "apt-get install ffmpeg" would simply not do at all what was > implied it would do. I would assume it would imply installing ffmpeg. :) > Let me use VLC as example: > > VLC (maintained by the same Debian multimedia maintainers as libav) > is using the libav libraries, and therefore depends on them. > > When all libav libraries used by VLC have sonames different from the > sonames of the ffmpeg libraries, then VLC will always use the libav > libraries and never use any ffmpeg libraries at all. > > If all you expect to happen after "apt-get install ffmpeg" is that > there is an ffmpeg binary that is using the ffmpeg libraries, then > this might be doable. I think that would be a fair expectation. > But if someone wants, as Lorenzo suggested, an "apt-get install ffmpeg" > to magically switch all applications like VLC from using libav to > ffmpeg, then one of the requirements for that would clearly be that > there would have to be two versions of all binaries and libraries > using libav/ffmpeg in the archive - one compiled with libav, and > one compiled with ffmpeg. I reread Lorenzo's email, and it doesn't actually say "switch all applications like VLC from libav to ffmpeg". He just said: > users should be able to do > > apt-get install ffmpeg > > or > > apr-get install libav I think some people here are talking about using ffmpeg as a commandline-based conversion tool, not necessarily the way you are bringing up, as a library that (say) vlc is linking against. > That would be technically insane, and politically impossible unless > CTTE (or a GR) would override the likely veto from the Debian multimedia > maintainers for doing that in any of the packages they maintain. Then maybe this RFP can focus on providing the ffmpeg binary again and not necessarily get into replacing libav altogether, which I think was the original intention here, hence my original email. :) Cheers, A. -- Ce que les siècles des grands abatoirs nous aura appris Devrait être inscrit au fond de toutes les écoles; Voici l'homme: le destructeur des mondes est arrivé. - [no one is innocent] pgpGyKghJNzs_.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 17:25:40, Adrian Bunk wrote: > Before what you quote he said in the same email: > Agree with many on at least providing the *option* for users to have > the original ffmpeg instead of libav > > There is no libav program, and he is clearly talking about the libraries. I assumed libav included programs, and that is also what the wikipedia article says. But maybe lorenzo can tell better what he meant than us. I certainly mean that we could provide the program. >> > That would be technically insane, and politically impossible unless >> > CTTE (or a GR) would override the likely veto from the Debian multimedia >> > maintainers for doing that in any of the packages they maintain. >> >> Then maybe this RFP can focus on providing the ffmpeg binary again and >> not necessarily get into replacing libav altogether, which I think was >> the original intention here, hence my original email. :) > > No. > > Rogério is listing in the initial email in this RFP many reasons for the > ffmpeg libraries. But he never mentions anything related to the ffmpeg > commandline programs. He did mention he wanted to package ffmpeg as a replacement of libav, I stand corrected. > Or are you seriously saying chromium would use the ffmpeg > commandline programs? Now where did I ever mention chrome? > The ffmpeg/libav commandline programs are relatively rarely used - what > is used heavily on Linux are the libraries. I guess my use case is different then. Certainly there's a use case for the ffmpeg program just working properly in the first place. Taking a step back, there seems to be a lot of frustrations flying around that issue, maybe it would be better to keep an open mind and try to fix issues here. One of the proposals on the table is to bring back ffmpeg, at least as a program, possibly as a library. You seem to be saying that is "insane", but I fail to see the technical reasons behind that argument, other than debian-multimedia "vetoing" it. Maybe that discussion should be taken there then? I see there was one email about ffmpeg on the mailing list about a month ago, without any response, but that's all... What's your proposal to fix the problems with libav mentionned in this thread? What's your response to the claims that ffmpeg is a superset of libav and that libav is lagging in development? If ffmpeg is technically superior and compatible with libav, why shouldn't we package it? I feel there's a knee-jerk reaction against the inclusion of ffmpeg here, and I don't understand the technical reasons for that. Certainly we could offer ffmpeg as a replacement (Conflicts: Replaces:) of libav and people could choose between the two, especially if libav is such a drop-in replacement for packages that depend on ffmpeg... I think any Debian Developper is perfectly entitled to work on a ffmpeg package, upload it to new and let the FTP masters decide what to do with it. Now of course to make other packages use its libraries is a matter that should be left to those other package's maintainers, that's a different story, and not the topic of this RFP, from what I understand. A. -- To be naive and easily deceived is impermissible, today more than ever, when the prevailing untruths may lead to a catastrophe because they blind people to real dangers and real possibilities. - Erich Fromm pgpbFmb9Sv_Ra.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 17:13:43, Rogério Brito wrote: >> Rogério, I would suggest you go ahead with the packaging and an upload, >> don't let the flames fan your enthousiasm. > > Thanks for the encouragement, Antoine. I am mostly paralized with this > situation and I don't really know how to proceed. I think that the forces of > having to potentially fight the tech-ctte, the pkg-multimedia-team, the > ftp-masters and some other people is that is preventing me right now from > packaging ffmpeg all by myself. I am not sure you should fight anyone here. Do the package, may it policy-clean and it will pass NEW. If someone wants to bring up something with the ctte, they can do it, but you don't have to right now. Having a discussion on pkg-multimedia may be necessary if other package dependencies should be changed, and it is probably good practice to discuss this topic on that mailing list, but it seems to me that people shouldn't object to the inclusion of another package in debian solely on the ground that they do not like it. If both packages are ABI-compatible, then ffmpeg can be designed as a drop-in replacement for libav and users will be free to choose. We have a policy for such procedures. Our social contract also says we should respond to the needs of users, and the overwhelming majority of people on this issue have voiced their need for a working ffmpeg implementation in Debian. We should respond to that. A. -- From the age of uniformity, from the age of solitude, from the age of Big Brother, from the age of doublethink - greetings! - Winston Smith, 1984 pgpggjYEO3yLa.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 17:58:48, Antoine Beaupré wrote: > I see there was one email about ffmpeg on the mailing list > about a month ago, without any response, but that's all... I was talking about the deprecated debian-multimedia, my bad. A. -- The Net treats censorship as damage and routes around it. - John Gilmore pgpY6GLrhujJN.pgp Description: PGP signature
Bug#729203: CTTE and reasonable solutions
On 2014-02-03 18:21:34, Adrian Bunk wrote: > On Mon, Feb 03, 2014 at 05:58:48PM -0500, Antoine Beaupré wrote: >> On 2014-02-03 17:25:40, Adrian Bunk wrote: >>... > Since the original intention of this RFP that you were referring to > listed chromium, that implies that you were saying that chromium > would use the commandline tools. I obviously wasn't saying that. I also stated above "I stand corrected", what else do you need here? >> One of the proposals on the table is to bring back ffmpeg, at least as a >> program, possibly as a library. You seem to be saying that is "insane", >>... > > I would appreciate if you would in the future refrain from wrongly > claiming that I said something, when I did in fact state the opposite: > > <-- snip --> > > If all you expect to happen after "apt-get install ffmpeg" is that > there is an ffmpeg binary that is using the ffmpeg libraries, then > this might be doable. > > <-- snip --> I am refering to your position which you restate below >> but I fail to see the technical reasons behind that argument, other than >> debian-multimedia "vetoing" it. Maybe that discussion should be taken >> there then? I see there was one email about ffmpeg on the mailing list >> about a month ago, without any response, but that's all... > > You do know the relevant history? I am familiar with the fork, yes. However, things change and it seems that ffmpeg has picked up a lot of speed since the fork. Maybe it's time to reopen that discussion? Or maybe not, considering how this is going so far... >> What's your proposal to fix the problems with libav mentionned in this >> thread? What's your response to the claims that ffmpeg is a superset of >> libav and that libav is lagging in development? If ffmpeg is technically >> superior and compatible with libav, why shouldn't we package it? > > All I am saying is that suggestiong along the lines of having both the > libav and ffmpeg libraries and then switching between them through > "apt-get install" is insane. I do not see any answer to the technical questions I have asked above. I also do not see why this proposal is inherently "insane". > If you disagree with the Debian Multimedia Maintainers on which to use > in jessie, the conflict resolution process is in the Debian Constitution. I am aware of the constitution as well, thanks. I wasn't aware I was in a conflict resolution process already, I was trying to get information about the situation. Things escalate quick around here don't they? :) >> I feel there's a knee-jerk reaction against the inclusion of ffmpeg >> here, and I don't understand the technical reasons for that. Certainly >> we could offer ffmpeg as a replacement (Conflicts: Replaces:) of libav >> and people could choose between the two, especially if libav is such a >> drop-in replacement for packages that depend on ffmpeg... > > What part of the technical reason "a binary/library compiled against > a library cannot be used with a version of this library with a different > soname" don't you understand? Well, that's one answer, thanks. I was under the understanding that ffmpeg was trying to keep backwards compatibility with libav, I guess that is all much clearer now. One thing I don't understand is how difficult this conversation feels for me right now. Maybe it's just me, but I was just looking at an offer to work on ffmpeg in Debian by a volunteer, and this is turning out to be a difficult conversation, what happened? >> I think any Debian Developper is perfectly entitled to work on a ffmpeg >> package, upload it to new and let the FTP masters decide what to do with >> it. Now of course to make other packages use its libraries is a matter >> that should be left to those other package's maintainers, that's a >> different story, and not the topic of this RFP, from what I understand. > > You already agreed that your claim "The library names of ffmpeg and > libav now seem perfectly orthogonal" is not true. I fail to understand what that statement brings to the conversation. Does that make me a bad person? :P > That is a mess, and would have to be sorted out by the Debian libav and > ffmpeg maintainers before such an upload could happen. That would be great! I support such an initiative. I'm glad we agree. A. -- Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208 pgpC_X41YBFWu.pgp Description: PGP signature
Bug#737494: fails to upgrade from wheezy to jessie
debug info - i set monkeysphere debugging and enabled tracing in the postinst: anarcat@marcos:~$ sudo env MONKEYSPHERE_LOG_LEVEL=DEBUG apt-get install Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait 0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour. 1 partiellement installés ou enlevés. Après cette opération, 0 o d'espace disque supplémentaires seront utilisés. Paramétrage de monkeysphere (0.36-1) ... + set -e + VARLIB=/var/lib/monkeysphere + getent passwd monkeysphere + /usr/share/monkeysphere/transitions/0.23 ms: checking authentication directory structure... ms: writing core gpg.conf... ms: writing sphere gpg.conf... ms: fixing sphere gnupg home ownership... ms: determining core key fingerprint... ms: core fingerprint: 2EBD247FA05765D924178575DD58DC050E79BE1D ms: Monkeysphere authentication trust core already exists. ms: exporting core pub key to sphere keyring... gpg: impossible d'ouvrir « /var/lib/monkeysphere/authentication/sphere/pubring.gpg » gpg: keydb_get_keyblock failed: eof gpg: aucun porte-clefs accessible en écriture n'a été trouvé : eof gpg: erreur de lecture de « [stdin] » : erreur générale gpg: import from `[stdin]' failed: erreur générale + RET=2 + echo Failed running transition script /usr/share/monkeysphere/transitions/0.23 Failed running transition script /usr/share/monkeysphere/transitions/0.23 + exit 2 dpkg: error processing package monkeysphere (--configure): le sous-processus script post-installation installé a retourné une erreur de sortie d'état 2 Des erreurs ont été rencontrées pendant l'exécution : monkeysphere E: Sub-process /usr/bin/dpkg returned an error code (1) It seems that the given file is not writable by the monkeysphere user: -rw--- 1 root root 682 juil. 19 2012 /var/lib/monkeysphere/authentication/sphere/pubring.gpg I have no clue how this happened. Changing the ownership of this back to monkeysphere:monkeysphere fixed my bug. A. -- Le pouvoir n'est pas à conquérir, il est à détruire - Jean-François Brient, de la servitude moderne pgphxK721bJEm.pgp Description: PGP signature
Bug#737585: O: semanticscuttle -- Self-hosted and web-based social bookmark manager
Package: wnpp Severity: normal I intend to orphan the semanticscuttle package. The package description is: SemanticScuttle is a social bookmarking tool experimenting with new features like structured tags and collaborative descriptions of tags. Originally a fork of Scuttle, it has overtaken its ancestor in stability, features and usability. . * LDAP/Active Directory authentication * RSS feed support: global feed, user feeds, per-tag feeds, private feeds * Public and private bookmarks * Delicious and Browser bookmark import * Theming support * Firefox plugin I am not really using the Debian package for deployment anymore, and can therefore not really fix the release-critical bugs which affect the installs (#659390). I will probably switch to Zotero to manage my bookmarks anyways (#709925). If anyone wants to take over the package, I can provide some overview of the package, but, quite frankly, it's been so long since I touched it that I barely remember anything at all. ;) I'll try to update to the latest upstream at least. Sorry for the inconvenience. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737882: atheme-services: status on the init script fails
On 2014-02-06 20:13:03, Mike Mestnik wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Attached find two patch files, one bug/lintian and the other > incorporates features. Hi! First, thanks for the patches! It's always appreciated. Can you clarify a little more why those patches are necessary? For example, here: > diff --git a/debian/init.d b/debian/init.d > index c026287..89bad8d 100644 > --- a/debian/init.d > +++ b/debian/init.d > @@ -29,6 +29,7 @@ if [ "$ENABLED" != "1" ] ; then > fi > > set -e > +. /lib/lsb/init-functions > > case "$1" in >start) > @@ -104,12 +105,11 @@ case "$1" in > exit 3 > else > if [ -f "$RUNDIR/atheme.pid" ]; then > - ( set +e > + set +e > start-stop-daemon --status --quiet --pidfile > $RUNDIR/atheme.pid > ext=$? > echo "." > exit $ext > - ) > fi > echo "pid file missing." > exit 3 How do those two chunks relate? I understand sourcing init-functions may be a good idea, but why remove the subshell? It seems to me that we disable error-checking for the whole script there, and only in this case... a little messy. If we want to avoid the subshell, we should probably "|| true" somewhere on the critical section instead of removing the subshell. > diff --git a/debian/init.d b/debian/init.d > index 89bad8d..77e9452 100644 > --- a/debian/init.d > +++ b/debian/init.d > @@ -99,23 +99,7 @@ case "$1" in > echo "." > ;; >status) > - echo -n "Status $DESC: $NAME " > - if [ ! -d "$RUNDIR" ]; then > - echo "run folder missing!" > - exit 3 > - else > - if [ -f "$RUNDIR/atheme.pid" ]; then > - set +e > - start-stop-daemon --status --quiet --pidfile > $RUNDIR/atheme.pid > - ext=$? > - echo "." > - exit $ext > - fi > - echo "pid file missing." > - exit 3 > - fi > - echo unknown. > - exit 4 > + status_of_proc -p $RUNDIR/atheme.pid $DAEMON $NAME > ;; >*) > N=/etc/init.d/$NAME This one makes a little more sense, but maybe the init function sourcing belongs here? Thanks again, A. -- Ou bien Dieu voudrait supprimer le mal, mais il ne le peut pas Ou bien Dieu pourrait supprimer le mal, mais il ne le veut pas. - Sebastien Faure pgpRoPWYNmY8P.pgp Description: PGP signature
Bug#738599: fails to decode H264: "Different bit depth between chroma and luma is not implemented"
Package: libavcodec54 Version: 6:9.10-2 Severity: important libav can't seem to play some H264 videos. Here's an example: anarcat@marcos:~$ avplay "/srv/video/films/Documentary/The Power of Nightmares/The_Power_Of_Nightmares-Part_1.mkv" avplay version 9.10-6:9.10-2, Copyright (c) 2003-2013 the Libav developers built on Jan 3 2014 23:27:39 with gcc 4.8 (Debian 4.8.2-11) [h264 @ 0x7f306c004960] Overread VUI by 8 bits [h264 @ 0x7f306c004960] Different bit depth between chroma and luma is not implemented. Update your Libav version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [h264 @ 0x7f306c004960] If you want to help, upload a sample of this file to ftp://upload.libav.org/incoming/ and contact the libav-devel mailing list. [h264 @ 0x7f306c004960] Decoding sps 0 from avcC failed [h264 @ 0x7f306c004960] Overread VUI by 8 bits [h264 @ 0x7f306c004960] Different bit depth between chroma and luma is not implemented. Update your Libav version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [h264 @ 0x7f306c004960] If you want to help, upload a sample of this file to ftp://upload.libav.org/incoming/ and contact the libav-devel mailing list. [h264 @ 0x7f306c004960] Decoding sps 0 from avcC failed Input #0, matroska,webm, from '/srv/video/films/Documentary/The Power of Nightmares/The_Power_Of_Nightmares-Part_1.mkv': Duration: 00:59:13.04, start: 0.00, bitrate: N/A Stream #0.0(eng): Video: h264, 704x480, PAR 182:205 DAR 4004:3075, 29.97 fps, 29.97 tbr, 1k tbn (default) Stream #0.1: Audio: ac3, 48000 Hz, stereo, fltp, 192 kb/s (default) [h264 @ 0x7f306c0f8f60] Overread VUI by 8 bits [h264 @ 0x7f306c0f8f60] Different bit depth between chroma and luma is not implemented. Update your Libav version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [h264 @ 0x7f306c0f8f60] If you want to help, upload a sample of this file to ftp://upload.libav.org/incoming/ and contact the libav-devel mailing list. [h264 @ 0x7f306c0f8f60] Decoding sps 0 from avcC failed I unfortunately can't provide a copy of the video, as the content is copyrighted. This has been reported elsewhere as well: http://ubuntuforums.org/archive/index.php/t-2137057.html https://www.kubuntuforums.net/showthread.php?62473-I-have-a-problem-on-playing-some-video/page4 A copy of a problematic file can probably be found on any torrent site when searching for Steroid_Hormone_Biosynthesis_1.flv - as this is the file reported above. It would probably be legal to download a part of that file for research purposes such as this one. The above post lead me to believe that ffmpeg is not affected by this problem. Thanks for your time and effort. A. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libavcodec54 depends on: ii libavutil526:9.10-2 ii libc6 2.17-97 ii libgsm11.0.13-4 ii libmp3lame03.99.5+repack1-3 ii libopenjpeg2 1.3+dfsg-4.7+b1 ii libopus0 1.1-1 ii libschroedinger-1.0-0 1.0.11-2 ii libspeex1 1.2~rc1.1-1 ii libtheora0 1.1.1+dfsg.1-3.1 ii libva1 1.2.1-2 ii libvorbis0a1.3.2-1.3 ii libvorbisenc2 1.3.2-1.3 ii libvpx11.3.0-2 ii libx264-1332:0.133.2339+git585324f-2+b1 ii libxvidcore4 2:1.3.2-9 ii multiarch-support 2.17-97 ii zlib1g 1:1.2.8.dfsg-1 libavcodec54 recommends no packages. libavcodec54 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#729203: ffmpeg packaging progress?
Is there a git repository or a source for a ffmpeg package? I understand there's a controversy against its inclusion in the main archive, but right now I have stumbled upon a bug (#738599) which keeps me from reading videos with libav. I'd like to see if I can reproduce the problem with ffmpeg, and possibly read the darn file. :) If not, I'll start my own somewhere so that people that compile manually ffmpeg on Debian at least have a semi-official way of doing so without reverting to deb-multimedia.org, something which I assume we all want to avoid here. A. -- Voter, c'est abdiquer - Élisée Reclus pgpu_sBlEIZKn.pgp Description: PGP signature
Bug#729203: ffmpeg packaging progress?
Here it goes - I have been able to make a statically-built ffmpeg package that can be installed alongside libav harmlessly. It doesn't replace the libav libraries, so things like VLC and others still link against libav. This package doesn't exhibit bug #738599. I pushed this on github for now: https://github.com/anarcat/FFmpeg/tree/debian/debian This can allow people to build ffmpeg binaries reliably under Debian sid and jessie right now. It is currently non-free because if links against libfaac0 and so on. But it's a good start, I believe. This package is based on Marillat's ffmpeg packages, so it will need to import a lot of the improvements from the libav packages, amongst other things. There's a TODO in the debian/ directory explaining required work. Enjoy! A. -- Tout ce qui n’est pas donné est perdu. - Proverbe indien pgpcUwYjyAqT0.pgp Description: PGP signature
Bug#737494: [monkeysphere] Bug#737494: cannot reproduce monkeysphere failing to upgrade from wheezy to jessie
On 2014-02-11 00:45:23, Daniel Kahn Gillmor wrote: > anarcat, if you're unable to pinpoint how the permissions got changed on > the server in question, perhaps you can close this bug? or if you can > reproduce it, i would be happy to know how. Thanks for the initial > report. Perhaps we can close this for now. I'll certainly have more upgrades of the sort to do in the coming years and we'll see soon enough if marcos was smoking crack. ;) A. -- While the creative works from the 16th century can still be accessed and used by others, the data in some software programs from the 1990s is already inaccessible. - Lawrence Lessig pgpN_6Rm9iCbc.pgp Description: PGP signature
Bug#738599: Acknowledgement (fails to decode H264: "Different bit depth between chroma and luma is not implemented")
I confirm that ffmpeg doesn't exhibit the same behaviour, when statically built using this provisionnal package: https://github.com/anarcat/FFmpeg The problem therefore seems specific to libav. A. -- Music gives a soul to the universe, wings to the mind, flight to the imagination and life to everything - Plato pgpIrXxcliCcP.pgp Description: PGP signature
Bug#729203: ffmpeg alongside libav
On 2014-02-11 13:04:53, Timothy Gu wrote: > I have experimented with the new --enable-rpath configure option of > FFmpeg, and found that it is even possible to install shared libraries > alongside Libav, without interrupting Libav headers, programs, or > libraries. See my gist: https://gist.github.com/TimothyGu/8533059 Hum... isn't that because you install in /usr/local more than -rpath? Besides, -rpath is actually a lintian warning: http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html ... so we shouldn't use that, generally. I would rather try to check to see if we could sync the packages to make them ABI-compatible. > I have also tried to build http://mpv.io/ with ffmpeg instead of > libav, and I received success in doing tthat as well. Build script is > in the gist as well. Thanks for sharing! That will certainly be useful for others. A. -- I'm sorry if any of you are catholic. I'm not sorry if you're offended, I'm actually just sorry by the fact that you're catholic - Bill Hicks pgpxA4E6NhMBX.pgp Description: PGP signature
Bug#729203: ffmpeg alongside libav
On 2014-02-11 19:00:45, Timothy Gu wrote: > On Feb 11, 2014 10:27 AM, "Antoine Beaupré" wrote: >> >> On 2014-02-11 13:04:53, Timothy Gu wrote: >> > I have experimented with the new --enable-rpath configure option of >> > FFmpeg, and found that it is even possible to install shared libraries >> > alongside Libav, without interrupting Libav headers, programs, or >> > libraries. See my gist: https://gist.github.com/TimothyGu/8533059 >> > >> Hum... isn't that because you install in /usr/local more than -rpath? > > I used /usr/local because if I mess up I can delete the installation > completely. But it should work with /usr. Understood. >> Besides, -rpath is actually a lintian warning: >> >> http://lintian.debian.org/tags/binary-or-shlib-defines-rpath.html > > The page states that: > > The only time a binary or shared library in a Debian package should set > RPATH is if it is linked to private shared libraries in the same package. > In that case, place those private shared libraries in /usr/lib/*package*. > > That's exactly what's happening here if we'd like to add the ffmpeg > programs but not use the libraries for other packages. Still, shared > libraries are better than statically linking the ffmpeg programs. Ah, right, I see what you mean. I guess it would be better, but I think it's only a marginal gain over a statically linked binary: it would bring some confusion over the purpose of those libraries... Would other packages be allowed to link against them? >> ... so we shouldn't use that, generally. I would rather try to check to >> see if we could sync the packages to make them ABI-compatible. > > I'd be interested in the results. Yeah, I'm not sure I'll get into that now, but I would welcome other brave souls stepping into this. I was merely scratching an itch to watch that silly video after all. :) >> > I have also tried to build http://mpv.io/ with ffmpeg instead of >> > libav, and I received success in doing tthat as well. Build script is >> > in the gist as well. >> >> Thanks for sharing! That will certainly be useful for others. > > It should work for all applications wishing to support FFmpeg, including > VLC. But the PKG_CONFIG_PATH is really not optimal. That, and -rpath is designed for private libraries, so I don't think that could end up in the archive legitimately. A static link, on the other hand, may have a legitimate purpose. A. -- Advertisers, not governments, are the primary censors of media content in the United States today. - C. Edwin Baker pgppGMQg632nc.pgp Description: PGP signature
Bug#738599: fails to decode H264: "Different bit depth between chroma and luma is not implemented"
On 2014-02-11 09:11:58, Sebastian Ramacher wrote: > Anyway, could you please test if the issues persists with libav 10 from > experimental? It doesn't, I marked the issue as fixed for the experimental version. Thanks, A. -- Rock journalism is people who can't write, interviewing people who can't talk, in order to provide articles for people who can't read. - Frank Zappa pgpivREX3h4ym.pgp Description: PGP signature
Bug#729203: ffmpeg alongside libav
On 2014-02-11 19:25:57, Anssi Hannula wrote: > Well, statically linking all the four ff* executables of ffmpeg would > quadruple the total size due to duplication, and the libraries already > take over 10MB even without that... Point taken, patches / pull requests / git send-email welcome. :P Note that at this point, I have lost interest in this a little since my peculiar bug is fixed in libav 10, available in experimental. :) A. -- Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle épinière suffit. - Albert Enstein pgp0wqGy6I8uw.pgp Description: PGP signature
Bug#731632: dgit adds to quild gitignored files
Package: dgit Version: 1.9 Severity: normal Running dgit git-build on my git checkout of bugs-everywhere commits a patch into quilt that include a file that is in .gitignore. The git repo: git+ssh://git.debian.org/git/dgit-repos/repos/bugs-everywhere.git The .gitignore: *.pyc build dist doc/man/*.1 doc/.build/ doc/libbe/ .be/id-cache libbe/_version.py How to reproduce: apt-get install bugs-everywhere apt-get source bugs-everywhere # to get the tarball (?) git clone git+ssh://git.debian.org/git/dgit-repos/repos/bugs-everywhere.git cd bugs-everywhere be list # make the cache of bugs generated dgit git-build Expected result: the package is built as usual Actual result: the package quilt series has an extra entry for .be/id-cache. $ diffstat debian/patches/auto-1.1.1-3-3caf93f13fc59943cc6162949b57ffdf57daad25-1386434682 .be/id-cache | 411 +++ interfaces/web/static/scripts/GPL-LICENSE.txt | 278 + interfaces/web/static/scripts/MIT-LICENSE.txt | 20 interfaces/web/static/scripts/jquery.corners.html | 465 ++ interfaces/web/static/scripts/jquery.corners.js | 405 +++ 5 files changed, 1579 insertions(+) The latter 4 are okay, the first one is wrong, as it is in my .gitignore. Of course, maybe it's my mistake in the first place to run commands on the source tree, making it unclean, but it took me a while to notice this file was there because git status wouldn't show it to me, because it's in .gitignore. Furthermore, I was expecting git-build to build the package in a separate checkout, the way git-buildpackage usually does... In fact, git-buildpackage uses cowbuilder to build the package in a chroot normally, so I am not sure what is going on here. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731633: dgit ignores my .gbp.conf settings
Package: dgit Version: 0.19 Severity: minor Minor really. I usually build my git packages using cowbuilder, and I have a rather convoluted setup to build packages, on my wheezy box, in a sid chroot to (a) get a clean environment and (b) to build against sid for uploads. My setup is a mix of those: https://wiki.debian.org/PbuilderTricks https://wiki.debian.org/PackagingWithGit#pbuilder https://wiki.debian.org/cowbuilder#Using_with_git-buildpackage Anyways, the point is I have this line in my .gbp.conf setting: builder = /usr/bin/git-pbuilder But when I try to build using dgit git-build, I get: anarcat@marcos:bugs-everywhere$ dgit git-build Format `3.0 (quilt)', urgh dpkg-source: info: utilisation des options depuis bugs-everywhere/debian/source/options : --single-debian-patch dpkg-source: avertissement: suppression du répertoire update-copyright ignorée dpkg-source: info: aucune modification locale à enregistrer nothing quilty to commit, ok. canonical suite name for unstable is sid changelog will contain changes since 1.1.1-2 dh clean --with=python2 dh_testdir debian/rules override_dh_auto_clean make[1]: entrant dans le répertoire « /home/anarcat/src/bugs-everywhere » dh_auto_clean make[2]: entrant dans le répertoire « /home/anarcat/src/bugs-everywhere » /bin/rm -rf build libbe/_version.py doc/man/be.1 doc/man/be.1.html make -C doc clean make[3]: entrant dans le répertoire « /home/anarcat/src/bugs-everywhere/doc » /bin/rm -rf .build libbe make[3]: quittant le répertoire « /home/anarcat/src/bugs-everywhere/doc » make[2]: quittant le répertoire « /home/anarcat/src/bugs-everywhere » rm -f libbe/_version.py make[1]: quittant le répertoire « /home/anarcat/src/bugs-everywhere » dh_clean gbp:info: Exporting 'HEAD' to '/home/anarcat/src/build-area/bugs-everywhere-tmp' gbp:info: Moving '/home/anarcat/src/build-area/bugs-everywhere-tmp' to '/home/anarcat/src/build-area/bugs-everywhere-1. dpkg-buildpackage: paquet source bugs-everywhere dpkg-buildpackage: version source 1.1.1-3 dpkg-buildpackage: source changé par Antoine Beaupré dpkg-buildpackage: architecture hôte amd64 dpkg-source -i.git/ -I.git --before-build bugs-everywhere-1.1.1 dpkg-source: info: utilisation des options depuis bugs-everywhere-1.1.1/debian/source/options : --single-debian-patch dpkg-checkbuilddeps : dépendances de construction non trouvées : tla darcs monotone rcs python-numpydoc dpkg-buildpackage: avertissement: dépendances de construction et conflits non satisfaits ; échec. dpkg-buildpackage: avertissement: (Utilisez l'option -d pour forcer.) gbp:error: Couldn't run 'dpkg-buildpackage -i\.git/ -I.git -us -uc -v1.1.1-2': dpkg-buildpackage -i\.git/ -I.git return git-buildpackage: failed command: git-buildpackage -us -uc --git-no-sign-tags '--git-builder=dpkg-buildpackage -i'\\'.g dgit: subprocess failed with error exit status 1 I notice --git-builder=dpkg-buildpackage seems hardcoded - why? This seems to work a little better here: DIST=sid ARCH=amd64 dgit git-build --git-builder=git-pbuilder It seems to me this shouldn't be hardcoded. A. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731633: still some problems with git-pbuilder, but it can work!
Ah, after more complete testing, it seems that push fails with packages built through pbuilder, because it can't find the .dsc file: anarcat@marcos:bugs-everywhere$ DEBSIGN_KEYID=7B75921E DIST=sid ARCH=amd64 dgit -L push DAMP RUN - WILL MAKE LOCAL (UNSIGNED) CHANGES From git+ssh://git.debian.org/git/dgit-repos/repos/bugs-everywhere * [new tag] debian/1.1.1-3 -> debian/1.1.1-3 canonical suite name for unstable is sid downloading http://ftp.debian.org/debian//pool/main/b/bugs-everywhere/bugs-everywhere_1.1.1-2.dsc... last upload to archive has NO git hash dget: retrieving http://ftp.debian.org/debian//pool/main/b/bugs-everywhere/bugs-everywhere_1.1.1-2.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 2143 100 21430 0 9512 0 --:--:-- --:--:-- --:--:-- 18474 dget: retrieving http://ftp.debian.org/debian//pool/main/b/bugs-everywhere/bugs-everywhere_1.1.1.orig.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 347k 100 347k0 0 337k 0 0:00:01 0:00:01 --:--:-- 380k dget: retrieving http://ftp.debian.org/debian//pool/main/b/bugs-everywhere/bugs-everywhere_1.1.1-2.debian.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 20004 100 200040 0 60638 0 --:--:-- --:--:-- --:--:-- 89704 bugs-everywhere_1.1.1-2.dsc: Good signature found validating bugs-everywhere_1.1.1.orig.tar.gz validating bugs-everywhere_1.1.1-2.debian.tar.gz All files validated successfully. dpkg-source: info: extraction de bugs-everywhere dans bugs-everywhere-1.1.1 dpkg-source: info: extraction de bugs-everywhere_1.1.1.orig.tar.gz dpkg-source: info: extraction de bugs-everywhere_1.1.1-2.debian.tar.gz dpkg-source: info: mise en place de debian-changes synthesised git commit from .dsc 1.1.1-2 HEAD is now at 11fb61b dgit: looked for .dsc bugs-everywhere_1.1.1-3.dsc, but Aucun fichier ou dossier de ce type; maybe you forgot to build Indeed, the files are in ../build-area. But after moving the files into place (in ../), the push proceeds further. Maybe there should be an option to specify the build directory? A. -- L'art n'est pas un bureau d'anthropométrie. - Léo Ferré, "Préface" pgpc3EaY0ql49.pgp Description: PGP signature
Bug#731635: syntax error in at line 1: PGP signature not allowed here
Package: dgit Version: 0.19 Severity: important I am finally trying to upload this package using "dgit push", and here's what I get: $ dgit push canonical suite name for unstable is sid downloading http://ftp.debian.org/debian//pool/main/b/bugs-everywhere/bugs-everywhere_1.1.1-2.dsc... last upload to archive has NO git hash dget: retrieving http://ftp.debian.org/debian//pool/main/b/bugs-everywhere/bugs-everywhere_1.1.1-2.dsc % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 2143 100 21430 0 9149 0 --:--:-- --:--:-- --:--:-- 19306 dget: retrieving http://ftp.debian.org/debian//pool/main/b/bugs-everywhere/bugs-everywhere_1.1.1.orig.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 347k 100 347k0 0 320k 0 0:00:01 0:00:01 --:--:-- 354k dget: retrieving http://ftp.debian.org/debian//pool/main/b/bugs-everywhere/bugs-everywhere_1.1.1-2.debian.tar.gz % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 20004 100 200040 0 58115 0 --:--:-- --:--:-- --:--:-- 88123 bugs-everywhere_1.1.1-2.dsc: Good signature found validating bugs-everywhere_1.1.1.orig.tar.gz validating bugs-everywhere_1.1.1-2.debian.tar.gz All files validated successfully. dpkg-source: info: extraction de bugs-everywhere dans bugs-everywhere-1.1.1 dpkg-source: info: extraction de bugs-everywhere_1.1.1.orig.tar.gz dpkg-source: info: extraction de bugs-everywhere_1.1.1-2.debian.tar.gz dpkg-source: info: mise en place de debian-changes synthesised git commit from .dsc 1.1.1-2 HEAD is now at 11fb61b Use of uninitialized value $_[0] in sprintf at /usr/share/perl5/Dpkg/ErrorHandling.pm line 48, line 1. dgit: error: syntax error in at line 1: PGP signature not allowed here I think this is because the package files were already signed by git-buildpackage+pbuilder (using AUTO_DEBSIGN=yes in pbuilder) during the build process - but what's wrong with that? And if *is* wrong, the error message could be a little more helpful. :) See also #731633 for using pbuilder here... Note that is also happens if you rerun dgit push after it failed once (e.g. because a third party uploaded a tag with the same name on the repo you're working on). -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731632: dgit adds to quild gitignored files
On 2013-12-07 21:59:02, Ian Jackson wrote:
> Ian Jackson writes ("Re: Bug#731632: dgit adds to quild gitignored files"):
>> Antoine Beaupré writes ("Bug#731632: dgit adds to quild gitignored files"):
>> > The git repo:
>> > git+ssh://git.debian.org/git/dgit-repos/repos/bugs-everywhere.git
>> >
>> > The .gitignore:
>
> Thinking about this some more, I become more puzzled. I think I would
> like to try to reproduce this.
>
> I have fetched your source tree. I guess you were trying to push
> 3caf93f13fc59943cc6162949b57ffdf57daad25 ? And your parent directory
> contained bugs-everywhere_1.1.1_orig.tar.gz ? How do I cause this
> .be/id-cache file to exist ?
>
> Or to put it another way, can tell me how to repro this problem ?
I think that file was created by running "be list" in the
bugs-everywhere directory. be then generates this cached file.
It's not part of the build process, it's just that I ran this in the
work tree. Deleting the file completely fixed the problem...
A.
--
Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est
pas réfutable relève de la magie ou de la mystique.
- Popper, Karl
pgphfBKp2186s.pgp
Description: PGP signature
Bug#731633: dgit ignores my .gbp.conf settings [and 1 more messages]
On 2013-12-07 21:32:29, Ian Jackson wrote:
> Antoine Beaupré writes ("Bug#731633: dgit ignores my .gbp.conf settings"):
>> Minor really. I usually build my git packages using cowbuilder, and I
>> have a rather convoluted setup to build packages, on my wheezy box, in
>> a sid chroot to (a) get a clean environment and (b) to build against
>> sid for uploads.
>
> Thanks for the report.
>
> Right. As the manpage says, you may use any technique you like to do
> the build, provided it results in a .dsc which matches your git tree
> exactly.
Ah right.
> So it's not necessary for the building functions in dgit to support
> every possible workflow. However, I'm certainly open to improving
> dgit's build functions if it would be possible and useful.
Of course.
>> My setup is a mix of those:
> ...
>> dpkg-buildpackage: paquet source bugs-everywhere
>> dpkg-buildpackage: version source 1.1.1-3
>> dpkg-buildpackage: source changé par Antoine Beaupré
>> dpkg-buildpackage: architecture hôte amd64
>> dpkg-source -i.git/ -I.git --before-build bugs-everywhere-1.1.1
>> dpkg-source: info: utilisation des options depuis
>> bugs-everywhere-1.1.1/debian/source/options : --single-debian-patch
>> dpkg-checkbuilddeps : dépendances de construction non trouvées : tla darcs
>> monotone rcs python-numpydoc
>> dpkg-buildpackage: avertissement: dépendances de construction et conflits
>> non satisfaits ; échec.
>> dpkg-buildpackage: avertissement: (Utilisez l'option -d pour forcer.)
>> gbp:error: Couldn't run 'dpkg-buildpackage -i\.git/ -I.git -us -uc
>> -v1.1.1-2': dpkg-buildpackage -i\.git/ -I.git return
>> git-buildpackage: failed command: git-buildpackage -us -uc
>> --git-no-sign-tags '--git-builder=dpkg-buildpackage -i'\\'.g
>> dgit: subprocess failed with error exit status 1
>
> So I think you are right that the problem here is that dgit is
> overriding --git-builder. dgit needs to do this because the default
> ignore rules are not correct: git-buildpackage (and various other
> tools) ignore .gitignore (and perhaps other things) by default, which
> is not correct with dgit.
Uh. That's weird. Seems like a bug in git-buildpackage...
> As far as I know the only way to specify a different set of ignore
> rules with git-buildpackage is to override --git-builder.
Yeah, I have this in my .gbp.conf:
[DEFAULT]
cleaner = fakeroot debian/rules clean
postbuild = lintian $GBP_CHANGES_FILE
builder = /usr/bin/git-pbuilder
[git-buildpackage]
export-dir = ../build-area/
[git-import-orig]
dch = False
> As it happens, I think you can achieve the same effect with dgit's
> subcommand override options. If I UTSL I see this in cmd_git_build:
> my @cmd =
> (qw(git-buildpackage -us -uc --git-no-sign-tags),
> "--git-builder=@dpkgbuildpackage");
>
> So it may work to say something like:
> dgit --dpkg-buildpackage=git-pbuilder git-build
>
> I appreciate that this isn't particularly discoverable, but the
> ability to override dpkg-buildpackage is documented in the manual
> and if you run dgit with the -D option it will show you the commands
> it's running. (Would it have been better to show this particular
> command by default?)
That would have been useful yes. But yeah, I must admit that I filed
those bugs without RTFM... my bad.
>> This seems to work a little better here:
>> DIST=sid ARCH=amd64 dgit git-build --git-builder=git-pbuilder
>> It seems to me this shouldn't be hardcoded.
>
> I assume that this works only because something else is somehow
> overriding the dropping of .gitignore.
Hum... Not sure. In fact, I am not sure I understand what you mean about
that .gitignore thing... You're saying git-buildpackage doesn't
*respect* or *package* the .gitignore file?
> Later in this bug you followed up:
>
> Antoine Beaupré writes:
>> Ah, after more complete testing, it seems that push fails with packages
>> built through pbuilder, because it can't find the .dsc file:
> ...
>> dgit: looked for .dsc bugs-everywhere_1.1.1-3.dsc, but Aucun fichier ou
>> dossier de ce type; maybe you forgot to build
>>
>> Indeed, the files are in ../build-area. But after moving the files into
>> place (in ../), the push proceeds further. Maybe there should be an
>> option to specify the build directory?
>
> I think that would be a good idea. (I won't yet clone this bug report
> for that, because I want to finish the whole conversation before
> deciding what's best to do.)
Right. Or maybe look at gbp's config? Just brainstorming here...
> (But: there is already an option to specify the .changes file. Does
> using it make dgit work in this case? I ask because I have a feeling
> it might not...)
Crap, I missed that option too... I guess I'll try again during the next
upload! Maybe that's all that's needed really...
A.
--
Si Dieu existe, j'espère qu'Il a une excuse valable
- Daniel Pennac
pgp1mkRWJi6Li.pgp
Description: PGP signature
Bug#732429: debirf: fails when running in a directory with spaces
Package: debirf Version: 0.33 Severity: normal Dear Maintainer, * What led up to the situation? trying to build debirf in a directory with spaces * What exactly did you do (or not do) that was effective (or ineffective)? running: debirf make torride a custom-made debirf build, source available here: https://redmine.koumbit.net/projects/torride * What was the outcome of this action? the build failed with some error, which i lost because i closed the terminal. * What outcome did you expect instead? just run. :) -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debirf depends on: ii apt 0.9.7.9+deb7u1 ii cpio 2.11+dfsg-0.1 ii debootstrap 1.0.48+deb7u1 ii fakechroot 2.16-1 ii fakeroot 1.18.4-2 ii klibc-utils 2.0.1-3.1 Versions of packages debirf recommends: ii grub-common 1.99-27+deb7u2 ii lsb-release 4.1+Debian8+deb7u1 ii syslinux-common 2:4.05+dfsg-6+deb7u1 ii xorriso 1.2.2-2 debirf suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732429: debirf: fails when running in a directory with spaces
On 2013-12-17 19:09:03, Daniel Kahn Gillmor wrote: > Control: tags 732429 + moreinfo > On 12/17/2013 06:26 PM, Antoine Beaupré wrote: >>* What was the outcome of this action? >> >> the build failed with some error, which i lost because i closed the >> terminal. > > can you supply the error message and its context please? it sounds like > you have the infrastructure all set up already. So it's pretty simple to reproduce, assuming debirf is already installed: anarcat@desktop008:~$ mkdir "test space" anarcat@desktop008:~$ cd "test space" anarcat@desktop008:test space$ git clone git://finestructure.net/debirf Cloning into 'debirf'... remote: Counting objects: 2964, done. remote: Compressing objects: 100% (1266/1266), done. remote: Total 2964 (delta 1556), reused 2640 (delta 1353) Receiving objects: 100% (2964/2964), 370.88 KiB | 625 KiB/s, done. Resolving deltas: 100% (1556/1556), done. Checking out files: 100% (72/72), done. anarcat@desktop008:example-profiles$ debirf make minimal debirf> loading profile 'test'... debirf> creating debirf root... debirf> distro/suite: debian/wheezy /usr/bin/fakeroot: line 89: [: /home/anarcat/test: binary operator expected faked, daemon for fake root environment Best used from the shell script `fakeroot' options for fakeroot: --key, --cleanup, --foreground, --debug, --save-file, --load, --unknown-is-real fakeroot: error while starting the `faked' daemon. boom. a classique misquote. a. -- Nothing incites to money-crimes like great poverty or great wealth. - Mark Twain pgpyQi594B83l.pgp Description: PGP signature
Bug#732429: debirf: fails when running in a directory with spaces
On 2013-12-18 14:59:25, Daniel Kahn Gillmor wrote: > On 12/18/2013 02:54 PM, Antoine Beaupré wrote: >> anarcat@desktop008:~$ mkdir "test space" >> anarcat@desktop008:~$ cd "test space" >> anarcat@desktop008:test space$ git clone git://finestructure.net/debirf >> Cloning into 'debirf'... >> remote: Counting objects: 2964, done. >> remote: Compressing objects: 100% (1266/1266), done. >> remote: Total 2964 (delta 1556), reused 2640 (delta 1353) >> Receiving objects: 100% (2964/2964), 370.88 KiB | 625 KiB/s, done. >> Resolving deltas: 100% (1556/1556), done. >> Checking out files: 100% (72/72), done. >> anarcat@desktop008:example-profiles$ debirf make minimal > > where did example-profiles come from here? is this transcript complete, > or elided? oops, i forgot: cd debirf/doc/example-profiles >> debirf> loading profile 'test'... >> debirf> creating debirf root... >> debirf> distro/suite: debian/wheezy >> /usr/bin/fakeroot: line 89: [: /home/anarcat/test: binary operator expected > > This looks like a bug in fakeroot, to me. can you narrow it down by > trying fakeroot directly? I don't think that's the problem, fakeroot runs fine: anarcat@desktop008:example-profiles$ fakeroot sh root@desktop008# >> faked, daemon for fake root environment >> Best used from the shell script `fakeroot' >> options for fakeroot: --key, --cleanup, --foreground, --debug, --save-file, >> --load, --unknown-is-real >> fakeroot: error while starting the `faked' daemon. > > also, looks more like fakeroot. actually, the problem is the way fakeroot is started. >> boom. a classique misquote. > > i'm not sure what this means :/ that means there's a problem in shell quoting. if you call a shell variable without double-quoting it, it will fail if the variable contains spaces. example: FOO="test dir/" cd $FOO # fail cd "$FOO" # works I believe this is a problem in the way fakeroot is called, here's a debug run of debirf for proof. anarcat@desktop008:example-profiles$ bash -x debirf make minimal ++ basename debirf + CMD=debirf + DEBIRF_COMMON=/usr/share/debirf/common + source /usr/share/debirf/common ++ export LC_CTYPE=C ++ LC_CTYPE=C ++ export LC_ALL=C ++ LC_ALL=C ++ export LANGUAGE=C ++ LANGUAGE=C ++ export LANG=C ++ LANG=C ++ export -f failure ++ export -f msg ++ export -f fakeroot_if_needed ++ export -f debirf_exec ++ export -f debirf_info_comment ++ export -f debirf_info_sh + DEBIRF_LABEL=debirf + DEBIRF_METHOD=nested + export ROOT_BUILD=false + ROOT_BUILD=false + STAGE_ROOT=true + STAGE_MODULES=true + STAGE_INITRD=true + ROOT_WARNING=true + export DEVICE_ARCHIVE=/usr/share/debirf/devices.tar.gz + DEVICE_ARCHIVE=/usr/share/debirf/devices.tar.gz + export INCLUDE=busybox-static,gpgv,less + INCLUDE=busybox-static,gpgv,less + export EXCLUDE=apt-utils,bsdmainutils,cron,ed,info,logrotate,man-db,manpages,tasksel,tasksel-data,tcpd,traceroute + EXCLUDE=apt-utils,bsdmainutils,cron,ed,info,logrotate,man-db,manpages,tasksel,tasksel-data,tcpd,traceroute + export -f pack_rootfs + COMMAND=make + '[' make ']' + shift + case $COMMAND in + make minimal ++ getopt --options -hcnosrwdik: --longoptions help,check-vars,new,overwrite,skip,root-build,no-warning,no-initrd,initrd-only,kernel: -n debirf -- minimal + TEMP=' '\''minimal'\'' --' + '[' 0 '!=' 0 ']' + eval set -- ' '\''minimal'\'' --' ++ set -- minimal -- + true + case "$1" in + (( 2 < 1 )) + break ++ id -u + '[' 10001 = 0 ']' + setup_environment minimal + DEBIRF_PROFILE=minimal ++ cd minimal +++ pwd ++ basename /home/anarcat/test space/debirf/doc/example-profiles/minimal + DEBIRF_PROFILE_NAME=test + '[' -d minimal ']' + msg 'loading profile '\''test'\''...' + echo 'debirf> loading profile '\''test'\''...' debirf> loading profile 'test'... + DEBIRF_CONF=minimal/debirf.conf + DEBIRF_MODULES=minimal/modules + '[' -f minimal/debirf.conf ']' + source minimal/debirf.conf ++ DEBIRF_LABEL=debirf-minimal + '[' '!' -d minimal/modules ']' ++ ls minimal/modules + '[' -z 'a0_motd a0_prep-root install-kernel network root-bashrc serial-terminal z0_remove-locales z1_clean-root' ']' ++ find minimal/modules + for MODULE in '$(find "$DEBIRF_MODULES")' + '[' '!' -s minimal/modules ']' + for MODULE in '$(find "$DEBIRF_MODULES")' + '[' '!' -s minimal/modules/root-bashrc ']' + for MODULE in
Bug#723763: monkeysign should not sign revoked uids
On 2013-10-16 15:28:46, Philip Jägenstedt wrote: > I looks to me --with-colons will show both revocation of the public keys > and uids, e.g. here's my old revoked key: > > pub:r:1024:17:C8D53F30F42163A4:2006-08-25:::-:Philip Jägenstedt > ::sca: > uid:r2008-06-30::FB9A4CAE39D8CE6BADFFF3E7D87D69568335E1FD::Philip > Jägenstedt : > sub:r:1024:16:2D587BA5340611CA:2006-08-25::e: That looks like the --list-keys output, not --list-secret-keys. > It's true that --list-secret-keys --with-colons doesn't show which uids > are revoked, but I don't think that's relevant when trying to determine > (programatically) whether or not the key/uid is revoked/expired. So yes, it's possible to extract that information, but that would involve re-running --list-keys for every secret key imported, really annoying. A. -- Semantics is the gravity of abstraction. pgpM_a7G7fFax.pgp Description: PGP signature
Bug#723763: monkeysign should not sign revoked uids
On 2013-10-16 15:49:29, Philip Jägenstedt wrote: > On Wed, 2013-10-16 at 15:44 -0400, Antoine Beaupré wrote: >> On 2013-10-16 15:28:46, Philip Jägenstedt wrote: >> > I looks to me --with-colons will show both revocation of the public keys >> > and uids, e.g. here's my old revoked key: >> > >> > pub:r:1024:17:C8D53F30F42163A4:2006-08-25:::-:Philip Jägenstedt >> > ::sca: >> > uid:r2008-06-30::FB9A4CAE39D8CE6BADFFF3E7D87D69568335E1FD::Philip >> > Jägenstedt : >> > sub:r:1024:16:2D587BA5340611CA:2006-08-25::e: >> >> That looks like the --list-keys output, not --list-secret-keys. > > Indeed it is. > >> > It's true that --list-secret-keys --with-colons doesn't show which uids >> > are revoked, but I don't think that's relevant when trying to determine >> > (programatically) whether or not the key/uid is revoked/expired. >> >> So yes, it's possible to extract that information, but that would >> involve re-running --list-keys for every secret key imported, really >> annoying. > > I don't understand, why is --list-secret-keys involved at all when > inspecting the key you're signing? Signing your own keys using > monkeysign sounds a bit weird, is that supported? Oh, wait - I was confused by another unrelated issue: monkeysign allows you to sign keys *with* a revoked secret key... So yes, you are right... A. -- Le péché est né avant la vertu, comme le moteur avant le frein. - Jean-Paul Sartre pgpdUnyQCVetr.pgp Description: PGP signature
Bug#693942: linux-image-3.2.0-4-amd64: regression / high load confirmed after wheezy upgrade
Also, note that we have many Debian servers, and this one is the only one (so far) affected by this problem. Here are dom0 xen servers that had their load actually go *down* by a factor of two since their move to wheezy: http://stats.koumbit.net/koumbit.net/chypre.koumbit.net/load.html http://stats.koumbit.net/koumbit.net/eros.koumbit.net/load.html http://stats.koumbit.net/koumbit.net/artemis.koumbit.net/load.html This server, however, had its load stable: http://stats.koumbit.net/koumbit.net/cereales.koumbit.net/load.html The only difference with that server is that it's using SSD drives, and so is the server I previously mentionned in my report (ceres). A. -- Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208 pgphsEt8VoEWK.pgp Description: PGP signature
Bug#726938: Vcs-* repositories are missing
Package: bugs-everywhere Severity: normal According to: http://packages.qa.debian.org/b/bugs-everywhere.html the package sources should be available at: http://bzr.debian.org/bzr/collab-maint/bugs-everywhere/bugs-everywhere.debian/ http://bzr.debian.org/loggerhead/collab-maint/bugs-everywhere/bugs-everywhere.debian/ Both URLs return 404s here. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726953: dgit fails with submodules
Package: dgit Version: 0.15 Severity: normal This one is a little hairy, but regardless... anarcat@marcos:bugs-everywhere$ dgit -n push --new -D DRY RUN ONLY + git diff --quiet HEAD | ssh coccia.debian.org 'set -e; cd /srv/ftp-master.debian.org/ftp/dists; if test -h experimental; then readlink experimental; exit 0; fi; if test -d experimental; then echo experimental; exit 0; fi; exit 1' => `experimental' | ssh git.debian.org ' set -e; cd /git/dgit-repos/repos; if test -d bugs-everywhere.git; then echo 1; else echo 0; fi' => `0' | ssh coccia.debian.org dak ls -asource -sexperimental bugs-everywhere => `' no version available from the archive previous reference hash= nothing found! actually entering push format 1.0 + git diff --quiet HEAD checking that bugs-everywhere_1.1.1-1.0.dsc corresponds to HEAD + dpkg-source -x -- ../../../../bugs-everywhere_1.1.1-1.0.dsc dpkg-source: avertissement: extraction d'un paquet source non signé (../../../../bugs-everywhere_1.1.1-1.0.dsc) dpkg-source: info: extraction de bugs-everywhere dans bugs-everywhere-1.1.1 dpkg-source: info: extraction de bugs-everywhere_1.1.1.orig.tar.gz dpkg-source: info: mise en place de bugs-everywhere_1.1.1-1.0.diff.gz dpkg-source: info: fichiers amont modifiés : bugs-everywhere-1.1.1/Makefile bugs-everywhere-1.1.1/libbe/_version.py + git init -q + git add -Af | git write-tree => `eb1d29cbe83eed3e3be96f52cb166c53da9ae871' + diff --git a/update-copyright b/update-copyright new file mode 16 index 000..f5629da --- /dev/null +++ b/update-copyright @@ -0,0 +1 @@ +Subproject commit f5629da9158f7f3467d986d51bd1f6ed2204da3a git: failed command: git diff --exit-code eb1d29cbe83eed3e3be96f52cb166c53da9ae871 dgit: subprocess failed with error exit status 1 I will try to push this git repo online once I have the benediction of the current maintainer, for further testing. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726953: dgit fails with submodules
On 2013-10-20 18:30:42, Ian Jackson wrote:
> Antoine Beaupré writes ("Bug#726953: dgit fails with submodules"):
>> Package: dgit
>> Version: 0.15
>> Severity: normal
>>
>> This one is a little hairy, but regardless...
> ...
>> I will try to push this git repo online once I have the benediction of
>> the current maintainer, for further testing.
>
> I'm not sure exactly what's going on here but AFAICT you are trying to
> do dgit push on a branch which contains git submodule metadata - ie,
> where the complete source tree depends on these other modules.
That is correct.
> How do you think dgit should handle these problems ?
Completely ignore the submodules. The original build tree doesn't
actually need it at all.
> (I tried a dgit clone of bugs-everywhere and found it was only in
> squeeze, and the clone seemed to work just fine.)
Yeah, you need to merge it with upstream and do all bunch of crazy
things to update it to the latest version.
I'll post the git repo shortly.
A.
--
C'est trop facile quand les guerres sont finies
D'aller gueuler que c'était la dernière
Amis bourgeois vous me faites envie
Ne voyez vous pas donc point vos cimetières?
- Jaques Brel
pgpzI4mabt7Nb.pgp
Description: PGP signature
Bug#726953: dgit fails with submodules
On 2013-10-20 18:44:42, Ian Jackson wrote:
> Antoine Beaupré writes ("Bug#726953: dgit fails with submodules"):
>> On 2013-10-20 18:30:42, Ian Jackson wrote:
>> > How do you think dgit should handle these problems ?
>>
>> Completely ignore the submodules. The original build tree doesn't
>> actually need it at all.
>
> But doesn't git expect to work with (check out, etc.) the submodules
> by default ?
That's not my experience so far.
> So the git tree with the submodule metadata isn't really suitable for
> general use by people who are expecting a "normal" git branch.
>
> Perhaps dgit should be given a special branch with the submodule
> metadata removed. (Please tell me you don't intend to publish the
> submodule metadata in the .git-less Debian source package.)
No, I don't intend to publish that stuff... and yes, maybe the simply
fix is to drop the submodule in the debian branch...
a.
--
From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
- Winston Smith, 1984
pgpUMWJhCDqqd.pgp
Description: PGP signature
Bug#726953: dgit fails with submodules
On 2013-10-20 18:44:42, Ian Jackson wrote: >> I'll post the git repo shortly. > > Thanks, I have went through a few hoops to push the git repo by hand in the dgit-repos, hopefully that's alright. (I went on git.debian.org, copied the _template into bugs-everywhere.git, then pushed my changes in, after laying down a tag manually. All this because dgit refused to push the new package because of #720177.) The git repo is now at: git+ssh://git.debian.org/git/dgit-repos/repos/bugs-everywhere.git Note that I removed the submodule in the dgit/sid branch. A. -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. - Brian W. Kernighan pgpdfeEeaNdbO.pgp Description: PGP signature
Bug#727044: Could not load plugin
Package: liquidsoap-plugin-gstreamer Version: 1.0.1+repack1-1.1 Severity: grave This plugin doesn't work at all in wheezy: anarcat@marcos:src$ liquidsoap 'out(input.gstreamer.audio(pipeline="udpsrc multicast-group=224.0.0.56 port=5004 ! \"application/x-rtp, media=(string)audio, clock-rate=44100, payload=(int)10\" ! rtpL16depay ! audioconvert ! alsasink sync=false"))' At line 1, char 26: the variable input.gstreamer.audio used here has not been previously defined. when loading another source, we see why: anarcat@marcos:src$ liquidsoap 'out(input.udp(host="224.0.0.56",port=5004,"audio/wav"))' 2013/10/21 15:57:48 >>> LOG START 2013/10/21 15:57:48 [protocols.external:3] Didn't find "ufetch". 2013/10/21 15:57:48 [protocols.external:3] Found "/usr/bin/wget". 2013/10/21 15:57:48 [main:3] Liquidsoap 1.0.1 2013/10/21 15:57:48 [main:3] Using: graphics=[distributed with Ocaml] pcre=6.2.5 dtools=0.3.0 duppy=0.4.2 duppy.syntax=0.4.2 cry=0.2.2 mm=0.2.0 xmlplaylist=0.1.3 lastfm=0.3.0 ogg=0.4.3 vorbis=0.6.1 speex=0.2.0 mad=0.4.4 flac=0.1.1 flac.ogg=0.1.1 dynlink=[distributed with Ocaml] lame=0.3.1 gstreamer=0.1.0 voaacenc=0.1.0 theora=0.3.0 schroedinger=0.1.0 gavl=0.1.4 bjack=0.1.3 alsa=0.2.1 ao=0.2.0 samplerate=0.1.1 taglib=0.2.0 magic=0.7.3 camomile=0.8.4 faad=0.3.0 soundtouch=0.1.7 portaudio=0.2.0 pulseaudio=0.1.2 ladspa=0.1.4 dssi=0.1.0 sdl=0.9.0 camlimages=4.0.0 lo=0.1.0 yojson=1.0.3 gd=1.0a5 2013/10/21 15:57:48 [dynamic.loader:3] Could not find dynamic module for aacplus encoder. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/mad.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/ogg.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/pulseaudio.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/vorbis.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/taglib.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/lame.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/flac_ogg.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/cry.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/voaacenc.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/flac.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Loaded plugin file /usr/lib/liquidsoap/1.0.1/plugins/faad.cmxs. 2013/10/21 15:57:48 [dynamic.loader:2] Could not load plugin file /usr/lib/liquidsoap/1.0.1/plugins/gstreamer.cmxs: error loading shared library: /usr/lib/liquidsoap/1.0.1/plugins/gstreamer.cmxs: undefined symbol: camlidl_free. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages liquidsoap-plugin-gstreamer depends on: pn libc6 ii libglib2.0-0 2.33.12+really2.32.4-5 ii libgstreamer-plugins-base0.10-0 0.10.36-1.1 ii libgstreamer0.10-0 0.10.36-1.2 ii libxml2 2.8.0+dfsg1-7+nmu2 ii liquidsoap 1.0.1+repack1-1.1 liquidsoap-plugin-gstreamer recommends no packages. liquidsoap-plugin-gstreamer suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726953: dgit fails with submodules
On 2013-10-21 17:31:42, Ian Jackson wrote:
> Antoine Beaupré writes ("Bug#726953: dgit fails with submodules"):
>> On 2013-10-20 18:44:42, Ian Jackson wrote:
>> > Thanks,
>>
>> I have went through a few hoops to push the git repo by hand in the
>> dgit-repos, hopefully that's alright.
>
> You can push whatever you like to dgit-repos provided you don't push
> it to the suite branches (refs/dgit/, on alioth).
>
> Don't push to the suite branches by hand.
Ah. Sorry. That wasn't clear to me.
>> (I went on git.debian.org, copied the _template into
>> bugs-everywhere.git, then pushed my changes in, after laying down a tag
>> manually. All this because dgit refused to push the new package because
>> of #720177.)
>
> This doesn't seem like a very good idea. I don't see how #720177
> would affect this situation.
The problem was that dgit push wouldn't work because I had changes that
dgit couldn't take into account, because of 3.0 quilt, as I detailed in
#720177.
>> The git repo is now at:
>> git+ssh://git.debian.org/git/dgit-repos/repos/bugs-everywhere.git
>>
>> Note that I removed the submodule in the dgit/sid branch.
>
> It seems like you did push to the dgit/sid branch. I don't have time
> now to check whether you broke anything. But it seems likely.
Should I drop the repository?
A.
--
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place. - Douglas Adams (1952-2001)
pgpz1RQPP8AYS.pgp
Description: PGP signature
Bug#727053: how to manage patches with dgit?
On 2013-10-21 17:39:07, Ian Jackson wrote: > Can you please (a) point me to the git tree and commit in question > (b) provide me somehow with a copy of the bugs-everywhere_1.1.1-1.dsc > and the files it refers to ? This should allow you to reproduce the problem: git clone git://git.debian.org/git/dgit-repos/repos/bugs-everywhere.git /tmp/be cd /tmp/be git checkout dgit/sid git-buildpackage mv ../build-area/bugs-everywhere* .. dgit push -N The current commit is d792004fb731c46396d6636fe4e7da6f96cc10d9. The .dsc files and friends are now in the NEW queue too... https://ftp-master.debian.org/new/bugs-everywhere_1.1.1-1.html A. -- To be naive and easily deceived is impermissible, today more than ever, when the prevailing untruths may lead to a catastrophe because they blind people to real dangers and real possibilities. - Erich Fromm pgptikOTfRHZG.pgp Description: PGP signature
Bug#727053: how to manage patches with dgit?
On 2013-10-21 18:15:12, Ian Jackson wrote:
> Antoine Beaupré writes ("Bug#727053: how to manage patches with dgit?"):
>> The .dsc files and friends are now in the NEW queue too...
>> https://ftp-master.debian.org/new/bugs-everywhere_1.1.1-1.html
>
> This isn't the actual files, just a summary of them. ftp-master
> deliberately doesn't make them publicly readable because of copyright
> concerns. I don't seem to be able to access ries any more, and coccia
> doesn't seem to have an incoming mirror.
>
> Please put the actual files somewhere I can find them.
I have provided you with a clear way to reproduce the issue, but oh
well...
http://paste.anarc.at/be-bug/
a.
--
Sous un gouvernement qui emprisonne injustement, la place de l’homme
juste est aussi en prison.
- La désobéissance civile, Henry David Thoreau
pgpsUfV5x6lqw.pgp
Description: PGP signature
Bug#727053: how to manage patches with dgit?
On 2013-10-22 08:05:08, Ian Jackson wrote: > retitle 727053 quilt fixup fails in dirty (built) trees > thanks > > So, thanks for your report. Looking at the git tree and the uploaded > files, I have repro'd what I think is at the root of your problem. Great! > I think the error you must have originally had (which prevented your > non-dry-run push) was due to your working tree being dirty when you > ran dgit push. Specifically, git-buildpackage would have left the > build products, debhelper log, and so forth. Hummm... I am really not sure about this. I believe that git-buildpackage builds in a completely different directory, after git-export'ing the repository, so there shouldn't be any such cruft around... > A workaround would be to run debian/rules clean before dgit push. > Also, I think using one of dgit's build wrappers would have avoided > the problem. ... furthermore, I couldn't use dgit's build wrapper because I use a combination of pbuilder/cowbuilder with git-buildpackage to build packages in a sid chroot (still running this server in wheezy here). So those packages were not even built within the same environment, so I strongly doubt those files were present. > Nevertheless, I think this is suboptimal and I have therefore > developed what seems to be a fix. 0.16 will have it. Okay. It would have helped a lot if the error message would have been clearer - I couldn't even understand the diff presented: what it was diffing, or why, or why it was an error, or how to fix it. > Thanks for providing that repro recipe. Unfortunately it's not > entirely accurate because using --dry-run prevents dgit from doing its > usual quilt fixup step. That means that the messages you get are > expected but not very helpful. 0.16 will have a new --damp-run mode > which is willing to make local changes, which will naturally produce a > more accurate transcript when things aren't working. That's a great idea. > I'm just about to finish up and push 0.16. Sweet! > The results of your attempts to manually fix things up for > bugs-everywhere aren't ideal. I don't know if the clone will work > after your package comes out of NEW. Could you let me know when it is > out of NEW and I'll check ? I will do my best to remember this. > If it doesn't work, I'd appreciate it if you'd give me your blessing > to upload an empty NMU (that is, an NMU with only a version number > bump) using dgit. This will allow me to check that the change I have > made in dgit 0.16 actually fixes your problem in your workflow, and > also make sure that the dgit-repos and archive have corresponding > contents. If this is OK, please let me know what version number I > should use for the upload. I subscribe to the "LowNMU" policy, but even without that, you have my full blessing. I believe a -1.0 suffix would be fine. > Alternatively, if you plan to make another upload yourself, with dgit, > then if we're lucky that will work. Awesome, I will let you know in any case. I suspect the package may have trouble getting through NEW, mainly because I feel I may have overlooked some things in the package, so I may very well have to do that upload again. :) Thanks for the great and quick followup! A. -- Antoine Beaupré +++ Réseau Koumbit Networks +++ +1.514.387.6262 #208 pgporblk3TuOX.pgp Description: PGP signature
Bug#688873: nomacs in Debian
Seem like I totally forgot about this package! Any progress here? Any way I can help? A. On 2012-09-28 10:57:12, Antoine Beaupré wrote: > On 2012-09-28, Stefan Fiel wrote: >> Hi, >> >> yes, you were right i was dealing with the hardening-no-relro warning >> if you just check out the svn (0.4.0 or trunk), debuild -us -uc then i >> get no warning or error from lentian (also when building this dsc with >> pbuilder). Don't know if this is a good way of checking packages. > > It's a great way! > > I still believe the fixes I suggested need to be applied if they haven't > been yet. > >> currently i don't use svn-buildpackage, wasn't aware of its existence >> when starting to make the first package for ubuntu :) Since we are >> planing to move to git in the next weeks/month I have not tried it with >> this. > > That's great! In this case I encourage you to take a look at > git-buildpackage. :) > > A. > > PS: regarding native vs non-native package, what I often do is that I > maintain a different repository for the debian meta-data. For example, > even though I am a maintainer in the Drush project, I chose to split out > the debian directory in a separate git repository because: > > a) it allows non-drush people to maintain the package > b) it makes it possible to maintain different *branches* for the > package (say stable and dev) and merge packaging changes between them > *without* merging stable in the upstream source code > c) it makes it easier for Ubuntu or other non-Debian people to make > changes to the package > > See the drush package here: > > http://git.debian.org/git/collab-maint/drush.git > > It also uses git-buildpackage. > > -- > Si Dieu existe, j'espère qu'Il a une excuse valable > - Daniel Pennac -- There has been only one Christian. They caught him and crucified him -- early. - Mark Twain pgpwYXweCLaUF.pgp Description: PGP signature
Bug#727307: segfaults after 3 days
Package: liquidsoap
Version: 1.0.1+repack1-1.1
Severity: normal
quidsoap[16658]: segfault at fffb ip 7f4c35df4a59 sp
7f4c2addd560 error 5 in libc-2.13.so[7f4c35d79000+18]
This happened after 3 days of continuously running, at the end of a
song, the stream just disappeared.
I couldn't find teh core dump, since liquidsoap seems to run with a CWD
of /, I assume it couldn't be written. I have attached a gdb process to
it to catch it when it crashes next time.
Here's a copy of my configuration:
#!/usr/bin/liquidsoap
# anarcat radio liquidsoap file.
# log to the logdir
# disabled while we test
set("log.file.path","/var/log/liquidsoap/anaradio.log")
# Listening icecast server settings
set("harbor.bind_addr","0.0.0.0")
# Store passwords in another configuration file,
# so that the main config can be safely version-controlled.
%include "passwords.liq.inc"
# checklist:
# 1. favorite playlist
# 2. random playlist
# 3. jingles playlist
# 4. manual playlist
#
# if 4, play it
# else play a weighted mix of 1,2,3
# 1. favorite playlist
favorites = playlist.safe(reload_mode="watch", '/srv/playlists/Favoris.m3u')
# 2. random playlist
shuffle = playlist('/srv/mp3')
# 2.1 incoming random playlist
incoming = playlist('/srv/incoming')
# play incoming one out of 15 times
shuffle = rotate(weights = [1, 15], [incoming, shuffle])
# 3. jingles playlist
jingles = playlist.safe(reload_mode="watch", '/srv/playlists/jingles.m3u')
# 3.1 strangelove
jingles = rotate(weights = [1, 10],
[playlist('/srv/playlists/strangelove.m3u'), jingles])
# play favorites roughly half the time, and jingles every 15 songs
radio = rotate(weights = [5, 10, 1], [favorites, shuffle, jingles])
# 4. manual / live input
# XXX: this introduces significant latency and overhead, would need to
# be replaced by an RTP multicast listener
live = input.harbor("radio.ogg",port=8001,password=pass)
# time-configurable crossfade
def crossfade(t,a,b)
add(normalize=false,
[ sequence([ blank(duration=t/2.),
fade.initial(duration=t,b) ]),
fade.final(duration=t,a) ])
end
# output live if available, fallback on radio
# we crossfade between the two, we could add jingles when switching, see also
# http://liquidsoap.fm/doc-svn/cookbook.html
output.icecast(%vorbis,
host = "localhost", port = 8000,
url = "http://anarc.at/services/radio";,
description = "Anarcat Radio!",
password = pass, mount = "radio.ogg",
fallback(track_sensitive=false,
transitions=[crossfade(5.),crossfade(3.)],
[live,radio]))
# XXX: missing RTP multicast output
-- System Information:
Debian Release: 7.2
APT prefers stable
APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages liquidsoap depends on:
ii adduser 3.113+nmu3
pn libc6
ii libcamomile-ocaml-data 0.8.4-2
ii libmagic1 5.11-2
ii libpcre31:8.30-5
ii perl5.14.2-21+deb7u1
ii sox 14.4.0-3
ii wget1.13.4-3
Versions of packages liquidsoap recommends:
ii liquidsoap-plugin-faad1.0.1+repack1-1.1
ii liquidsoap-plugin-flac1.0.1+repack1-1.1
ii liquidsoap-plugin-icecast 1.0.1+repack1-1.1
ii liquidsoap-plugin-lame1.0.1+repack1-1.1
ii liquidsoap-plugin-mad 1.0.1+repack1-1.1
ii liquidsoap-plugin-pulseaudio 1.0.1+repack1-1.1
ii liquidsoap-plugin-taglib 1.0.1+repack1-1.1
ii liquidsoap-plugin-voaacenc1.0.1+repack1-1.1
ii liquidsoap-plugin-vorbis 1.0.1+repack1-1.1
ii logrotate 3.8.1-4
ii mp3gain 1.5.2-r2-2
ii vorbis-tools 1.4.0-1
ii vorbisgain0.37-2
Versions of packages liquidsoap suggests:
ii festival 1:2.1~release-5.1
ii icecast2 2.3.2-9+deb7u2
ii liguidsoap 1.0.1+repack1-1.1
pn liquidsoap-plugin-samplerate
pn liquidsoap-plugin-xmlplaylist
ii mplayer2 [mplayer] 2.0-554-gf63dbad-1+b1
-- Configuration Files:
/etc/liquidsoap/radio.liq.example changed [not included]
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678727: package mostly done for nfsometer
Hi, I have done a first draft package here: Vcs-Git: git://git.debian.org/collab-maint/nfsometer.git Vcs-Browser: http://git.debian.org/?p=collab-maint/nfsometer.git;a=summary It seems to work, although I have yet to perform a full benchmark. One problem with the package is that it seems like the manpage doesn't generate properly. Other than that, it's probably ready for NEW. A. -- All cruelty springs from weakness. - Seneca the Younger pgpxYgDBJ9_eM.pgp Description: PGP signature
Bug#734753: RFP: poche -- self hostable read-it-later application
Package: wnpp Severity: wishlist * Package name: poche Version : 1.3.1 Upstream Author : Nicolas Lœuillet * URL : http://www.inthepoche.com/ * License : DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE Programming Lang: PHP Description : self hostable read-it-later application poche is a self hostable read-it-later app. Unlike to other services, poche is free and open source. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694744: working on the bugs-everywhere package
On 2013-10-20 19:36:17, Ben Finney wrote: > On 20-Oct-2013, anarcat wrote: > >> Ben, are you still interested in maintaining this package? Can I make a >> tentative upload to experimental? > > Following up on our IRC discussion: > > I have orphaned this package and am not interested in maintaining it. You > are welcome to adopt it, and you now have the VCS history for the packaging > work to date. > > Thank you very much for contacting me to confirm. Good hunting to you! Thanks! I have uploaded a package to NEW: https://ftp-master.debian.org/new/bugs-everywhere_1.1.1-1.html It's been sitting there for almost a month now, hopefully it will get unblocked soon. :) A. -- Quidquid latine dictum sit, altum sonatur. Whatever is said in Latin sounds profound. pgpfUR_NVUAdo.pgp Description: PGP signature
Bug#694744: working on the bugs-everywhere package
On 2013-11-12 18:11:01, Antoine Beaupré wrote: > On 2013-10-20 19:36:17, Ben Finney wrote: >> On 20-Oct-2013, anarcat wrote: >> >>> Ben, are you still interested in maintaining this package? Can I make a >>> tentative upload to experimental? >> >> Following up on our IRC discussion: >> >> I have orphaned this package and am not interested in maintaining it. You >> are welcome to adopt it, and you now have the VCS history for the packaging >> work to date. >> >> Thank you very much for contacting me to confirm. Good hunting to you! > > Thanks! > > I have uploaded a package to NEW: > > https://ftp-master.debian.org/new/bugs-everywhere_1.1.1-1.html > > It's been sitting there for almost a month now, hopefully it will get > unblocked soon. :) It was actually refused, because of unsource minified javascript files. I have now patched that to include the original files (and notified upstream) and we go back to the waiting game now. A. -- We should act only in such away that if everyone else acted as we do, we would accept the results. - Kant pgpFlQSrg9_iG.pgp Description: PGP signature
Bug#694744: Re-packing upstream source for Debian (was: working on the bugs-everywhere package)
On 2013-11-30 22:01:43, Ben Finney wrote: > On 30-Nov-2013, Antoine Beaupré wrote: >> It was actually refused, because of unsource minified javascript files. > > Right. I've been learning about that in some of my recent packages too. > > As a Debian package maintainer, we need to remove non-source (compiled, > obfuscated, etc.) files from the pristine source tarball and re-pack it to > a different tarball. Well, what I did was to actually ship the original source, instead of removing code. I did forget to change the version number however. :( A. -- Le péché est né avant la vertu, comme le moteur avant le frein. - Jean-Paul Sartre pgpmvbEy24CLd.pgp Description: PGP signature
Bug#731207: please add prettyping functionality
Package: oping Version: 1.6.2-1 Severity: wishlist File: /usr/bin/noping Tags: upstream Hi, I have implemented a significant improvement to the noping part of this package. The details are here: http://anarcat.koumbit.org/2013-12-03-announcing-prettier-noping And the code is here: git clone -b prettyping git://src.anarc.at/liboping To review the code, do: git diff liboping-1.6.2 I have contacted upstream about merging that code here, and I am waiting for his response, but I felt that since there's already another non-upstream, functionality patch in the package (the -Z option), I figured I would try my luck. Thanks for your consideration! A. -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages oping depends on: pn libc6 ii libncurses5 5.9-10 ii liboping01.6.2-1 ii libtinfo55.9-10 oping recommends no packages. oping suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738493: LWPx::ParanoidAgent still broken
Control: reopen -1
Control: notfixed -1 1.10-2
This is still broken:
anarcat@marcos:~$ dpkg -l liblwpx-paranoidagent-perl
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
|
État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ NomVersion Architecture Description
+++-==---=
ii liblwpx-parano 1.10-2 all a "paranoid" subclass of LWP::Use
anarcat@marcos:~$ PERL_LWP_SSL_CA_PATH=/etc/ssl/certs perl
-MLWPx::ParanoidAgent -e 'print
LWPx::ParanoidAgent->new->get("https://www.google.com";)->status_line'
500 Can't connect to www.google.com:443 (Net::SSL from Crypt-SSLeay can't
verify hostnames; either install IO::Socket::SSL or turn off verification by
setting the PERL_LWP_SSL_VERIFY_HOSTNAME environment variable to 0)
anarcat@marcos:~$ dpkg -l '*io-socket-ssl*'
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
|
État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ NomVersion Architecture Description
+++-==---=
ii libio-socket-s 1.992-1 all Perl module implementing object o
--
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place. - Douglas Adams (1952-2001)
pgpY6sc59ZNs4.pgp
Description: PGP signature
Bug#744306: ITP: bookie -- Python based delicious.com replacement
On 2014-04-12 16:01:39, Ana Guerrero Lopez wrote: > On Sat, Apr 12, 2014 at 03:48:00PM -0400, Tiago Bortoletto Vaz wrote: >> On Sat, Apr 12, 2014 at 09:17:26PM +0200, Jelmer Vernooij wrote: >> > Package: wnpp >> > Severity: wishlist >> > Owner: Jelmer Vernooij >> > >> > * Package name: bookie >> > Version : 0.0 >> > Upstream Author : Rick Harding >> > * URL : http://www.bmark.us/ >> > * License : AGPLv3 >> > Programming Lang: Python >> > Description : Self-hosted bookmark management service >> > >> > Bookie is a self-hosted bookmark management service. It supports >> > multiple users. Bookmarks can be created, tagged and managed through a >> > web service or a Chromium or Iceweasel extension. >> >> Nice one! So I think it's time to remove semanticscuttle from Debian >> (#659390). Also, scuttle package doesn't seem to be in good shape >> neither (#607068). I'm cc'ing this to interested people on this. > > Fully agreed. > I personally stopped using scuttle some months ago. I am still using semanticscuttle, but the package is basically dead, and I'm not upgrading my install right now. I'm considering switching to Zotero (as it unites with my book library management, #709925) or "poche" (https://www.wallabag.org/, #734753). I am not sure what bookie has more to offer than those two, which also allows me to save the content of the webpages for offline reading. Nevertheless, assuming that semanticscuttle is dead in Debian is correct right now. :) A. -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir - Lofofora pgpa3vAM0arxK.pgp Description: PGP signature
Bug#744404: LWPx::ParanoidAgent fails complaining about Mozilla::CA, which is not in Debian
Package: liblwpx-paranoidagent-perl
Version: 1.10-1
Severity: important
So this package's whole purpose is to verify X509 certificates.
Right now, it totally fails at doing that:
$ perl -e 'use LWPx::ParanoidAgent;
print $LWPx::ParanoidAgent::VERSION, " $] \n";
print LWPx::ParanoidAgent->new->get
("https://google.com/";)
->decoded_content, "\n";'
1.10 5.018002
500 Can't verify SSL peers without knowing which Certificate Authorities to
trust
This problem can be fixed by either setting the PERL_LWP_SSL_CA_FILE
envirionment variable or by installing the Mozilla::CA module.
To disable verification of SSL peers set the PERL_LWP_SSL_VERIFY_HOSTNAME
envirionment variable to 0. If you do this you can't be sure that you
communicate with the expected peer.
It would be great if we could just magically install (and this package
could depend on) the libmozilla-ca-perl package, unfortunately it's
not in Debian because it overlaps with the ca-certificates package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702124
I guess a workaround may be to install the package through CPAN...?
I have tried to use PERL_LWP_SSL_CA_PATH=/etc/ssl/certs, but then I
stumbled upon #738493.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages liblwpx-paranoidagent-perl depends on:
ii libcrypt-ssleay-perl 0.58-1+b1
ii libnet-dns-perl 0.68-1.2
ii libwww-perl 6.05-2
ii perl 5.18.2-2+b1
liblwpx-paranoidagent-perl recommends no packages.
liblwpx-paranoidagent-perl suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744866: allow system-wide configuration file
Package: redshift Version: 1.7-2 Severity: wishlist Redshift seems to use only ~/.config/redshift.conf which makes one-time configuration for all users of a set of workstation with a known location difficult. A. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages redshift depends on: ii gconf-service 3.2.6-2 ii libc6 2.18-4 ii libgconf-2-4 3.2.6-2 ii libglib2.0-0 2.38.2-5 ii libx11-6 2:1.6.2-1 ii libxcb-randr0 1.10-2 ii libxcb11.10-2 ii libxxf86vm11:1.1.3-1 redshift recommends no packages. redshift suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#663101: review of the upstream foreman debian package
Hi, I have tried the debian packages for foreman to consider inclusion in Debian. There is a lot of work to do. First off, the foreman-installer completely overwrites existing apache configuration files, which is contrary to Debian Policy, c. 7.6.1: http://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.1 Also, the underlying packages do not seem to cleanup properly after themselves: root@puppet0:/etc# apt-get purge foreman-postgresql foreman foreman-mysql2 Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : ruby-ansi ruby-clamp ruby-hashie ruby-kafo ruby-little-plugger ruby-logging ruby-multi-json ruby-powerbar ruby-rdoc Veuillez utiliser « apt-get autoremove » pour les supprimer. Les paquets suivants seront ENLEVÉS : foreman* foreman-mysql2* foreman-postgresql* 0 mis à jour, 0 nouvellement installés, 3 à enlever et 0 non mis à jour. 3 partiellement installés ou enlevés. Après cette opération, 46,5 Mo d'espace disque seront libérés. Souhaitez-vous continuer [O/n] ? (Lecture de la base de données... 46384 fichiers et répertoires déjàinstallés.) Suppression de foreman-postgresql ... Purge des fichiers de configuration de foreman-postgresql ... Suppression de foreman-mysql2 ... Purge des fichiers de configuration de foreman-mysql2 ... Suppression de foreman ... Purge des fichiers de configuration de foreman ... dpkg : avertissement : lors de la suppression de foreman, le répertoire « /usr/share/foreman » n'était pas vide, donc il n'a pas été supprimé pardon my french, but the last line says it can't remove the directory because it's not empty. this is a violation of Also, apt-get install foreman just fails: Setting up foreman (1.4.2-1) ... dpkg: error processing foreman (--configure): subprocess installed post-installation script returned error exit status 7 Errors were encountered while processing: foreman E: Sub-process /usr/bin/dpkg returned an error code (1) Enabling debugging shows me: /usr/sbin/foreman-rake db:migrate You have requested: rails = 3.2.17 The bundle currently has rails locked at 3.2.13. Try running `bundle update rails` Run `bundle install` to install missing gems. ... which basically means it will totally fail to install on wheezy, which still has rails 2.3. There's probably way more stuff i'm missing here. In this condition, it is quite unlikely that foreman can get in debian at all. Having it installable on a simple wheezy environment would be a start. I also strongly encourage you to run the package through "lintian" to make sure it's properly built. Looking forward to see Foreman in Debian... a. -- Men often become what they believe themselves to be. If I believe I cannot do something, it makes me incapable of doing it. But when I believe I can, then I acquire the ability to do it even if I didn't have it in the beginning. - Mahatma Gandhi pgpP4xsqr3sFE.pgp Description: PGP signature
Bug#663101: review of the upstream foreman debian package
On 2014-04-17 07:52:05, Greg Sutcliffe wrote: > Hi Antoine, > > I'm on vacation at the moment - I'll go through your email next week. Would > you mind if I cc'ed our dev mailing list? I see no reason not to... I don't see why not. A. -- Marijuana grows naturally on the planet. Mushrooms grows naturally on the planet. Don't you think making nature against the law is a bit... unnatural? - Bill Hicks pgpwfe8sB0WwX.pgp Description: PGP signature
Bug#657405: ITP: mediagoblin -- web application for sharing pictures and videos
On 2014-03-15 12:27:50, Simon Fondrie-Teitler wrote: > Hey, > > Sorry for the delayed response. No problem here. :) > anarcat writes: >> It seems like upstream fixed a bunch of those issues already, is that >> right? At least the mediagoblin/tests/test_submission/ seems fine to me. >> The extlib directory seems more tricky, but my guess is that you could >> just not ship what's in another debian package in the gmg binary >> package, and for the rest ship it until someone packages the goods. > > Upstream did fix the issues. I've cherry-picked the changes and applied > them to a dfsg-free version of 0.6.1. That's great. >> What are exactly the issues needing to be solved now? > > Right now I'm waiting on a review. I haven't thoroughly tested or looked at the package, but it looks fairly sane. I would say let's start with that and then others can probably join in to improve it. Getting it out of the WNPP queue would certainly help with that, in my opinion. One thing I keep thinking about, is that the stuff detailed in the README.Debian should probably be implemented as a postinst script: we could detect whether to configure nginx or apache, have a soft (recommends) dependency on psql (because we want to allow external db servers) and use dbconfig-common to configure that database. But again, this can be done later, shipping the code in a debian package is a good start. >> How are you communicating with upstream, are there bug reports? It would >> be helpful if you would cc this bug report in those communications to >> get an idea of the progress being made. :) > > There are bug reports. I'll make sure to CC this bug in the future. The > two tickets for the issues that I've referenced above are: > > https://issues.mediagoblin.org/ticket/847 > https://issues.mediagoblin.org/ticket/848 So it seems both tickets shouldn't be considered a show-stopper for inclusion in Debian. 847 has a patch and 848 should simply be included in the copyright file. I would say give it a try, just upload the package with the modifications to the copyright file and see where it leads us! A. -- Men often become what they believe themselves to be. If I believe I cannot do something, it makes me incapable of doing it. But when I believe I can, then I acquire the ability to do it even if I didn't have it in the beginning. - Mahatma Gandhi pgpuH88sEUjn9.pgp Description: PGP signature
Bug#745570: fails to display
Package: stellarium Version: 0.12.4-1 Severity: grave Stellarium just doesn't startup. A window pops up, but it is blank and just sits there doing nothing. -s or -f no do not help. anarcat@marcos:~$ stellarium -s Using default graphics system specified at build time: raster User config directory does not exist: "/home/anarcat/.stellarium" Creating directory "/home/anarcat/.stellarium" --- [ This is Stellarium 0.12.4 - http://www.stellarium.org ] [ Copyright (C) 2000-2013 Fabien Chereau et al ] --- Writing log file to: "/home/anarcat/.stellarium/log.txt" File search paths: 0 . "/home/anarcat/.stellarium" 1 . "/usr/share/stellarium" Config file "/home/anarcat/.stellarium/config.ini" does not exist. Copying the default file. Config file is: "/home/anarcat/.stellarium/config.ini" Going to initialize the OpenGL 2 renderer OpenGL supported version: "2.1 Mesa 10.1.0" Qt GL paint engine is: "OpenGL" StelQGL2Renderer::init : Failed because Qt paint engine is not OpenGL2 If paint engine is OpenGL3 or higher, this code needs to be updated Failed to initialize the OpenGL 2 renderer, falling back to the OpenGL 1 renderer OpenGL supported version: "2.1 Mesa 10.1.0" Qt GL paint engine is: "OpenGL" GL vendor is "Intel Open Source Technology Center" GL renderer is "Mesa DRI Intel(R) G41 " [hang] result: https://i5.minus.com/i9COPkyRTkp7b.png i tried moving my .stellarium aside, no luck. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages stellarium depends on: ii libc6 2.18-4 ii libgcc1 1:4.8.2-16 ii libgl1-mesa-glx [libgl1] 10.1.0-5 ii libglu1-mesa [libglu1]9.0.0-2 ii libice6 2:1.0.8-2 ii libqt4-network4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-opengl 4:4.8.5+git242-g0315971+dfsg-2 ii libqt4-script 4:4.8.5+git242-g0315971+dfsg-2 ii libqtcore44:4.8.5+git242-g0315971+dfsg-2 ii libqtgui4 4:4.8.5+git242-g0315971+dfsg-2 ii libsm62:1.2.1-2 ii libstdc++64.8.2-16 ii libx11-6 2:1.6.2-1 ii libxext6 2:1.3.2-1 ii stellarium-data 0.12.4-1 ii zlib1g1:1.2.8.dfsg-1 stellarium recommends no packages. stellarium suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
