You are not logged in.

#1 2017-02-19 13:23:03

Head_on_a_Stick
Moderator
From: London
Registered: 2015-09-29
Posts: 7,383
Website

obmenu in BunsenLabs, package version is too new

The version of obmenu in the BunsenLabs repostories is 1.0-5:

https://www.bunsenlabs.org/repoidx.html … gen-obmenu

The package is actually available in jessie:

https://packages.debian.org/search?keyw … ection=all

I'm not sure why we have it in the BL repository as well but the stretch version is 1.0-4 and this will cause a `dist-upgrade` to fail because of the lower version number:

https://forums.bunsenlabs.org/viewtopic … 419#p45419

Is there a specific reason why we have obmenu in the BL repositories when it is also available from Debian?

I think perhaps we should remove it and rely on the Debian package instead.


"The first principle is that you must not fool yourself - and you are the easiest person to fool" — Richard Feynman

Forum Rules   •   How to report a problem   •   bunsenlabs(7)

Offline

#2 2017-02-19 15:13:55

twoion
ほやほや
Registered: 2015-08-10
Posts: 1,895
Website

Re: obmenu in BunsenLabs, package version is too new

Does not have anything to do with the version number but the dependency python-support, which is gone in stretch.

Not sure why there is an extra obmenu package: maybe there was a reason? It comes from #! times. It is unmaintained anyway and I'd be glad to see it gone from at least helium.

Besides,

python-support transition

    python-support has been deprecated, but it is still widely used

    Packages (build-)depending on python-support

    Transition bugs

    Lintian tag

https://wiki.debian.org/Python/StretchRoadmap.


Where time just endlessly spins…

Online

#3 2017-02-19 15:35:49

damo
....moderator....
Registered: 2015-08-20
Posts: 4,169

Re: obmenu in BunsenLabs, package version is too new

twoion wrote:

Does not have anything to do with the version number but the dependency python-support, which is gone in stretch.

Not sure why there is an extra obmenu package: maybe there was a reason? It comes from #! times. It is unmaintained anyway and I'd be glad to see it gone from at least helium.

AFAICS you packaged it as architecture-independant...

changelog wrote:

obmenu (1.0-5) bunsen-hydrogen; urgency=medium

  * Build architecture-independent package.


Be Excellent to Each Other...

FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#4 2017-02-19 16:42:15

twoion
ほやほや
Registered: 2015-08-10
Posts: 1,895
Website

Re: obmenu in BunsenLabs, package version is too new

damo wrote:
twoion wrote:

Does not have anything to do with the version number but the dependency python-support, which is gone in stretch.

Not sure why there is an extra obmenu package: maybe there was a reason? It comes from #! times. It is unmaintained anyway and I'd be glad to see it gone from at least helium.

AFAICS you packaged it as architecture-independant...

changelog wrote:

obmenu (1.0-5) bunsen-hydrogen; urgency=medium

  * Build architecture-independent package.

If it was that trivial: we already have architecture-dependant packages anyway (yad) one more or less doesn't matter. Let's switch to the jessie/stretch package then?

That leaves just to somehow facilitate this downgrade using a bunsen-* package, or leave it as it is and just remove python-support from the equation, e.g. re-package and re-write if needed. I'll be looking at this next week.


Where time just endlessly spins…

Online

#5 2017-02-20 01:22:17

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: obmenu in BunsenLabs, package version is too new

No, no there was a reason Philip patched obmenu - the standard version doesn't work.  tongue

It doesn't support the current standard for commands

                <action name="Execute">
                    <command>
                        somecommand
                    </command>
                </action>

but only the old <execute>...</execute>
The #!/BL version actually outputs a message to that effect on installation - something about depreciated (sic) syntax.

The Stretch version has gone from 1.0-2 to 1.0-4 but we'd have to look at the code to see if the bug has been fixed. The changelog doesn't mention it so I'm not optimistic.
EDIT: since the version number is still lower than 1.0-5 I'm inclined to think the BL package was probably patched from the sid version of that time, implying the bug still existed with 1.0-4.

I don't suppose doing another patch of the Stretch version would be too hard, twoion? It looks as if the python dependencies need tweaking. The Stretch version is built differently, but should automatically resolve the python dependencies problem.

EDIT2: Just had a look at the package contents and in fact 1.0-4 on Stretch is quite different in its structure from ours. The command bug has not been fixed though. It's on line 210 of obxml.py:

		exe = self.dom.createElement("execute")

should be:

		exe = self.dom.createElement("command")

The files themselves are in different directories when the package is built, and the Stretch package is built using dh_python2 as opposed to dh_pysupport on ours.

I have no idea why our version was set to 1.0-5. The changelog, though, says that the shift to dh_python was done in 2015 with 1.0-2+nmu2. 1.0-4 only arrived this January!

Anyway, maybe we (er, twoion) can patch obmenu 1.0-4 and release it when we have a Helium repo, as 1.0-4+bl1 or something?

Last edited by johnraff (2017-02-20 02:47:17)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#6 2017-03-17 22:36:56

damo
....moderator....
Registered: 2015-08-20
Posts: 4,169

Re: obmenu in BunsenLabs, package version is too new

Doing a diff on the stretch and patched bunsen obmenu sources, shows 4 places where "command" should replace "execute":

Lines 120,210,259,266

I built a patched version (depends python-all-dev), and confirm that it works fine on a BL stretch installation smile

I never use it though - editing menu.xml seems easier!


Be Excellent to Each Other...

FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#7 2017-11-28 06:55:53

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: obmenu in BunsenLabs, package version is too new

I've revisited this issue as Helium must be released soon, and spent some time poking round the source code of the debian Stretch and BL Hydrogen versions.

The version numbering has got out of sync, because Corenominal, when he patched 1.0-2 on 01 Oct 2012, pushed the version to 1.0-3. (Upstream has stayed at 1.0 the whole time, so all the version bumps are to the "Debian" part, after the hyphen.)
Now, if he had chosen 1.0-2+cb1, or even 1.0-2.1, then the next Debian version jump (after 1.0-2+nmu1 and 1.0-2+nmu2) to 1.0-3 on 19 Jan 2017 would not have clashed.

Subsequent #! and BL upgrades took our version to 1.0-5 while Debian are now at 1.0-4 but the two packages' contents have diverged, and the debian package has some improvements we should also be shipping.

Right now, I'm going to try applying the same patch Corenominal used for the <execute>/<command> fix to the Debian 1.0-4 package, and push the version to 1.0-4+bl1.

@2ion You edited the Architecture field in debian/control from "any" to "all" to allow a single package for all architectures. I don't think you changed anything else - is that correct?

I'll attempt to merge in everyone's contributions in the new debian/changelog and debian/copyright so it makes some kind of sense...

EDIT:

Here's the suggested debian directory: https://drive.google.com/open?id=1TxcyW … D-lebJOj_7

Applied to the original obmenu.tar.gz, builds this .deb file: https://drive.google.com/open?id=17HKiW … bW0UspjYjV
Installed in a virtual Helium system it seems to be doing the job OK.

The version number is above the Debian Stretch package, so will install by default.
The only snag is that it is below the BunsenLabs Hydrogen version, so a dist-upgrade from Hydrogen to Helium will not bring it in automatically. I don't think that's a major problem, though.

Especially @twoion does this look OK? If so, I'll push the binary out to the helium-dev repo.
Also @twoion is there a git repo of the BL obmenu? If so I can perhaps start a new branch on it. Otherwise I'll make a new repo on GitHub.

Last edited by johnraff (2017-11-28 08:13:33)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#8 2017-11-28 07:37:33

cloverskull
Member
Registered: 2015-10-01
Posts: 193

Re: obmenu in BunsenLabs, package version is too new

Hey johnraff, I'm curious. What type of bugs should one expect to see using obmenu from stretch on a helium netinstall? I manually installed stretch's obmenu and everything feels like I would expect.

Offline

#9 2017-11-29 02:40:39

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 3,409
Website

Re: obmenu in BunsenLabs, package version is too new

cloverskull wrote:

What type of bugs should one expect to see using obmenu from stretch on a helium netinstall? I manually installed stretch's obmenu and everything feels like I would expect.

johnraff wrote:

It doesn't support the current standard for commands

                <action name="Execute">
                    <command>
                        somecommand
                    </command>
                </action>

but only the old <execute>...</execute>

So it will write menus using the old syntax - which is still supported so not an issue - but will also fail to read correctly "execute" entries written with the new, approved, syntax.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

Board footer

Powered by FluxBB